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

706ff501573a736401aa4de5adc88e05?s=47 nihonbuson
November 04, 2019

テスト戦略ハンドブック / 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/

706ff501573a736401aa4de5adc88e05?s=128

nihonbuson

November 04, 2019
Tweet

Transcript

  1. 3.

    望ましい結果 テスト戦略は次の結果を達成するために試みるべきです • どのような問題を解決するかを推進する。「なぜこれを行うのです か?」に答えられるようにする。 • プロジェクトのマイルストーンと決定に影響を与える。 • レポートのサポートをする。以下のものを伝える。 ◦

    テストするもの ◦ テストしたもの ◦ テストしなかったもの • テスターとアジャイルチームの共通理解を高める。 • コードを書く前にテストを開始する。 • 統合テストを計画する。 • 説明責任を促進する。
  2. 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”が出典です。
  3. 5.

    コンテキストを理解する(BUTT) BUTTは以下の4つからなる記憶術です。 • Business Drivers • Usage • Technology •

    Team これは、コンテキストを判断するのに役立つ「MIDTESTD」という記憶術 を補完するためのものです。 ヒューリスティックテスト戦略モデルの記憶術に加えて、BUTTを考慮す る必要があります。コンテキストを理解するために必要な情報が分から ない場合は、探す必要があります。 「分からない」と言うことを恐れないでください。 チームによって作られた仮定と決定になる質問として 「もし…だったら?」があります。 状況に対する理解を図にしてチームに示してください。 その際に修正/コメントを貰ってください。 Created by Paul Holland
  4. 6.

    ビジネスドライバー (Business Drivers) • クライアントは誰ですか? • 製品はクライアントにとってどのような問題を解決しますか? • 製品が解決されるとする他の問題(間違った使い方)は何ですか? •

    製品はお客様にどのような価値を提供しますか? • 内部および外部の顧客の考えにある製品のイメージは何ですか? • 契約、罰則、またはその他の法的義務はありますか? • 競合他社は(現在もしくは将来)ありますか? • これはどのくらいのビジネスチャンスですか? • なぜこの製品が構築されているのですか?なぜ今なのですか? • 市場の力とプロジェクトの推進力について知っていますか?
  5. 7.

    使用法(Usage) • さまざまなタイプのユーザー(知っている人、ペルソナ)、さまざまな ニーズ、さまざまな感情、さまざまな状況は何ですか? • 彼らはどのように製品を使用しますか?(シナリオ) • 彼らはどのように製品を誤用しますか? • 「良い」ユーザーは間違って何をするのでしょうか?

    • 悪意のあるユーザーは何をしようとしますか? • 製品の使用パターンは何ですか? • 新しいテスト方法につながるような変更はありますか? • 現在の状況で、他にテスト対象に影響するものは何ですか? • エンドユーザー、プリセールス、販売、マーケティング、コンサルタン ト、サポート担当者にインタビューし、顧客のニーズについてさらに 理解する • 彼らが好きなものと嫌いなもの、製品の隣で何をするのかを見つけ ましょう。
  6. 8.

    技術(Technology) 問題のある領域や問題が発生する傾向があるものを理解するために、 ソフトウェアが動作するテクノロジーの内部動作を理解するための質問 をしてください アーキテクチャ • 仮定に挑戦する • 他の製品や機能との相互作用を理解する •

    データの依存関係(ソース) • データ出力 • 製品を流れるデータ • 他の製品/機能/システムへの依存関係は何ですか? • 製品に依存している他の製品/機能/システムは何ですか? プラットフォーム • 製品の言語は何ですか? • 製品で使用しているライブラリ/gems/プロシージャ/オープンソース コードは何ですか? • どのサーバーとサービスが使用されていますか? ◦ ロードバランサー、スプーラー、ネットワークデバイスなど • プロジェクトの自動化戦略は何ですか? • 利用可能なツールは何ですか?
  7. 9.

    チーム(Team) あなたのチームについて • あなたのチームには誰がいますか? ◦ 彼らの役割は何ですか? ◦ 彼らはあなたにどんなドキュメントを期待していますか? • どのチームとやり取りする必要がありますか?

    ◦ 彼らの役割と責任は何ですか? ◦ 彼らはあなたが誰であり、あなたが彼らに何を期待しているかを知っています か? • プロジェクトとその人々には、どの長所と短所がありますか? • これらの項目に対して一連のテストアイデアをマッピングできるよう にするためのプロジェクトの技術的負債は何ですか? • 開発者に、コードのどの部分を改善したいのか尋ねてください。 • 開発者はどの機能で問題を抱えていますか? 他のチームについて • 知っておく必要のある習慣や伝統はありますか? • 文化の違いと、それがあなたとあなたの仕事にどのような影響を与 えるかを知っていますか? • あなたの利害関係者は誰ですか? • 利害関係者が本当に心配していることは何ですか? • 他の利害関係者は誰ですか? • 他の人によってテストされているものは何ですか?
  8. 10.

    ヒューリスティックテスト戦略モデル ヒューリスティックテスト戦略モデルは、James BachとMichael Boltonが 作成した”Rapid Software Testing”が出典となっている、テスト戦略を設 計するための一連のパターンです。 プロジェクト環境には、テストを有効化または妨害する可能性のあるプロ ジェクト内のリソース、制約、およびその他の要素が含まれています。テ

    スターは制約に挑戦しなければならないこともあれば、受け入れることも あります。 製品要素は、テストする予定の要素です。ソフトウェアは複雑で目に見え ません。見やすい部分だけでなく、重要なすべてをカバーするように注 意してください。 品質基準は、テスターとして製品に問題があるかどうかを判断できる ルール、値、およびソースです。品質基準は多次元であり、多くの場合、 隠されているか、矛盾しています。 テスト技術は、テストを作成するためのヒューリスティックです。すべての 手法には、プロジェクト環境、製品要素、および品質基準の何らかの分 析が含まれます。 知覚品質はテストの結果です。ソフトウェア製品の「実際の」品質を知る ことはできませんが、さまざまなテストを適用することで、情報に基づい た評価を行うことができます。今回、詳しい紹介はしません。
  9. 14.

    プロジェクト環境(MIDTESTD) 開発者との関係(Developer Relations) • 傲慢:開発チームは、製品のあらゆる側面について自信過剰に見 えますか? • 防御性:開発者がテストしたことに奇妙に反対していると思われる 製品の部分はありますか? •

    関係性:プログラマーと友好的な関係を築いていますか? • フィードバックループ:プログラマーとオンデマンドですばやく通信で きますか? • フィードバック:開発者はテスト戦略をどう考えていますか?
  10. 16.

    プロジェクト環境(MIDTESTD) 機器とツール(Equipment & Tools) • ハードウェア:テストを実行するために必要な機器はすべて揃って いますか?セットアップして準備はできていますか? • 自動化:テストツールは必要ですか?それらは利用可能ですか? •

    調査:テスト対象製品の観察を支援するために必要なツールはあり ますか? • マトリックスとチェックリスト:テストの進捗を追跡または記録するた めに必要な文書はありますか?
  11. 18.

    プロジェクト環境(MIDTESTD) テスト項目(Test Items) • 範囲:製品のどの部分がテスト責任の範囲内にあり、どの部分がそ うでないか? • 可用性:テストする製品はありますか?利用可能なテストプラット フォームはありますか?新しいビルドはいつ入手できますか? •

    揮発性:製品は常に変化していますか?再テストの必要性は何で すか? • 新しいもの:最近製品に変更または追加されたものは何ですか? • テスト容易性:製品は機能的で信頼性が高く、効果的にテストでき ますか? • 将来のリリース:将来の製品リリースに適用するために、テストのど の部分を設計する必要がありますか?
  12. 22.

    製品要素(SFDIPOT) 関数(Function) • アプリケーション:製品を定義または区別する機能、またはコア要件 を満たす機能。 • 計算:算術関数または他の関数に埋め込まれた算術演算。 • 時間関連:タイムアウト設定。日次または月末レポート。夜間のバッ チジョブ。時間帯。休業日。利息計算。条件と保証期間。クロノグラ

    フ機能。 • 変換:何かを変更または変換する機能(フォントの設定、クリップ アートの挿入、アカウントからのお金の引き出しなど)。 • 起動/シャットダウン:呼び出しと初期化、および製品の終了のため の各メソッドとインターフェース。 • マルチメディア:サウンド、ビットマップ、ビデオ、または製品に埋め 込まれたグラフィック表示。 • エラー処理:すべてのエラーメッセージを含む、エラーを検出して回 復する機能。 • 相互作用:製品内の機能間の相互作用。 • テスト容易性:診断、ログファイル、アサート、テストメニューなど、製 品のテストに役立つ機能が提供されます。 • 失敗モード:「what-if」質問をして、内部/外部、予想/予想外、(意図 しない)、現実的/挑発的な障害の処理を公開するテストのアイデア を生成します。 • システムのフォールトトレランスに挑戦します。すべてのオブジェクト またはコンポーネントが破損する可能性があります。
  13. 23.

    製品要素(SFDIPOT) データ(Data) 意図的および意図的でないデータを特定し、依存関係を悪用し、多くの 場所でデータを調べます。 • 入力:製品によって処理されるデータ。 • 出力:製品による処理から生じるデータ。 • プリセット:製品の一部として提供される、または事前に作成された

    データベース、デフォルト値など、製品に組み込まれているデータ。 • 永続的:内部に保存され、複数の操作で永続化されると予想される データ。これには、オプション設定、表示モード、ドキュメントの内容 など、製品のモードまたは状態が含まれます。 • シーケンス/組み合わせ:単語の順序、並べ替えられたデータと並 べ替えられていないデータ、テストの順序など、データの順序また は順列。 • カーディナリティ:オブジェクトまたはフィールドの数は異なる場合が あります(例:0、1、多く、最大、オープン制限)。一部は一意である 必要があります(データベースキーなど)。 • ビッグ/リトル:データのサイズと集計のバリエーション。 • ノイズ:無効であるか、破損している、または制御されていないか不 正な方法で生成されたデータまたは状態。 • ライフサイクル:データエンティティが作成、アクセス、変更、および 削除される際のデータエンティティの存続期間にわたる変換。
  14. 24.

    製品要素(SFDIPOT) インタフェース(Interface) • ユーザーインターフェイス:ユーザーとのデータ交換を仲介する要 素(たとえば、ディスプレイ、ボタン、フィールド、物理または仮想)。 • システムインターフェース:他のプログラム、ハードディスク、ネット ワークなど、ユーザー以外のものとのインターフェース • API

    / SDK:この製品を使用した新しいアプリケーションの開発を可 能にすることを目的とした、プログラムによるインターフェースまた はツール。 • インポート/エクスポート:別の製品で使用するためにデータをパッ ケージ化する機能、または別の製品からのデータを解釈する機能。
  15. 26.

    製品要素(SFDIPOT) 操作(Operations) • ユーザー:さまざまな種類のユーザーの属性。 • 環境:ノイズ、光、注意散漫などの要素を含む、製品が動作する物 理的環境。 • 一般的な用途:製品が通常遭遇する入力のパターンとシーケンス。 これはユーザーによって異なります。

    • 不利な使用:無知な、誤った、不注意な、または悪意のある使用に よって生成された入力のパターン。 • 極端な使用:製品の意図された使用と一致する挑戦的なパターンと 入力のシーケンス。
  16. 31.

    品質基準(CRISP DUCCS) インストール性(Installability) • システム要件:必要なコンポーネントが欠落しているか不足している 場合、製品は認識しますか? • 構成:システムのどの部分がインストールの影響を受けますかファ イルとリソースはどこに保存されますか? •

    アンインストール:製品をアンインストールするときに、きれいに削除 されますか? • アップグレード/パッチ:新しいモジュールまたはバージョンを簡単に 追加できますか?既存の構成を尊重しますか? • 管理:インストールは特別な人員が処理するプロセスですか、それ とも特別なスケジュールですか?
  17. 34.

    品質基準(CRISP DUCCS) 開発(Development) どのくらいうまく作成、テスト、修正できますか? STMPLを考えると良いでしょう。 • サポート性(Supportability):製品のユーザーにサポートを提供する ことはどれくらい経済的ですか? • テスト容易性(Testability):製品をどれだけ効果的にテストできます

    か? • 保守性(Maintainability):製品の構築、修正、強化はどれくらい経済 的ですか? • 移植性(Portability):他の場所に技術を移植または再利用すること はどれくらい経済的ですか? • ローカライズ可能性(Localizability):製品を他の場所に適応させる ことはどれくらい経済的ですか?
  18. 36.

    品質基準(CRISP DUCCS) カリスマ(Charisma) 製品の魅力は何ですか? • 美学:製品は感覚に訴えます。 • 一意性:製品は何らかの点で新規または特別です。 • 必要性:製品には、ユーザーが期待する機能が備わっています。

    • 有用性:製品は重要な問題を解決し、それをうまく解決します。 • エントランス:ユーザーは夢中になり、楽しみ、製品を使用するとき に完全に関与します。 • 画像:製品は、品質の望ましい印象を投影します。
  19. 37.

    品質基準(CRISP DUCCS) 適合性(Compatibility) 外部コンポーネントと構成でどれだけうまく機能しますか? • アプリケーションの互換性:製品は他のソフトウェア製品と連携して 動作します。 • オペレーティングシステムの互換性:製品は特定のオペレーティン グシステムで動作します。

    • ハードウェアの互換性:製品は特定のハードウェアコンポーネントと 構成で動作します。 • 下位互換性:製品はそれ自体の以前のバージョンで動作します。 • 製品のフットプリント:製品は、メモリ、ストレージ、またはその他の システムリソースを不必要に占有しません。
  20. 38.

    品質基準(CRISP DUCCS) セキュリティ(Security) 製品は不正使用や侵入からどの程度保護されていますか? • 認証:ユーザーが本人であることをシステムが検証する方法。 • 承認:さまざまな特権レベルで認証されたユーザーに付与される権 利。 •

    プライバシー:顧客または従業員のデータを無許可の人々から保護 する方法。 • セキュリティホール:システムがセキュリティを実施できない方法(例 :ソーシャルエンジニアリングの脆弱性)
  21. 42.

    テスト技術(FDSFSCURA) ストレステスト(Stress Testing) • 困難なデータまたは制約のあるリソースが存在する場合、過負荷ま たは「破損」に対して脆弱なサブシステムと機能を探します。 • これらのサブシステムと機能に関連するデータとリソースを特定しま す。 •

    困難なデータ、またはリソース制約条件を選択または生成してテス トします。たとえば、大規模または複雑なデータ構造、高負荷、長い テスト実行、多くのテストケース、低メモリ条件などです。
  22. 46.

    テスト技術(FDSFSCURA) ユーザーテスト(User Testing) • ユーザーのカテゴリと役割を特定します。 • ユーザーの各カテゴリが何をするか(ユースケース)、どのように実 行するか、そして何を評価するかを決定します。 • 実際のユーザーデータを取得するか、実際のユーザーをテストに参

    加させます。 • それ以外の場合は、体系的にユーザーをシミュレートします。(体系 的にユーザーをシュミレートできていない場合でも、「ユーザーに似 ている」と簡単に考えてしまう点は注意してください。) • 強力なユーザーテストとは、1人だけでなく、さまざまなユーザーと ユーザーロールを含むテストです。
  23. 47.

    テスト技術(FDSFSCURA) リスクテスト(Risk Testing) • 製品にはどのような問題がありますか? • どの種類が最も重要ですか?それらに注目してください。 • それらが存在する場合、それらをどのように検出しますか? •

    興味深い問題のリストを作成し、それらを明らかにするためのテスト を設計します。 • 専門家に相談したり、ドキュメントを設計したり、過去のバグレポート を作成したり、リスクヒューリスティックを適用したりできます。