あろうことか、途中まで書いたはずが、ロストしてしまいました。
保存大事ですね。
- テスト組織
- 独立したテスト
- テストマネージャーとテスト担当者のタスク
- テストマネージャーのタスク
- テスト担当者の役割
- テスト計画書の目的と内容
- テスト戦略とテストアプローチ
- テスト戦略
- テストアプローチ
- テストのモニタリングとコントロール
- 構成管理とは
- テストウェア構成管理の手順
- リスクの定義
- プロダクトリスク
- プロジェクトリスク
- リスクベースドテストとプロダクト品質
- 欠陥マネジメント
- 欠陥の特徴
- 欠陥マネジメントの必要性
- 欠陥レポート
- 欠陥マネジメントのプロセス
テスト組織
自分で書いた文書の間違いは、自分では気が付きにくいものです。作成した文書の誤字や技術の間違いを見つけるには、作成した本人以外の人に読んでもらうことが有効です。
作成者自身では気が付かない間違った言い回しや誤字などの思い込みを排除できるため効率的に指摘してもらえるからです。
文書をいちいち指摘して、修正というのは割と手間がかかり、ストレスのかかる作業です。
品証から文書の誤字を指摘されて、だったら直してよと、開発と揉めたことも。
今は指摘するための機能がGoogle DocumentやNotionには用意されているので、これを有効活用したいところですね。
そうすると、集計取れないから云々とかなりそうですね。
ここでのポイントは思い込みにあると思っています。自分が書いたら大丈夫だろ、これなら他の人でもわかるのだろう、そうした思い込みを排除できるかを意識してレビューするともう一段階いいレビューができるかもしれません。
って、言っても、なかなか難しいんですけどね。
独立したテスト
テストを担当する人の独立性が高くなると効率的に欠陥が発見しやすくなります。
開発担当者と異なる独立したテスト担当者がテスト実行をすると、開発担当者が持っている先入観や、知らず知らずのうちにかけてしまっている心理的バイアス、特に確証バイアスの影響を受けずにテストが行えます。
その他の利点として、専門の知識を持った独立したテスト担当者は、テストやレビューに対する動機付けを与えることができます。
特に、顧客よりの人に触ってもらって早めにフィードバックをもらいたいというのが開発の本音です。
コールセンターの人に触ってもらって不具合や問題点が見つかってよかった経験があります。
しかし、それがなかなかできない。リリースしてからしばらくして、営業の人がこの仕様は違うとか、コールセンターの人に触ってくださいねってアプリを渡しても触ってくれない、なんてことがしばしばです。
以下に、組織によるテストとして独立性の低いレベルから高いレベルの順に並べていきます。
- 独立したテスト担当者不在（開発担当者が自分のコードをテストするのみである）
- 開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者（開発担当者が同僚の成果物をテストすることもある）
- 組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織
- 顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある特定のテストタイプを専門に行う独立したテスト担当者
- 組織外の独立したテスト担当者。オンサイト（インソーシング）またはオフサイト（アウトソーシング）で作業する
2人くらいのチーム規模だったら、独立したテスト担当者不在って状況でした。
今は、Pull Requestはセルフマージできないので、同僚が確認してマージするという形ですね。
独立したテストチームというのはそれなりの規模がないと抱えられないと思います。開発予算の都合です。
独立したテストをすることで、以下のメリットを享受できます。
- 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い。
- 独立したテスト担当者は、仕様作成時および実装時にステークホルダーが行った仮定について、検証、説明の要求、または反証を行うことができる
欠点としては以下のものがあります。
- 開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある
- 開発担当者の品質に対する責任感が薄れることがある
- 独立したテスト担当者は、ボトルネックとして見られたり、リリース遅延で責任を問われたりすることがある
- 独立したテスト担当者にテスト対象の重要な情報が伝わらないことがある
情報共有のために仕様書がってなるんですが、仕様通りにいかず、仕様書が腐って、テストするのもカオスというのが想像に浮かびます。
テスト担当者が積極的に開発の情報を取っていって欲しいのですが、テストに向いている人って慎重でおとなしい人が多いです。
かつ開発スキルがないと把握が難しいですが、そこまであったら開発やってよとなってしまい、なかなか悩ましいのです。
テストマネージャーとテスト担当者のタスク
テストチームを組織する場合、担当する活動や作業を職務で分けることができます。
ISTQBではテストマネージャーとテスト担当者の２つの職務を説明しています。
テストマネージャーのタスク
テストマネージャーはテストプロセス全体の責任を持ちます。そのためには指導力を発揮しテストプロジェクトをまとめ、テスト活動をリードしていかなければなりません。
テストマネジメントの役割は、以下の担当者などが担います。
- プロのテストマネージャー
- プロジェクトマネージャー
- 開発マネージャー
- 品質保証マネージャー
テストマネージャーは、プロジェクト全体を考慮し、テストの計画を立案し、プロジェクト全体を考慮し、テストの計画を立案し、テスト活動状況のモニタリング、コントロールを実施します。
テストマネージャーの代表的なタスクは以下の通りです。
- 組織のテストポリシーやテスト戦略を開発もしくはレビューする
- プロジェクトの背景を考慮した上で、テスト目的とリスクを理解してテスト活動を計画する。これにはテストアプローチの選択・テストにかかる時間/工数/コストの見積もり、リソースの獲得、テストレベルやテストサイクルの定義、欠陥マネジメントの計画を含む
- テスト計画書を作成し構成する
- プロジェクトマネージャー、プロダクトオーナーなどの間でテスト計画書の内容を調整する
- テスト側の考え方を、統合計画などの他のプロジェクト活動と共有する
- テストの分析、設計、実装、実行の開始を宣言し、テスト進捗とテスト結果をモニタリングし、修了基準（または完了(done)の定義）のステータスを確認する
- テスト進捗レポートとテストサマリーレポートを、収集した情報に基づいて準備し配布する
- (テスト進捗レポートおよび/またはプロジェクトで既に完了しているテストのテストサマリーレポートで報告済みの）テスト結果やテスト進捗に基づいて計画を修正し、テストコントロールのために必要なあらゆる対策を講じる
- 欠陥マネジメントシステムのセットアップと、テストウェアの適切な構成管理を支援する
- テスト進捗の計測、およびテストや対象ソフトウェアの品質の評価のために、適切なメトリクスを導入する
- テストプロセスで使うツールの選択と実装を支援する。これには、ツール選択（および、購入および/またはサポート）のための予算の提案、パイロットプロジェクトのための時間と工数の割り当て、継続的なツール使用支援の提供を含む
- 構築するテスト環境を決定する
- 組織内のテスト担当者、テストチーム、テスト専門職を昇格及び支持する
- テスト担当者のスキルアップとキャリアアップを促す（トレーニング計画、業績評価、コーチングなどを使用）
実は、外部のテスターにテストを依頼しているので、ぼくがテストマネージャーに当たる立場だったりします。
できていることはモニタリングくらいですね。
テスト担当者の役割
テスト分析、テスト設計、テストの自動化、特殊なテスト実行（例えば、セキュリティテストや性能テスト）は、それぞれのスキルを十分に持った技術者が担当者となるべきです。
テスト担当者の役割は以下の通りです。
- テスト計画書のレビューによって貢献する
- 試験性のために、要件、ユーザーストーリーと受け入れ基準、仕様、モデル（すなわち、テストベース）を分析し、レビューし、評価する
- テスト条件を識別し文書化し、テストケース、テスト条件、テストベースの間のトレーサビリティを確立する
- テスト環境（システムアドミニストレーションやネットワークマネジメントと協調する場合が多い）設計、セットアップし、検証する
- テストケースとテスト手順を設計し実装する
- テストデータを作成、および入手する
- 詳細なテスト実行スケジュールを作成する
- テストケースを実行し、結果を評価して、期待結果からの逸脱を文書化する
- 適切なツールを使用して、テストプロセスを円滑にする
- 必要に応じてテストを自動化する（開発担当者や、テストの自動化の専門家の支援が必要な場合がある）
- 性能効率性、信頼性、使用性、セキュリティ、互換性、移植性など非機能特性を評価する
- 他の人が開発したテストケースをレビューする
テストを自動化できるといいですね。Webなら、Autifyなどよくできたツールの登場で、テスト担当者が自立してできるらしいです。
らしいので、現実は、そんな簡単な話じゃない気もしますが。
テスト計画書の目的と内容
日程を作るだけでなく、目的を明らかにし、さまざまな制約を考慮してこそテスト計画であることを説明していきます。
テスト計画の種類
テスト計画は目的に応じて作成します。
プロジェクト全体のテストを計画するマスターテスト計画と、個別に計画を立てるものとがあります。
個別のテスト計画には、システムテスト計画、受け入れテスト計画のようにテストレベルに合わせて作成する場合と、性能テスト計画やセキュリティテスト計画といったテストタイプに合わせて作成する場合とに分かれます。
マスターテスト計画は、複数のテストレベルの計画を扱います。
マスターテスト計画という言葉は初耳です。
テスト計画書の概要(ISO/IEC/IEEE 標準:ISO/IEC/IEEE 29119-3)
ISO/IEC/IEEE標準を参考にして、テスト計画書にどんな内容を盛り込めば良いのか確認します。
以降の3.2 テストアイテムの3.2はISO/IEC/IEEE標準の内容の項目番号になります。
3.2 テストアイテム
何をテストするのか記述します。次のようなものがテストアイテムになります。
3.3 テスト範囲
テストを実行するフィーチャーと、実行しないフィーチャーを記述します。テストを実行しないフィーチャーに関しては、実行しない理由も併せて記述します。
6.8 確認テストおよびリグレッションテスト
確認テストおよびリグレッションテストが実行される条件を記述します。
テスト計画において確認テストとリグレッションテストは、テストサイクルとして表現されることがあります。
変更後に実行するリグレッションテストのレベルを定義することがあります。
とありますが、基本変更後に影響ありそうな箇所をリグレッションテストするかなあ、と。
その粒度は、まあなんとなくですね。定義していないので。とはいえ、定義も難しい気がします。
6.10 組織レベルのテスト戦略からの逸脱
組織内で実行されるすべてのプロジェクトでどのようなテストを実行するかについてのガイドライン（組織レベルのテスト戦略を定めることがあります）
このガイドラインを遵守できない場合に、遵守できないガイドラインとその理由を記述します。
テスト計画書の内容の拡充
テスト計画は作成したら終了というものではありません。
プロジェクトを進めながら育てていくものです。
プロジェクトが進むに伴い、テスト計画に利用できる情報が増え、テスト計画の内容がより具体化していきます。
テストを実行している間も、リスクの変化を認識しつつスケジュールなどを調整し、テスト計画にフィードバックします。
このようにテスト計画は、プロダクトのライフサイクルを通じて継続される活動です。
プロダクトのライフサイクルとは、プロジェクトが完了して、保守フェーズに移行し、プロダクトが破棄されるまでを指します。
保守フェーズに入っても、テスト計画の活動があります。
テスト計画の考慮点
テスト計画を立案するに当たり、さまざまな要素を考慮しなければいけません。
次のような要素があります。
- 組織のテストポリシーや組織のテスト戦略
- 使用する開発ライフサイクルや方法
- テストの範囲
- テストの目的
- リスク
- 制約
- 重要度、優先度
- テスト容易性
- 使用するリソース
テストを実行するのに手間がかかる設計になっているテストアイテムが存在する場合、手間がかかる分をスケジュールに反映させなければいけません。
テストアイテム間でテスト実行の重要度や優先度が異なる場合には、それを反映させたスケジュールにしなければいけません。
テスト計画の活動
これまでに説明したテスト計画書を作成するため、テスト計画では、次のような活動を行います。
- テスト範囲を決める
- テスト目的を決める
- リスクを洗い出す
- テストアプローチを検討し、定義する
- 次に挙げる事柄を決める
- 何をテストするか
- さまざまなテスト活動でどのような人的リソースや他のリソースが必要か
- どのようにテスト活動を進めるか
- 次に挙げる活動をスケジューリングする
- テスト分析
- テスト設計
- テスト実装
- テスト実行、および終了基準の評価（シーケンシャル開発の場合は特定の日付を設定する。イテレーティブ開発の場合は各イテレーションの状況でスケジューリングする）
- テストのモニタリングやコントロールに使用するためのメトリクスを選ぶ
- テストドキュメントに関して次に挙げる事柄を決める
- テストドキュメントの詳細レベル
- テストドキュメントの種類とそれらの構造
- 使用するテンプレートやサンプルドキュメント
- テスト活動の予算を決める
- ソフトウェアライフサイクル（獲得、提供、開発、運用、保守）での活動にテスト活動を統合し協調させる
テスト戦略とテストアプローチ
テスト戦略は、テスト設計をはじめとしたテストプロセスの指針となる汎用的な考え方のことです。
テストアプローチは、特定のプロジェクトやリリース用にテスト戦略をテーラリングしたものです。
テスト戦略
テスト戦略には組織レベルのものやプロダクトレベルのものがあります。よく用いられるテスト戦略を分類すると次の通りです。
分析的戦略
要件やリスクなどの要因を分析した結果を用いてテストを設計します。
リスク分析を実施し、優先度が最も高い分野を重点的にテストするリスクベースドテストはこの分類になります。
## モデルベースド戦略
何らかのモデルを基にしてテストを設計します。
基にするモデルには、ビジネスプロセスモデル、機能、内部構造、状態遷移モデル、信頼度成長モデル（故障率）、運用プロフィール（使い方）などさまざまなモデルがあります。
## 系統的戦略
あらかじめ定められているテストケースまたはテスト条件を用いてテストを設計します。
例えば次のようなテストはこの分類になります。
- チェックリストをベースにしたテスト
- 発生する可能性高いものを体系的に分類した故障リストを用いたテスト
- 組織またはプロダクトで重要な品質特性をベースにした
- 企業で定めているモバイルアプリケーションやWebページのルックアンドフィール標準を用いたテスト
プロセス準拠（または標準準拠）戦略
企業の内外で定められてるルールまたは標準を用いてテストの分析、設計の実装を行います。
企業外のルールまたは標準の例として、業界固有の標準やプロセスドキュメントなどがあります。
ルールまたは標準の中には、厳密にテストベースを識別しているものもあります。
組織で定められているプロセスや各種標準を用いる場合にはこの分類になります。
指導ベース（コンサルテーションベース）戦略
外部（テストチーム外であったり組織外であったり）のステークホルダー、ビジネスドメインの専門家、技術的な専門家からの助言、指導、ガイダンスを基にテストを実施します。
顧客（エンドユーザー）の意見に基づいてビジネスプロセスをテストする場合にはこの分類になります。
リグレッション回避戦略
リグレッション（日本では一般的リグレッションのことをデグレードと呼ぶことが多いです。）に着目し、リグレッションが発生しているかどうかを確認できるようにテストを組み立てます。
組織やテストチームで持っている標準テストスイートを再利用したり、既存のテストケースやテストデータを再利用したりします。
高度に自動化されたリグレッションテストもこの分類になります。
リグレッションもデグレードもどちらも使う感じですね。不具合をデグレ（デグレードを略して）と呼んで、その確認の時はリグレッションテストと呼ぶみたいな感覚でした。
対処的戦略
事前に計画するのではなく、テスト実行時に発生するイベントやテスト結果に対応してテストを行います。
多くの場合、テスト設計、実装、実行と評価を同時に行います。
探索的テストを実行する場合にはこの分類になります。
これらのテスト戦略は単独で使用することも可能ですが、一般的には複数の戦略を組み合わせて構築します。補完的なテスト戦略を組み合わせることによりテストの有効性が高まります。
テストアプローチ
テスト技法、テストタイプ、各テストレベルの開始・終了基準をどの程度にすれば良いのかを決めるために、テストアプローチを決めます
プロジェクトのゴールや複雑さ、プロダクトの種類やリスクなどを踏まえてテスト戦略をテーラリングします。
主に考慮すべき要素を次に示します。
- プロジェクトの種類
- リスク
- 安全性
- 使用可能なリソース
- スキル
- 技術
- システムの性質
- テスト目的
- 法規制
開始基準と終了基準-準備完了(ready)の定義と完了(done)の定義
テスト目的に応じて、テストレベルごと、テストタイプごとにテスト活動の開始基準と終了基準を定めます。
開始基準
テスト活動を開始するための事前条件を定義します。アジャイル開発では、通常、準備完了(ready)の定義と呼びます。
代表的な開始基準が以下。
- テストベース
- テスト可能な要件、ユーザーストーリーが準備できていること
- モデルベースド戦略を採用している場合、モデルが準備できていること
- テストアイテム
- 1つ前のテストレベルで終了基準を満たしたテストアイテムが、利用できるように準備できていること
- テスト環境
- テスト環境がテストに利用できるように準備できていること
- テストツール
- 必要なテストツールがテストを利用できるように準備できていること
- テストデータ
- テストデータが利用できるようになっていること
- その他リソース
- その他の必要なリソースが準備できていること
開始基準が満たされないままにテスト活動を開始すると、難易度が上がり、テスト時間が増え、コストも増え、リスクが高まります。
仕事の無駄は、仕事のやり直しですからね。ただ、このあたりの開始基準をきちんと定めて運用というのは経験上あまりないです。
ただ、聞いた話だとデータがまだ揃っていない段階でも間に合わせるために始めなければならないケースとかあるそうです。納期にどう間に合わせるかが結局の開始基準になってしまうのが現場の現状なのかな、とも。
終了基準
テスト活動を終了するために達成すべき条件を定義します。アジャイル開発では、通常、完了(done)の定義と呼びます。
代表的な終了基準は以下
- 実行済みテスト
- 計画したテスト実行が完了していること
- カバレッジ
- 残存リスク
- 未修正の欠陥やカバレッジ不足の領域が合意された制限内であること
- 残存欠陥数
- 信頼度成長モデルなどを用いて想定した残存欠陥数が十分に少ないこと
- 品質特性
- 信頼性、性能効率性、使用性、セキュリティ、その他の関連する品質特性の評価レベルが十分に高いこと
予算、納期、品質のバランスを考慮した結果、終了基準を満たしていなくてもプロジェクトのステークホルダーやビジネスオーナーの了承があればテスト活動を切り上げることがあります。
以前、結合テストでアプリケーションが落ちる不具合が見つかり、血眼で不具合を再現できる操作を見つけ出すというテストをしていた時がありました。
なかなか再現方法が確立できず、時間が過ぎていくばかり。
プロジェクトマネージャーの人はビジネスオーナーにあたる営業の人に納期に間に合わない可能性があると、あらかじめ電話してました。
なんとか不具合の操作を見つけ出し、納期に間に合わせることができました。
彼いわく、心配でしょうがなかったが、ドンと座って待っていた、とのことでした。
テスト実行スケジュール
テストケースの実行順序を決める際に考慮すべき事柄を次に示します。
- 優先度
- テストケース間の依存性
- テスト対象機能間の依存性
- 効率性
- 確認テスト
- リグレッションテスト
その他にテスト環境の準備状況、要員の稼働状況なども考慮する場合があります。
依存関係を考慮しつつ、優先度の高いテストケースから実行するようにスケジューリングします。
依存関係の分析を疎かにすると、テストを実行しようとしても実行できないという状況に陥ることがあるため、シラバスでは依存関係について注意を促しています。
効率性、優先度、依存関係のバランスを取りながらスケジュールを作成します。
確認テストやリグレッションテストは、開発担当者がテスト結果のフィードバックを急いでいるかどうかを判断し、優先度を割り当てます。
依存関係が強調されていますが、どちらかというとスタンドアローンのアプリケーションの経験が多く、ぼくはあまり認識がありません。
Webアプリケーションなどですと複数のサービスが連携するので欠かせない要素です。依存関係を認識するにはシステムの連携がわかる全体図が必須になります。
この全体図がないというプロジェクトがありました。作ることばかりに注力しすぎて全体を見るマネージャーがいないのです。
話は逸れますが、エンジニアにはマネージャー志望が少なく、こういうマネージャー不足が起こりがちなのが実情です。これはエンジニアはコンピューターと会話するのが仕事であり、人と会話することが苦手なことが多く、人と会話するマネージャーを希望しなくなりがちな職業的なものがあります。
テスト工数に影響する要因
テスト工数を見積もるためには、テスト工数の見積りに影響を与える要因を知っておく必要があります。
見積りに影響を与えるものとして、テスト対象であるプロダクトの特性、開発プロセスの特性、人の特性、テストの結果などが挙げられます。
ある程度、見通しを立てていつもテスト工数を見積もっていますが、難しいです。
この人、このテストこれくらいできるだろと思ってたら、全然進まなかったり、あれ、あの人、もう終わったの？なんて、しばしばです。
プロダクトの特性
主なプロダクトの特性を次に示します。
- プロダクトの規模
- 品質特性の要件（例えば、セキュリティ、信頼性）
- 法規制への適合性の要件
- テストベースの品質
- プロダクトドメインの複雑度
- プロダクトに関するリスク
- テストドキュメントの詳細度に関する要求レベル
開発プロセスの特性
主な開発プロセスの特性を次に示します。
- 組織の安定度合いと成熟度合い
- 使用している開発モデル
- テストアプローチ
- 使用するツール
- テストプロセス
- 納期のプレッシャー
納期のプレッシャーとは納期が厳しいため並行タスクを増やし、それに応じて要員を増加するなどを指すようです。
組織の安定度合いと成熟度合いってどうなんでしょう。これが高いと感じた職場にいた記憶がありません。
安定する前に、だったらもっと頑張れるよねって経営者から、ハードルを引き上げられがちな印象があります。
人の特性
主な人の特性を次に示します。
- メンバーのスキルや経験、特に類似プロジェクトや類似プロダクトのスキルや経験
- メンバーのドメイン知識の有無
- チームのまとまりとリーダーシップ
昨今では、固定メンバーでテスト含め開発するのが難しい状況です。外注を使うことが多いわけですが、どうしても流動的になりがちです。
そういった中で、ある程度のレベルを保つのはかなり難しい。
同じスキルの人を補充してもドメイン知識は一から覚え直しになりがちです。
また、toBのシステムでは、ドメイン知識そのものを取得するのがなかなかに難しいです。そういったことの教育体制は整ってません。大企業の新人教育ではないので何ヶ月も教育時間を割けるわけでもないですから。
テスト結果
- 検出した欠陥の数と重要度
- 必要な再作業の量
テスト見積りの技術
シラバスでは、主に2つ挙げられています。
- メトリクスを活用する
- 専門家の知識を基にする
ワイドバンドデルファイ法とは、専門家によるテスト見積り技法。チームメンバーから集めた知識を用い、正確な見積りをするもの。だそうです。
メトリクスなのか、専門家なのか、ということですが、両方を見比べるのが良いといえるとしめています。
ここでいう専門家は外部のテストの専門家のみならず、経験豊富な開発メンバーも含められます。
ここでテスト計画と見積りは終了します。
練習問題は、全然ダメでした。
最適なテストスケジュールを選べという問題もあります。これはガンとチャートを書かねばならず、時間がかかるので、実際のテストだったら後回しでしょう。
テストのモニタリングとコントロール
様々な指標を設けて、テストプロセスの様々な状態をモニタリングします。そして、そのモニタリング結果を使ってテストの活動をコントロールします。遅れているようであれば、スケジュールの見直し、必要なリソースの投入、その他の策を講じます。モニタリングとコントロールはテストを進める上での車の両輪です。
- 識別するリスクが現実になった場合（例えば、リリース遅延）、テストの優先度を見直す
- テスト環境や他のリソースの利用可否により、テストスケジュールを変更する
- 再作業が発生した場合に、テストアイテムが開始基準と終了基準を満たすかを再評価する
テスト活動をモニタリングするためのメトリクス
まず、テスト活動の期間中、および終了時に、次のようなものを評価し、テストレポートにまとめます。
- 計画したスケジュールや予算に対する進捗
- テスト対象の現在の品質
- テストアプローチの十分性
- テスト目的に対するテスト活動の効果
代表的なメトリクスは以下。
- 計画したテストケースの準備が完了した割合
- 計画したテスト環境の準備が完了した割合
- テストケースの実行
- 欠陥情報
- 要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ
- タスク完了、リソースの割り当てと稼働状況、工数
- テストに費やすコスト
以前の職場、上司がフルカバレッジ通さなきゃダメだよねって（ドヤァ）言ってましたが、そんなの無理です。
だったら、もっと予算がかかりますよっていったら、そんなの出せるわけないだろう、なんとかしろ、良きにはからえという暗黙の了解になるのがオチです。
本書でも100%が望ましいが、100%に近づくほど例外処理、異常処理などが残ってしまい、テストケース選定が困難になり、消化しようとするあまり、多大な工数がかかってしまう場合があル。未実行の部分についてはレビューで欠陥がないことを確認した方が効率的と書いてあります。
テストレポートの目的、内容、読み手
テストレポートの目的は、テスト活動の結果を要約しステークホルダーに周知することと、テスト活動から得られた教訓をメンテナンスフェーズや未来のプロジェクトなどの活動に活かすための情報をステークホルダーに提供することです。
- テスト活動の結果の要約 ... テスト活動の期間中に発生した事象および発生日付（終了基準を満足した日など）。
- 次の活動に活かすための情報と ... テスト活動全般にわたる分析情報や前項で解説したメトリクス。
テストレポートは、テスト活動期間中に作成するテスト進捗レポートと、テスト終了後に作成するテストサマリーレポートに大別することができます。
ISO/IEC/IEEE 29119-3 テスト進捗レポートの構成について
ぼくとしては、今の時代には合わない気がしています
クラウド上のドキュメントなので、変更履歴とかは不要でしょう。文書の識別情報とかもいらないと思います。この辺りは古臭いのでやめたいですね。
承認者や発行機関のスピードを意識するのであれば、不要です。やるのであればGitHubで管理してApproveするフローにするとかでしょうが。
参照も文書のリンクを貼ればいいので、いちいち「はじめに」でまとめる必要もないでしょう。
形式を簡略して、中身であるテストの状況を充実させることに注力させるべきでしょう。
- 期間
- テスト計画に対する進捗
- 進捗を妨げる要因
- テスト方法
- 新規および変更されたリスク
- 計画されたリスク
ISO/IEC/IEEE 29119-3 テスト完了レポートの構成について
異なるのは中身がテストの状況ではなく、実施したテストについてとなる点です。
- 実行したテストの概要
- 計画からのテストの逸脱
- テスト完了評価
- 進捗を妨げた要因
- テスト方法
- 残存リスク
- テスト成果物
- 再利用可能なテスト資産
記載内容のテーラリング
プロジェクトの性質、組織から与えられた要件、ソフトウェアライフサイクルなどによって記載内容のテーラリングが必要になります。
テーラリングというのは洋服の仕立て直しという意味になります。状況に応じて構成を変えなければならない、ということです。
- 多くのステークホルダーが関与する複雑なプロジェクトや法規制を受けるプロジェクト
- 簡易なソフトウェアの更新のプロジェクト
- はじめには共通フォーマットにして作らないといった効率化
- アジャイル開発
- タスクボード、欠陥サマリー、バーンダウンチャートなどでテスト進捗レポートは代用
- 開発担当者やテストチームが対象のレポート
- プロジェクトマネージャー向けのレポート
- 経営者向けのレポート
面倒なのは提出先が複数にわたるケース。
以前なんて、部長向けのフォーマット、品証向けのフォーマットで、各々書かなければならないようなことがあり、無駄とストレスを感じることが多かったです。
大きな問題が起きると経営者向けのレポートも必要になり、対応に追われているのに、余計な仕事が増え、余計大変になります。
社内であれば統一できないのは会社としての問題なのですが、法規制などの外部機関が相手になると、流石に統一するのは難しいでしょう。
構成管理とは
ソフトウェアの場合、特にSCM(Software Configuration Management)と呼び、部品のマネジメントと共にバージョンをコントロールすること、そしてトレーサビリティを確保することが特に重要となります。
簡単にいうと、「構成管理はある時点（バージョン）のプロダクトの部品が一意に特定できるようにコントロールし、記録すること」となります
構成管理というと、以前在籍した会社でITIL Foundationという資格を取らせされたことを思い出しました。
しかし、役に立った記憶はありませんが。
例えば、このバージョンのアプリケーションはAというdllは3.0.0のバージョンでBというdllは2.0.0というような形がバージョンコントロールが出来ている状態となります。
今はJenkinsやCircle CIのような自動ビルドやGitやパッケージマネージャーの仕組みが提供されているので、これらを使っていれば、自然と構成管理は出来ているように感じます。
古い仕組みしか知らない方々をそれをいちいち文書として出してくれと仕事を増やしてくるのですが。
構成管理の目的
構成管理によって得られる効果として、間違ったバージョンのプロダクトを出荷しない、違った欠陥の報告を行わない、ベースとなるバージョンを間違えて開発を始めないなど多数あります。
構成管理をしっかり行なっておけば、開発担当者自身は必要なバージョンや環境を探し回る手間がなくなり、本来の作業に集中できるようになります。
となっております。自身の経験で構成管理がうまくいかなかった例としては、ユーザーへのリリース物と、こちらで管理しているものが一致しないため、それが起因してトラブルになったことがあります。
要はソースリポジトリをきちんと利用出来ていなかったケース。これはソースリポジトリを正しく運用することで解決されます。
もう一つは、手でビルドしていて、テストしていたらビルドに失敗していて、一部の機能が正常動作しなかったことがありました。こちらについても自動ビルドの仕組みを用意することで解決しました。
テストにおける構成管理
例えば、あるテストのテスト手順に対して、そのテストに必要な入力データがわかるように記録されていなかったとします。そうなると、そのテストを再度実行する必要性が生じたときや、次のバージョンでテストを行うことになったときに、テスト担当者はテストデータを何日もかけて探し回ることになるでしょう。
また、あるテストで故障を発見したと気、その故障を再現するためのテストスクリプトが明確になっていないと、修正後の確認テストを行うときに都合の悪いことになるでしょう。
テストにおける構成管理ではテストアイテム（テスト対象プロダクト部品のこと、例えば、ソースコードなど）のバージョンだけでなく、ソフトウェア（テスト計画、テスト手順、テストスクリプト、テスト環境、テスト結果など）が対象になります。
テストシナリオのソースコード管理も検討したことはあります。しかし、スプレッドシートが便利なせいか、それに変わるツールも見つかっておらず、なかなかそうは至っていません。
そういう意味ではテストにおける構成管理が難しいですね。
テストでの構成管理の対象
テストでの構成管理においては、例えば以下のものをマネジメント対象と考えることができます。
- テスト対象となるソフトウェア
- ソフトウェアの動作環境（OS、ハードウェア）
- テストスクリプト、テストデータなど
- 欠陥（故障、インシデント）
- テスト結果
- ドキュメント（テスト計画書、仕様書、マニュアル、評価仕様書、テスト手順書、報告書など）
これらのうち、テスト対象となるソフトウェア、仕様書などは開発側でマネジメントされているものです。しかし、テスト担当者側でも、バージョン、版番号などテストウェアと関連付けて記録しておく必要があります。
テスト成果物も構成管理の対象となります。
テストウェア構成管理の手順
通常、構成管理を行う手順は以下のようになります。
- 構成管理対象を決める
- 構成管理方法を決める
- 記録を残す
- きちんと管理し、必要なときに参照できるようにする
1. 構成管理対象
ソフトウェアプロダクトの場合、構成管理の中身はバージョンコントロールになります。
前述した構成管理対象となり得る成果物の中から、プロジェクトごとに何をマネジメントしたら良いかを選択します。何を構成管理対象とし、どのようにマネジメントしていくかということについてはプロジェクト開始時に決めておく必要があります。
いきなり全てを記録していくのは大変なため、プロダクト規模や性質、組織の規模などに応じてできる範囲でマネジメントする対象を決めていけば良いでしょう。
とはいえ、今、スタートアップ隆盛の時代においては、全般的に開発直後、テストウェアの構成管理を考えるなんてないと思います。まず動くMVPを作るのが大事であり、テスト自体、適当なものではないかなとも思います。
2. 構成管理方法を決める
どのタイミングでバージョン付けを行い、どのようにマネジメントしていくかについてルール作りを行います。
トレーサビリティを確立しておくと、例えば、あるソフトウェアの一部の機能を改造したときに、どのようなテストを行わなければならないかがわかります。このため、効果のあるテストを確実に無駄なく行うことができるようになります。
今はテストの自動化もありますし、どちらかというと開発物、主にソースコードをどう管理するかに引きずられる気がします。
開発物がGitHubで管理するなら、一緒に入れられるものではないかな、とも。
3. 記録を残す
構成管理対象やマネジメント方法が決まり、構成管理を開始したら、更新したバージョン情報などの記録を残していきます。文書として記録を残してもいいですし、構成管理ツールを使用しても構いません。
4. きちんと管理し、必要なときに参照できるようにする
継続してマネジメントし、必要なときにいつでも参照できるようにしておきましょう。中途半端に構成管理を行うと、構成管理による恩恵を受けることができず、作業負荷のみが残ってしまいます。維持管理に努めましょう。
多くの物事について言えることなのですが、最初立派なルールは作るが結果、維持できず暗黙の了解で見てみぬふりで流してしまうとなりがちです。
以前の職場で、改版履歴がきちんと管理されている設計書を見たことがありますが、開発当初は開発リソースが十分あるため、そうしたことが維持できるのですが、その後、予算内の改修のため、手が回らず、設計書が古いままになっていたことがあります。
維持管理が難しい時は、省力化、やめることを考えることも必要だと思っています。記載されているように中途半端な構成管理は意味がありません。
働き方改革、生産性向上と謳われている昨今ですが、そもそもやらなくていい作業を捨てることから始めるべきかなと思っている次第です。
当たり前のこと言っているように思えるかもしれませんが、これがまたやめられないんですよ。大企業は。
リスクの定義
シラバスではリスクを「将来的に「否定的な結果となる事象が起きる恐れを含む。リスクのレベルはそのような事象が起きる可能性とその影響（事象による結果がもたらす損害）で決まる」と定義しています。
リスクの定義は文献ごとに微妙に異なりはしますが、リスク自体には次の2つの性質を持つことが知られています。
- 不確実性 : リスクを有する事象は起きたり起きなかったりする。すなわち100%発生するリスクというものはない
- 損失 : リスクが現実となった場合は、望まれていない結果、または損失が発生する。
つまり、リスクとは発生可能性がある不利益をもたらす「何か」と言えます。
不確実性と損失。この2つの要素を考慮した上で、どういった程度で重要なものとして取り扱うべきかを設定します。
プロダクトリスク
シラバスでは、プロダクトリスクを「作業成果物（仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む」と表現しています。
プロダクトとはテスト対象そのものであり、プロダクトリスクとは、テストが漏れたことにより発生し得る損失や損害に対するリスクと考えれば良いでしょう。
と、ここからプロダクトリスクとプロジェクトリスクの二つについて語られていきます。リスクなんて言葉は当たり前のように使っていると前項で思っていましたが、考えてみればプロダクトリスクとプロジェクトリスクの分類の概念で考えたことはありませんでした。興味深いです。
プロダクトリスクは、プロダクトの要求品質によって異なります。いかにプロダクトリスクの例をいくつか挙げておきます。
- 故障の起きやすいソフトウェアの出荷
- ソフトウェアやハードウェアが個人や会社に対して損害を与える可能性
- 貧弱なソフトウェア品質特性
- 品質特性には、機能適合性、セキュリティ、信頼性、使用性、性能効率性などがあります。レスポンスが顧客の期待を満たしてなければ、製品への信頼感や魅力喪失につながります。
- 貧弱なデータの完全性と品質
- データそのものがデータの内容を規定する標準類に準拠していないことなどが原因でプロダクトが所定の目的を果たせないというリスク
- 予定の機能が動作しないソフトウェア
リスクの洗い出しと優先度付けはプロジェクト計画段階から行い、テスト計画の策定で洗練させていきます。
リスクが高い機能などに対し、リスクが軽減されていることを確認する方法で最もわかりやすいのは、テストを実行して期待通りに動くことを確認することです。
テストは強力な事前予防策の1つであると言えるでしょう。
テストを事前予防策として考慮していない場合、プロダクトリスクが顕在化する可能性が極めて高くなります。シラバスにはいくつか例が挙げられています。
- ソフトウェアの意図されている機能が仕様通りには動かないかもしれない
- ソフトウェアの意図されている機能がユーザー、顧客、および/またはステークホルダーのニーズ通りには動かないかもしれない
- システムアーキテクチャーが非機能要件を十分にサポートしないことがある
- 特定の計算結果が状況によって正しくないことがある
- ループ制御構造が正しくコーディングされていないことがある
- 高性能トランザクション処理システムで応答時間が適切でないことがある
- ユーザーエクスペリエンスのフィードバックがプロダクトの機体と異なるかもしれない
プロジェクトリスク
シラバスでは、プロジェクトリスクとは、「発生した場合にプロジェクトの目的達成に悪影響を与える」と表現しています。
プロジェクトリスクは、いわゆる「ヒト、モノ、カネ」のどの観点にも潜んでいます。
テストの観点でプロジェクトリスクとしてマネジメントすべき対象となる「ヒト、モノ、カネ」について説明します。
ヒト
ヒトの要素はテストを行う組織そのものと、そこに関わる組織とに分けることができます。
テストを行う組織やメンバー
実際にテストプロセスを推進するエンジニアや、そのエンジニアが属する組織を指し、テストマネジメントを行う主体です。スキル不足やトレーニング不足といったメンバー個人に付随する問題や、適切な要員が揃わないといった組織的な問題にまつわるリスクがあります。
人員配置や、配置されたメンバーをどう評価するかといった人事や考課に関わる問題がリスクになることもあります。他には、レビューやテスト実行していたとしても、やりっぱなしで組織的なフォローアップがないために生じるリスクなどが挙げられます。
書いていて、テストに関係なく、どこの会社でもあるあるですね。そして、適切な要員が揃うことなんて、ほぼあり得ないというのが実情です。ワールドカップで優勝するぐらいのチームでもそうでもないかもしれません。
テストに関わる他のプロジェクト内外の組織
プロジェクトマネジメント、開発部門、テスト環境を独自にマネジメント・運営するグループ（テスト自体は行わない）、テクニカルサポートやカスタマーサポート部門といったテスト計画や設計のための情報をやり取りする部門などもします。また、プロジェクトのステークホルダー（マネジメント層、営業・企画部門、お客様）も直接あるいは間接的に関わりを持ちます。
厳しいお客さんで苦労するというのはあったりしますね。スマホゲームだと、他社IPを使って開発する会社もあるので、IPをお借りしている会社との関係性による難しさもあったりするようです。
そういった外部はどうにもできないのですが、悲しいほど内部の連携がチグハグなことが多いです。複数プロジェクト掛け持ちになることが多く、大体、プロジェクトによってはおざなりになることがしばしばです。特に規模の小さいプロジェクト。
## モノ
- ソフトウェア
- テスト対象のアプリケーションやシステム
- OS、ミドルウェア、ドライバ
- ハードウェア
- テストで使用する物理的な環境、計測機器など
- ドキュメント
- テスト設計用ドキュメント
- テスト実行用ドキュメント
- テストスクリプト、テスト用データ
- テストログ、テスト報告書、欠陥レポートなどのテストの成果物
ドキュメント類については、開発に深く関わっていれば、ある程度カバーできるものと思ってます。というかカバーして欲しい。
ただ、難しさではソフトウェア。スタンドアローンのアプリケーションならいいのですが、Webアプリケーションとなると、データベースサーバーやアプリケーションサーバーといったテスト環境を構築する必要があります。そこまでをテストエンジニアが自前で用意するのは、難しいというか、多分できないでしょう。できるとありがたいでしょうけど。
カネ
カネには、予算および実績コスト、コストを管理するための見積もりやスケジュールなどが該当します。
直接テストを実行するための人件費以外に、トレーニング費用、テスト環境整備、維持費用、通信費間接コストも含まれます。
上司が変わってから、予算を取ってくれるようになって良くなったということを聞いたことがあります。
結局、カネでヒトの部分をカバーするのですが、人月の神話になって、うまくいかないというのがオチです。
「ヒト、モノ、カネ」といったプロジェクトリスクのマネジメント対象を、計画段階であらかじめ明らかにしてから、それぞれに対してどのようなリスクがあるのかを洗い出します。その上でリスクへの対策を講じた上で、日々テストマネジメントを行う必要があります。
想定したリスクが現実に起きた場合は、基本的には計画段階で想定した対策を打つべきですが、リスクが発火した時点で当初の対策が現実に即していないなら柔軟に見直しを行わなければなりません。
なお、リスクが発火した時点で顕在化した状態になったなら、発火前のリスクと同一にマネジメントするのではなく、解決すべき「問題」として対策を打てるよう分けて取り扱わないと、対策が後手に回ったり、効果が低くなったりします。
このため、プロジェクトリスクのマネジメントはプロジェクトマネージャーのみの責務ではなく、テストマネージャーのみが責任を負うものではありません。プロジェクト全体進捗のマネジメントとしてはプロジェクトマネージャーの責任の下となりますが、テスト活動の進捗に対する全般的な責任をテストマネージャーが負うことは珍しくはありません。
以下にテストに関するプロジェクトリスクの例をいくつか挙げておきます。
- スケジュールに関するリスク
- テスト環境整備に関するリスク
- テストマネジメントに関するリスク
リスクベースドテストとプロダクト品質
ISTQBではリスクベースのアプローチを採用するとプロダクトリスクを軽減する予防的措置を講じられる、としており洗い出したリスクに対して以下のように対処するとしています。
- 適用するテスト技法を決める
- リスク優先度付けが高いと判断された機能のテストケースには、網羅率が高くなるようテスト技法を選択します。
- 実施するテストレベルおよびテストタイプを決める
- テストを実行する範囲を決める
- テスト実行のための環境をどの程度用意するのかといったこともリスクをベースに考える。ブラウザのシェアでどこまでのブラウザでテストするか、など
- 重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める
- テスト以外の活動でリスクを減らす方法があるか検討する
リスクベースドテストは、プロダクトが、ユーザーの手元で故障を起こす可能性を最小限にするために「リスクベースのアプローチ」を取り入れたテストの方法です。リスクベースのアプローチのためには、さらにリスクの分析と評価、リスクの重要度決め、リスク軽減策の策定のようなリスクマネジメントの視点が重要になります。
リスクベースドテストの進め方としては、リスク分析から着手します。プロダクトリスクに対して、予見できるプロジェクトのステークホルダーの総合的な知識や洞察力を使って行います。リスク分析にて、リスクアイテムが識別され、また、それらに対して重要度を決めます。
プロダクトリスクに対しては、リスクの重要度に基づきテストで事前予防策として対策すべきテストのレベルを決定し、テスト設計に反映していきます。
リスクという観点でテストを捉えるため、重要度の低いリスクに対するテストは動作確認のみにとどめるという選択肢も取れます。重要度の高いリスクに対しては、リスクに対して十分なカバレッジが得られるようにトレーサビリティを明確にした上でテストケースを作成するといったアプローチをとる必要があります。例えば、すべてのプロダクトリスクに対してテストケースがあるかどうかを確認するため、トレーサビリティマトリクスを作成する方法などが考えられます。
計画段階でのリスクの重要度に基づいてテストを実行し、プロジェクトに対してプロダクトリスクがどの程度軽減されているかをテストリーダーからプロジェクトマネージャーやステークホルダーに情報提供します。また、テスト実行を通して明らかになった新たなプロダクトリスクに対しては、その都度重要度を付け、全体的に重要度を見直した上でテストを増減させていきます。リスクはプロジェクトの進展によって常に変化するものであるため、リスクに応じたテストの見直しは非常に重要な作業になります。このようにリスクベースドテストでは、計画段階からリスク重要度を評価し、プロジェクトの進捗に応じてリスクの軽減状況を把握しながらテストを見直していきます。
リスクベースドテストについて詳しく知りたい方は、Advanced Levelのテストマネージャーのシラバスを参照してください。と締めくくっています。
せっかくなので少し見てみます。
https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf
リスクベースドテストは、次の 4 つの主な活動で構成されます。 - リスク識別 - リスクアセスメント - リスク識別したリスクを可能性や影響を判定する - リスク軽減 - リスクをカバーするように、テストを計画、実装、および実行します。リスクが高いとより精緻なテスト技法（ペアワイズテスト）を活用し、一方、リスクが低いと、あまり精緻でないテスト技法（同値分割方法やタイムボックスを使った探索的テストなど）を使用します。 - リスクマネジメント - ライフサイクル全体でリスクマネジメントを行うのが理想です。
欠陥マネジメント
シラバスでは「検出したすべての欠陥を調査し、発見や分類から解決にいたるまで追跡する必要がある」と記載しています。
とはいえ、欠陥というのは大量に存在し、全てを追跡するのは無理があるのが現実かなとも。
欠陥の特徴
テストケースで定めた入力に対して期待した結果と異なる事象（つまり故障）の引き金が欠陥だといえます。期待した結果と実際の結果が異なるという事象を認識し、そこに欠陥があるため調査が必要だとわかることがほとんどです。
このため全てが明らかに欠陥だと区別できない場合があります。そういった事象をシラバスでは不正と表現しています。
故障や不正の中には調査した結果、テスト対象そのものに欠陥が存在しているわけではなく、タイミングやテスト対象に影響を及ぼす外部環境により、テストでの観測から期待結果と異なることが判明し、欠陥ではないと判断する場合があります。このことをシラバスでは欠陥レポートに偽陽性があると説明しています。
と、欠陥、故障などと言葉が出てきました。１章で解説されたのですが、再びおさらい。
- エラー（誤り）:間違った結果を生み出す人間の行為
- 欠陥(Defect):作業成果物に存在する、要件または仕様を満たさない不備または欠点。バグ、フォールトも同様
- 故障(failure):コンポーネントやシステムが定義された範囲内で要求する機能が実行しないこと
よくあるのはテストしたのですが、期待結果が異なる。
なんか、おかしいんだけど？みたいな聞かれ方をすることもあります。この時点では不正ですね。
で、担当にこれは故障かと確認してみたら、仕様が変わったためで、故障ではないということが多いです。
話を戻します。
故障の発見をその元となる欠陥の検出はテスト実行期間中だけに行うものではありません。開発中、レビュー、テスト実行以外のテスト活動そしてシステムの稼働中に現れます。また、欠陥は、コードに埋め込まれるだけではなく、開発やテストのドキュメント、インストールガイドやヘルプのような種類のドキュメントにも存在します。
と、コードだけではなく、テストのドキュメントにも欠陥があると。これは頭が痛いですね。仕様の変更にテストケースが追いついていないことが多いので、こうした欠陥を減らしていきたいところです。
欠陥マネジメントの必要性
欠陥を処理するために、適切な活動を定義します。欠陥は、検出時点から分類、修正、最終確認まで、きちんと追跡しなければなりません。その対策が終了するまでマネジメントできなければなりません。欠陥の対応が終了するまでのステップは組織によって異なりますが、おおよそ次の通りです。
- 故障（もしくは不正）が発生したことを認識する
- 故障（もしくは不正）を記録する
- 故障（もしくは不正）の原因を調査する
- 影響範囲を分析し、欠陥を分類する
- 修正が完了するまで待機する
- 修正が終わったことを確認する
これは、文句なしですね。おおよそこの通りです。
影響範囲を分析し、欠陥を分類するのフローについての粒度は割と流動的です。細かく分類わけしろとうるさく言われることがありますが、正直、そんなことをやっている場合ではないことが多いですし、僕はこれが有効に活かされる印象を持っていません。
すべての欠陥を上記のようにマネジメントするためには、欠陥レポートとして残さなければなりません。そして、組織で欠陥マネジメントのためのプロセスを決め、分類のための規則を設ける必要があります。
欠陥レポート
欠陥をマネジメントするためには、発生した全ての欠陥を記録しなければなりません。欠陥を記録するのは、テスト担当者だけではありません。開発担当者であったり、場合によっては顧客かもしれません。顧客が期待した結果と違う時、つまり故障（もしくは不正）として認識した時に、欠陥を記録することになるからです。
記録してるでしょ。と思われがちですが、組織が大きくなると実はそうでもないのです。営業が顧客から受けた故障の報告が開発に伝わってないということがありました。ゆえにいつになったら対応されるんだと、顧客の怒りを買うなんてことが起きるのだそうです。
この欠陥レポートには、以下のような目的があるとシラバスに記載しています。
- 開発担当者や他の関係者に対して、発生したあらゆる期待に反する事象についての情報を提供する。また、必要に応じて、もしくは問題を解決するために、具体的な影響を識別して、最小の再現テストで問題の切り分けを行い、欠陥の修正ができるようにする
- テストマネージャーに対し、作業成果物の品質や、テストへの影響を追跡する手段を提供する（欠陥の報告数が多いと、テスト担当者は多くの時間をテスト実行ではなく報告作業に費やす必要があり、さらに多くの確認テストが必要になる）
- 開発プロセスとテストプロセスを改善するためのヒントを提供する
欠陥レポートの構成
シラバスに記載されている一般的な記載内容
- 識別子
- レポート対象の欠陥の件名と概要
- 欠陥レポートの作成日付、作成した組織、作成者
- テストアイテム（テスト対象の構成アイテム）および環境を識別する情報
- 欠陥を観察した開発ライフサイクルのフェーズ
- ログ、データベースのダンプ、スクリーンショット、（テスト実行中に検出された場合は）実行状況などの欠陥の再現と解決を可能にする詳細な説明資料
- 期待結果と実際の結果
- ステークホルダーに与えるインパクトの範囲や程度
- 修正の緊急度/優先度
- 欠陥レポートのステータス
- 結論、アドバイス、承認
- 欠陥の修正が他の領域への影響を与えるといった、広範囲にわたる懸念事項
- プロジェクトチームのメンバーによる欠陥の切り分け、修正、確認といった一連の修正履歴
- 問題を明らかにしたテストケースを含む参照情報
多いですね。
今の時代、何かしらのチケット管理ツールを使うので識別子や欠陥レポートの作成日付などは、自動的に生成されるでしょう。
期待結果と実際の結果をきちんと書いてくれる人はいないです。ただ、期待結果、あるべき結果がわからないこともあります。
なので、難しいんですよね。
最初からきちんと書いてくれは厳しいので、テスト担当者なりが間に入って、きちんとした内容にするのがいい気がしています。
ぼくは外注のテスターさんにテストをお願いして、報告を受けた時に再現するかは確認していますが、そのタイミングで整備するのがいいのかな、とも思います。
形式ばかりにこだわってしまうと、ちょっと気になることを報告しづらくなります。偉そうな態度のでかい上司には声をかけづらいのと一緒です。
欠陥マネジメントのプロセス
欠陥マネジメントのプロセスには、欠陥レポートの状態遷移に着目する場合と、ワークフローに着目する場合の2種類があります。それぞれ、メリット・デメリットがありますが、ツールを活用して欠陥マネジメントを行う場合には、欠陥レポートの状態遷移に着目するのが良いでしょう。
今は、オープンとクローズだけですね。これでも回せます。
今の職場はうるさくいう上司なんていないのでいいですが、そういう上司がいると、状況がどうなっているかわからん、俺が瞬時で判断できるように見やすくせい！みたいになるので、きちんとしたステータスが必要でしょう。
オープンとクローズだけで管理しているとはいえ、実際には、より複数の状態を持っているのは事実です。
ざっと思い浮かんだのを書いてみると、こんな感じですね。
- オープン
- 再現確認
- 原因調査
- 不具合修正
- 修正確認
- クローズ
再現確認は、ただの起票ミスだったりするので、開発に時間を取らせないためや切り分けのために行うこともあれば、なんか起きるんだけど再現手順がわからないという時、再現手順を確立するためにそれが上手い人にお願いすることがあります。
そこからは原因調査から不具合修正。ただ、今の所、原因調査と不具合修正を別々の人がやることはあまりありません。
たまに、再現確認ついでに勉強がてら原因調査までしてみるかと、ぼくはやったりします。
修正確認は、欠陥レポート上では依頼せずに、GitHubのプルリクエストで確認して済ませたりします。
不具合ってモノによって様々なので、どれもこれも同じ粒度で細かくやっていてはキリがないんですよね。捗りません。
この手の仕組みを構築する手伝いをさせられたことがありますが、そんないちいち担当者を選んでられないよ、とか言われてしまったこともあります。特に営業さんや年配の方はパソコンを使ってシステムを使うことに慣れてませんので。
ここまでが第５章。
長いです。そして、模擬問題にも苦戦しました。
