コラム
TOP >  コラム >  コラム詳細

あるトラブル案件のテスト推進の顛末  第2回 : テスト担当者としてなにをやったか

■はじめに

1つのプロジェクトが社内でトラブル案件に認定された。

そのプロジェクトは、

  ・顧客とのコミュニケーション不全
  ・管理されず山積したチケット
  ・疲弊したメンバー

など多くの問題を抱えていた。

(詳細は前回の「トラブル案件に認定、その時なにがおきていたのか」参照)

残された1か月の猶予期間の中で、問題を解決し、リリースまで持っていくことをミッションとして与えられた我々が、実際にどのようなアプローチをとってプロジェクトを収束させていったかについてこれから数回に渡ってみていく。

まずは、テスト工程の責任者として、新たにプロジェクトにアサインされた筆者が、プロジェクトに対して行ったアプローチについてみていきたいと思う。


飯田秀樹/福良智明
株式会社オープンストリーム(http://www.opst.co.jp/)において、テスト推進チームとしてプロジェクトに従事。品質向上とプロジェクト事故撲滅のため何ができるか日々奮闘中

■現状の把握

プロジェクトにアサインされ、最初に行ったことは、なにはともあれ現状の把握である。

アプリケーションを実際に動かして確認、各工程で作成されたドキュメントの確認、プロジェクトメンバへのヒアリングを通じて、現状の品質レベルを確認した。

現状の品質を確認する際に気を付けたポイントしては、

  ・アプリケーション動かしてみて見つけた不具合は、どのテストレベルで
   検出すべき不具合なのか

  ・存在するドキュメントをテストベースとした場合に、どのテストレベルなら
   実施できるか

で、立ち返るべきテストレベルはどこなのかを意識して確認を行った。


■みえてきた問題点

現状の把握を行ってみて、

  ・ボタン押下など画面イベントを行うとエラー画面に遷移するなど、単体テスト
   レベルの不具合が発生していること

  ・設計書に単体テストでの確認に必要な、詳細な処理定義と画面イベントの
   記載が漏れていること

  ・結合テストでの確認に必要な機能間の関連が記載された設計書(業務シナリオ、
   ユースケース、DFD)がないこと

が分かった。

当初は、最低限単体テストレベルの品質くらいは保証されており、不具合が多く発生して品質が低いとされているのはきっと一部の複雑な機能だろうと高を括っていたのだが、それは見事に裏切られた。

事態は、予想以上に深刻なものであった。


続いて、「問題点に対して行った対策」を紹介していく。

1| 2| 3

>

>>



第1回 第3回


連載一覧

1| 2

>

>>