62.テストの7原則 その④
テストの7原則『初期テスト』
問題はできる限り早い段階で発見、修正されることが理想的だ。
問題は気づくのが遅くなれば遅くなるほどコストがかさむ。
なので「最後の最後でまとめてテストしよう！」なんてことをすると、とてもひどい目に遭う。
例えば今回のマンガの「カレー」の例を見てみよう。
- 作りはじめる前に「ニンジン入れない」といった要件を確認すれば、聞くだけで解決できた。
- ニンジンを切る前に気付けたなら、ニンジンを買ってきたコストはかかっている。
- ニンジンを切ってしまった後なら、ニンジンを買ってきて、ニンジンを切るコストはかかっている
- ニンジンを炒めてしまった後なら、ニンジンを買ってきて、ニンジンを切って、炒めるコストがかかっている
- ニンジンをカレーに入れてしまった後なら、修正は作り直しになってしまう。
仮にこれが「ニンジンが入っていないレトルトカレー」なんていう形で売り出されるとしたら、改修騒ぎになったりする。
なので、テストはなるべく開発の早い時期からこまめに行い、問題の早期発見に努めるのが理想的だゾ。
要件定義段階の問題が後半もちあがる
たまにあるのが「その状態が当たり前だと思っていた」というバグ。
プロジェクト関係者は開発期間中は大体はそのプロダクトを触りまくっている。
そうすると「こうなっているのは当然」みたいな当たり前状態になったり。
目が曇ってしまい「そもそもそれってあってたっけ？」に気付かなくなったりする。
こういう時は第三者検証が効力を発揮するゾ。
検証がプロジェクト内にある場合でも、新しく入ったメンバーに触ってもらうと新鮮な意見を聞けて、そこから問題が発覚する場合があったり。
うわー最後の最後に特大のヤバいやつ見つけちゃったよどうしようという闇
テストリーダーをやっているとたまに遭遇するのが「テストのホントの最後の最後、明日リリースするぜ！」というときにちゃぶ台返しレベルの大きなバグの発見である。
もちろんこのブログを読んでいる平常時なら
「見つかってよかった♪ 報告報告♪」
となる。
だがしかし！！
以下の情景を想像してみてほしい……。
ぎりぎりのスケジュールで開発をし……
テストを行い……
バグは収束せず毎日修正とデグレに追われる毎日……
毎日終電ギリギリの残業で疲労もピーク……
「尻はずらすな！！」と言われ続け……
最終日……
ようやく見つけたバグの修正も終わり……
最後のリグレッションテストを実施……
チャット上では「今日からは早く帰って嫁さんの手料理を食うんだ、俺」とか言っちゃってる人がいる……
そんな中であなたは特大のバグを見つけるのだ！！
一言で言うと「ゲ！！！」ですよ。
そのあと
「え、これ…どうするの？ え？ い、言う？ 言わなきゃまずいよね？ え、いや、けどコレ明日出せなくなるぞ？ え？ ちょ…え？ あぁあぁ、やっぱり3回やっても再現するしチクショウ。全てを忘れて無に還りたいボクおうちかえりたい」
という葛藤ですよ。
さて。
仮に内緒にしてリリースしたとしましょう。
俗にいう握りつぶすです。はい。
みんな超笑顔で「おつかれさま～～～♪」となります。ハッピーです。
お家に帰って嫁さんの手料理を食う人もいるでしょう。ハッピーです。
そう。その時は。
例えばそれが数万人が遊ぶゲームだとしましょう。
余裕でそのバグは見つかりTwitter上で
「うｗｗｗはｗｗｗｗ草生えるｗｗｗｗｗｗ」
となりリツイート8192件とかになります。
1日のハッピーの代わりに、そこから1週間くらいアンハッピー生活が待っています。
事後処理で帰れなくなってコンビニでカップ麺とレッドブル、会社自販機の若干高い菓子パンとレッドブル生活です。アンハッピーです。
「わび石配布で損失額800万だったよ。どうするんだっけこれ？」
とか言われちゃうわけです。自分の無力さについて関係各所で謝罪後、そのバグを発見できなかった経緯を自尊心を削りながらワードに延々書き続けます。アンハッピーすぎて毛と魂が抜けます。
これが工業製品だとしたらリコールです。
ニュースになるアレです。
言わないと、ほんと～～～～～にとんでもなくヒドイ目に遭いますヨ。
だからちゃんと見つけたらスグに率直に言おうねｗ
エネル顔
マンガを描きながら絵の練習もしています。
3コマ目はワンピースの画風です。
エネルの顔、といえば通じる人も多いでしょうｗ
トーンを使わず線の密度の濃さで影の強弱をつけているのか……と見様見真似で描いておりましたｗ
