はじめに
これは社内LTのプレゼンテーション資料です。
ちなみに、当日はビール5缶飲んだ後だったのでうまく発表できなかったです。
先日、QAエンジニアのKさんにソフトウェアテスト講義を受けたので、"テストって大事だなぁ"と思って作ったスライドです。
今回は、私の過去の職場などの体験を参考に、フィクションでお送りいたします。
あなたは、とあるプロダクト開発にジョインしました。
キックオフミーティングでは、次のようなマスタースケジュールが提示されました。
マスタースケジュール
とてもキレイなウォーターフォールです。
条件として、"リリース日は繁忙期前だからマストで！”とのこと。
さて、要件定義が始まりました。
現場で起きてしまったこと
要件定義が伸びに伸びてしまいました。
このままでは、リリース日に間に合いません。
そこで、あなたは名案を思いつきました。
「安心してください。入ってますよ。」
あなたは、完璧なスケジューリング能力を発揮してしまいました。
テストを重ねることで、約束のリリース日に間に合わせることができたのです！
さて、その結果、何が起きるでしょうか...？
リリースを合図に、アレが作動します
（アレね。アレ。優勝のことじゃないよ）
（不具合の時限爆弾ね...）
その後、不具合が案の定、見つかりました。
いったい、あなたはどこで間違えたのか？
考えてみました...
不具合はいつ見つかると良いのか？
A: テストフェーズで見つかる不具合
B: リリース後に見つかる不具合
このAとBでは、何が違うのでしょうか？
テストしない方がリリースは早まる？
- テストフェーズで不具合が見つかったあ場合、テスト期間や修正期間が伸びて、リリース日も伸びてしまいました
- 一方、テストをおろそかにした場合、修正も発生しないのでリリースを早めることができました
- けれど...
リリース後に見つかる不具合は影響範囲が大きくなる
そう、リリース後に見つかった不具合では、お客様からの営業への問い合わせ、社内の連絡、プログラムの調査・修正、その後始末だったり、影響範囲がとても広くなってしまいます。
後始末が終わった後、いつも温厚な上司に呼び出されます。
上司「あなたが3分かけてテストをしていたら、私たちは3日を失わなかった!!」
（タイトルの伏線回収www）
（人のせいにするのは良くないよね、仕組みを変えないと...）
とはいえ、失ったものが3日ですまないケースもありますよね？
3日ですまないケース
- ABテストの誤った計測が、誤った経営判断に繋がる
- 本番アクセス量に耐えきれずシステムダウン
- システムに脆弱性を埋め込み個人情報が流出する
（失ったものは何か？）
さて...
どうしていたら良かったか
- リリース日が決まっていた場合、Q（品質）、C（コスト）、D（納期）、S（スコープ）で一番調整ができるのはスコープ
- 『アジャイルサムライ』参照
- スコープを小さくして、小さくリリース、早いフィードバックを得る
- テストをおろそかにしない
テストをおろそかにしない
（大事なことなので2回言いました）
とはいえ、人間はミスする生き物。
不具合は必ず発生するので、ポストモーテムを使って振り返りと対策をやっていきましょう。
ご清聴ありがとうございました。