こんにちは。freeeでQAエンジニアをしているkenseiです。 freee QA Advent Calendar2024の4日目です。
QAとしてある程度経験を積むと「もっと上流から関わっていきたい」という意識が出てくるという話をよく聞きます。 そこで今回は「QAが上流から関わる」というのは具体的に何をしているのか、どういったメリットがあるのかについてや、チームでやっている取り組みについて書こうと思います。
はじめに
まずはfreeeでは実装に入る前にどういった工程があるのか、私が所属している開発チームを例に見てみましょう。
成果物 | 詳細 | オーナー |
---|---|---|
Brief | 開発のきっかけとなる課題や背景、想定ターゲットやインパクトについて記載する。 後述のPRDと合わせて作成されることが多い。 | PdM |
PRD | 課題解決にあたり何をするのか、しないのかをざっくり記載。スケジュールについてもここで考慮する。 | PdM |
要求・要件一覧 | [PM]PRDから整理した要求とユースケースを記載 [Eng]要求をシステムで実現するために必要な要件を記載、合わせて概算工数見積を行う。 | PdM+Eng |
デザイン | 個別の画面設計や文言、画面構成や遷移フローを設計する。 | PD |
DesignDoc | 実装にあたり必要な情報を整理, 設計する。また、結論に至るまでの設計思想も記載しておく。 | Eng |
※1: PdM = ProductManager
※2: PD = ProductDesigner
名称は独特ですが、企画→要求整理→要件定義→外部+内部設計という一般的な流れを踏襲しています。
QAはどうする?
これらの成果物に対してQAは何を見てどういったアクションを取るのかについて記載します。
Brief/PRD
こちらに関しては記載されている情報を見て理解するに徹することが多いです。 特に下記は注意して見ているポイントです。
- 課題として上がっている内容が実は既存のサービス仕様で解決可能だったりしないか?無駄な新規実装になったりしないか?
- 想定ターゲットはどんな属性だろう?大規模事業所がメインターゲットであれば性能面など非機能要件のテストもこの時点で想定しておく。
要求・要件一覧
この段階で漏れがあれば不具合に直結するため、こちらがQAとしては最も重要な資料だと考えています。
QAとしては主に異常系動作や、データ操作をトリガーに行われる副作用(ステータス変更など)が考慮されているかという点を中心に、「この要件を元にテストできるか?」という意識を持って確認します。
こちらはEngが作成する資料ですが、QAも一緒に作るのが理想です。
デザイン
デザインに関してはFigmaで作成することが多いです。 QAとしてはこちらを元にテストを行い、デザインの不備がないかを確認します。
DesignDoc
こちらは要件定義段階より深ぼった詳細設計が書かれているので、QAとしては処理の流れや処理方法について確認し、不明瞭な部分があればツッコミを入れます。
例として、非同期処理を行う箇所があるか、非同期処理が失敗した場合のリカバリ手段まで考慮されているかなどがあります。
また、この段階で開発案件の重篤度(どういった不具合が起きるとマズいのかを事象ベースで表現した指標)を決定します。
QAが上流から関わる効果
前段で説明した通り、Brief/PRDとデザインに関しては情報を得るために利用し、要求・要件一覧とDesignDocに関してはEngと一緒に考えるというスタンスで向き合うことが多いです。 そのように関わっていくと大きく2つのメリットがあります。
フィードバックの高速化
ひとつはQAが考えるテスト観点を早期に共有, 反映させる、フィードバックの高速化が可能になります。 一般的に工程が後になるほど不具合の修正コストが増加します。 修正コストが増加する要因としてはテスト段階での不具合増加によるチケット起票や不具合修正+修正確認によるものが大きいです。 しかし開発フィードバックの高速化により、手戻りを減らして開発全体のリードタイムを短くすることができます。
テストプロセスの効率化
もうひとつはテストプロセスの効率化です。 テストプロセスは主にテスト分析→テスト設計→テスト実行→不具合修正確認という流れですが、要求・要件一覧の段階で「この要件を元にテストできるか?」という視点でQAが入りフィードバックを行うことにより、テスト対象を理解してどういったテストが必要かを整理するテスト分析の工程をほとんどゼロに近づけることが可能になります。
みんなで品質を高めよう
ここまではQAが主体の話をしましたが、良いプロダクトを作るためには関係者全員で品質を高めていく、ファンクションを横断した品質保証ができるチームが理想です。
そういった理想のチームに向けて新しく始めた取り組みをひとつ、ミニぽち会というものを紹介します。
ミニぽち会とはストーリー単位で実装した成果物に対し、開発関係者が集まって要件を満たしているかを短時間(15分ほど)で確認するイベントです。
合わせて使い勝手やデザイン面など気になる点があれば共有し、対応するか否かを判断します。
元々は開発した機能をリリース前にみんなで触ってみるぽちぽち会というイベントがあったのですが、それを細かい単位で実施するという点がミニぽち会の名称の由来になっています。
ここで要件を正として扱うので、事前に定義する要件の正確性, 網羅性がミニぽち会を有意義な時間にできるかに直結します。
こちらの取り組みもフィードバックの高速化によるリードタイム短縮に寄与しています。
実際にミニぽち会をやってみた開発ではテスト段階の不具合が非常に少なく、テスト完了とほぼ同時にリリース可能な状態となりました。
ちなみにミニぽち会はEngがやってみようと言ってくれたのがきっかけで始まったもので、チーム全体で品質を上げていこうというのを体現しているようなエピソードだったと思っています。
おわりに
ここまで書いた内容は全く新しい革新的なものではありません。仕様段階で品質を担保しよう、前工程で不具合を検知して手戻りを減らし開発スピードを上げていこうというどこかで聞いたことのある内容だと思います。当たり前と感じる人もいるでしょう。
しかし、品質を上げていくには「これをやれば万事解決」といった銀の弾丸はありません。当たり前のことだとしても地道に継続していくことが大事だと考えています。
明日は、QAエンジニアのsugeno-sanが「チームで実例マッピングをやってみた」について記事を書いてくれます。 お楽しみに〜!良い品質を〜