スポンサーリンク

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

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

スポンサーリンク

なぜ書くのか?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本当にそれだけ?

んなわけありません。継続的インテグレーション、継続的デリバリー、継続的テスト、継続的データ分析を継続的に行っていかなければなりません。これらを実現するためのスキルが開発チームには求められるはずです。

  • 継続的インテグレーションを実現するために、CIを構築運用しビルドを安定化する役割
  • 継続的デリバリーを実現するために、CIや各種自動化技術を活用しビルドパイプラインを作り上げる役割
  • 継続的テストを実現するために、探索的テストやテスト自動化技術に精通し、プロダクトの品質を作り込んでいく役割
  • アジャイル開発、スクラムを適切に運用改善できるスキル
  • などなど

「テスト関係の仕事だからQAエンジニアがやる」や「プログラムを書くから開発者が」という考えは避けていくべきでしょう。それが続くと開発と品質間に壁が生まれてしまいます。

開発者はもうプログラムを書くだけでは評価されません。QAエンジニアはもうテストをするだけの仕事では評価されません。

どういった付加価値をキャリアに積み上げていくか? この問いは、すべての人に問われているのだと思います。

タイトルとURLをコピーしました