黒柴的パンセ　#2

「考える」ということ　その２

つまり「単体テスト」≒「コンポーネントテスト」というのは、ソフトウェア開発の経験がある諸兄らが考えるように、テスト対象の関数を独立して動かし、その動作の確認をするテストのことだと定義できる
当然、このプロジェクトで開発を担当する自社の作業者たちも、そういう認識だった

この「単体テスト」を、ソフトウェア開発を理解しているSIerやメーカーではない、エンドユーザが「巻き取る」と言ってきたのだ
この話を聞いたとき、黒柴は驚いたし、無理だろうと思った
コンポーネントテストは、テストフレームワークなどを用意して対象の関数のみを動作できる環境を作り、その上で入力値に対する期待値を整理したうえでテストデータを作成し、ようやくテストが実施できる
しかし、ソースコードを読み書きするスキルもなければ、対象の関数の仕様も理解していないエンドユーザ側の担当者たちに、どうやってコンポーネントテストができるのだろうと・・・

このとき、黒柴は別件でエンドユーザ社内に常駐していた
エンドユーザ社内の打ち合わせの状態をそれとなく確認していたが、実はエンドユーザのPMが「単体テスト」と呼称しているテスト内容が、自社が想定しているものとは著しく異なっているということが分かってきた

このシステムはWebアプリとして実装されていたが、エンドユーザ側のPMが単体と呼称してるのは、requestからresponseまでを一つの機能とし、その機能についてのテストのことだった
エンドユーザ側のPMが社内に説明していたのは、

• 一つ一つの処理（機能）について、テストを行う（だから機能「単体」のテスト）

• 一つ一つの機能自体は、きちんと動作する（例外などはほとんど発生しない）

• ただ、テストデータのバリエーションが不足しているので、実際の業務に従ったデータを投入して、機能の確認を行う（その中でエラーも発生する）

という感じだった

しかし、本来の単体テストも満足に実施していないソースを、とりあえず実行可能なようにビルドしただけのアプリケーションである
それは、本来の「単体テスト」を実施しないまま、「結合テスト」どころか「シナリオベース」の「受け入れテスト」に近いことを始めたに等しかった

当然だが、エンドユーザ側で触り始めたら、本来正常に動くはずのルートでも例外が発生してしまい、まったくテストにならない
そんなテストが全く進まない状況が２～3日続いたところで、エンドユーザ側で不満が爆発し、自社に対して品質に関する強烈な申し入れがあった
このあたりから、エンドユーザと自社の間には大きな不信感が生じてしまい、最終的には訴訟一歩手前まで行く状態になった
このように、お互いが同じ言葉（この場合「単体テスト」）を使いながら、その内容、定義をきちんと確認しておかなかったため、お互いが苦しい、嫌な体験をした

もっとも、エンドユーザ側のPMは、かなり「癖のある」人だったため、あえて「単体テスト」の定義をこちら側とは異なる、独自の定義を持ち出してきたことは十分考えられた
しかし、そういう齟齬を避けるためにも、契約においては「単体テスト」という作業項目において、「何を」「どのように」作業し、「アウトプットとして何を」提出するのかをきちんと定義しておく必要があると感じた
これが、黒柴が「言葉を定義する」ということを強く意識するに至った出来事である