テストアナリストのレビュー

本記事の概要

本記事は、JSTQBテストアナリスト シラバスのレビューのセクションの要約です。

目的

• テストアナリストはレビューで意見を言う。
• レビューで欠陥をあぶり出し、除去することで、後続のプロセス(例えば、設計、実装、テスト）での欠陥を防げる。
  それゆえ、納品時の品質を高めるためにコスパの良い手段である。

方法

• チェックリスト
  例：ドキュメントが一意に定まること、「未定」「TBD」と記される部分がないこと、書式が適切であること、など。

適用範囲

• 要件や仕様のドキュメント　例：ユースケース、要件書、ユーザーストーリー
• 全てのレビューで使うことも、一部の品質特性、ドキュメントのみに絞ることもできる。
• テスト担当者のスキルセット
• 特定のリスクの可能性と影響度。例：セーフティクリティカルなシステムの場合
• 特定のテスト技法。例：デシジョンテーブルで提示される規則など

チェックリストレビューのメリット

• チェックリストを使うことで、検証すべき具体的なポイントを意識できる。
• 属人的なレビューを避けられる。
• 問題を発見することを支援する。さらに、チェックリストでカバーできていない項目について議論できる。

使い方

• 複数のチェックリストを組み合わせて使うことも可能。

要件レビュー

チェックリストの例

1. 要件を提示したステークホルダー(人、部署)
2. 各要件がテスト可能かどうか
3. 各要件の優先順位がついているか
4. 各要件の受け入れ基準は定義されているか
5. ユースケースの実現に必要な呼び出しの仕組みの可用性
6. 各要件/ユースケース/ユーザーストーリーに対し、一意な識別子はあるか
7. 各要件/ユースケース/ユーザーストーリーに対し、バージョンは定義されているか
8. ビジネスの要件と、システム要件の間のトレーサビリティは確立されているか
9. 要件とユースケースの間のトレーサビリティが確立されているか(あれば)
10. 使われている用語に一貫性があるか(用語集の使用など)

• テスト不可能な要件は、欠陥のある要件だとみなすべきである。
  例：「ユーザーにやさしいエラー表示をする」という要件
• もしも品質特性に関する標準ドキュメントを参照しているならば、その標準とテストケースの間のトレーサビリティも確立すべきである。というのも、標準が変更された際に、テストケースも変更する必要があるためである。
• 合格・不合格を判断できるテストを作れない要件も、欠陥のある要件である。
  例：「永久に可用性100%であること」、という要件はテストを作れない。いつまで試せばよいか不明だからである。

ユースケースレビュー

チェックリストの例

1. システムの振る舞いは明確に定義されているか？
2. 全ての代替シナリオは洗い出されており、エラー処理も定義されているか？
3. ユーザーインターフェースに表示されるメッセージは定義されているか。
4. メインな振る舞いは1つだけか?
5. それぞれのシステムの振る舞いはテスト可能か？

ユーザーストーリーのレビュー

• ユーザーストーリーとユースケースの違い
  ユースケースは複数の機能を含むユーザーのトランザクションである。一方ユーザーストーリーはより独立した機能である。

• チェックリストの例

1. ストーリーのイテレーションorスプリントへの割り当ては適切か
2. ストーリーはユーザーの目線で記述されているか
3. 受け入れ基準は定義されているか？
4. 機能は明確に定義されており、他と区別できるか？
5. ストーリーは他のストーリーに依存していないか？
6. ストーリーに優先度が割り当てられているか？
7. ストーリーは一般的に使用される形式を守っているか？
   (形式：<>として<>をしたい。なぜなら<>だから)

チェックリストのテーラリング

チェックリストをテーラーリング/アレンジする必要性が発生する要因

• 組織のポリシー、標準、慣習
• 法的制約
• プロジェクトの取り組み (例：重点項目)
• レビュー対象の作業成果物の種類。コードレビューはプログラミング言語ごとにアレンジするのが望ましい
• レビュー対象の作業成果物のリスクの可能性と影響度。例：ミッションクリティカルなシステムならば綿密にチェックするのが望ましい
• 使用するテスト技法

参考資料

ISTQB®テスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト
Version 3.1.1.J03