こんにちは
freee会計のQAエンジニアをしているsugenoです。
freee QA Advent Calendar 2023 24日目です。
私は2023年4月にfreeeにQAエンジニアとして入社しました。
今回は、会計チームでマインドマップを用いたテスト分析を始めてみたので実際やってみてどうだったかを記事にしたいと思います。
マインドマップを始めた経緯
QA業務をやっていく中で、私は会計のドメイン知識も浅くQA業務をするにあたり不安感を抱えており、開発チームの方にどのようにキャッチアップしてるかを相談したところ、コードを見つつ、各々が仕様をキャッチアップしてるとのことでした。
そのため、開発チームは開発チームでQAチームはQAチームで同じ施策に対して、それぞれ仕様理解を各々が行っている状況でした。
それなら、開発エンジニア/QAエンジニアそれぞれが気にしたいところ等が共通認識を持てるようになれば、
上流工程でリスクや考慮漏れが防げるのではないかということで、やってみることにしました。
使用ツール
マインドマップはmiroを使っています。
案件の流れ
①開発チームに対応画面の影響範囲（ざっくり）を共有してもらったらQAは画面を元に以下を意識し機能の洗い出しをします。
・今回の機能は何かを書き出す
・機能についての仕様を書き出す
・なぜこのような仕様になったかなどの仕様背景等、書き出す
・気になった部分はとりあえず記載する！！
②QA側で出した要件分析が50%〜60%くらい記載が完了したら開発エンジニアに共有し、
コード上の仕様や今回の対応で気にして欲しい部分などこれも気になったことをコメントやハイライトで記載をします。
③要件分析会を開催し、この会では主に以下を確認しています。
・今回の範囲/範囲外の認識合わせ
・考慮要否の確認、開発/QAが気にしているところを確認
・不明点の解消
④要件分析を元にリスク洗い出し会を開催します。
過去にリスク洗い出しについて紹介していますのでご覧ください。
⑤要件分析/リスク洗い出しを元にQA側で観点をこちらもmiroで以下を意識し、作成しています。
・どんな部分をテストすべきなのかという視点で気にしているところを記載する
・それぞれのマインドマップの枝（観点）について気にしてることは何かを考える
・何ができれば対象チケットは完了にできるかを考える
同期的に観点会をやってるとはいえ、複数出てくるテスト観点に対して、何を目的としているか何を気にしているかが伝わりづらい部分もあるので、気にしているところという枝を作成して、特に重要な観点がどこなのかはっきりさせるように作成しています。
⑥観点会を開催し、この会では主に以下を確認しています。
・対象の観点でどの部分を気にしていて、どうすればテストとして問題なしと言えるか
・今回実施しない箇所の確認/リスクの確認
・テストパターンの確認
※この段階ではデシジョンテーブルなどは作成せず、どのパターン（要素）でテストするかを認識合わせをする。
マインドマップはこのようになります。
・ピンクの線は対応の概要を記載
・紫の線は要件分析の内容を記載
・青の線は気にしている/テストが問題なしと言えるかを記載
・水色の線は観点を記載
QA /開発で要件分析会・観点会をやってみての感想
今までは仕様書を元に影響範囲の確認やテスト内容の検討を行っていましたが、
仕様変更があった場合など、都度仕様書が更新できていないという課題があり、
QAは仕様書を元に分析/設計しているため、実施時に仕様確認やテストケースの修正が必要になることが多々ありました。
要件分析や観点会を行うことで、仕様の認識合わせや修正予定の部分が認識合わせできるため、実施等の下流工程での仕様確認/考慮漏れが減ったように感じます。
始めたばかりでまだ改善の余地はありますが、ブラッシュアップしながら引き続きマインドマップを使っていきたいと思っています。
最後まで読んでいただきありがとうございました。
明日は、QAマネージャーのdn-sanが「QA組織作っていく中での失敗5選」について記事を書いてくれます。
お楽しみに〜！
良い品質を〜
