【ソフトウェアテスト】デシジョンテーブルテスト
さまざまな入力値が想定されており、それぞれの入力値を統合した結果として複数の状態を返すようなシステム仕様に対しては、デシジョンテーブルテスト技法を用いることで、複雑な条件を整理することができます。サービス利用時に新規アカウントを作成するような場面で、ユーザー情報を入力して登録する機能を想定した場合、[名前(ローマ字)][よみがな][任意のパスワード][パスワード確認入力][年齢][住所]などを入力し、それらの入力値が全て正常であれば登録処理を進めて、入力値のうち1つでも正常ではない値が入力されている場合は、エラーメッセージを表示して再度入力を促すようなシステムがあります。対象のステータスによって期間限定のサービス適用有無を判定するようなシステムでも、サービス対象となるかどうかを複数条件から判定するような仕様が想定されます。5年以上サービスを利用していて、アカウントの利用者ランクがゴールド以上の場合、商品購入時の金額から5%をサービス固有ポイントとして還元するというイベントを、n年n月n日～n年n月n日まで開催するといった追加開発システムのテストをする際に、デシジョンテーブルによってテスト対象を適切に抽出できます。
テスト(運用・保守・サポート)
【ソフトウェアテスト】ドメイン分析テスト
同値分割法/境界値分析については他の記事で記載しましたが、ドメイン分析テストも境界値を用いてテストします。このテスト方法は、関係性のある複数の変数について、入力データの有効範囲にフォーカスしてテストをする手法です。同値分割法/境界値分析では、一つの機能に関して境界がいくつか設定されていて、各境界の前後でそれぞれ動作が変わるような仕様に対してパーティションを分けてテストしていましたが、そのような数値による境界をもつ機能がいくつか関連して複数結果に分かれるような仕様のケースでは、ドメイン分析テスト技法が使用できます。ゲームのダメージ計算式で、与えた最終ダメージ数値に応じてクリティカル倍率をかけた数値を上乗せするといった場合に、元となるダメージ数値がいくつか、相手の防御数値がいくつか、数値いくつ以上でクリティカル倍率は何倍が適用されるか、各数値には有効・無効となる境界があり、かつ最終の数値ごとに複数のクリティカル倍率が用意されているといった仕様があったときに、ドメイン分析テストによって必要なテストケースを洗い出すことができます。
テスト(運用・保守・サポート)
【ソフトウェアテスト】ユースケーステスト
ユースケース(use case)テストとは、システム開発要件や機能仕様などのテスト対象に対して利用者サイドから想定しうるテスト対象の使用状況や相互の作用をユースケースとしてシナリオを想定することで、対象の利用に際して問題がないかを主軸にしてテストを行う手法です。シナリオを想定してテストを行うため、シナリオテストと混同されやすいですが、シナリオテストと比較してテスト対象や目的やテストの粒度など違う部分があるので、ユースケーステストとシナリオテストはそれぞれ別の手法として、実施するテストケースに応じて使い分けが必要です。シナリオテストは主に特定の機能や操作の流れを一連のシナリオとしてテストするもので、対象となる仕様や要件のみならず、ストーリーとして関連が想定される動作や異常系処理などもテストスコープに含むため、ユーザーサイドの視点で対象に対して詳細なテストを実施しますが、ユースケーステストは、あくまで対象となる仕様や要件から想定されうるユーザーストーリーをテスト対象とする前提で、シナリオテストよりもテストスコープは狭くなると想定されます。また、記事内にて後述しますが、ユースケース図を用いていることもユースケーステストの特徴であり、シナリオを順序立てる記述形式はシナリオテストもユースケーステストも同様ですが、テストケースの整理や共有の方法によってテストケース自体をレビューできるため、静的テストのアプローチがしやすいテスト技法です。
テスト(運用・保守・サポート)
【ソフトウェアテスト】不具合報告のインシデントレポートについて
開発プロジェクトで発生した問題はインシデントとして、管理・分析・対応が必要です。プロジェクト全体を通しての問題となるとかなり範囲は広く、人的トラブルやステークホルダー間での問題など、開発しているプロダクト以外の問題も含んでしまうので、本記事では主にプロダクトのテストに関して検出された動作の不具合(バグ)に焦点を絞って記載します。プロダクトのテストに際して検出した不具合は、報告・対応したあとは蓄積データとして、引き続きプロジェクトで参照・活用されます。実際の開発現場によっては、早期レビューでのやりとりに関するものや、開発とテスターが口頭で連携できるような状況で報告即時対応できる程度の不具合対応など、状況により必ずしも定められたドキュメントの形式で報告されるものとは限りませんが、可能な限り検出対応した不具合は履歴を残しておくことで、プロダクトの品質向上を目指すことができます。ほとんどの場合は不具合管理に別途外部のbug tracking system（BTS）を使用しています。BTSはインシデントレポート1件をチケットという1単位で扱います。チケットの形式や内容が必ずしも同一の形式に沿っているというものではありませんが、不具合の報告管理をするチケットの内容は、管理運用の観点から記載が必要となる項目はある程度決まっています。余談ですが、BTSは不具合報告のみならず、チケット駆動開発 (TiDD) を実施するプロジェクトでは開発作業自体の管理進行目的で使用される場合もあります。
テスト(運用・保守・サポート)
【ソフトウェアテスト】レビューについて
ソフトウェアテスト領域には、動作させることを前提とした対象をテストする動的テストと、動作させることを前提としていない対象をテストする静的テストがあります。単体テストや結合テストなど、作成したものを動作させてテストをするのが動的テストですが、静的テストは動作させる対象がなくてもテストが実施できます。静的テスト活動の種類としてレビューがありますが、開発活動の中で作成された製品やシステム自体以外のものは、レビュー対象としてテストすることが可能です。
テスト(運用・保守・サポート)
【ソフトウェアテスト】エラー推測テスト
エラー推測テストは経験ベーステストの一種です。最も単純な表現をするならば、「どうすればエラーが発生するか」を想像して試行し、エラーを再現させることを目的としたテストの手法です。
テスト(運用・保守・サポート)
【ソフトウェアテスト】シナリオテスト
シナリオテストはユーザー視点で利用場面を想定し、操作フロー、入力値、発生する正常系挙動異常系挙動など、ユーザーが利用する一連の流れを想定したうえで発生しうるストーリーを元にテストを実施する手法です。ブラックボックステスト技法はさまざまあり、あくまで無数に存在しうるテストケースから粒度や対象を整理抽出してより広く浅いテストケースを目指すようなものがほとんどです。しかし、複数機能をもつシステムを実際に利用する際には、複数回の遷移を繰り返したりシステムが何重にも関連したりするので、1つの機能を対象としたテストや、2つ3つの機能間の関連をテストしただけでは、再現し得ないような組み合わせでの不具合が発生する懸念は常にあります。フリーチェックやモンキーチェックなどと呼ばれるものも、結局は「ユーザーなら再現しうる」可能性を想定して実行するものですが、それを数値や手順を明確にしてより詳細にテストし、かつ明示することでその内容をテストの履歴としたり、テストの要件自体もレビューなどで評価対象とできることがこのシナリオテスト手法の利点と考えられます。また、ユーザーのストーリーを元にテストするという点から、よりユーザーサイドでの視点から評価できるため、単純に欠陥を検出するのみならず、UI/UXの評価検討なども実施することができます。
テスト(運用・保守・サポート)
【ソフトウェアテスト】QC7つ道具と新QC7つ道具 ①
生産の分野における管理手法に関して、各種データの分析に使用する代表的な7種類の手法が、QC7つ道具と呼ばれています。もともとは工業系生産などの製造現場における品質に関して、顧客信頼度を高めたり現場の問題解決に取り組むための視点として、品質管理の思考が波及しました。そのことから、管理の手法を明示化することで、手法を用いて誰でも品質管理に取り組むことができるようになることを目的としてさまざまな手法が作成されました。それらの中でも特に代表的なものがQC7つ道具と呼ばれるようになりました。ソサエティー5.0が提唱されている現代において、市場や製造現場におけるソフトウェア関連開発業務の割合は増えています。ITの基本資格でもある基本情報技術者試験のストラテジ系領域の内容にもQC7つ道具に関する問題が含まれており、ソフトウェア開発現場におけるQC(Quality Control)活動においても、QC7つ道具の利用される場面は増えています。QC7つ道具は主に、数値などの定量的分析が可能なデータを取り扱う分析の際に用いられる手法です。定性的な事象の分析に用いるような手法は新QC7つ道具として別でまとめられています。※以降に記載する図の中でも定性的事象分析に使用できる図はあるため、QC7つ道具が必ずしも定量的分析にしか使用しないものというわけではありません。
テスト(運用・保守・サポート)
システムテストについて
システムテストとはシステム開発の一環として行われるテスト手法の一つで、「総合テスト」とも呼ばれています。システム開発の最終段階で行われることが多く、実際に使用される状況と同じ設定でテストを行います。システムテストでは、開発したシステムが期待通りに動作するか、構築したシステムが仕様書通りの機能や性能要件を満たしているかについて検証します。実際の使用状況を想定して、本番と同じ環境で多角的にテストを行うことで、開発環境ではわからないバグや不具合を発見するのに役立ちます。さらに、システムの一部だけではなくシステム全体を俯瞰して、ハードウェアも含めたテストが実施されるため、ハードウェアの環境に関連する不具合も検出できます。システムテストが行われるのは、プログラムや機能ごとの確認を行う単体テストや、プログラムを結合してバグがないかを確認する結合テストを終えた、開発の最終段階です。納品前に全体を通したテストを行うことでシステムの品質を確保し、クライアントに引き渡したあとに残存するリスクをできるだけ減らすことができます。
初心者
関連タグ
カテゴリ別人気記事
もっと見るテレワーク関連人気記事
2023年10月02日
製造・コーディング(PG/フロントエンド)2023年07月18日
アーキテクト・技術選定(PG/バックエンド)2023年10月26日
テスト(運用・保守・サポート)2023年11月17日
学習・スキル2023年01月09日
詳細設計(内部設計)(インフラ)
週間人気記事
もっと見る【これからJP1に触れる人向け】JP1とは
開発プロジェクトに携わる際にJP1というツールに触れたことはあるだろうか。JP1は開発工程、特にテスト作業においては非常に利便性の高いツールである。この記事ではまだJP1に触れたことがない人向けにJP1の概要やJP1を合う買う際に知っておくべき用語を取り上げる。
テスト(運用・保守・サポート)
【初心者必見】Python独学を通し、プログラミング入門についてまとめてみた
とあるきっかけからPythonに関心を持ちまして、手探りですが勉強をしてみました。 まだ入り口に片足踏み込んだ程度ですが、プログラミング初心者にとってはその難しい「一歩」の助けになればと思い、記事にしました。 当記事では、ざっくりと ・使用した教材、感じた利点 ・学習のコツ、簡単に応用力を伸ばしていける工夫 について、書いていきます。 プログラミング学習のコツについても解説していくので、Python初心者に留まらず、プログラミング自体が初めての方にも参考になると思います。 ※注意点！ ・本記事は、あくまで学習方法、コツについての解説です。Pythonって何？ どうコーディングすればいいの？ といった点に触れたものではありません。 ・本記事における学習ラインは、タイトルに「入門編」と書いた通り、変数の概念や条件分岐や繰り返し文といった初歩の初歩までです。機械学習やデータ分析といったディープな部分までを補完しうるものではありません。
製造・コーディング(PG/バックエンド)
【ソフトウェアテスト】直交表/ペアワイズ法 ①
本記事では直交表について記載します。さまざまな資料を調べて情報をまとめているうちに、直交表、ペアワイズ、HAYST法はそれぞれ直交表を元に関連しているようだと思ったので、直交表から順を追って記載していこうと思います。しかし、それぞれが個別の手法として確立しており、その手法を使用するシーンも違うことから、記事としては独立させたほうが適切かと思ったので、まずは直交表についてまとめたのち、続いて別の記事でペアワイズ法をまとめていきます。
テスト(運用・保守・サポート)
【初心者向け】Packet Tracerでネットワークを学ぶ（NAT）
NATとはNetwork Address Translationの略称でIPアドレスを変換する技術です。 インターネットに接続する際にプライベートIPアドレスをグローバルIPアドレスに変換します。
詳細設計(内部設計)(インフラ)