テストリーダへの足がかり,最初の一歩

第11回 テスト実行(中編)

この記事を読むのに必要な時間:およそ 3 分

バグの状態を定義しよう

大塚先輩:
ここにあるインシデントレポートの今の状態はどうなっているの?
中山君:
状態ですか……?
大塚先輩:
このままファイリングされるわけではないよね。どうするんだ。
中山君:
開発者にバグを直してもらいますので,開発者に渡します。
大塚先輩:
直してもらったらどうなるんだ。
中山君:
再テストします。
大塚先輩:
この流れの中でバグの状態は変わっているのはわかるだろう。
中山君:
はい。
大塚先輩:
うちの会社では,バグの状態はあらかじめ決まっているんだ。品質管理規程を調べておかなきゃ駄目だよ。

バグの状態を確認しよう

インシデントレポートをただ書けばよいというものではありません。バグが除去されたことを確認するまで,インシデントレポートは生き続けます。インシデントレポート,つまり,バグは状態を持ち,さまざまなイベントによって状態を変え続けます。

バグの状態は,次のように定義されるのが一般的です。

  • インシデントレポートを書いたタイミングで「Open」
  • バグを修正する担当者をアサインしたタイミングで「Assigned」
  • バグを修正したタイミングで「Resolved」
  • 修正が正しいことを確認したタイミングで「Verified」
  • 再テストが完了したことを確認したタイミングで「Closed」

しかし,バグの状態は組織によってさまざまに定義されています。リーダは,自分が属している会社,または,発注先が指定している状態を確認する必要があります。

バグ管理のワークフローを確認しよう

大塚先輩:
ところで,このインシデントレポートはどうするつもりだったんだい。
中山君:
はい,いつものように開発者に渡そうと思っていました。
大塚先輩:
開発チームとどのようなやり取りをするか合意していたかい?
中山君:
えっ,開発者にインシデントレポートを渡すのは当たり前だと思っていましたが。
大塚先輩:
どのようなタイミングで渡すんだい?
中山君:
インシデントレポートを書いたら直ぐに渡そうと思っていました。
大塚先輩:
開発チームもそう思っているの?
中山君:
……。
大塚先輩:
そのレポートは誰に渡すんだい? 開発チームだったら誰でも良いわけではないよね。

バグ管理のワークフローを確認しよう

インシデントレポートを開発者に渡し,欠陥を除去してもらい,再テストを行います。この流れの中に多くの人が携わり,さまざまなチェックポイントがあります。

「テスト実行」におけるテストリーダは,テストの実行だけを管理すればよいというわけではありません。バグ管理に関しても責務を負っています。

多くの組織では,バグ管理のワークフローが決まっていますので,どのようなワークフローで行えばよいのか確認します。ワークフローが決まっていない場合は,開発とテストの両チームで打ち合わせをもち,ワークフローを決める必要があります。

BTSを用意しておこう

バグやインシデントの管理はそのステータスや情報の管理はExcelベースで行うとかなり大変です。そこで利用をおすすめするのがBTS(バグ・トラッキング・システム)です。BTSを導入することでインシデントレポートの管理が自動化され大変楽になります。また,情報の一元管理が行えます。多人数でテスト実行を分担したり,拠点が分散している場合にこのBTSは大きな効果があります。このBTSについての詳細は連載の範囲を超えますのでここでは割愛しますが,山本健さんの連載記事「ソフトウェア開発の必須アイテム,BTSを使ってみよう」を参考にして導入すると良いでしょう。また,さらに興味がある方は「ソフトウェア構成管理」「変更管理」というキーワードで情報を調べてみることをおすすめします。

今回は小川君のまじめさと機転故にいろいろとアドバイスをもらうことになってしまいました。皆さんも自分を振り返ってみてはいかがでしょうか。

次回は千秋ちゃんと中山君へのアドバイスです。

参考:インシデントレポートに記入すべき内容

インシデントレポートに,以下の詳細情報を記入する。

  • ログの作成日付,作成した組織,作成者
  • 期待した結果と実際の結果
  • テストアイテム(構成アイテム)および環境の識別
  • インシデントが発生したソフトウェアやシステムのライフサイクルプロセス
  • 再現および解決を可能にするインシデントの記述,たとえばログ,データベースのダンプ,スクリーンショットなど
  • 対応するステークホルダに与えるインパクトの範囲や程度
  • システムに与えるインパクト
  • 修正の緊急度/優先順位
  • インシデントのステータス(例えば,オープン,次バージョンへ延期,重複,修正待ち,再テスト待ち,解決済みなど)
  • 結論,アドバイス,承認
  • 外部との問題。例えば,インシデントを修正することで他の分野に及ぼす影響
  • 修正履歴。例えば,インシデントを抽出し,修正し,修正が正しいことを確認する時にプロジェクトチームのメンバが実施した作業など
  • 問題を摘出したテストケースの仕様のID番号など参照情報

『ISTQBテスト技術者資格制度Foundation Levelシラバス』より引用

著者プロフィール

鈴木三紀夫(すずき みきお)

1992年,(株)東洋情報システム(現TIS(株))に入社。複数のエンタープライズ系システムの開発に携わり,現在は社内のソフトウェアテストに関するコンサルタントとして活動中。ASTER理事,JaSST実行委員,JSTQB技術委員,SQiPステアリング委員 他。

著書


池田暁(いけだ あきら)

2002年日立通信システム(現日立情報通信エンジニアリング)に入社。設計,ソフトウェア品質保証業務を経て,現在は開発に関する設計/テストツールの導入や,プロセス改善に関する業務に従事。ASTER理事,JaSST実行委員,品質管理学会・ACM正会員。

著書