ソフトウェアテストの基礎:テストプロセス

Pocket

テストプロセスの各工程とその作業内容、各作業における注意点等について学習します。
前回はソフトウェアテストを扱う際の心得ということで、まずソフトウェアテストの7原則について紹介しました。これらの心得をしっかりと念に置いたうえで、テストの基礎について学習していきましょう。さて、一般的に「テスト」というと、対象となるシステムを打鍵しながら結果を確認する「テスト実行」を意味することが多いと思います。しかし、実際には他にもテストに関する作業はさまざまあります。今回はテストにどのような作業があり、それをどういう順番で実施していくべきか、すなわち「テストプロセス」について紹介します。

1. テストプロセスの概要

ISTQBのテストプロセスにおける定義は、以下5つの活動で構成されています。

  • テスト計画作業とコントロール
  • テストの分析と設計
  • テストの実装と実行
  • 終了基準の評価とレポート
  • 終了作業

今回はこれらの活動について解説をしますが、以下の表にあるように、8つの作業に分割、および言い換えをして話を進めていきます。

ISTQBでの作業名 本記事での作業名
テスト計画作業とコントロール テスト計画
テスト管理
テストの分析と設計 テスト分析
テスト設計
テストの実装と実行 テスト実装
テスト実行
終了基準の評価とレポート 終了判定
終了作業 終了作業

そして、これらの作業は、以下の図のような順序で実施されます。

まず、テストの作業全体をどのような方針で実施していくかを計画します。そして、その方針に基づいてテストの分析、設計、実装、実行を進めます。これらの作業が最初に立てた計画通りに進んでいるかどうかをチェック、コントロールするのがテスト管理です。そしてテスト実行が完了したら、結果を確認しテスト作業を終了してよいかどうかの判定を行い、最後に終了作業を実施します。

2. テスト作業の詳細

