スポンサーリンク

テストマネージャになったら，どうする？ SEの視点での書評：「現場の仕事がバリバリ進む ソフトウェアテスト手法」

book テスト プロジェクトマネジメント

現場の仕事がバリバリ進む ソフトウェアテスト手法

現場の仕事がバリバリ進む ソフトウェアテスト手法

ソフトウェアテスト手法，技術評論社，2006。


テスト工程を「テストマネージャ」の観点から見た場合，

何から手をつけて，どうやって進めていけばよいのか。


特に，テスト自体の要件定義（マスターテストプラン）や，テストの基本設計（テスト分析）の成果物を，

どのように文書化したらよいのか。


そういった，いち担当者レベルよりももっと上の，マネージャレベルでのテスト工程の進め方が書いてある本。



開発の場合，工程の分類は下記のようになる。

  1. 立ち上げ
  2. 要件定義
  3. 基本設計
  4. 詳細設計
  5. 実装
  6. テスト
  7. リリース

ここで，テスト工程だけに注目してそれをさらに細分化し，上記の工程分類を再度当てはめてみよう。


テストマネージャの観点で，テスト工程を時系列で列挙するとどうなるか。

書籍の内容を自分なりに再解釈すると，下記のようになる：

  1. テストマネージャに任命される。
  2. 「テストの立ち上げ」をする。概要レベルで，テスト対象の把握，見積もり，作業準備。
    1. テスト対象の機能を洗い出して「テスト要求一覧表」とする
    2. コアメンバを中心に人を集める。テスト担当者１人あたりが見つけ出すバグの数を最大化するようなちょうどよい人数にする（開発者の半数弱など）
    3. APやNWの環境把握し，テストに必要な機材調達。BTSなどテストインフラも準備。
    4. 開発メンバ側とのコミュニケーション方法を定義
  3. 「テストの要件定義」をする。「マスターテストプラン」を作成。「テスト工程で何が求められているか」を大まかに書く。
    1. テスト対象の要約と，テストアイテム・テスト対象機能の列挙
    2. アプローチ。
      1. 単体・統合・システム・受け入れといったテスト種別ごとに，誰が，どの粒度の，どんな目的のテストをやるのか。
      2. バグ管理方法。
      3. 利用するテストツールやメトリクス
    3. テストアイテムの合否判定基準，中止基準，再開基準。
    4. テスト成果物を列挙。
    5. 人員計画
  4. 「テストの基本設計」をする。「テスト分析」を行なう。「テスト工程を大体どのように行なってゆくのか」を書く。テストケース作成作業の方針が決まる。
    1. テスト対象の情報を収集して理解する
    2. テスト対象の要求や仕様を整理し一覧にする
    3. 要求（縦軸）に対するテスト種別（横軸）を具体化する。そして「テストマトリックス」にする。
      1. テスト種別ごとに，テストケース作成方法やテスト実施方法，特別な考慮点を決定
    4. 複雑なものや優先順位の高いものを明らかにし，そのテストケース作成方針を早めに具体化。（負荷テストの実行環境とか）
    5. テストケース作成方針を決定
      1. テストベース（テストケースのネタ本）を決定（この時点で開発側のドキュメントも揃いだすので）
      2. テストケースの分類と管理方法
      3. テスト仕様書の目次を書く（機能名称から，テスト項目までブレイクダウンする）
      4. テストケースの粒度を決定（入出力の値の１ペアとするか，または同値分割された１つのクラスとするか）
      5. テストパスを決定（ビルド確認用最低限パス，リリース用全網羅パスなど）
    6. 開発側で不足しているドキュメントがあったらこの時点でテストチーム側が作ってしまう
  5. 「テストの詳細設計」をする。テストケース作成。
    1. 機能テスト：遅かろうが，機能が動けばよし
    2. ドメインテスト（境界値テスト）：境界の前後を試す
    3. スペックベーステスト：ユーザマニュアル通りか試す
    4. ストレステスト：最大負荷ポイントとその前後を検査
    5. 回帰テスト：バグが正しく修正され，その横展開も余波も無いことを確認
    6. シナリオテスト：製品でなくユーザに注目。良いユーザと悪意のあるユーザを想定。
    7. 状態遷移テスト：状態遷移図から状態遷移マトリクスを作り，全マスを網羅。
  6. 「テストの実装」をする。テストケース消化。
    1. BTSなどのバグ管理ツールを活用する。進捗や発生バグ数のモジュール別グラフも見れると良い
    2. １日あたりの目標を決めて，テストケースを消化してゆく
    3. 随時，バグレポートを作成し，トラッキングする
  7. 「テストのテスト」をする。統計情報から品質を算出。
    1. バグ分析を行い，バグをタイプ別に分類し，品質情報を提供する
    2. オープンクローズチャートなどを描画して，テスト自体の作業の成果（確保された品質）を明示化する
  8. テストのリリース。
    1. 要求された品質を確保できていることの証跡など，成果物類を提出する。

