超(個人)訳JSTQB Foundation Level シラバス Part5

はじめに

今回はテスト活動に関するシラバスを読解していく。

引用元について

テーマにある通り、ISTQBが提供するFoundation Levelシラバスを引用させて頂く。

1.4 テスト活動、テストウェア、そして役割

テストはコンテキスト次第である。しかし、ハイレベルでは、テスト目的を達成する確率を高くする、汎用的なテスト活動のセットというものが複数ある。これらテスト活動のセットがテストプロセスを構成する。テストプロセスは、多くの要因を考慮して特定の状況に対する適切な調整ができる。テストプロセスの中で、どのテスト活動を、どのように、いつ実施するかは、通常、特定の状況に対するテスト計画の一部として決定する（5.1 節参照）。
以降の節では、テストプロセスの一般的な側面を、テスト活動やタスク、コンテキストの影響、テストウェア、テストベースとテストウェア間のトレーサビリティ、テストの役割の観点から説明する。ISO/IEC/IEEE 29119-2 標準には、テストプロセスのより詳細な情報が記載されている。

これからの章で語ることの説明なので、飛ばします。

1.4.1 テスト活動とタスク

テストプロセスは多くの場合、以下に説明する主な活動のグループから構成される。これらの活動の多くは論理的にはシーケンシャルに行われるように見えるが、イテレーティブにまたは並行して実施されることが多い。これらのテスト活動は、通常、システムやプロジェクトに合わせて調整する必要がある。

テストにも開発と同様に工程が存在し、段取りに沿って進めるものもあれば、並行して進めていくこともあり、それらは取り扱うシステムやプロジェクトに合わせて変わる、ということである。以降でテストの活動の概要を説明していく。

テスト計画は、テスト目的を定義することと、その後に全体のコンテキストにより課せられた制約下に
おいて目的を最も効果的に達成するアプローチを選択することから構成される。テスト計画について
は、5.1 節でさらに説明する。

テストはいきなり実行せず、計画を立てるところから始める。
テストの計画を立てることで、テストを行う目的やどういうアプローチでテストを進めるかについての段取りを決めていく。

テスト分析は、テストベースを分析して、テスト可能なフィーチャーを識別し、関連するテスト条件を定義して優先順位を付けるとともに、関連するリスクとリスクレベルを分析することを含む（5.2 節参
照）。テストベースとテスト対象を評価し、それらに含まれている可能性のある欠陥を識別したり、試験性のアセスメントをしたりする。テスト分析では、多くの場合、この活動を支援するためにテスト技法を使用する(第 4 章を参照)。テスト分析では、計測可能なカバレッジ基準から見て「何をテストするか？」という問いに答えている。

テスト分析というと小難しそうに聞こえるかもしれないが、こんなことをしている。

• テスト実施に必要な開発文書や要件に関する情報を集める(要件定義書、基本設計書等)
• テスト対象に潜むリスクが可視化し、リスクが顕在化した時の影響を考慮する
• テストを実施するための条件を整理する
• リスクを考慮したうえで、どのテストを優先して行うかを判断する

テスト設計は、テスト条件をテストケースやその他のテストウェア（テストチャーターなど）に落とし込む作業を含む。この活動には、多くの場合、テストケースの入力を指定するためのガイドとして機能するカバレッジアイテムの識別が含まれる。テスト設計では、この活動を支援するために、テスト技法（第 4 章を参照）が使用できる。テスト設計には、テストデータ要件の定義、テスト環境の設計、およびその他の必要なインフラストラクチャとツールの識別も含まれる。テスト設計では、「どのようにテストするか?」という問いに答えている。

テスト分析で整理した条件をベースに、テストケースへ落とし込むフェーズがテスト設計である。
テスト設計では、どのようにテストを行うかを実現するためにテスト技法を駆使する。
また、テストで使用するデータや環境、ツール等の情報をまとめることもこの工程に含まれる。

テスト実装は、テスト実行に必要なテストウェア（例えば、テストデータ）の作成または取得を含む。テストケースはテストプロシジャーに編成でき、多くの場合、テストスイートにまとめる。手動および自動のテストスクリプトを作成する。テストプロシジャーは、効率的なテスト実行のために、テスト実行スケジュール内で優先順位を付けて配置する（5.1.5 項を参照）。テスト環境を構築し、正しく設定されていることを検証する。

