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

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

【今回の登場人物】

大塚先輩:
入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で、暇さえあれば写真を撮りに出かける。
中山君:
入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。
小川君:
入社2年目。新人研修後、その有望さから半年間顧客先に常駐。テスト業務の他、設計作業も経験を積んできた。趣味はベースで、定期的に仲間とライブを行うなど仕事と趣味を両立している。

状況説明

いよいよテスト実行の工程に入り、まずはそれぞれがテスト実装で分担した範囲のテストケースを実行することとなりました。15時になりお互いの状況を確認するために会議室に集合した3人でしたが、問題が山積みでした。

中山君が頭を抱えているところに、他のプロジェクトに行ったはずの大塚先輩が顔を出しました。

大塚先輩:
やはり混乱してるみたいだね。
中山君:
どうもすみません。今度こそはうまくやろうと思っていたんですが…。

アドバイスをもらうため、中山君をはじめ小川君や千秋ちゃんはそれぞれの状況を大塚先輩に報告することにしました。

ようやく「何か重大な問題が起きた場合には早期にエスカレーションを行う」ということがわかってきた中山君です。

大塚先輩:
…なるほど。こりゃまたいろいろとあるなぁ。
大塚先輩:
じゃ、ひとつずつ指摘をしていこうか。

テストの実行結果とバグの情報は適切に記録しよう

大塚先輩:
小川君のテスト実行結果とインシデントレポートを見てみよう。
大塚先輩:
小川君、君はフォーマットがなかったから自分なりに作ってみたと言っていたね。
小川君:
はい、特に指示されませんでしたので、自分なりにやりました。
大塚先輩:
まず、それが1つめの失敗だ。フォーマットのあるなしは個人が勝手に判断すべきではない。まずは責任者、今回は中山君に確認を取るべきだった。
大塚先輩:
中身を見てみようか。まず目につくのは、実行者はいいとして、観察者がないことだね。
小川君:
観察者ですか……。今回は個別にテストを実行することと指示が出ていましたので、そこは考えていませんでした。
大塚先輩:
インシデントレポートの文章の書き方についても2~3ある。情報は事実を客観的に書くべきで、そこに自分の私情を入れてはならない。見直してごらん、気になるところはたくさんあるはずだよ。
小川君:
なるほど… 確かにそう。
大塚先輩:
こういったことを防ぐためにはどうすればいいかな? 中山君。
中山君:
レビュー… ですか?
大塚先輩:
そうだ。何か成果物がある場合、できるだけリーダは目を通すことが必要だ。特に公式文書となりえるものは、だ。

実行結果のログとインシデントレポートは情報の源

テストケースの実行結果のログやインシデントレポートの中身は、品質状況を測るための情報として取り扱われたり、バグの調査の情報となります。長年組織で改善されながらできあがったそれらのフォーマットは、これらの情報を記録し損なわないようにするためにできるだけ利用することを心がけましょう。

また、場合によっては社内の開発プロセスにおいて使用が義務づけられている場合があります。大塚先輩は小川君に対し責任者に確認を取るようにとアドバイスをしていますが、本来ならば中山君がフォーマットを提供し、記述内容の詳細について説明をしなければなりません。

なお、インシデントレポートに記述すべき項目として『ISTQBテスト技術者資格制度Foundation Levelシラバス』で述べていることを、この記事の最後に示します。

テスト実行にはできる限り観察者/確認者を付ける

小川君の作ったテスト実行結果のログを見ると、実行者の欄はありますが、観察者/確認者の欄がありません。この場合の観察者/確認者とは、テスト実行者が確実にテストケースを手順に沿って実行しているかを確認します。

テスト実行者も人間ですから、ヒューマンエラーの混入を根絶するのは困難です。観察者/確認者を置くことで、可能なかぎりこのヒューマンエラーが混入することを防ぎます。

また、そのテストケースが実行されたとき、それが一人の目で確認されたのか複数の目で確認されたのかは、後々テスト結果を評価する場合の判断基準の1つになります。現実としてペア以上でテストケースを実行していくのは難しい場合もありますが、そこはそのテストやテストケースの重要度によって判断をしましょう。

インシデントレポートは人のことを考えたレポートに

小川君が作成したインシデントレポートを見ますと、小川君個人の見解を見つけることができます。インシデントレポートは事実を客観的に書き、個人の見解は必要ありません。個人の見解は事実を惑わす危険性があるほか、書きようによってはインシデントレポートを受け取る設計者などの心証を悪くしてしまう場合があります。

インシデントレポートの書き方の詳細については本稿では取り扱いませんが、⁠誰が何のために読むのに作成されるのか」を意識しておかねばなりません。そしてその意識の情勢は中山君が言ったとおりレビューなどを通して行います。リーダはインシデントレポートのように他部門に送付される文書についてはできるだけレビューを行ってその記述内容の品質を確認するようにしましょう。

インシデントレポートの記述レベルを合わせるために

今回のケースでは、人数が少ないためお互いにインシデントレポートをレビューし合えば、記述レベルを揃えることができます。しかし、大規模開発の場合はどうでしょうか。あらかじめインシデントレポートの書き方や起票の基準を学ばなければ、つまり、一人一人が好き勝手にインシデントレポートを発行してしまったら、プロジェクトは混乱してしまいます。ある人がバグ一件だと判断しインシデントレポートを一枚発行したとしても、別の人はバグ十件だと判断することもあります。これは管理する立場としては、大変困った状況になります。

バグの状態を定義しよう

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

バグの状態を確認しよう

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

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

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

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

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

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

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

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

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

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

BTSを用意しておこう

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

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

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

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

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

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

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

おすすめ記事

記事・ニュース一覧