テストは要件と仕様を検査するだけでテストで品質は向上しない

「テストでバグが出たら直すんだから品質はそれで向上するのでしょう」

「（はっ！何言っているんだこいつ）」

上記の班のする側のお気持ちにご同意いただけるのであれば大変嬉しいです。「そんなことないよ、バグを直せばいいじゃない」と思われた方にはそういう方なんですねぇとしか感想はありません。

テストで品質は向上しない

さて、この標題で「そうだよね」と思われた方は考え方に近いところがあります。なんでと思われた方とはお仕事したくないです。

テストは何を目的にやるか、です。テストは書いたコードが書いたように動いていることを確認するためにコストを使ってやるものではありません。

要求仕様が実現できているかを現物を使って検証するために行うものです。言い換えれば、コードの検査を行っているのです。

検査ですから生産的な活動はありません。インプットはコード、プロセスの中で試験仕様を作成します。次に試験仕様とコードをインプットに試験を実施することでアウトプットに試験結果を得ます。

この作業プロセスでは生産されるものは試験仕様、試験結果のみです。プロダクトとしてのコードをリファクタリングしたり、品質向上のためのコードの書き換えなどは行っていません。

ですから、テストで品質は向上しないと言っているのです。

品質は上げるものではない

品質という特性を持っているのは仕様書とコードです。仕様書はコードのインプットになるので、仕様書の出来が悪ければコードの出来も悪くなります。また、仕様書の出来は良くてもコーディングの品質が悪ければコードの出来は悪くなります。

このことから、deliverablesを生産する際に、品質という特性を与えているのがエンジニアであることは明瞭なことです。

よく聞くセリフで「テストで品質を向上させる」という考え方は、見方を変えれば

「エンジニアの生産的な活動の質が悪いのでテストで補正する」

と言っているのと一緒です。テストで品質を上げると言っているのはテストでダメ出しを自分でやって、品質の悪いコードを手戻りさせて直しているのです。

プロジェクトマネージャの立場から言えば、最初から手戻りして直すくらいの品質を確保できる作業をしてよ、って感じです。だって、手戻りする工数と時間をかけるくらいなら、最初から1.n倍の工数かけてやってもらった方が安くて美味しいのですから。

テストを書く意味

テスト仕様を先に書く手法があります。あまり流行っていませんけど。テスト仕様を書くタイミングはいつにするかはさておき、テスト仕様を書くということは要件や仕様が実装されているかを検証するために行う検査行為だと認識して書くことに意味があるのです。だって、仕様はこうだ、と理解状況をテスト仕様として可視化するので。

それはエンジニアの要件と仕様に対する理解度がテストケースとして現れる。そういうことです。

ウォーターフォールでコーディングをしてから試験工程に入る場合、テスト仕様はコードを書いてからという順序になります。でも、上記の要件と仕様の検査行為であるとするなら、その要件と仕様に基づいてコードを書いた方が良いわけです。テスト仕様の項目の並びがだいたいコードのファンクションの順序になるのですから。

それってテキストでコードを表現しているようなものですね。疑似コードまではいかないですけど。だからテストケースを先に書く方が合理的なのですけどね。