【今回の登場人物】
- 大塚先輩:
- 入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で、
暇さえあれば写真を撮りに出かける。 - 中山君:
- 入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。
- 大塚先輩:
- さて、
さっそく見ていくことにしようか。 - 中山君:
- はい、
よろしくお願いします。 (ドキドキ) - 大塚先輩:
- まず最初に…、
表紙を付けたのはいいね。最初の計画書に表紙を付ける人はあまりいないんだ。よく気づいたね。 - 中山君:
- 今までの計画書を参考にしました。
- 大塚先輩:
- で、
中身なんだが…これはずいぶんと薄いね…… - 中山君:
- (あれれ、
何か足りなかったのかな…) てっきり、
すんなりとOKがもらえると思っていた中山君はうろたえました。 - 大塚先輩:
- 中山君、
この計画書には何を書けばいいと思う? - 中山君:
- 何を書けばいいって……。スケジュールは重要ですよね。スケジュールが無い計画書って見たことありません。
- 大塚先輩:
- スケジュールは重要だよね。他には?
- 中山君:
- 体制図も入れました。でも、
それだけじゃ計画書として不十分なんですか? - 大塚先輩:
- そう。確かに中山君が書いたものも計画書と言うこともあるけれども、
この内容だけでは、 うちで仕事をするには不十分なんだ。 - 中山君:
- でも…。たくさん書いても計画って結局使わないですよね? 無駄じゃないですか。
- 大塚先輩:
- 無駄にするかどうかはリーダの腕次第だ。そう思わないかい? 立派な計画書に見せるために、
意味のない情報を羅列している計画書ならば、 俺も無駄だと思う。でもそうじゃないよね。
目的は何?
- 大塚先輩:
- まず聞こう。今回のテストの目的はなんだと思う?
- 中山君:
- テストの目的ですか? バグを見つけるためではないんですか?
- 大塚先輩:
- テストにはいろんな目的がある。目的が変われば、
テスト設計の方針やテストケースも変わってくる。 - 中山君:
- え? そうなんですか?
テストの目的
テストの目的はおおむね3種類に分けることができます。
- 不具合を予防するため
- バグを見つけるため
- 品質を保証するため
バグを見つけるためのテストケースと、
テストの定義とテストの範囲
- 大塚先輩:
- 次に、
どんなテストをするつもりなんだい? - 中山君:
- えっ? 普通のテストですけど…。特別何か変わったテストをするつもりはありません。
- 大塚先輩:
- コンポーネントテストなの? システムテストなの?
- 中山君:
- システムテストです。
- 大塚先輩:
- じゃぁ、
システムテストの定義は? - 中山君:
- みんながやっているテストと同じことを今回もやろうとしています。新しめのテクニックとか使うつもりはありません。
- 大塚先輩:
- …質問を変えよう。どの範囲をテストしようと思っている?
- 中山君:
- 範囲ですか? 仕様書に書かれている範囲をテストしようと思っています。
- 大塚先輩:
- 仕様書に書かれていたら、
全部やるのかな? - 中山君:
- 全部はできません……。 何となくわかってきました。そういうことなんですね。
テストの定義
テストレベルやテストそのものについての定義を計画書に記述するかどうかは、
しかしながら、
テストの範囲
行うべきテストの定義が決まったら、
計画書を読ませるターゲット
- 大塚先輩:
- ところで、
この計画書を読んでもらう相手は誰なの? - 中山君:
- 大塚先輩です。
- 大塚先輩:
- そうじゃなくて、
誰のために書いたの? - 中山君:
- 特に決めていません。強いて言えば、
みんなのためになります。 - 大塚先輩:
- みんなって誰になる?
- 中山君:
- プロジェクトのメンバー全員です。
- 大塚先輩:
- プロジェクトのメンバーだけでいいの?
- 中山君:
- えっ? プロジェクト以外のメンバーがいるんですか?
計画書のターゲット
よほど特殊な事情がない限り、
誰のために作成するのかを意識して、
テスト環境とは?
- 大塚先輩:
- ところで、
このテストどこでやるんだ? - 中山君:
- お客様が指定された場所だと思いますが。
- 大塚先輩:
- そうじゃなくて、
ソフトウェアが実装されている環境だよ。テスト環境のこと。 - 中山君:
- テスト環境? あまり意識していなかったんですけど…。
- 大塚先輩:
- 環境が特殊だと、
その準備にいろいろと手間がかかるだろう。事前にどのような環境なのか整理しておかないと計画の精度が落ちるよ。 - 中山君:
- えっ? ただテストするだけなのに、
そんなことまで考えるんですか?
テスト環境
テスト計画時には、
テストの体制とスケジュール
- 大塚先輩:
- スケジュールにちゃんとテスト設計が入っているのはいいね。テスト計画、
テスト実施、 テスト報告だけで終わらせる人が多いんだ。 - 中山君:
- ありがとうございます。
- 大塚先輩:
- だけど、
その仕事を誰がやるのか決めている? - 中山君:
- 朝ミーティングの時にでも決めようと思っています。
- 大塚先輩:
- 朝ミーティング?
- 中山君:
- はい。事前に仕事を割り当てても、
結局できないこと多いので無駄だと思っています。 - 大塚先輩:
- 事前に決めた方がよいこともあるんだ。たとえば、
中山君はリーダの仕事だけだと思っているの? - 中山君:
- はい、
今回のプロジェクトではリーダとして管理作業を中心にやろうと思っています。 - 大塚先輩:
- この体制でそれは難しいんじゃないか? このチームの人員数から中山君にも実作業をやってもらうことになる。
- 中山君:
- つまり兼任ということですか?
- 大塚先輩:
- その通りだ。リーダーとプレイヤー、
両方を行うことになる。こうなってくると何をやるか事前に決めておかないと、 混乱してしまう。また、 先々どんな準備が必要かもわからなくなるよ。
体制とスケジュール
タスクと役割の関係を整理したものをTRM
このように役割を明確にすることで、
スキル一覧
もし、
その他
この他に、
そうそう、
- 大塚先輩:
- まずは目につくところを挙げてみたがどうだい?
- 中山君:
- はい、
正直簡単に考えていました。まさかこんなに考えることが多かったなんて… - 大塚先輩:
- テスト実施の担当者を長年やっていると自信がついてくるが、
リーダーというのは単なる作業とりまとめ者じゃない。必要となる考え方や視点、 スキルなど大きく違ってくる。 - 中山君:
- 今までは自分に直接関係がなかったので、
計画書などもまじめに読んでいませんでした。だからダメだったんですね。 - 大塚先輩:
- そこに気がついただけでも、
一歩前進だ。適当に読んでいた計画書をもう一度しっかり読んでごらん。そしてもう一度作成してごらん。 - 中山君:
- はい!
初心に戻って、 もう一度作成してみます!
どうせ計画書なんて使われないから適当でいいやと考えていた中山君でしたが、
テスト実施者とテストリーダでは求められるものが大きく異なります。特に今回取り組んだテスト計画は、
終わりに
さて、
また、