前回のテストケースファーストのエントリに対して、yusaku さんよりコメントで質問をいただきました。
問題は以下です。
- テスト仕様書を先に記載するため、仕様書作成時に予定しておらず、実装時に必要なため実装したコードに対してテストケースが漏れる。
- 実装者がテスト仕様書を記載するため、ホワイトボックスの観点での項目も盛り込めるが、
- レビュアーからすると過不足が判断できない。
我々のプロジェクトでは、上記の問題に対しては以下のような対策を行っています。
◆トリオプログラミング
実装時に追加されたテストケースがメンテナンスされない問題への対策として行っているプラクティスではないのですが、次のような進め方が効果を発揮しています。
名づけるなら「トリオプログラミング」とでもいいましょうか。
トリオプログラミング概要
1人のSEを中核にして、2人のPGが配下につきます。
この3人を1ユニットとしてチームを編成して、
1ユニットにつき2本のプログラムを進めていきます。
SEレベルのメンバーは「テスト仕様書のレビュー」や基本設計書の修正、スケジューリング、仕様変更の調整、それから部分的に（難しい部分や複雑なSQLなどの）プログラミングを行います。
テスト仕様書の作成は、プログラマーが行いますが、実装時に必要に応じて追加したコードについてのテストケースは、SEレベルの判断によりテスト仕様書に追記の注釈が行われます。
（発生時点でSEがテスト仕様書に追加してしまう場合もあります）
なぜトリオか
あえてペアプログラミングではなくPG：SEの比率を2：1にしている表向きの理由は、ペアプログラミングだと要員手配がままならないことと、体制上のインパクトが大きすぎて、上の方の人が納得しないからです。
本心の狙いとしては、プログラマーがプログラムに集中しやすい環境を作り出すためです。
いつでも仕様について質問できる相手がいることは、プログラミングの効率をかなり向上させます。（数値化は難しいのですが。。。）
実際、今回僕の関わっているプロジェクトでは、若手（経験1年ぐらい）のメンバーが大勢入っているのですが通常このレベルだと、少し割り引いて0.5ぐらいのパフォーマンスで見積をします。
それならまだよいぐらいで、時には質問や手助けにベテランの手がとられてしまい、-0.1ぐらいになってしまうこともしばしばです。
ところが、このトリオプログラミングを採用することで、
進捗上、（SE）1+(PG)0.5+(PG)0.5が、2.5ぐらいになっています。
トリオプログラミングによる効率
プログラマーが一旦プログラミングに入ってしまうと、プログラミング以外の作業を間に挟んでしまうのは、効率の上では大きなロスになります。
そういったことが原因でテスト仕様書のメンテナンスが疎かになると思うのですが、上記の体制にしておけばSEレベルのタスクの中のプログラミング作業が少なくてすむため、テスト仕様書メンテナンスにも手が回るようになります。
◆ホワイトボックス観点のケースに対するレビュー
ホワイトボックステストに対する過不足、つまりカバレッジをどのようにレビューで判断するかという問題は、テストケースファーストの手法と切り離して考えるべきところかもしれません。
また、ここは議論の別れるところです。
よくテスト格言として言われるのは以下のような言葉です。
「壊れていることは証明できるが、壊れないことは証明できない」
つまり、どれだけテストを行ったとしても絶対に壊れていないという保証にはなりません。
そのため、状況に応じてコストに見合った基準を設けて、それに準拠するしかないように思います。
ただ、ホワイトボックス観点の項目を盛り込む事に関しても、上記のトリオプログラミングの体制が役に立ちます。
SEレベルが実装まで踏み込んで検討するスキルをもっている場合は、そもそも問題にならないと思いますが
SEレベルが実装観点でレビューできない場合でも、トリオでのレビューをおこなうことでPGレベルのエンジニアが2人いるわけですから、お互いのホワイトボックス観点のケースに対するレビューは行えます。
