黒柴の来歴　その２

テストって、どうやるんですか？

最初の配属先での仕事は、ある通信機器のMMI（Man-Machine-Interface）がUNIXのコードを移植していて、その移植部分の確認だった
当時（1980年代後半）はPC（Personal Computer）は一般的ではなく、開発環境もUNIX（ハードはミニコン）であったため、マシン室まで移動して端末からプログラムを入力し、コンパイルが通ったら紙に出力して、自席でそれを確認するという感じの仕事だった

移植自体は終わっていたので、紙に出力したプログラムコードのファイルをリーダーが自分に渡して、これをテストしろと指示してきた
テストといっても、現代のように動的にテストができるわけもなく、いわゆる「机上デバッグ」という奴で、紙に出力されたプログラムを目で追いながら、変数の値を別の紙に書き出して、全体的なプログラムの流れやデータの整合性を確認するという作業になる

テスト自体のやり方は分かっているのだが、何をどのように確認すればよいのかが分からず、そのファイルを持ってきたリーダーに質問してみた
「テストって、どうやるんですか？」

当時も「単体テスト」、「結合テスト」とかの用語はあり、おそらくリーダーが指示してきたのは「単体テスト」だと思われる
しかし、リーダーは上記したやり方を説明するだけで、どのようにテスト項目を作成して、それにより何が確認できるのか？ということは説明してくれなかった
そのため、自分にとってはプログラムの動きを机上でシミュレーションしているだけで、何一つテストはできていない
一日かけて、「このプログラムって、こう動くんだ」ということが分かっただけだった

そして、ライフワークへ

この「テストのやり方が分からない」ということは、自分にとっては軽くショックだった
もちろん、自分自身が「分からない」ということではなく、自分の周囲の人がテストのやり方をきちんと理解しておらず、またそれを疑問にも思っていないということにである
上記のリーダーも、「プログラムを動かして確認する」ということは理解できているのだが、それにより何が確認できるのか？ということまでは理解できていなかったようだ

別にリーダーが悪いわけではなく、だいたい自分の周囲にいる人たちは同じような感じだったし、解説本のようなものを探そうにも、プログラミング言語やシステムの解説はあっても、テストそのものを解説した書籍はなかったと思う

そんなわけで、
「ソフトウェアテストとは何か？」
「どのように項目を作るのか？」
「それにより何が確認できるのか？」
「どういう状態になればテストが終わったといえるのか？」
など、ソフトウェアテストについて考えていくのが、ライフワーク的な課題となった