では、前節で簡単にふれた各テスト作業について、もう少し詳しく説明していきましょう。

  • 2.1. テスト計画
    • テスト計画では、テストのスコープや目的を明確にし、その後のテスト作業の方針や体制、スケジュールなどを策定します。作業の方針を検討する際は、入力成果物と出力成果物も合わせて考えるとよいですが、場合によっては十分な入力成果物が要件定義や設計の段階で作成されていないこともあり得ます。体制やスケジュールを決定する際には、そういった開発の状況も考慮した上で作業量を見積もる必要があります。テスト作業の終了基準もこの段階で策定します。
  • 2.2. テスト管理
    • テスト管理では、テスト計画以降の作業が策定した通りに実施できているかどうかを確認し、問題がある場合はその状況に対するアクションを行います。テスト分析からテスト実装までの作業については主に進捗管理が中心になりますが、テスト実行の段階では実際にテスト対象のバグを発見するため、バグの発見状況のモニタリングと、それに対するアクション、すなわち品質管理も実施します。
  • 2.3. テスト分析
    • テスト分析では、テストベース(テストケースを作成する際にインプットとなる成果物)を整理し、これらからテストすべき条件や要件、さらにはそれを実現するテストケースの作成方針(どのテスト技法を使うか、など)を決定します。テスト計画の際にもふれましたが、テストベースが不足している、テストベースの品質が悪い、といった状況も考えられるので、必要に応じて成果物の作成やレビューも実施する必要があります。
  • 2.4. テスト設計
    • テスト設計では、分析で洗い出した条件や要件を満たすような具体的なテストケースを作成します。このときテスト(設計)技法を用いて、抜けもれや重複のないテストケースを作成することが望ましいです。テスト技法にはさまざまなものがありここでは扱いきれないため、次回以降の記事で紹介します。また、テストケースを作成する際には、操作や期待結果だけではなく、実行するためにはどのような環境や事前条件が必要か、なども明らかにしておく必要があります。
  • 2.5. テスト実装
    • テスト実装では、設計で作成したテストケースを元に、実際に実行するための具体的な手順を作成します。また、手順と合わせて想定した振る舞いを発生させるためのデータや、実行を自動化する場合は、テストスクリプトもこの作業の中で作成します。テストの自動化についても語るべき項目が多いためここでは割愛しますが、データやスクリプトの作成も、ソースコードと同様に構成管理をしながら作業を進めることが望ましいです。
  • 2.6. テスト実行
    • テスト実行では、実装で作成した手順に従ってシステムを操作し、期待した振る舞いをするかどうかを確認します。期待通りにいかない場合は、キャプチャなどの証跡を残してインシデントとして報告します。また、そのインシデントの原因分析も合わせて実施します。原因の特定、修正が完了したら、発見元のテストケースを再度実行し修正されたかどうかを確認します。またその際、修正の影響を分析した上で、影響箇所については関連する他のテストケースも再度実行する(回帰テスト)必要があります。
  • 2.7. 終了判定
    • 終了判定では、テスト実行の結果などを分析し、作業を終了して次に進んでよいかどうかを判定します。分析対象は、例えばバグの検出状況などがあげられます。判定基準はテスト計画で策定したものを利用します。ただし、基準に満たなかったからといって即座に作業をやり直すのではなく、計画の段階で予期できなかった妥当な理由がある場合には、終了と判断します。そうでない場合は、必要に応じて追加テストなどのアクションを実行します。これらの判断過程や結果を開発者以外のステークホルダと共有する場合は、内容をレポートとしてまとめた上で共有を行います。
  • 2.8. 終了作業
    • 終了作業は、判定を通った後の作業の最終確認や今後の活動へのフィードバックを実施する作業です。計画通りに成果物が作成されているか、未対応のインシデントレポートはないか、あるとしたら今後の対応方針は決まっているか、などを確認し、最終レポートを作成します。また、作成したテスト資材は今後再利用できるものもあるはずなので、それらの整理や再利用のための文書化を行います。以上がテストプロセスを構成する8つのテストの作業に関する説明となります。特に前半のテスト分析やテスト設計などは、なじみのない方も多いかもしれません。今までやっていなかった作業が増えると工数も増えてしまうと感じられるかもしれませんが、これらをきちんと実施することでテストの漏れや無駄がなくなり、テストプロセス全体ではむしろ作業工数は減ると筆者は考えています。ぜひとも取り入れられる部分から取り入れてみて下さい。各作業についてより詳細に知りたい方は、ぜひISTQBのシラバスや教科書などを参考にしてみて下さい。

参考文献:
テスト技術者資格制度 Foundation Level シラバス 日本語版
© International Software Testing Qualifications Board VER2011
© 日本語翻訳版Japan Software Testing Qualifications Board Version 2011.J02, ソフトウェアテスト標準用語集(日本語版)Version 2.0.J02 (2011年04月19日)
International Software Testing Qualifications Board 用語集作業班

執筆者プロフィール  みけねこ

某IT企業勤務。入社以来B2B、B2C系のWebシステムの開発やテストに従事。現在は社内の開発支援ツールの開発や、テスト工程も含めた標準開発プロセスの整備を担当。興味のある分野は振る舞い駆動開発とテストコードの自動生成。

コメントは受け付けていません。


<お知らせ>

2015年7月3日
iOS8.4がご利用いただけます(30分無料利用キャンペーン中)
2015年6月18日
キャリア各社のAndroid 5.0へのアップデート情報とバージョンアップの注意点
2015年6月10日
株式会社スクウェア・エニックス様のRemote TestKit導入事例を掲載しました
2015年6月3日
「Android M Developer Preview」インストール済みのNexus5,6,9端末をRemote TestKitで無料体験いただけます!
2015年6月2日
「Android M Developer Preview」のインストール方法解説
2015年4月27日
Remote testKitを使ってノマド実機テスト(AndroidStudioとRemote TestKit連携)
2015年3月26日
Remote TestKitでXcodeとの連携が可能になりました
> Remote TestKit Topページへ