「e発送サービスは受付を一時休止しています」。

 ほぼ毎日のようにローソンを訪れる筆者にとって、この注意書きはおなじみになってきた。レジ横で目にする注意書きは、心なしか紙にしわが寄りはじめている。2017年6月28日にシステム障害で停止したこのサービスは、1カ月を経過しても復旧できていない。

 デジタル化が進むほど、システムはビジネスと直結するようになる。システムが止まったり、間違った結果を返したりするバグがあると、ビジネスに直接ダメージを与えてしまう。こうした欠陥を見つけ出し、品質を確保する関門となるのがテストだ。ただ、十分なテストを実施できているかどうか、実のところ心許ないのではないだろうか。

 さまざまなプロジェクトのテスト工程を経験したSHIFTの小林元也ソフトウェアテスト事業本部本部長は、大きく三つの要因が欠陥の見逃しにつながると指摘する。「後工程に責任を放り投げる」「パターンの整理を面倒くさがる」「テスト観点を知らない」――である。

 以下では、起こりがちなテストケース作成の失敗を見ていこう。踏み抜きがちな落とし穴を知っておくだけでも、「これはマズイかも」と気付ける可能性が高まる。

「正常に処理されている」が信用できない

 一つめの「後工程に責任を放り投げる」は、プロジェクトのそこかしこで見受けられる光景だという。まず、開発担当者からテスト担当者への放り投げ。同社の藤貫美佐エンタープライズビジネスユニット品質管理グループグループ長は「仕様書に『AであるときにBという動作をする』とは書いてあっても、『Aでないとき』の動作は書かれていない場合が多い」と話す。

 「仕様書が曖昧でどうとでも作れてしまうので、実装者が自分なりの解釈でプログラムを書く」(藤貫グループ長)。この状況で「仕様書通りに作られているかを確認する」という姿勢でテストケースを作成すると、欠陥を見逃してしまう可能性が高まる。「AであるときにBの動作をする」ことだけを確認して、「Aでないとき」の動作を確認しないからだ。

 テスト設計者がテスト実行者の作業を考えていないというパターンもある。テストケースの書き方が正しくないのだ。最悪の書き方が「正常に処理されることを確認する」というもの。「何が正常なのか、テスト実行者が勝手に判断できてしまう。この記述を見つけたらテスト結果を信用しない」(小林本部長)。

 そこまで行かなくても、テスト実行者の時間を食いつぶす不親切な記述がある。例えば「仕様書通りである」という書き方だ。正解が何なのか、仕様書を確認する必要が出てくる。「ユーザーのステータスが××の場合」という記述も良くない。ステータスのバリエーション、そのステータスにする操作方法を仕様書まで遡って確認しなければならないからだ。