早めにテスト、みんなでテスト、開発者としてテスト

Agile Testing Days 2019に行ってきた vol.5

バックエンド開発者のテスト

Agile Testing Days 2019（以下、ATD2019）に行って思ったことは、みんな同じような境遇で、アジャイル開発の中でテストに関して悩みを持っており、その悩みを共感しあえることでした。

それはそれで楽しいのですが、実際開発者の声が聴きたいと思ってプログラムを調べていると、ちょうどバックエンド開発者のトークがあったので興味津々で聞いてきました。そして実際かなり勉強になりました！

QA from the perspective of a Backend devをご紹介

Virginia Weidhaas（ @vweidhaas）はミュンヘンでフィットネス系アプリのバックエンド開発者で、普段からテストに関して関心があり、開発者とQAエンジニアがチームでどのような活動をしたかを説明してくれました。

このトークでは開発者もQAエンジニアもお互いを理解し合い、早めのテストをすることが一番効果的だということを理解した上で、どう改善したかを話していました。

相互理解

テスターが思うテスターの仕事って？

• 情報収集
• 期待と現実の確認
• リスクを発見して軽減する

開発者が思うテスターの仕事って？

• チームのゴールに向かって働く
• エッジケース（限界値等）見る
• アプリケーション壊す

そもそもプロジェクト内のメンバー同士の理解が一致していません。

早めにテスト

開発の後にテストを始めるのではなく、リファイメントの中でテストを開始します。テストシナリオはユーザーストーリーの一部として捉えるそうです。

そのためには、意味のあるテストデータを開発とQAでお互いに提供して、テストシナリオを事前に作成します。またコードが変更されたら早めにQAエンジニアにプルリクエストかけてレビューしてもらうとユーザー視点の指摘が来るので効果的とのことです。

みんなでテスト

意味のあるテストデータでテストし、バグが発見された場合は、一緒に再現させ、お互いをサポートします。またいつでもバグの状況が見えるようにしておくと良いのだそうです。

何より一緒にテストすることが大事とのことです。

（ということで この写真が紹介されました。雰囲気が良いことが伝わってきますね！）

開発者としてテスト

トークの中で面白い例がありました。

テストのボリュームを水道の蛇口から出る水の量で表現すると、開発者のテストはチョロチョロ、テスターのテストは勢い余ってシンクから出るくらいの量。

つまりこの例のように、「開発者のようにテストしないでください（Don't test like a developer）」
ただし「開発者としてテストしてください（But test as a developer）」というもの。

Controllability

開発者はユニットテストの中でテストをコントロール出来ます。正常パターンと異常パターンを事前に把握し、考えられるテストパターンをユニットテストの中で網羅するようにすれば、デプロイ後のテストはコントロールできます。

Observability

HTTPのエラーコードは普通に使いますが、標準のエラーメッセージを使っても、何かあった時に観測しにくいです。エラーコードと意味のあるエラーメッセージを仕込むことでObservabilityが向上します。つまりデプロイ後もテストは終わりません。

感想

バックエンド開発者も普段からテストを意識して開発していることが良くわかりました。特にデプロイ後のテストは膨大でそれを全部手動テストするとコストがかかることをよく知っており、ユニットテストで出来る限りテストを網羅することの意識が高いです。一方でデプロイ後のテストは極力コストかけずに、むしろObservabilityに注力することに意識が向いていることがわかりました。

なんと言ってもこれを実現するためには開発者とQAエンジニアが一体となって品質を作り上げる。この一体感が成熟すれば生産性も品質も向上するということでした。アジャイルの醍醐味ってこれですね！