5.1 テスト組織
5.1.1 テスト組織と独立性
故障や欠陥を見つけることに対する客観性が欠如する
特に高位レベルのテストでは利用者の立場で考えることが大事
独立したテストチーム
開発とのコニュニケーションの取り方
開発チームとの協調性が重要な提案をする場合は上位管理者の明確な要請を受けてからするべき
一方的にテストプロセスを強要すると開発チームと対立してしまう
慢性的な対立が続くとテストチームが孤立してテストの組織として機能しなくなる
独立した組織の形態
同じ開発プロジェクト内の独立したテストチーム
本来の独立性はない
プロジェクト納期やコストなどの品質以外の要求の圧力を受けている
同じ会社内にある独立したテストチームで、プロジェクトマネージャーや上位管理者の直属組織
プロジェクトに関する圧力はかかりにくい
品質保証部とかQA室とかの外部組織だとこれに当たる?
顧客、ユーザーコミュニティから派遣された独立したテストチーム
利用者視点のテストチーム
ソフトウェアに対する要求は理解している
プロジェクトに対する圧力などは排除できる
ユーザによるクローズドベータテストとか??
標準準拠 = ソフトウェアが基準や規定に準拠していることを認定すること
組織外の独立したテストチーム
他の事業部門や協力会社など外部組織に委託したメンバーで構成されたテストチーム
作り手と完全に独立する
独立したテストの利点と欠点
メリット
先入観がないため、開発担当者と異なる視点で欠陥を見つけられる システムの仕様策定中や実装中に想定どおりかを検証できる
デメリット
開発チームから拒絶されていることも…
念密に協調していくことが大事
「テストはテストチームがやるので品質の確認は任せています」
欠陥を未然に防いだり、実装段階のテストレベルで取り除くことができない 5.1.2 テストリーダとテスト担当者の作業
プロジェクト全体を考慮してテストの計画を立案し、テスト活動状況をモニタリング・コントロールする
プロダクトマネージャー、開発マネージャー、品質保証マネージャー、テストグループのマネージャーがこの役割をする
代表的な作業
テストの観点から、テストプロセスの提案などを通じてプロジェクトの他の活動(ビルド計画とか)に貢献する テストの目的、リスクを理解してテストを計画する
プロジェクトの状況を考慮してテストの仕様化、準備、実装、実行を開始し、結果の測定と終了基準を満たしているかを確認する
テスト結果やテストの進捗に基づいて計画を必要に応じて修正する
問題を補正するための対策をとる
トレーサビリティ向上のため、テストウェアの十分な構成管理を検討し、セットアップする テスト対象の仕様、テストの仕様書、テスト結果など
進捗の計測、品質の検証
どんな作業をどの程度、どのように自動化するかを決定する
構築するテスト環境や構築する個数を決める
関係者とテストに適切な環境、リソースを協議しながら
適切なタイミングでテスト期間中に収集した情報をベースにテストレポートを書く 代表的な作業
テスト容易性の観点で、要件、仕様、モデルの分析・レビューする
テスト環境のセットアップ、実施中の管理
テスト実行に必要なデータの入手・作成
テストを実装、実行し、テスト結果を文書化して報告する
必要に応じて、テストコントロールツールやマネジメントツールを使う
テストを自動化する
必要に応じて、コンポーネントやシステムの性能を計測する
他の技術者が実施したテストをレビューする