アジャイル・DevOps時代におけるQAエンジニアのあるべき姿

最近、話す機会が多くなった「アジャイル・DevOps時代のQAエンジニアのあるべき姿」について書いてみようと思います。

なぜ書くのか？

アジャイル開発においてQAエンジニアは必要なのか？

なかなかキャッチーなテーマで興味をそそりますが、「いる・いらない」の議論になるほどシンプルではないでしょう。さらに、どちらにころんでもその先が見えません。よって、個人的には「どうあるべきか」を議論する方を好みます。

QAエンジニアに限らず、時代の変化とともに役割も変わっていきます。おそらく、これまではひとつのことをずっとやっていても問題ありませんでしたが、チーム開発が増えてきて、役割分担も曖昧になり、キャリアとともに求められる成果も高くなっていきます。

残念ながら、この記事を読めば未来予想できるというわけでもありません。あくまで、自分が見た範囲の想像でしかありません。

しかし、もしこの記事が、少しでも誰かの地図になれるとしたら、僕にとってそれはとても喜ばしいことです。いつかその地図の先でお会いできることを楽しみにしています。

誰が何をテストするのか？

開発に関わる関係者全員が品質に貢献すべきです。その手段は「テスト」でなくともいいと思います。よいフィードバックを提供するのも品質につながるでしょうし、よい設計も品質につながります。

アジャイル開発には開発もテストも含まれているはずです。開発とテストを分けて扱うと便利な面もありますが、アジャイル開発やDevOpsを目指すのであれば、職能横断的なチームで分離を避けるべきでしょう。

「テスト」に注目してみましょう。あらゆるすべてを語るのは難しいので、単純に表現します。

単体テスト
機能テスト
リグレッションテスト
受け入れテスト

単体テストは、開発者の大切な仕事です。すぐれた小さい部品は性能の良いネジのように、組み立てたときにさらなる価値を提供してくれます。

さらに、単体を組み合わせて作った機能のテストも、開発者の責任範囲にしてみましょう。機能とはAPIであったり、画面を通しての機能を指しています。機能テストは、ユーザーストーリーに書かれている物語の実現を確認するテストです。仕様通りかの確認を開発者にまかせることで、「QAにチケットが回ってきたけど動かない」なんていう、品質に対する関心の分離を避けられます。

もしあなたのチームにQAエンジニアがいるなら、リグレッションテストはQAエンジニアが責任を持ちます。開発者による機能テストに対してレビューや助言を与え、よりよいテストを支援します。そして、そこで得た知見を活かし、機能テストをリグレッションテストに落とし込みます。

あらゆるすべてをリグレッションテストに含めるのは不可能です。よって、機能テストからリグレッションテストに落とし込み、「本当にこれをリグレッションテストに加えるのか？」を検討します。自動化するかどうかも同時に決めるといいでしょう。自分でコードを書いて自動化したり、mablのようなサービスを使うのも手です。

ユーザーストーリーや仕様を実現したならば、それが本当に必要だったのか。もっとよくできないのかを受け入れテストで確認します。スクラムでいうスプリントレビューかもしれませんが、そんな場で仕様通りかの確認をしていては時間がもったいない！動いているものをみながら、よりよいアクションを皆で考える場にしましょう。