この本で力を入れて詳しく書いてある部分：

  • マスターテストプラン：２章
  • テストの分析・設計：３章
  • テストチームの運営，テスターの面接方法：10章


用語の使い分け：

  • 「テスト条件（テスト項目）」：１つの仕様項目に対応する。APが満たすべき１つの仕様項目を「〜であること」と書き下したもの。
  • 「テストケース」：１つのテスト条件に対して，１つ以上作成する具体的なテスト手順。

実践


テスターの面接の方法は参考になった。

  • 目の前にあるホチキスのテストケースを書かせる
  • 自動販売機とか身近なもののテスト方法を考えさせる
  • メモ帳とか，ありふれたソフトを使わせて，バグを見つけろと命じる。その際にとるアプローチ（境界値とか）に着目する。

これは，普段から自分の身の回りをどう見るか，日常のものの見方にも影響する。


こういう見方ができる人は，物事を体系的に把握してタスクを定義・分割したり，

現実世界を手早く正確にモデリングしたりする能力に長けることになるだろう。



また，具体的な数値例や実例があちこちに掲載されており，とても参考になる。

例えば：

  • 80％以上のエンジニアはブラックボックスでテストする。
  • 平均的なテストケース量は，１FP（ファンクションポイント）あたりの1.3乗である。
  • バイクに乗って怪我をする確率は，1000時間当たり0.1。高信頼性SWが障害を起こす確率もそれぐらい。
  • 素人を集めて単純作業をさせるぐらいなら，それはツールで自動化すべき。そして自動化が不可能ならオフショアする。中国なら，優秀な人材が月25万円。
  • SW開発の全コスト中で，テストは３〜４割という調査結果。
  • Microsoftでは開発者１人に対しテスタ１人がおり，テスタ用にドキュメントを書く手間は減る。
  • ２：８の法則より，バグの多そうな場所にテストケースをフォーカスせよ。


また，ドキュメント等を作成する上で参考にすべき「標準」類も紹介されていた。

  • 開発プロセスの標準は，ISO9001で定義されている。
  • ソフトウェアの品質は，ISO9126で定義されている。


ボキャブラリも増える。

  • TBD（To Be Determined）：決定待ち
  • GQM分析（メトリクスの選定方法）
    • Goal：まず目標を明確にする
    • Question：目標達成のために何が必要かという一連の質問を作成
    • Metrics：質問に答えるために必要な各種数値を定義。これらが収集対象のデータとなる
  • 医療で言う「トリアージ」
    • 負傷者を選別することによって，より多くの負傷者の治療を可能にすること。
  • COTS（Commercial Off-The-Shelf）：外部から購入してきた製品のこと


なお，この本の主題はあくまで「テスト手法」であり，

デシジョンテーブルなどの細かな「テスト技法」は，あまり説明されていない。

この本に対する他の書評


実際にテストする上で割り切るところは割り切る。一通り、勉強したあとで、理論に溺れず現実に戻るためにもう一度読み直すのもよい
http://booklog.jp/asin/4774127116


テストマネジメントより。Good Enough Qualityという考え方。筆者はてーげーソフトウェアといっている
http://d.hatena.ne.jp/xenop/20090309/p1


私自身は大体プロジェクト全体の３分の１をテストの工数に割り当てるが大抵「なんでテストにこんなかかるの」って言われる
http://blog.setunai.net/20061104/%E3%...



　

language_and_engineering 読者になる

広告を非表示にする
スポンサーリンク
スポンサーリンク