ブラックボックスで！と言っても、自分の思うブラックボックスのテスト仕様書とは違うものが作成された件

ここ2か月程は単体テスト仕様書作成とコーディングの工程です。自分はテスト関連の責任者ということで、テスト仕様書作成やテスト実施関連の指揮をとっているのですが、そこで上手くいったことや上手くいかなかったことについて、何本か書きたいなと思います。

さっそくですが、今回は以下のようなことで困りました。
--------------------------------
●困ったこと
ブラックボックスで！と言っても、自分の思うブラックボックスのテスト仕様書とは違うものが作成された
※自分の中ではそれはホワイトボックス！と思う成果物になっていた

●プロジェクト概要
現行システムの刷新プロジェクトとなります。
　システム：勤怠管理システム
　画面数　：約130画面程
　メンバー：プロパー5人、パートナー25人

●事前に行っていた対策
事前に以下のことを行ってました。

　・初めに1本、サンプルとなるテスト仕様書を時間をかけて作成して、「記載粒度などはこれ参考にしてください」と展開
　・ブラックボックスでのテストとなることを周知
　・設計書の記載内容は一通りテストする必要があるため、テスト仕様書にすべて反映されているか確認すること
　・ブラックボックスなので、プログラムに対してINとOUTの組み合わせが仕様通りかを確認し、どの分岐を通ったかなどは確認不要であることを周知 

●期待していたテスト仕様書のイメージ
　・INPUTとなる画面の入力値、データの値が明記されている
　・INPUTとOUTPUTの組み合わせがデシジョンテーブルで全パターン表現されている
　・OUTPUT（予想結果）には画面の項目値やエラーメッセージ、データの登録値や更新値がどうなるかが明記されている

●出来上がったテスト仕様書
一部のメンバーで以下のようなテスト仕様書を作成する人がいました。
　・あるチェック処理のOUTPUT（予想結果）に、「戻り値がAとなる」と記載
--------------------------------

何が起きたのかというと、設計書には「共通のXXXチェック処理を呼び出し、エラーがある場合は戻り値がA」という記載があったため、その人はエラーの場合は戻り値がA、それ以外の場合は戻り値が別の値であることをテストしようとしたのです。でも僕が期待していた予想結果は、[エラーの場合は画面にエラーメッセージ「～～～～」が表示されること]というような記載でした。

これ、この人にとってはブラックボックスのテストケースだったのです。
チェック処理のロジックはどうあれ、戻り値が想定通りかどうかをテストすることはたしかにブラックボックス...
でも僕の中ではこれをホワイトボックスと呼んでいました。。。

僕の中では画面レベルのテストでしたが、この人にとってはメソッドレベルのテストだったようです。

なるほど、、、
社内のプロパーであれば、単体テストでブラックボックスと言えば画面の表示やデータの値を確認するテストのこと。という共通認識があったのですが、プロジェクトメンバーは様々なベンダーのメンバーから構成されており、言葉の認識は人それぞれだったのです。
そもそもブラックボックスとは？ホワイトボックスとは？を語れるほど勉強する人ってほとんどいないと思うので、意外と人によって認識って違いますよね。
テストの対象が画面レベルなのか、メソッドレベルなのかをしっかり伝えられてなかったのも要因かと思いますが、メソッドレベルで～とか、ブラックボックスで～とか、言葉（用語）だけで済ますと解釈が異なるケースがよくあるので、危ないかなと思いました。おそらくここが1番の反省点ですね。。。

★まとめ★
・テスト対象が画面なのかメソッドなのかといったテストレベルでブラックボックスの予想結果の確認範囲が変わってくる
・用語は人によって解釈が異なることが多いので、用語を使うときは視覚的な説明（実際のものを見ながら身振り手振りでの説明など）をしたほうがいい

※サンプルを見といて～で済ませるのも危ない
※単体テスト、結合テストも現場によってスコープやテスト方法が全く違うので、「うちではこうやってやりますよ～」の説明はマスト

どの工程でもあるあるですが、ブラックボックスという用語は盲点だった話でした。

次回もブラックボックスに関する話を書きたいと思います。