JaSST'13東海SIG(11)
JaSST'13東海SIG(10)からの続きです。
今回は、「JaSST'12東海SIGでの気付き」の【6.教訓】です。
探索的テストを探索する from Masao Tsuzuki
(1)ふりかえりで次回プロジェクトへの取り組み
新規プロジェクト終結前後に反省会を実施することがありますが、「良かった点：○○を取り組んだ」「悪かった点：□□ができなかった」といった内容が挙がります。KPT法やYWTなどでふりかえりを行い、次に繋げるために何に取り組むのかをメンバーで共有すると、次に何を探索するのかを検討する材料になります。
(2)ベテラン技術者の経験談(失敗したこと)
プロジェクトによりますが、ベテラン技術者と連携してテスト実施することがあります。雑談時にベテラン技術者から過去関わってきたプロジェクト案件について、苦労話を聞くことがあります。特に納期が迫り、慌ててコーディングした後のテストでなかなかPass(合格)しないことが多々あったそうです。同じ過ちを犯さないようにソフトウェア設計で状態遷移図を書いて網羅性について机上で検証した上で、コーディングしてからは以前のような苦労も少なくなったとのこと。失敗から学ぶことは多く、我々が陥りやすい罠を知ることもテストチャータになると考えます。
(3)開発でよく失敗する処理に関わる機能
(2)に関連しますが、私がインシデントレポートからピックアップして処理で失敗した内容をメンバーで共有後、少し議論することがあります。議論の末、新たな気付きが出てくることがあり、テストチャータとして活用しています。
(4)表示系デバイスの連打入力
とある勉強会の懇親会(居酒屋)での出来事ですが、タッチパネル式の注文用端末があったので、端の領域を連打したところ、突然ブラックアウトして再起動され、Linuxの起動画面を目にしたことがありました。メカニズムは分かりませんが、発生した事象をパターンとして蓄積することで、様々なタブレット端末で「タッチ領域の端」「連打する」というアイディアが浮かびます。
(5)市場不具合の再発防止策
市場不具合発生時、開発マネージャや開発リーダから不具合事象と不具合修正方針、再発防止策案の説明頂くことがあります。不具合修正確認テストは、数日から1週間程度の期間で完了する必要があり、スクリプトテストを抜粋しただけでは、潜在不具合を検出することが困難な場合があります。そこで、私と1～2人のメンバーで、不具合事象と不具合修正方針、再発防止策の内容を共有した上で、「不具合修正されたとき、(副作用として)どのような失敗が発生するのか？」を話し合い、「何に着目して、どのようにテストを実施するか？」を大まかに決め、スクリプトテストを抜粋したテストケースと共に念のため探索的テストを実施することにしています。
次回は、「JaSST'12東海SIGでの気付き」の【7.○○をやってみた】です。
