テストのプロセスの全体像

はじめに

この記事では、テストのプロセスについての知識を整理しています。

テストの目的

7つの目的(JSTQBをもとに筆者が修正)

• 要件、ユーザーストーリー、設計、コードなどの成果物を評価する。欠陥が発見されたら修正する。それにより、ソフトウェアの欠陥を防ぐ。
• ソフトウェアが定義された全ての要件を満たしていることを検証する(検証)。
• ソフトウェアが完成したことを確認し、ユーザーやその他ステークホルダーの期待通りに動作することを確認する(妥当性確認)。
• ソフトウェアの品質が「大丈夫そうだ」という確認を集める。それを、ソフトウェアの品質が所定のレベルにあるという証拠にする。
• 欠陥や故障を発見し、ソフトウェアの品質がマズくなるリスクレベルを軽減する。
• ステークホルダーが意思決定をする際に参照する情報を提供する。その情報とは、特にテスト対象の品質レベルについて。
• 契約上、法律上、または規制上の要件や標準を遵守する、またはソフトウェアがそのような要件や標準に準拠していることを検証する。

ここではわかりやすさのために、システムテストを想定してテストの目的を記述しました。具体的には、主語が「ソフトウェア」としています。ですが、原文は「テスト対象」でした。テストタイプごとに、テスト対象は異なるため、そのようなハイレベルな単語が使われているのかもしれません。そのため、単体、結合テストを想定した場合の目的は、主語を「コンポーネント」「結合コンポーネント」などに置き換えるのが正確でしょう。

ソフトウェア開発プロセスの中でのテストの進め方

プロセスの種類

V字プロセス

ウォーターフォール型の開発プロセスをベースにする。
ここでは、テストのフェーズは開発が完了した後に開始される。

W字プロセス

V字プロセスの内、開発完了前から開始できるタスクは先に開始するプロセス。
メリット：テストの設計によって、実際の設計で見過ごされるシナリオを見つけ、設計に取り込める。

プロセスの詳細

• 計画

• 分析

• 設計

• 実装

• 実行

• 完了

• これらのプロセスと並行して、
  テストの進行に対するモニタリングとコントロールが行われる

計画のタスク

• テストの目的を定義する
• 目的を達成するための方法を抽象的なレベルで定義する
  例えば、スケジュールやコスト、テストの進捗を評価するためのメトリクスを定義する
• テスト計画書のテンプレートの例
  ISO/IEC/IEEE 29119-3:2021 Part 3: Test documentation

モニタリングとコントロールのタスク

• モニタリング、つまりメトリクスを用いてテストの進捗を評価する。
• 進捗が遅れるなどしていたら、コントロールする。つまり実際の進捗が計画に追いつくよう措置をとる。

分析のタスク

• 何をテストするのかを定義する。定義する際は複数の水準を考える。

  • 何をテストするか？(コード?ハードウェア間の接続？サービスが提供する価値?)

  • どの観点でテストするか？(処理が仕様通りか?性能が十分か?ユーザーにとっての使い勝手が十分か？)

  • テストする観点について参考になる資料：
    ISO/IEC 25000:2014Systems and software Quality Requirements and Evaluation (SQuaRE)

設計のタスク

• どうテストするのかを定義する。より具体的に何を検証するのかを定義し、ハイレベルなテストケースを作成する。テストがシステムのどんな機能と対応しているかが分かるように決める。
  例：ショッピングサイトなら、「商品をお気に入りボタンを押すとお気に入りリストに登録される」「ギフトコードを入力したらショッピングで使えるポイントが登録される」
• ただし値を定義するまで具体的にはしない。

実装のタスク

• 設計で定義したハイレベルなテストケースを実行可能なレベルまで具体化する。
  例：「リンゴという商品のお気に入りボタンを押すと、お気に入りリストに登録される」「123456というギフトコードを入力したら、ショッピングで使える1000ポイントが登録される。」
• テスト環境を準備する。
• テストを実行し、その結果を得るためのテスト手順を定義する。
• テストを実行するためのスクリプトを作成する。
• テストに必要なデータを作成する。

実行のタスク

• テストを実行する。
• 実行結果を記録する。
• 実際の結果と期待される結果の比較をする。
• 故障が発見された場合は分析し、欠陥を特定する。その後ソフトウェアを修正し、再テストする。

完了のタスク

• テストの完了条件を満たしたか確認する。
• テスト環境やテストデータを次回のテストに再利用できるよう整理する。
• テストプロセスを振り返り、教訓を得る。

以上がテストプロセスでした。
次はこのプロセス内で作成される成果物を見ていきます。

テストプロセスの成果物

• テスト計画

• テスト要求

  • 何をテストすべきかを示した情報

• テストケース

• テストスイート

  • 何かの基準でテストケースをグルーピングしたもの

• テストデータ

  • テスト実行時に使用するデータ。例：アカウント登録時に入力するダミーユーザーの生年月日のデータ

• テスト環境

• テストスクリプト

  • テストケースの内容を実行するための具体的な操作や作業の指示
    例：
    1.商品ボタンを押し、商品紹介ページに遷移する
    2.商品をかごに入れるボタンを押す
    3.かごボタンを押してかご内の商品一覧を表示する

• テスト実行結果

• 以上の成果物間の関係
  

成果物の指す内容はISTQB用語集とUML Testing Profileの間でさえ異なっています。そのため、プロジェクト内でも言葉の指す内容がメンバー間でずれていないか、確認するのが良いでしょう。

テストプロセス内のRoleとResponsibility

• テスト依頼元
  • テスト要求を出す人。テストプロセスの成果物、結果をレビューする。
• テストマネージャー
  • テストの目的を達成できるよう、現場のモニタリングやコントロールを行う。
• テストリーダー
  • テストプロセスの活動の一部をリードし、状況をテストマネージャーに報告する。
• テスト設計者
  • テストの目的を達成するためのテスト設計と、テスト実装を行う。
• テスト実施者
  • テスト環境を構築し、テストを実行し、結果をテストリーダーに報告する。
• テスト自動化技術者
  • テストの自動化の仕組みを設計、実装する。運用と保守をする。

(ただし、プロジェクトごと定義するので普遍的にこうとは限らない)

おまけのポエム

自分のこの一年の仕事を振り返って文字にして保存しておきたいというモチベで
アドベントカレンダーを書きました。

2023年は上記のロールでいうテスト設計者を担当しました。
作成した成果物はテストケースとテストデータでした。

アサイン当初はテストプロセスの全体像が見えておらず、
自分のタスクの前後に何が控えているのか謎でした。
そして蓋を開けてみたら、テストにもたくさんステップがありました。
語彙がないとカオスなプロジェクトにおいて自分のタスクの役割を理解するにも困難でした。
この一年で、自分で無から物を見る枠組みを構築できるほど賢くはなかったと確認されました。
なので、概念を勉強していきたいです。もちろんプロジェクトの見方を固定化するのもよろしくないでしょうが、
私は守破離の守から始めるのが良いと思いました。

また、図を書く時にはdraw.ioというウェブアプリがオススメ。
無料で便利。

参考資料

『土台からしっかり学ぶーーソフトウェアテストのセオリー』
『JSTQB Foundation 第4版: ソフトウェアテスト教科書 シラバス2018対応』