テストのふりをしているだけ

テストというものは

この前の仕事中、ずっと引っかかっていることがある。

「テスト」って、結局なんなんだろうか？

現場では、だいたいいつもこんな流れになる。

• テストシナリオを作成せよ

ユースケースは特に考えられていない

• テスト仕様書を作成せよ

参照できるのは設計書だけ

• テスト手順書を作成せよ

ステップバイステップで、丁寧に

• テストを実施せよ

手順書をもとに

そして最終的に行われていた「テスト作業」は、

Excel のスプレッドシートに書かれた手順書に従って、

クリックして、またクリックして、さらにクリックして、画面を確認し、

何か表示されたらエビデンスを撮る、という作業だった。

たまに「想定外のエラー」についての記述はあるのに、

「想定されているエラー」はどこにも存在しなかった。

もし、うまくいかなければどうするのか。

──おっと、手順書には書いていない。

それはテストというより、

むしろテストをしているように見せるためのパフォーマンスだった。

さらにややこしいのは、

システムやソフトウェアのことをほとんど知らない方々が、

「確認する側」としてテストを実施する場面があったことだ。

情報セキュリティを理由に、

実際の中身は分からないまま、

手順書どおりに操作し、チェックを入れることが求められる。

その結果として出てきたのが、

「確認項目を確認するための確認手順を作ってほしい」という要望だった。

そもそも何を確認すれば安心なのかという問いだけが、

最初からどこにも存在していなかった。

どこか違和感がある

気づくと、頭の中にはこんな問いが溜まっていた。

• ソフトウェアに詳しくない作業者が、見逃しやすい点はどう扱われているのか。
• ボタンや表示が手順書と少しだけ違っていた場合、どう判断すればいいのか。
• エビデンスは何のために取るのか。

作業をしたという証明なのか、それともテスト結果を評価するためなのか。

• そもそも、このテスト方法自体はきちんと検証されているのか。
• 一番大事なのは、何のためにテストをしているのか。

仕組みや性能の確認なのか、不足や異常を見つけるためなのか。

答えがなかった

それらの問いに答える役割や仕組みは、最初から存在していなかった。

少なくとも、私はそう感じていた。

テストは実施されていたが、

結果をどう解釈し、どう判断するのかは定義されていなかった。

想定外のエラーは語られていた一方で、

「これは失敗だ」と判断する基準は存在せず、

迷ったときに立ち止まる場所も用意されていなかった。

なぜこうなったのか。

テストの意味は、シナリオを作る段階ですでに失われていた。