QAがプロダクト品質保証のOwnershipをもつ方針へ！現状課題と今後の展望 | Resilire Tech Blog
はじめに
サプライチェーンリスク管理クラウドサービスResilire の@teruhikyです。
本件について、JaSST nano vol.38でLTしましたが、
今回改めてプロダクト品質のQA方針・直近の取り組みをテックブログにしたいと思います。
本内容は、QAエンジニアの方々との壁打ちを通して見えてきた弊社における方針であり、一例程度に捉えていただければと思います。
プロダクト開発フローとその根底にある方針
QA方針や直近の取り組みについて話す前に、まずはその前提となる弊社のプロダクト開発フローを紹介します。
上図のように、タスク管理はAsana、プロダクト仕様はFigmaに集約しています。
ロードマップ案件が始まるとPRD(Product Requirements Document)、デザイン、レビューを踏まえて、
その後実装担当のエンジニアを入れてキックオフを行い、設計とタスク分解が始まります。
キックオフの場で、それまでのユースケースやデザインを踏まえたユーザー体験をどういう仕様で実現しようとしているかを説明します。
リードエンジニアが開発観点で一定のレビューはしているものの、詳細設計を進めていく中で
仕様上難しい点が生じることはあるので担当エンジニアによる設計時に改めて整理していきます。
そのあとはスケジュールとリリース戦略をPdMと整理した上で、段階的にリリースを行いリリースインパクトを限定するように進めています。
段階的なリリース方針を支えるリグレッションテスト
このプロダクト開発フローの根底には、新機能リリースの準備段階の変更や既存機能のエンハンス、リファクタリングを都度リリースしていくことで、
ビッグバンリリースを回避するという方針があります。この方針を実現するためにはリグレッションテストの充実が欠かせません。
B-to-Bプロダクトの場合、一部の機能の仕様変更はユーザーの同意を得てからリリースするケースもありますが、
設定値による切り替えとソースコードのリリースは別で進めていけるように考えています。
この方針からも、弊社のリグレッションテストの充実と自動化が本方針を維持するために非常に重要であることが伝わるかと思います。
現状のテスト状況と課題感
そんな弊社ですが、プロダクト特性の観点でもリグレッションテストを自動化していかないと品質担保が難しいというのが現状です。
以下がResilireのプロダクト画面イメージになりますが、ユーザーは会社と会社の取引先を結んでいくことでサプライチェーンのツリー構造を構築します。
ツリー画面内の個々のノード上で入力された情報と、システムが裏で収集してきた災害情報を突合することで、”どこの取引先拠点が被災したのか”や、
アンケートを自動送信することで”その取引先の稼働に影響があるのか”といったことを確認します。
サプライチェーンのツリーと被災地域の可視化
仕様の概要としては、
- ”地震などの災害が発生した時に”
- ”自動でシステムが被災した取引先拠点の担当者にアンケートを送信する”
という仕組みになっているため、リグレッションテストが画面操作だけで完結しないという特徴があります。
大部分を人の手に頼らざるを得ないリグレッションテストの現状
現状はPdMがリリース時のテストの大部分をこなしてくれていますが、一般的なWebサービスの機能の部分はともかく上記の機能が正常に動作するのか、
被災取引先の数が正しいのかといった確認はPdMだけで完結しないので、PdMとエンジニアが手分けして確認する必要があるのが現状です。
Resilireにおけるリグレッションテストの一例を挙げましたが、他にも画面上で大規模なツリーを操作するなどUI/UXがリッチで実装の複雑性も高い画面も多いため、ユーザー観点やエンジニアリング観点でのテストも必要です。
それぞれの観点で品質を担保していくためには、リグレッションテストまで含めて担保するべき観点を整理して自動化していく必要があります。
QAがプロダクト品質保証のOwnershipをもつ方針へ
これまでの観点から、弊社のプロダクトの品質担保のためにはリグレッションテストの自動化が重要ということがわかりました。
とはいえ、今後も変化・拡充されていくプロダクトにおいて自動化されたリグレッションテストの運用保守はそれなりにリソースがかかります。
そこで、効率的かつ戦略的にアプローチするためにも弊社では、
”QAがプロダクト品質保証のOwnershipをもち、チーム全体で協働して品質保証を実現していく” 方針にしようと考えることにしました。
自動化を念頭に開発チーム全体で実現する品質保証
もしQAチームを別途作ってEnd-to-Endテストの拡充をお願いする場合、開発担当エンジニアが担保する単体テスト・結合テストとのテスト観点の重複が考えられます。
また、End-to-Endテストでしか担保しにくいエンジニアリング観点のテストはやはり扱いづらくなってしまいます。
リグレッションテストを単体テスト・結合テスト・End-to-Endテスト・手動テストのどこで担保していくのかを効率的に判断・運用するためにも前述のとおり、
”QAがプロダクト品質保証のOwnershipをもち、チーム全体で協働して品質保証を実現していく” 方針を目指すことを考えています。
この方針はQAオーナーとしてより高い視座を持ってプロダクト品質へのOwnershipを期待することになるため採用ハードルが上がります。
しかし、QAの方にはよりチャレンジングな機会を提供でき、開発担当エンジニアの方にも単体テストからEnd-to-Endテストまでカバレッジが広がることによりドメインの理解が進むのではないかと考えています。
直近の取り組み
上記QA方針を踏まえて、実現のために早速足元で動き始めています。
リグレッションテストの自動化を進める必要があるのですが、スタートアップの限られたリソースで効率的に品質を改善・担保していく必要があります。
そのため、Asana上で障害や不具合報告、またリリース前のテスト時に見つかった不具合について、分析できる体制を整え始めています。
具体的には、Asanaの各チケットにおいて分析用の項目を追加して、既存のチケット運用フローに入力を組み込んでいきます。
現状は追加する項目とその選択肢をもう少しでFIXするところですが、こうすることで、
- リリース後の不具合については、どの機能・実装箇所の品質をどのテストで改善するべきかとその優先順位
- リリース前の不具合については、正しいタイミングで検出できている不具合なのか（シフトレフトできるのか）
を判断できるようになる見込みです。
今後の展望
現状はまだまだ採用の関係もあり限定的な動きしか取れていませんが、
今後は以下の取り組みも考えています。
- プロダクトユースケースを整理することで主要導線のテストケースを整理
- End-to-Endテストのためのツールの選定と検証（Playwrightが現状有力候補）
- プロダクト開発フローへの品質担保とテスト観点の組み込み（どの観点のテストをどの自動テストの実装で担保するべきか）
まずはプロダクト開発フロー全体への取り組みがメインになってはいますが、究極的には組織全体でいかにユーザーの求める品質を担保していけるのか
といったところへの取り組みもQAの方と取り組んでいきたいなと考えています。
まとめ
そんな株式会社 Resilire (レジリア) では、サプライチェーンリスク管理クラウドサービスResilireのQA・開発メンバーを募集中です。
特に、エンジニア・PdMとチーム一体でプロダクト品質を向上しにいく1人目QAの方をやりたい！という方、ぜひお待ちしております。
Discussion