単体テスト仕様書兼成績書にテスト回数を書く愚

 最近(似非)SDEM に対する愚痴が止まらない id:itoasuka です。こんにちは。


 今日は、単体テスト仕様書兼成績書に「テスト回数」というものを書く愚について書きます。前提条件は

  • 開発者1人につき1台以上のPCが割り当てられている。
  • それらのPCの中にソースコードのビルド環境と単体テスト環境が入っている。

です。こういった開発環境で「単体テスト仕様書兼成績書」にテスト回数という項目を入れるのはちょっとおかしいんじゃないかと言う話です。特に SDEM とその類似開発プロセスでです。

 SDEM を例にとってみますと、いわゆるメイキングだとかコーディングという工程を「PG」といいます。そして、これで出来上がったものが正しく動くかを試す工程を「PT」といいます。


 さて、この PG なんですが、何をしたら終わりなんでしょうか? たとえば、とりあえずコンパイルが通るけど、動きがへろへろだったら終わったと言えるでしょうか? 何せ自分のところにそれを試す環境があるのです。動かせばわかる話なので、動きがへろへろだったら PG が終わったなんて言えないでしょう。

 そうすると PG が終わったということを堂々と宣言するためには単体テストをするのが一番なんです。つまり PG が完成したと同時に PT が完了するのです。ですから、これについて 1 回目とか 2 回目なんてありません。


 では、なぜ、テスト回数を取りたがる人がいるかといいますと、これまた昔の名残です。

  1. 1人1台の開発環境がなかったので、とりあえずコーディングだけする。
  2. あるマイルストーンで、コードをもってビルド環境にコンパイル(ビルド)しにいく ←ここで成績をとる。
  3. コンパイルが通らなかったら1に戻る。
  4. コンパイルが通ったら、テスト環境に投入しテストする。 ←ここで成績をとる。
  5. テストに通らなかったら1に戻る。
  6. 最後にそれぞれの環境を何度行ったり来たりしたかの集計を行う。


 ということで、きょうびの開発スタイルでは、テスト回数を取るとしたら結合試験以降(SDEMでいったらIT以降)じゃないと意味がないでしょう。

 それでも単体テストの回数を取りたがる人がいたら、こういえばいいんです。「何ができたら PG 完って言えばいいんですか?」と。そこで「だいたい動くと判断できたとき」なんて答えをするようだったら、その人は単なる役人です。「だいたい」なんていう属人的な尺度で話しておきながら、テスト回数によって品質を(似非)見える化しようとしているんですから、まともにプロジェクトを成功させる気なんてありません。



 ちなみにうちは、富士通系と仕事をするときは進捗度合いを語る上での「共通言語」として SDEM 的な言葉を使う(使わざるを得ない)ことが多いのですが、PG と PT は対です。スケジュール上でも PG/PT とくっつけて書いてあります。なので、テスト回数は取ってません。同じようにしているところも少なくないようですが、やっぱり一所懸命回数取ってるところもありますね。それで、1回目で満点とると「テスト項目が足りないんじゃないか」なんて言ってきたりして。こういうのは非常に疲れます。