テスト工程を軽んじることなかれ

　多くのテストを実施することで、実際の運用に耐え得る品質を確保します。皆さんは、テスト工数に開発全体の何割程度を割り当てていますか？　わたしの経験ですが、やはり「テスト工程は全体の50％以上の工数が掛かる」と感じています。もちろん、常にそうなることではありませんが、ある程度の規模のシステム開発を実施すると、やはり50％以上の工数が必要になると思います。皆さんも感じているかもしれませんが、「テスト工程とは、開発案件の中で多くの時間を費やし、かつ品質を決定する重要な工程だ」といえるでしょう。

　多くの人が重要だと認識しているテスト工程ですが、プロジェクトメンバーによっては「大変で退屈な作業だ」と思われるかもしれません。例えば、テストによっては「画面への打ち込みをひたすら繰り返す作業」がその工程の多くを占める場合があります。その際には最も長く作業時間を取られたりします。

　「システム開発を行う上で、どの工程が一番好きですか？」とシステム開発者に尋ねると、多くの方が「実装」だと答えるのではないでしょうか？　あくまでわたしの経験上の話ですが、「システムの設計や要件定義を担当したい」という要望はあっても、「テストを積極的にやりたい」というメンバーはこれまでいませんでした。

　わたし自身もそうですが、テスト関連の技術やノウハウについて詳しいシステムエンジニアやプログラマーは少ないような気がします。皆さんの周りではいかがでしょうか？　例えば、ある機能に対するテスト仕様書を有効かつ理論的に設計できる人がどれだけいるでしょうか。わたしは、「テスト設計技術に興味や関心を持っている人があまり多くはない」ことがその理由のように感じます。

　しかし、正しい理論・視点に基づいた効果のあるテスト仕様書を作成しなければ、不具合が発生する確率が高くなるのは、皆さんも肌で感じていることだと思います。また、効率的な仕様書であれば、テスト工数を短くすることができます。作業時間が短ければそれだけメンバーのモチベーションも高く維持できるでしょう。

モチベーションの低下が招くリスクを考える

　わたしは「テスト工程を効果的に進めるためには、メンバーのモチベーションに気を付けるべきだ」と思います。テスト項目やテスト仕様書の作成を終え、実際にテストを実施する際にメンバーのモチベーションが時間とともに低下することが多いと感じています。この状態のままテストを進めていくと、テスト実施者は自身が入力した内容や結果に自信を持てなくなることもあります。例えば、以下のようなケースが考えられます。

　このケースではテストを再実施した際に、テスト対象プログラムの実行環境に何らかの変化があった可能性が高く、その判断結果は不具合を発生させることにもつながりかねません。また、実施したテストケースでは発見されない隠れた不具合が存在する可能性も否定できません。実施者のモチベーションが高ければ、「なぜ1回目がNGだったのか」についての調査を行うでしょう。しかし、モチベーションが低下しているときはどうでしょうか？　テストケース上では「OK」となったので「試験結果も問題なし」としてしまうかもしれません。

　人が長時間作業を続ければ、時間の経過とともにモチベーションが低下するのは、当たり前のことです。プロジェクトマネジャーであるわたしは、そうしたメンバーを単純に責めることはできないと考えます。「疲れるとミスをしやすくなる」ことを念頭に置いて適切に休憩を取るメンバーもいますが、中にはそれがうまくできない人もいます。

テスト工程を楽しく乗り切ってもらうために

　プロジェクトマネジャーの役割として重要なこととは「テスト工程の進ちょく状況や結果もさることながら、テストを実施するメンバーがどのような状態で作業しているのかについて気を使うことだ」と思います。そのために、わたしが行っていることをここで紹介します。

まめに進ちょくを聞く

　特に何をするということもないのですが、メンバーからすれば状況を聞いてもらうだけでも安心感が生まれて、余裕ができると思います。その場合は「調子はどう？」と軽く声を掛けるだけでもよいでしょう。こちらがかしこまって尋ねるわけではない点がポイントで、その聞き方にも工夫が必要です。

別案件のタスクもお願いする

　作業内容を変えることで、気持ちを切り替えることができます。気分を切り替えたくても、タスクがテストだけしかなければ、もちろんそれは不可能です。プロジェクトマネジャーがテスト以外の作業を割り振り、そのやり方をメンバー自身がやりやすいように任せてみましょう。これによって、メンバー自身のタイミングでリフレッシュすることができるのではないでしょうか。

　案件によってはメンバーも異なるのが一般だと思いますので、上記の方法が参考にならない場合もあるでしょう。しかし、これらの方法を実施する目的は「テスト実施者のモチベーションを管理することで、より多くの不具合を発見し、システム品質を確保することにつなげること」にもあります。当たり前のことだと思われるかもしれませんが、カットオーバーが近づくとついつい忘れがちだと思います。この場で、あらためて思い返していただければ幸いです。

テストに対する意識変革を

　「テストというものはやればやるほど、そのシステムが不完全であることを立証するジレンマを抱えている」ともいえるかもしれません。システム開発者にとって「どこまでをテスト範囲とすればよいのか」は、今後もずっと付きまとう難問です。このような状況で適切な判断を下すためには、その根拠となるような知識を身に付けていく必要があると思います。また、多くの開発者がテスト工程に興味を持ち、正しい知識を習得すれば、一見退屈だと感じていたテスト工程に対する意識も変化するのではないでしょうか。

　わたしが担当するコラムは今回が最終回となります。ご拝読ありがとうございました。プロジェクトマネジャーの方にとって、何かしらの共感や参考になったというものがあれば幸いです。