このフェーズではテスト設計でまとめた情報から、テスト実行に必要なデータを作ったり、テスト実行のスケジュール作成やテスト環境の動作確認を行う。
これらは実際にテストする時に、効率よくテストを進められるための事前準備に当てはまる。

テスト実行は、テスト実行スケジュールに従ってテストを走らせること（テストラン）を含む。テスト実行は、手動でも自動でもかまわない。テスト実行には、継続的テストやペアテストセッションなど、さまざまな形式がある。実際のテスト結果は、期待結果と比較する。テスト結果を記録する。不正を分析して、考えられる原因を識別する。この分析により、観察された故障に基づいて不正を報告することができる（5.5 節を参照）。

手動テストや自動テストをを行うフェーズであり、テストで期待すべき結果に対して、実際の動作を比較してその結果を記録していく。期待結果と動作が一致すれば問題ないが、一致しなかった時は不正の線を疑ってみる。テスト内容に問題がないかや、投入したデータに問題がないかを精査した上で、テスト実行側で準備した要素に問題がなければ、不正をステークホルダーへ報告する。
シラバス上では不正と言っているが、実務では不正より不具合とかの方がよく聞く。
(実務上バグとも言っているところもあるが、シラバス上では欠陥を指す言葉でもあり、紛らわしいのであえて触れないでおく)

テスト完了の活動は、通常、プロジェクトのマイルストーン（リリース、イテレーションの終了、テストレベルの完了など）で、未解決の欠陥、変更要求、または作成したプロダクトバックログアイテムに対して行う。将来役立つ可能性のあるテストウェアをすべて識別し、保管するか、適切なチームへ引き渡す。テスト環境は合意した状態でシャットダウンする。将来のイテレーション、リリース、またはプロジェクトに向けて、教訓と改善点を識別するために、テスト活動を分析する（2.1.6 項を参照）。テスト完了レポートを作成して、ステークホルダーへ伝える。

シラバスで示すマイルストン到達次第により、テストが終わり次第、継続的に役立つ見込みのあるテストウェアを整理・保管した上で、必要に応じて適切なチームへ引き継ぐ。
また、次のプロジェクトに向けての良かった点や改善点を洗い出し、それらをレポートの形でステークホルダーへ報告する。

1.4.2 コンテキストに応じたテストプロセス

テストは、単独で行うことはない。テスト活動は、組織内で行われる開発プロセスに不可欠な要素である。また、テストはステークホルダーによって資金提供され、その最終ゴールは、ステークホルダーのビジネスニーズの充足を支援することである。したがって、テストを行う方法は、以下のようないくつかのコンテキストに応じた要因に依存する：

• チームメンバー（スキル、知識、経験レベル、空き状況、トレーニングの必要性など）。
• ビジネスドメイン（テスト対象の重要性、識別したリスク、市場ニーズ、特定の法的規制な
  ど）。
• 技術的要因（ソフトウェアの種類、プロダクトのアーキテクチャー、利用技術など）。
• プロジェクトの制約（スコープ、時間、予算、リソースなど）。
• 組織的要因（組織構造、現行のポリシー、使用する実践例など）。
• ソフトウェア開発ライフサイクル（エンジニアリングの実践例、開発手法など）。
• ツール（利用可能な状況、使用性、標準適合性など）。
  これらの要因は、利用するテスト戦略、テスト技法、テスト自動化の度合い、求められるカバレッジの
  度合い、テストドキュメントの詳細度合い、レポート作業などを含む、テストに関する多くの事柄に影
  響を与える。

これまでテストプロセスと各過程における活動内容について触れてきたが、テストを行うに当たり、シラバスで列挙している様々な状況に応じて実施方法が変化する。
例えば、人的リソースが少ない時と多い時、ツールの利用状況、テスト期間等の要因が絡み、テストのスケジュールの引き方がいくらでも変わってくる。
テストを担当する人や組織は、こうしたソフトウェア開発を取り巻く状況からステークホルダーのニーズを汲み取った上で、最適なテストプロセスを検討し、選択しなければならない。

おわりに

1.4章を全て取り扱うとやや長くなりそうなので、次回で続きを扱う。