経験・行動面接

例えば、ポイントの付与の変更で、キャンペーン期間の境目の日に二重にポイントが付く不具合を見逃したことがあります。テストでは日付の境目を検証環境の時刻で試せず、確認を省いていました。

発覚後は、影響を受けた利用者を DB で洗い出して開発者と修正の対応をし、ポストモーテムで「時刻に依存する処理を試せない」ことが根本の原因だと共有しました。開発者と相談して時刻を差し替えられる仕組みを入れ、日付の境目のケースを自動テストにしました。それ以来、期間ものの機能では境目のテストを必ず計画に入れています。

例えば、ある不具合を私は重大度「高」としましたが、開発者は「まれな操作なので低い」と主張したことがあります。私は、まず相手の言う「まれ」を確かめるために、分析のデータでその操作の割合を調べました。

割合は約 3% でしたが、起きると注文の金額が誤るので影響は大きいと、データと再現手順を添えて話しました。そのうえで、すぐの修正が難しいなら入力の段階で止める暫定の対策を提案し、合意しました。それ以来、重大度は「頻度」と「影響」を分けて書く決まりをチームで作りました。

例えば、リリースの前日に、古い版のアプリから新しい API を呼ぶとログインできなくなる不具合を見つけたことがあります。利用者の約 2 割がまだ古い版だったので、影響と再現手順をまとめて PdM に伝え、延期を提案しました。

同時に、延期以外の案として、古い版のときだけ従来の API を使う設定を開発者と検討しました。結果、その対応を入れて半日遅れでリリースでき、問い合わせは出ませんでした。止めることそのものより、判断に必要な事実と代案を素早くそろえることが大事だと学びました。

例えば、営業のイベントに合わせたリリースで、テストの期間が予定の半分になったことがあります。私は、変更点ごとに影響と壊れやすさを付けた表を作り、PdM と開発者と30分で優先度を合意しました。

お金にかかわる計算と新しい画面の主要な流れは厚く確かめ、変更のない画面は自動の回帰テストだけにしました。削った範囲は「しないこと」として書き残し、リリース後の監視の項目と、1週間後の追加のテストを計画に入れました。重大な流出はなく、削った範囲の判断の記録は、次の計画のときにも役立ちました。

不満ではなく、やりたいことを中心に話します。例えば、「今の職場では手動のテストで多くの不具合を見つけてきましたが、その経験から、仕組みで品質を上げることに面白さを感じるようになりました。自動化と仕様の段階からの関わりにもっと深く取り組みたいと考えています」と話します。

そのうえで、応募先の QA の体制や技術ブログの取り組みから、そこでなら実現できる理由を具体的に結びつけます。QA を続ける理由は、自分が見つけたことがチームの仕組みとして残り、利用者の困りごとを減らせる点だ、と自分の言葉で伝えます。

最初の1か月は知ることに使います。製品を一通り使い、過去の不具合と流出の記録を読み、開発者・PdM・サポートに「いちばん困っている品質の問題」を聞きます。テストと自動化が今どこにあるか、CI でどれくらい時間がかかるかも確かめます。

2か月目からは、聞いた問題のうち効果が大きく小さく始められるものを1つ選んで成果を出します。例えば、flaky なテストの整理や、主要な流れのスモークテストの自動化です。3か月目に、分かったことをもとに品質の目標とテストの戦略の案を作り、チームと合意します。いきなり大きく変えず、信頼を作ってから広げます。