品質やテストのアドバイザーであり続けるQAチームへ

※この記事は 2023年05月15日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。

Tebiki社でQAエンジニアをしている中西です。

「開発エンジニア自身がプロダクトの品質保証をする。」このように開発エンジニアが自信をもって開発・テストできるようになってほしいと思いませんか？

この記事では、「品質やテストのアドバイザーであり続けるQAチームへ」というタイトルで、Tebiki社での品質やテストのアドバイザーとしての関わり方とそのような関わり方をしている理由、今後の関わり方を紹介します。開発エンジニアを間接的に支える働き方をするQAチームに興味を持って頂ければ幸いです。

品質やテストのアドバイザーとは

我々QAチームは、「プロダクト開発に関わる全ての人がより早く、自信を持って、継続的にユーザにとって正しい価値を提供し続けることを支援する。」というミッションのもと活動しています。現在は「自信を持って、継続的にユーザにとって正しい価値を提供し続ける」ことに注力したサポートを行っています。

具体的なサポート内容は以下の通りです。

・要件の確認・開発内容の確認・実装方針の確認・テスト観点のアイデア出し・テストケースの作成要領の説明

なお、QAエンジニアが得意とする各機能のテスト設計やテスト実行、リリース前のリグレッションテスト（手動）は開発エンジニアが行っています。一部のテストタスクは、QAエンジニアと開発エンジニアで、モブワークを行い、テスト設計やテスト実行を支援します。

また、「継続的にユーザにとって正しい価値を提供し続ける」ために、QAチームは以下のテストプロセス改善や開発エンジニアへのテスト技術伝承にも取り組んでいます。

・テスト技術マニュアルの作成と技術伝承・プロダクトリスク分析の導入・シナリオテストの導入・テストレベル、テストタイプの整理 etc

このように弊社のQAチームは品質やテストのアドバイザーとして、開発エンジニアの業務をサポートしたり、プロセス改善をリードするようなチーム横断的なサポートを担っています。そのため、QAチームはスクラムチームに所属していません。

品質やテストのアドバイザーであり続ける理由

理由は3つあります。

１. スクラムチームに一定のプロダクト品質を確保する仕組みがある

弊社のスクラムチームには以下の特徴があります。

・フィーチャートグルを使って、開発〜リリースまでを行い、本番環境に影響が出ないように、コード管理をシンプルにしている。

・プロダクトバックログ1件に対する開発ボリュームを極力小さくしつつ、開発〜リリースまでを行っている。

・開発エンジニア自身が各プロダクトバックログの背景を理解し、開発・テストを行っている。

・改修したコードに対して、単体テストやAPIテストを書く運用が定着している。

このように、シンプルなコード管理を採用し、少しずつ開発を進め、リリースするサイクルを繰り返すことで、スクラムチーム内で一定の品質を保ちながら、開発とリリースを行っています。

2. QAチームに依存しない仕組みを継続させたい

QAエンジニアがスクラムチームに入り、探索的テストやアドホックテストを行うことで、QAエンジニアが品質の門番になり、開発のボトルネックになってしまうリスクがあります。そのため、開発エンジニアと一緒にテストを行い、テスト内容をサポートすることで、QAエンジニアに依存しない仕組みを継続させる狙いがあります。

3. QAエンジニア以外のメンバーに品質やテストを好き・得意になってもらう

プロダクト品質を上げるための一つの施策として、QAエンジニア以外のロールのメンバーに品質やテストについて考えることが好きで、得意になってもらうことを挙げています。そのため、テスト設計やテスト実行をQAエンジニアのタスクとして捉えるのではなく、QAエンジニアがテストや品質の魅力や考え方を伝える立場を取っています。

弊社のスクラムチームは、品質やテストを自分事として捉えてくれています。自分たちでより良い品質のプロダクトをユーザに提供するためにはどうすれば良いかを考えて、行動しています。そのようなスクラムチームであるからこそ、QAチームが品質やテストのアドバイザーとしてあり続けられると考えています。