プロジェクトに所属する一人のプログラマとして、
QAチームのために自主的にやっている事をまとめました。
エビデンスは無い為、ツッコミ大歓迎です。
1．影響範囲を過不足なく伝える
例えばログイン機能へエラー処理を追加した場合に
影響範囲：ログイン画面
と書いてしまうと、QAチームはログイン画面のUIと挙動の全てを検証する羽目になってしまいます。
エラー処理を追加しただけなら、UIやログイン成功時の処理は影響範囲外のはずです。
この場合は
影響範囲：ログイン画面のログインボタン押下時の異常系
と書くことで、QAチームが必要最小限の検証で済むようにしています。
2．検証中に遭遇する既存バグを、事前に伝える
プログラマは影響範囲を細かく把握しているため、検証中に見つかったバグがデグレか既存バグか容易に切り分けできます。
しかしQAチームが切り分けする場合は、古いバージョンと動作を比較する必要があるため時間がかかります。
そこで、自分が行う単体試験中に見つかった既存バグは起票し、検証を依頼するタイミングでその既存バグを伝えることで、QAチームはバグの切り分けをしないで済むようにしています。
3．試験方法を伝える
例えば通信速度が遅い環境で起きるバグを修正した場合、試験に使える方法(Network Link Conditionerなど)を伝えることで、QAチームが効率的に検証が行えるようにしています。
また、アプリ内にデバッグメニューを用意している場合は、その使い方も伝えています。
4．起こりうるバグを伝える
複雑な実装をしたり影響範囲が非常に広い場合、検証の難易度は高くなります。
例えばバックグラウンドで定期的に行う処理は、動作が目に見えないため試験項目が漏れやすいです。
そのようなケースでは影響範囲と合わせて「起こりうるバグ」を伝えています。
例えばバックグラウンドで行われるニュース自動取得機能を修正した場合、「起こりうるバグ」は以下になります。
アプリを再インストールした場合に、ニュースがしばらく表示されない
アプリ起動時には記事が更新されるが、10分後に記事が自動更新されない
サーバ上で非公開になった記事がアプリ上で表示され続ける
これらを伝える事で、QAチームは
「そのバグが起こりうるなら、あのケースも確認したほうがいいな」
とイメージできるようになり、検証の精度が向上すると考えています。
5．感謝を伝える
QAチームがバグを検出してくれるからこそ、我々プログラマは安心して開発に集中できます。
そのためQAチームに検証のお礼を伝えるようにしています。
QAとエンジニアの関係が良好になれば心理的安全性が高まり、コミュニケーションが活発になることでバグを大きく減らせると考えています。
↧
