ブレーキにもエネルギーは要る

テスト計画というと、いつ何をどれくらいのリソース充ててテストするのか、というところに焦点があたりがちだけど、テストの中止条件もちゃんと定めといたほうがいいんじゃないか。というお話。

 

「バグが出まくりだし、収束しないし、テストしても意味なくね?」っていう状況は、割とよく見かけます。
そんな状況になったときに、速やかにテストを中止して、開発フェーズを上流に戻せれば健全なのですが、いろんなシガラミで、テストを渋々続けざるを得ないことも、ママあります。


まぁ、そんな状況でテストしてるだけでも、結構しんどいのですが(しょうもないバグのバグ報告に手を取られるので)、場合によっては、「なんでこんなに不具合出てるの?リリース遅れちゃうんだけど。」みたいなことを、テストチームに言ってくる輩も存在し(バグを作ってるのはプログラマなので、クレーム言う先を間違えている)、こうなると、テストチームは、一気に無力感と疲弊感と無常観に襲われ、モチベーションもパフォーマンスも下がっていくわけです。

 

なので、そうなる前に、テストを中止できたらよかったよね。
と思うことが、長年テストの現場を見てると、ちょくちょくあるので、そのためには、
テスト始める前に、中止条件をきっちり、ステークホルダと握っておきましょう。

 

中止を伝えるときですが、以前もこのブログ(リンク)で書きましたが、QA側に必要なのはデータと誠実さです。

データは、まぁ、新規オープンしたバグ、未対応のバグ、対応されたバグ、の3つが可視化されてて、未対応のバグが増えていってるのが見えれば良いのではないでしょうか。
誠実さに関しては、過度に煽ったりせず、このままの品質だと市場に出してもユーザは評価してくれないということを、丁寧な言葉で伝えればよいかと思います。このとき、大事なのは、レポートを出すだけではなく、ちゃんと口頭でも説明することです。悪いニュースの書かれたレポートは、読み手が誤解して、変なトラブルになることもあるので(実際に「これ書いたやつ誰だ!」と、プロデューサに逆恨みされそうになった人も居ました)、レポートだけが独り歩きしないように気をつけましょう。


なお、このテのトラブルが発生するプロジェクトの共通点は、以下が挙げられると思います。以下の条件を幾つか満たすプロジェクトのテストをする際は、気をつけましょう。

  • 技術力の低い開発会社(チーム)が開発している
  • これまで取引実績のない開発会社(チーム)が開発している
  • テストチームにバグを洗い出してもらおう、という意識が働いている(QAチーム、テストチームの役割を勘違いしている)
  • 新しいテクノロジを採用している
  • 開発ボリュームの割にはスパンが短い
  • テスト側は、きっちりリソースとスケジュールを組んでしまっている。そのため、走り出してからの融通が効きにくい