テスト戦略ハンドブック / Test Strategy Handbook

Created by @PaulHolland_TWN ( https://twitter.com/PaulHolland_TWN )
Translated by @nihonbuson ( https://twitter.com/nihonbuson )

Agile Testing Days 2019でのチュートリアル "Test Strategy Workshop" でいただいた資料を日本語に翻訳しました。
https://agiletestingdays.com/

Transcript

1. テスト戦略 ハンドブック Paul Holland (訳：ブロッコリー)
2. 目次 望ましい結果…3 テスト戦略…4 コンテキストを理解する（BUTT）…5 ヒューリスティックテスト戦略モデル…10 • プロジェクト環境(MIDTESTD)…11 • 製品要素(SFDIPOT)…20 • 品質基準(CRISP DUCCS)…28 • テスト技術(FDSFSCURA)…39
3. 望ましい結果 テスト戦略は次の結果を達成するために試みるべきです • どのような問題を解決するかを推進する。「なぜこれを行うのです か？」に答えられるようにする。 • プロジェクトのマイルストーンと決定に影響を与える。 • レポートのサポートをする。以下のものを伝える。 ◦ テストするもの ◦ テストしたもの ◦ テストしなかったもの • テスターとアジャイルチームの共通理解を高める。 • コードを書く前にテストを開始する。 • 統合テストを計画する。 • 説明責任を促進する。
4. テスト戦略 はじめに、コンテキストを理解することから始めます。 プロジェクト/製品/リリースの次の側面を理解しましょう。(BUTT) • ビジネスドライバー(Business driver) • 使用法(Usage) • 技術(Technology) • チーム(Team) その後、リスクとテストの必要性を理解するのに役立つ「Product Coverage Outlines(PCO)」を作成するために、ヒューリスティックテスト 戦略モデルを使用しましょう。 下記のようなパターンがあります。（後ほど紹介します） • MIDTESTD • SFDIPOT • CRISP DUCCS (STAMPL) • FDFSCURA これら4つは、James BachとMichael Boltonが作成した”Rapid Software Testing”が出典です。
5. コンテキストを理解する(BUTT) BUTTは以下の4つからなる記憶術です。 • Business Drivers • Usage • Technology • Team これは、コンテキストを判断するのに役立つ「MIDTESTD」という記憶術 を補完するためのものです。 ヒューリスティックテスト戦略モデルの記憶術に加えて、BUTTを考慮す る必要があります。コンテキストを理解するために必要な情報が分から ない場合は、探す必要があります。 「分からない」と言うことを恐れないでください。 チームによって作られた仮定と決定になる質問として 「もし…だったら？」があります。 状況に対する理解を図にしてチームに示してください。 その際に修正/コメントを貰ってください。 Created by Paul Holland
6. ビジネスドライバー (Business Drivers) • クライアントは誰ですか？ • 製品はクライアントにとってどのような問題を解決しますか？ • 製品が解決されるとする他の問題（間違った使い方）は何ですか？ • 製品はお客様にどのような価値を提供しますか？ • 内部および外部の顧客の考えにある製品のイメージは何ですか？ • 契約、罰則、またはその他の法的義務はありますか？ • 競合他社は（現在もしくは将来）ありますか？ • これはどのくらいのビジネスチャンスですか？ • なぜこの製品が構築されているのですか？なぜ今なのですか？ • 市場の力とプロジェクトの推進力について知っていますか？
7. 使用法(Usage) • さまざまなタイプのユーザー（知っている人、ペルソナ）、さまざまな ニーズ、さまざまな感情、さまざまな状況は何ですか？ • 彼らはどのように製品を使用しますか？（シナリオ） • 彼らはどのように製品を誤用しますか？ • 「良い」ユーザーは間違って何をするのでしょうか？ • 悪意のあるユーザーは何をしようとしますか？ • 製品の使用パターンは何ですか？ • 新しいテスト方法につながるような変更はありますか？ • 現在の状況で、他にテスト対象に影響するものは何ですか？ • エンドユーザー、プリセールス、販売、マーケティング、コンサルタン ト、サポート担当者にインタビューし、顧客のニーズについてさらに 理解する • 彼らが好きなものと嫌いなもの、製品の隣で何をするのかを見つけ ましょう。
8. 技術(Technology) 問題のある領域や問題が発生する傾向があるものを理解するために、 ソフトウェアが動作するテクノロジーの内部動作を理解するための質問 をしてください アーキテクチャ • 仮定に挑戦する • 他の製品や機能との相互作用を理解する • データの依存関係（ソース） • データ出力 • 製品を流れるデータ • 他の製品/機能/システムへの依存関係は何ですか？ • 製品に依存している他の製品/機能/システムは何ですか？ プラットフォーム • 製品の言語は何ですか？ • 製品で使用しているライブラリ/gems/プロシージャ/オープンソース コードは何ですか？ • どのサーバーとサービスが使用されていますか？ ◦ ロードバランサー、スプーラー、ネットワークデバイスなど • プロジェクトの自動化戦略は何ですか？ • 利用可能なツールは何ですか？
9. チーム(Team) あなたのチームについて • あなたのチームには誰がいますか？ ◦ 彼らの役割は何ですか？ ◦ 彼らはあなたにどんなドキュメントを期待していますか？ • どのチームとやり取りする必要がありますか？ ◦ 彼らの役割と責任は何ですか？ ◦ 彼らはあなたが誰であり、あなたが彼らに何を期待しているかを知っています か？ • プロジェクトとその人々には、どの長所と短所がありますか？ • これらの項目に対して一連のテストアイデアをマッピングできるよう にするためのプロジェクトの技術的負債は何ですか？ • 開発者に、コードのどの部分を改善したいのか尋ねてください。 • 開発者はどの機能で問題を抱えていますか？ 他のチームについて • 知っておく必要のある習慣や伝統はありますか？ • 文化の違いと、それがあなたとあなたの仕事にどのような影響を与 えるかを知っていますか？ • あなたの利害関係者は誰ですか？ • 利害関係者が本当に心配していることは何ですか？ • 他の利害関係者は誰ですか？ • 他の人によってテストされているものは何ですか？
10. ヒューリスティックテスト戦略モデル ヒューリスティックテスト戦略モデルは、James BachとMichael Boltonが 作成した”Rapid Software Testing”が出典となっている、テスト戦略を設 計するための一連のパターンです。 プロジェクト環境には、テストを有効化または妨害する可能性のあるプロ ジェクト内のリソース、制約、およびその他の要素が含まれています。テ スターは制約に挑戦しなければならないこともあれば、受け入れることも あります。 製品要素は、テストする予定の要素です。ソフトウェアは複雑で目に見え ません。見やすい部分だけでなく、重要なすべてをカバーするように注 意してください。 品質基準は、テスターとして製品に問題があるかどうかを判断できる ルール、値、およびソースです。品質基準は多次元であり、多くの場合、 隠されているか、矛盾しています。 テスト技術は、テストを作成するためのヒューリスティックです。すべての 手法には、プロジェクト環境、製品要素、および品質基準の何らかの分 析が含まれます。 知覚品質はテストの結果です。ソフトウェア製品の「実際の」品質を知る ことはできませんが、さまざまなテストを適用することで、情報に基づい た評価を行うことができます。今回、詳しい紹介はしません。
11. プロジェクト環境(MIDTESTD) テストの作成と実行は、テストプロジェクトの中心です。ただし、プロジェ クト環境には、作成する特定のテストについての決定に不可欠な多くの 要因があります。以下の各カテゴリで、その要因がテスト設計プロセスを どのように支援または妨害するかを検討してください。すべてのリソース を活用してください。 • ミッション(Mission) • 情報(Information) • 開発者との関係(Developer Relations) • テストチーム(Test Team) • 機器とツール(Equipment & Tools) • スケジュール(Schedule) • テスト項目(Test Items) • 成果物(Deliverables) James BachとMichael Boltonが作成した”Rapid Software Testing”が 出典です。
12. プロジェクト環境(MIDTESTD) ミッション(Mission) • 顧客が誰であるか知っていますか？誰の意見が重要ですか？誰 があなたの仕事の恩恵を受けていますか？ • このプロジェクトで顧客があなたに何を期待しているか知っていま すか？同意しますか？ • 顧客は、どのテストを作成して実行するかについて強力なアイデア を持っているかもしれません。 • たぶん、彼らは相反する期待を持っています。それらを特定して解 決する必要があります。
13. プロジェクト環境(MIDTESTD) 情報(Information) • このプロジェクトについて学ぶために誰と相談できますか？ • 利用可能なエンジニアリング文書はありますか？ユーザーマニュア ル？ウェブベースの資料？仕様？ユーザーストーリー？ • この製品には歴史がありますか？修正または延期された古い問題 はありますか？顧客の苦情のパターンはありますか？ • あなたの情報は最新ですか？新しい情報または変化する情報につ いてどのように通知されますか？ • 重要な情報を収集できる同等の製品やプロジェクトはありますか？
14. プロジェクト環境(MIDTESTD) 開発者との関係(Developer Relations) • 傲慢：開発チームは、製品のあらゆる側面について自信過剰に見 えますか？ • 防御性：開発者がテストしたことに奇妙に反対していると思われる 製品の部分はありますか？ • 関係性：プログラマーと友好的な関係を築いていますか？ • フィードバックループ：プログラマーとオンデマンドですばやく通信で きますか？ • フィードバック：開発者はテスト戦略をどう考えていますか？
15. プロジェクト環境(MIDTESTD) テストチーム(Test Team) • 誰がテストするのか知っていますか？実施するのに十分な人がい ますか？ • 「テストチーム」に参加していない人がいますか？似たような製品を 以前にテストしたことがある人はアドバイスをしますか？それは描 いた人ですか？ユーザーですか？プログラマーですか？ • チームが実行する特別なスキルや動機を持っている特定のテスト 手法はありますか？ • トレーニングは必要ですか？利用可能ですか？ • 誰か同じ場所にいますか？タイムゾーンは問題になりますか？
16. プロジェクト環境(MIDTESTD) 機器とツール(Equipment & Tools) • ハードウェア：テストを実行するために必要な機器はすべて揃って いますか？セットアップして準備はできていますか？ • 自動化：テストツールは必要ですか？それらは利用可能ですか？ • 調査：テスト対象製品の観察を支援するために必要なツールはあり ますか？ • マトリックスとチェックリスト：テストの進捗を追跡または記録するた めに必要な文書はありますか？
17. プロジェクト環境(MIDTESTD) スケジュール(Schedule) • テスト設計：どれくらい時間がありますか？後ほど作成する方が早 いテストよりも良いテストはありますか？ • テスト実行：テストはいつ実行されますか？回帰などのために、いく つかのテストが繰り返し実行されていますか？ • 開発：テスト、追加された機能、コード凍結などのために、いつビル ドが利用可能になりますか？ • ドキュメント：ユーザードキュメントはいつレビューできるようになりま すか？
18. プロジェクト環境(MIDTESTD) テスト項目(Test Items) • 範囲：製品のどの部分がテスト責任の範囲内にあり、どの部分がそ うでないか？ • 可用性：テストする製品はありますか？利用可能なテストプラット フォームはありますか？新しいビルドはいつ入手できますか？ • 揮発性：製品は常に変化していますか？再テストの必要性は何で すか？ • 新しいもの：最近製品に変更または追加されたものは何ですか？ • テスト容易性：製品は機能的で信頼性が高く、効果的にテストでき ますか？ • 将来のリリース：将来の製品リリースに適用するために、テストのど の部分を設計する必要がありますか？
19. プロジェクト環境(MIDTESTD) 成果物(Deliverables) • 内容：どのようなレポートを作成する必要がありますか？作業メモを 共有しますか、それとも最終結果のみを共有しますか？ • 目的：成果物は製品の一部として提供されていますか？他の誰か があなたのテストを実行する必要がありますか？ • 標準：従うことになっている特定のテスト文書標準はありますか？ • メディア：レポートをどのように記録して伝えますか？
20. 製品要素(SFDIPOT) 最終的に製品は、顧客に提供されるエクスペリエンスまたはソリューショ ンです。製品には多くの側面があります。したがって、適切にテストする には、これらの重要性を調べる必要があります。以下にリストされている 各カテゴリは、製品の重要かつユニークな側面を表しています。 これらのいくつかにのみ焦点を当てるテスターは、重要なバグを見逃し がちです。 • 構造(Structure) • 関数(Function) • データ(Data) • インタフェース(Interface) • プラットフォーム(Platform) • 操作(Operations) • 時間(Time) James BachとMichael Boltonが作成した”Rapid Software Testing”が 出典です。
21. 製品要素(SFDIPOT) 構造(Structure) • コード：実行可能ファイルから個々のルーチンまで、製品を構成する コード構造。 • ハードウェア：製品に不可欠なハードウェアコンポーネント。 • 非実行可能ファイル：マルチメディアまたはプログラム以外のファイ ル（テキストファイル、サンプルデータ、ヘルプファイルなど）。 • 担保：紙の文書、Webリンクとコンテンツ、パッケージ、ライセンス契 約など、製品の一部でもあるソフトウェアとハ ードウェアを超えたも の
22. 製品要素(SFDIPOT) 関数(Function) • アプリケーション：製品を定義または区別する機能、またはコア要件 を満たす機能。 • 計算：算術関数または他の関数に埋め込まれた算術演算。 • 時間関連：タイムアウト設定。日次または月末レポート。夜間のバッ チジョブ。時間帯。休業日。利息計算。条件と保証期間。クロノグラ フ機能。 • 変換：何かを変更または変換する機能（フォントの設定、クリップ アートの挿入、アカウントからのお金の引き出しなど）。 • 起動/シャットダウン：呼び出しと初期化、および製品の終了のため の各メソッドとインターフェース。 • マルチメディア：サウンド、ビットマップ、ビデオ、または製品に埋め 込まれたグラフィック表示。 • エラー処理：すべてのエラーメッセージを含む、エラーを検出して回 復する機能。 • 相互作用：製品内の機能間の相互作用。 • テスト容易性：診断、ログファイル、アサート、テストメニューなど、製 品のテストに役立つ機能が提供されます。 • 失敗モード：「what-if」質問をして、内部/外部、予想/予想外、（意図 しない）、現実的/挑発的な障害の処理を公開するテストのアイデア を生成します。 • システムのフォールトトレランスに挑戦します。すべてのオブジェクト またはコンポーネントが破損する可能性があります。
23. 製品要素(SFDIPOT) データ(Data) 意図的および意図的でないデータを特定し、依存関係を悪用し、多くの 場所でデータを調べます。 • 入力：製品によって処理されるデータ。 • 出力：製品による処理から生じるデータ。 • プリセット：製品の一部として提供される、または事前に作成された データベース、デフォルト値など、製品に組み込まれているデータ。 • 永続的：内部に保存され、複数の操作で永続化されると予想される データ。これには、オプション設定、表示モード、ドキュメントの内容 など、製品のモードまたは状態が含まれます。 • シーケンス/組み合わせ：単語の順序、並べ替えられたデータと並 べ替えられていないデータ、テストの順序など、データの順序また は順列。 • カーディナリティ：オブジェクトまたはフィールドの数は異なる場合が あります（例：0、1、多く、最大、オープン制限）。一部は一意である 必要があります（データベースキーなど）。 • ビッグ/リトル：データのサイズと集計のバリエーション。 • ノイズ：無効であるか、破損している、または制御されていないか不 正な方法で生成されたデータまたは状態。 • ライフサイクル：データエンティティが作成、アクセス、変更、および 削除される際のデータエンティティの存続期間にわたる変換。
24. 製品要素(SFDIPOT) インタフェース(Interface) • ユーザーインターフェイス：ユーザーとのデータ交換を仲介する要 素（たとえば、ディスプレイ、ボタン、フィールド、物理または仮想）。 • システムインターフェース：他のプログラム、ハードディスク、ネット ワークなど、ユーザー以外のものとのインターフェース • API / SDK：この製品を使用した新しいアプリケーションの開発を可 能にすることを目的とした、プログラムによるインターフェースまた はツール。 • インポート/エクスポート：別の製品で使用するためにデータをパッ ケージ化する機能、または別の製品からのデータを解釈する機能。
25. 製品要素(SFDIPOT) プラットフォーム(Platform) • 外部ハードウェア：出荷製品の一部ではないが、製品が機能するた めに必要な（またはオプションの）ハードウェアコンポーネントと構成 ：システム、サーバー、メモリ、キーボード、クラウド。 • 外部ソフトウェア：出荷製品の一部ではないが、製品が動作するた めに必須（またはオプション）であるソフトウェアコンポーネントと構 成：オペレーティングシステム、同時実行アプリケーション、ドライ バー、フォントなど • 内部コンポーネント：製品に組み込まれているがプロジェクトの外部 で作成されたライブラリおよびその他のコンポーネント。
26. 製品要素(SFDIPOT) 操作(Operations) • ユーザー：さまざまな種類のユーザーの属性。 • 環境：ノイズ、光、注意散漫などの要素を含む、製品が動作する物 理的環境。 • 一般的な用途：製品が通常遭遇する入力のパターンとシーケンス。 これはユーザーによって異なります。 • 不利な使用：無知な、誤った、不注意な、または悪意のある使用に よって生成された入力のパターン。 • 極端な使用：製品の意図された使用と一致する挑戦的なパターンと 入力のシーケンス。
27. 製品要素(SFDIPOT) 時間(Time) • 入力/出力：入力が提供されるとき、出力が作成されるとき、および それらの間のタイミング関係（遅延、間隔など）。 • 高速/低速：「高速」または「低速」入力によるテスト。最速および最 遅。高速と低速の組み合わせ。 • レートの変更：スピードアップとスローダウン（スパイク、バースト、ハ ング、ボトルネック、中断）。 • 同時実行性：複数の事柄が同時に発生します（マルチユーザー、タ イムシェアリング、スレッド、セマフォ、共有データ）。
28. 品質基準(CRISP DUCCS) 品質基準は、製品がどうあるべきかを定義する要件です。さまざまな種 類の基準について考えることにより、重要な問題を迅速に発見するテス トをより適切に計画できるようになります。このリストの各項目は、潜在 的なリスク領域と考えることができます。 以下の各項目について、それがプロジェクトにとって重要であるかどうか を判断し、その点で製品がうまく機能したか、うまく機能しなかったかをど のように認識するかを考えてください。 • 能力(Capability) • 信頼性(Reliability) • インストール性(Installability) • 拡張性(Scalability) • 性能(Performance) • 開発(Development) • 使いやすさ(Usability) • カリスマ(Charisma) • 適合性(Compatibility) • セキュリティ(Security) James BachとMichael Boltonが作成した”Rapid Software Testing”が 出典です。
29. 機能(Capability) 必要な機能を実行できますか？ 品質基準(CRISP DUCCS)
30. 品質基準(CRISP DUCCS) 信頼性(Reliability) 製品は適切に機能し、必要なすべての状況で障害に耐えますか？ • 堅牢性：製品は、合理的な条件下で、劣化することなく長期間機能 し続けます。 • エラー処理：製品はエラーの場合に障害に耐え、障害が発生しても 優雅であり、すぐに回復します。 • データの整合性：システム内のデータは、損失または破損から保護 されます。 • 安全性：製品は、生命や財産に損害を与えるような方法で故障する ことはありません。
31. 品質基準(CRISP DUCCS) インストール性(Installability) • システム要件：必要なコンポーネントが欠落しているか不足している 場合、製品は認識しますか？ • 構成：システムのどの部分がインストールの影響を受けますかファ イルとリソースはどこに保存されますか？ • アンインストール：製品をアンインストールするときに、きれいに削除 されますか？ • アップグレード/パッチ：新しいモジュールまたはバージョンを簡単に 追加できますか？既存の構成を尊重しますか？ • 管理：インストールは特別な人員が処理するプロセスですか、それ とも特別なスケジュールですか？
32. スケーラビリティ(Scalability) 製品の展開はどの程度うまくスケールアップまたはダウンしますか？ 品質基準(CRISP DUCCS)
33. 品質基準(CRISP DUCCS) パフォーマンス(Performance) それはどれほど迅速で敏感ですか？
34. 品質基準(CRISP DUCCS) 開発(Development) どのくらいうまく作成、テスト、修正できますか？ STMPLを考えると良いでしょう。 • サポート性(Supportability)：製品のユーザーにサポートを提供する ことはどれくらい経済的ですか？ • テスト容易性(Testability)：製品をどれだけ効果的にテストできます か？ • 保守性(Maintainability)：製品の構築、修正、強化はどれくらい経済 的ですか？ • 移植性(Portability)：他の場所に技術を移植または再利用すること はどれくらい経済的ですか？ • ローカライズ可能性(Localizability)：製品を他の場所に適応させる ことはどれくらい経済的ですか？
35. 品質基準(CRISP DUCCS) ユーザビリティ(Usability) 実際のユーザーが製品を使用するのはどれくらい簡単ですか？ • 学習可能性：製品の操作は、目的のユーザーが迅速に習得できま す。 • 操作性：製品は最小限の労力と手間で操作できます。 • アクセシビリティ：製品は関連するアクセシビリティ標準を満たし、O / Sアクセシビリティ機能と連携します。
36. 品質基準(CRISP DUCCS) カリスマ(Charisma) 製品の魅力は何ですか？ • 美学：製品は感覚に訴えます。 • 一意性：製品は何らかの点で新規または特別です。 • 必要性：製品には、ユーザーが期待する機能が備わっています。 • 有用性：製品は重要な問題を解決し、それをうまく解決します。 • エントランス：ユーザーは夢中になり、楽しみ、製品を使用するとき に完全に関与します。 • 画像：製品は、品質の望ましい印象を投影します。
37. 品質基準(CRISP DUCCS) 適合性(Compatibility) 外部コンポーネントと構成でどれだけうまく機能しますか？ • アプリケーションの互換性：製品は他のソフトウェア製品と連携して 動作します。 • オペレーティングシステムの互換性：製品は特定のオペレーティン グシステムで動作します。 • ハードウェアの互換性：製品は特定のハードウェアコンポーネントと 構成で動作します。 • 下位互換性：製品はそれ自体の以前のバージョンで動作します。 • 製品のフットプリント：製品は、メモリ、ストレージ、またはその他の システムリソースを不必要に占有しません。
38. 品質基準(CRISP DUCCS) セキュリティ(Security) 製品は不正使用や侵入からどの程度保護されていますか？ • 認証：ユーザーが本人であることをシステムが検証する方法。 • 承認：さまざまな特権レベルで認証されたユーザーに付与される権 利。 • プライバシー：顧客または従業員のデータを無許可の人々から保護 する方法。 • セキュリティホール：システムがセキュリティを実施できない方法（例 ：ソーシャルエンジニアリングの脆弱性）
39. テスト技術(FDSFSCURA) テスト技術は、テストを作成するための発見的な手法です。多くの興味 深いテクニックがあります。 ここでは9つの一般的なテクニックが書かれています。「一般的な手法」 とは、この手法がシンプルで普遍的であり、さまざまな状況に適用できる ことを意味します。 多くの特定の手法は、これら9つのうちの1つ以上に基づいています。そ して、このモデルの他のリストのカバレッジアイデアと1つまたは複数の 一般的な手法を組み合わせることにより、さまざまな特定のテスト手法を 構築できます。 • 機能テスト(Functional Testing) • ドメインテスト(Domain Testing) • ストレステスト(Stress Testing) • フロー試験(Flow Testing) • シナリオテスト(Scenario Testing) • クレームテスト(Claim Testing) • ユーザーテスト(User Testing) • リスクテスト(Risk Testing) • 自動チェック(Automatic Checking) James BachとMichael Boltonが作成した”Rapid Software Testing”が 出典です。
40. テスト技術(FDSFSCURA) 機能テスト(Functional Testing) • 製品が実行できること（機能およびサブ機能）を識別します。 • 関数が機能していたかどうかを判断します。 • 各機能を1つずつテストします。 • 想定外のことではなく、各機能が想定通りに機能することを確認し ます。
41. テスト技術(FDSFSCURA) ドメインテスト(Domain Testing) • 製品によって処理されたデータを探します。入力だけでなく出力も 見てください。 • テストする特定のデータを決定します。境界値、標準値、便利な値、 無効な値、または最適な代表値などを考慮してください。 • 一緒にテストする価値のあるデータの組み合わせを検討してくださ い。
42. テスト技術(FDSFSCURA) ストレステスト(Stress Testing) • 困難なデータまたは制約のあるリソースが存在する場合、過負荷ま たは「破損」に対して脆弱なサブシステムと機能を探します。 • これらのサブシステムと機能に関連するデータとリソースを特定しま す。 • 困難なデータ、またはリソース制約条件を選択または生成してテス トします。たとえば、大規模または複雑なデータ構造、高負荷、長い テスト実行、多くのテストケース、低メモリ条件などです。
43. テスト技術(FDSFSCURA) フローテスト(Flow Testing) • エンドツーエンドで接続された複数のアクティビティを実行します。た とえば、状態モデルを介してツアーを実施します。 • アクション間でシステムをリセットしないでください。 • タイミングとシーケンスを変えて、並列スレッドを試してください。
44. テスト技術(FDSFSCURA) シナリオテスト(Scenario Testing) • 製品の周りで起こっているすべてについて考えることから始めま す。 • 製品との意味のある複雑な相互作用を含むテストを設計します。 • 良いシナリオテストは、重要な人が製品で重要なことをする方法に ついての説得力のあるストーリーです。
45. テスト技術(FDSFSCURA) クレームテスト(Claims Testing) • 製品に関する主張を含む参考資料を特定します（暗黙または明 示）。SLA、EULA、広告、仕様、ヘルプテキスト、マニュアルなどを 検討してください。 • 個々のクレームを分析し、あいまいなクレームを明確にします。 • 製品に関する各クレームの真実さをテストします。 • 明示的な仕様からテストしている場合、それと製品が一致すること を予測してください。
46. テスト技術(FDSFSCURA) ユーザーテスト(User Testing) • ユーザーのカテゴリと役割を特定します。 • ユーザーの各カテゴリが何をするか（ユースケース）、どのように実 行するか、そして何を評価するかを決定します。 • 実際のユーザーデータを取得するか、実際のユーザーをテストに参 加させます。 • それ以外の場合は、体系的にユーザーをシミュレートします。（体系 的にユーザーをシュミレートできていない場合でも、「ユーザーに似 ている」と簡単に考えてしまう点は注意してください。） • 強力なユーザーテストとは、1人だけでなく、さまざまなユーザーと ユーザーロールを含むテストです。
47. テスト技術(FDSFSCURA) リスクテスト(Risk Testing) • 製品にはどのような問題がありますか？ • どの種類が最も重要ですか？それらに注目してください。 • それらが存在する場合、それらをどのように検出しますか？ • 興味深い問題のリストを作成し、それらを明らかにするためのテスト を設計します。 • 専門家に相談したり、ドキュメントを設計したり、過去のバグレポート を作成したり、リスクヒューリスティックを適用したりできます。
48. テスト技術(FDSFSCURA) 自動チェック(Automatic Checking) • 多くのアクションを実行し、多くのことを確認できるツールを探すか 開発をしてください。 • テストカバレッジを部分的に自動化するツールを検討してください。 • オラクルを部分的に自動化するツールを検討してください。 • 自動変更を検出するツールを検討してください。 • 自動テストデータジェネレータを検討してください。 • 人間のテストをより強力にするツールを検討してください。