完璧を目指した先で出会った、想定外を暴く知恵
うわっ、テストってこんなに奥が深いのか!?――それが、私が社会人になって最初のシステム構築プロジェクトで感じた率直な驚きでした。
空いた時間でお小遣いを貯めよう！「アイリサーチ」
■ 最初のシステム構築プロジェクトの洗礼
配属されて間もなく参加した、人生初の本格的なシステム構築プロジェクト。そこで教え込まれたのが、「テストは気合と根性ではなく、構造でやるものだ」という考え方でした。
■ マトリックステスト表との出会い
当時のテストは、マトリックステスト表が中心。
縦軸と横軸に条件やデータを並べ、あらゆる組み合わせを一つひとつ確認していきます。
ロジックはすでに分かっている。だからこそ、そのロジックに合わせてテストケースを作る。
組合せ網羅――これがマトリックステスト表の最大の強みでした。
■ 「これをやっていれば漏れはない」はずだった
正直、ここまで細かくやれば、バグなんて残るはずがない。
当時は本気でそう思っていました。
実際、このテストはかなり優秀で、論理的な抜け漏れはほぼ防げます。
■ あれ？これ、普通じゃない？
ところが後になって気づきます。
このマトリックステスト表、日立では当たり前のように使っていたのに、他社ではあまり見かけない。
テスト関連の書籍を読んでも、あまり詳しく出てこない。
「これ、もしかして企業内の知恵なのかな？」
そう感じた瞬間でした。
■ それでも、最後にバグは残る
どれだけ組合せを網羅しても、なぜか最後にバグは残ってしまう。
なぜなのか。
■ バグは“意識の外”に潜んでいる
後で分かったのは、バグは意識しているところにはいない、という事実でした。
設計によるバグ、仕様によるバグ、コーディングバグ、テスト漏れ…。
いくつもの関門をすり抜けて、しぶとく残るバグがいるのです。
■ そこで登場、モンキーテスト
この残党バグを見つけるために使われたのが、モンキーテスト。
サルのように、バンバンとキーボードを叩く。
意味不明な文字を入力する。
順序もルールも無視する。
■ 想定外をあぶり出す力
一見ふざけているようですが、これが結構優秀。
設計者もテスターも想定していなかった操作によって、サーバの問題や例外処理の弱点が浮かび上がります。
論理ではなく、混沌で攻めるテスト。
歴史あるモンキーテストは、今もなお現役です。
■ 社会人になって知った、面白い世界
完璧を目指すマトリックステスト。
想定外を暴くモンキーテスト。
この両方を知ったとき、テストの世界は一気に面白くなりました。
完璧を信じすぎないこと。
そして、偶然を味方につけること。
それもまた、品質を守る大切な知恵です。
私ならできる！明日から踏み出す
コメント
コメントを投稿