プロダクト開発チームがスクラムを回しながらQAも実施するためやっていること

私たちのプロダクト開発チームは自分たちでQA活動にも取り組んでいます。どんな取り組みかをまとめてみました。

こんにちは、グロービスの企業研修向けLMS開発チームでチームリーダー兼スクラムマスターをやっている成木です。
以前に弊社QAチームの取り組みやチャレンジについて投稿されていますが、今度はプロダクト開発チームが行っているQAの取り組みについてご紹介したいと思います。

なぜプロダクト開発チームがQAに足を踏み入れるのか

グロービスでは各プロダクト開発チームとは独立した形でQAチームが組織されています。現状はプロダクトに対してQAエンジニアの人数がまだまだ足りておらず、各プロダクト開発チームにてQAエンジニアのリソースを取り合っている状態です。

いつでもQAチームに協力をお願いできるとは限らないため、プロダクトの品質を維持しながらも素早く価値をとどけていくためには自分たちでQAを行えるようになっていく必要がありました。

とはいえ、チームにはQAに関する知識やスキルを持った人はほとんどいません。そこで「少ないリソースでQAの効果が期待でき、かつ、チームが継続的に実施できること」を前提として、可能な限り効率的にチームでQA活動を行うためには何が必要なのか、QAチームと相談しながら模索しました。最終的に「プロダクトバックログの改善」と「テストコードの改善」の2つにTryすることにしました。

プロダクトバックログの改善

プロダクトバックログはユーザーストーリー形式でつくられており、プロダクトオーナー（PO）がWhy（なぜやるのか）とWhat（なにをやるのか）を、開発者がHow（どう実現するのか）を記載していました。しかし、これだけだとQAとして必要な観点が不足しているため、考慮漏れが度々発生しバグを生み出す原因になっていました。

そこで、プロダクトバックログのふりかえりを実施し、記載する内容を改善していくことにしました。プロダクトバックログがどんな風に書かれていると良かったかをQAチームを含めて議論していきました。

プロダクトバックログはチームでつくりあげる

プロダクトバックログは基本的にPOが書きます。しかし、POだけが書くと確認するポイントに偏りが生じてしまいます。なので、プロダクトバックログの内容はPO・開発者・QAチームがそれぞれの立場で観点を追記していき、全員でつくりあげるようにしました。特に、受け入れ条件は事前にすべての確認事項を網羅してつくるのは難しいので、開発者やQAチームが気づいた段階で追記するようにしています。

こうすることで、プロダクトバックログが開発者がやるべきこと・満たすべきことがわかるだけでなく、QA/テストを行う上での観点や注意しなければならないことをチーム全員の共通認識として得られるようになります。QA/テストに必要な観点の抜け漏れを減らし、さらにこれらの作業を属人化させないことにも繋がりました。

現在チームで使っているプロダクトバックログテンプレートはこのようになっています。

[Title]
___として、___したい。なぜなら___だからだ。
[Description]
Why・What 【課題/ニーズ/提供価値】
やりたいこととその理由および背景（発端となる出来事など）を記載
Reference 【参照】
発端となった問い合わせやディスカッションの内容、決まったデザインなどがわかるURLやファイル添付
Acceptance Criteria【受け入れ条件】
PO・開発者・QAがそれぞれの立場で確認する内容を記載
画面上で確認できないものであっても想定している動きのメモとして残しておく。例えば裏でデータを操作すれば確認できる場合にはその条件や内容を、テストコードで担保している場合はその範囲と内容を記載
Ready for Development【開発Readyのための確認事項】
開発を行う上で決めておきたい細かな仕様や確認事項などを記載
Test Cases 【テストケース】
テストコードの概要やどこまでテストを行うかを記載（開発者はテストコードを書く前にこのストーリーで何をテスト・確認するかを先にかく）

テストコードの改善

これまではシステムのバージョンアップや、システム構造の大規模な変更を伴う改修など、必要に応じて開発者がテスト項目書をもとに手動でテストを行っていました。しかし、時間がかかる割にバグの検知率はそれほど高くありませんでした。とはいえ、全くやらないというわけにはいきません。そこで、テストコードが担う役割と範囲を広げようと考えました。

テストコードをドキュメント化

まず最初に行ったのは、テストコードのドキュメント化です。テストコードは、プログラムを変更したことで他の箇所が壊れていないかを確認するためのもので、主に開発者しか活用していませんでした。開発者がわかればよいという考えがベースにあるため、テスト項目（タイトルや説明）の粒度や記述の仕方が整理されておらず、文法や表現なども書く人によってばらつきがあり、他の人が見たときに何を確認しているのかがわかりにくい状態でした。

そこで、テスト項目書を先に作り、それをテストコードに落とし込むようにしました。テスト項目書として整形されているドキュメントから作るので、各テスト項目がとても読みやすくなるメリットがあります。これにより、このテストコードでは何を確認しているのか、きちんと要件を満たされているのかがとてもわかりやすくなりました。またテストフレームワークの機能で実行結果をドキュメント形式で出力することもできるので、テスト結果を他の開発者・QAチームに共有することで仕様の理解やお互いの認識あわせがとてもスムーズに行えるようになりました。

QAチームによるテストコードレビュー

開発者だけではどのようなテストコードが書かれていればQAとして担保できるのか判断できないケースがあります。そこで、テストコードの内容についてフィードバックを受けられるようにしました。開発段階でのコードレビューにQAチームにもレビューワとして参加してもらい、テストコード部分だけをレビューしてもらっています。そのおかげで、早い段階でテストコードに関する見直しと改善ができるようになりました。
（テストコードのレビューを行うためには、プログラミング知識やスキルが求められます。QAチームにはかなり開発側に歩み寄っていただいているので実現ができています。感謝！）

Featureテストの充実化

Featureテストはブラウザの操作をシミュレートすることによって動作を検証するテストです。Featureテストにかかれている内容を整理すると、Viewの単体テストとして書かれるものと、E2E（End to End）に近い結合テストとして書かれているもの2種類に分けられることがわかりました。後者に関しては、AutifyのようなE2Eテストツールを補完するものとして利用できそうであったため、実際の一連の操作の流れを想定してテストコードを作るようにしています。これによって、手動で行う形式的テストの大部分はここでカバーできるようになる想定です。まだ実現できていませんが、ゆくゆくは開発者が手動で実施している形式的テスト（スクリプトテスト）を全てテストコードで担保できることを目標に取り組んでいます。

まとめ

プロダクト開発チームがスクラムを回しながらQAも実施するための取り組みを紹介いたしました。開発フローの中にQAを意識するプロセスが入り込むことで、ドキュメントの質があがり、チーム内での仕様理解が深まり、そして、プロダクトの品質を向上させ維持していくことにつながっていくのではないかと思っています。

まだかなりの部分をQAチームに協力してもらいながら進めていますが、将来的にはチーム内でQAまで完結できるようにしていきたいですね。

最後に

グロービスでは一緒にプロダクト開発をしてくれるエンジニアを募集しています。プロダクト開発チームとしてQAまで責任をもってやりたいエンジニアの方、そんなプロダクト開発チームを支援したいQAエンジニアの方、お気軽にお問い合わせください！

ENTRY | GLOBIS エンジニア・デザイナー採用サイト