はじめに
はじめまして。enechainのQAエンジニアのtaise-です。
enechainは電力や環境価値といったエネルギーのオンラインマーケットプレイスを運営する会社です。私は、電力取引を仲介する社内のブローカーのブローキング業務を支援する社内ツールのQAを担当しています。
enechainにQAチームが発足して約3年が経ち、会社が急成長を遂げる中でQAチームの形もそれに合わせて常に変化し続けており、現在は複数同時並行で開発・運用されている各プロダクトを、QAエンジニアがそれぞれ1名専任で担当するチーム体制となっています。
この記事では、私の担当プロダクトにおけるQA業務と、そこで得た成果や課題について紹介します。
プロダクト専任体制のQAエンジニアが業務の中でどう立ち回り、どんな価値貢献ができるのか、我々と同じようなスタートアップの、特にQAチーム立ち上げフェーズにあるQAエンジニアの方にとって少しでも参考になれば幸いです。
enechainでのQA業務
enechainのQAチームは現在、プロダクト品質管理全体の中でシステムテストを主に担当しています。基本的な業務フローは一般的ではありますが、テスト計画 → テスト設計 → テスト実施 → 結果報告という流れとなっています。
また、システムテストの前提となるインプットとして、enechainでは各プロダクトの担当PdMがSpec Documentと呼ばれるドキュメントを作成しています。このドキュメントでは、ユーザーの要求がユーザーストーリーとしてまとめられ、ユーザーストーリー毎にシステム要件や仕様が記載されています。
Spec Documentがユーザーストーリーとして記載されていることで、実際にプロダクトを使用する際の懸念などユーザー目線でのレビューが行いやすくなり、操作性やユーザビリティの品質担保につながると考えています。
ここからは、業務フローの各工程について説明していきます。
QA目線での仕様レビュー
Specが完成し次第QA目線でのレビューすることで、仕様の抜け漏れ発生を防いでいます。これにより、早期にバグの芽を潰し、あとになるほど高くなるバグの検出・修正コストを抑えることにつながります。ユーザーストーリー毎のテスト方針決め
Specのレビューが完了したら、PdMと一緒にユーザーストーリー毎に、テストケースを作成するのか、それとも探索的テストで確認するのかを決定します。重要度が低い / 確認観点が少ない等バグ流出のリスクの低いストーリーは探索的テストで確認する方針とすることで、設計コストの最適化や削減に繋がります。テスト観点の作成・レビュー
テストの方針が決まったら、次にテスト観点を作成し、PdM / エンジニアを交えた観点レビュー会を実施、テスト観点に漏れがないことを確認します。観点レビューでは、以下の確認も行っています。
- テストケース作成時にあとから不明点が出ないよう、仕様や実施手順に関する疑問点をすべてクリアにする
- 想定されるテストケース数が多い場合、テスト実施をPdMと分担して行う等、テスト実施体制を決める
見積もり・テストケース作成
観点作成が終わり大方のケース数がわかったら、そこから以下の工程にかかる工数を見積もります。- テストケース作成
- テスト実施
- 実施後作業（品質レポート作成・テスト完了報告）
見積もりをPdMと連携し、相違なければ、テストケースを作成します。
見積もりを作成し、あらためて開発スケジュールや目標とするリリース時期とテスト設計・実施スケジュールを照らし合わせると、十分なテスト期間が確保できないことがあります。その際には、スケジュールやリリーススコープの調整、PdMとのテストの分担実施等、実現可能なオプションを提案することを心がけています。
テスト実施
テストケース作成が完了し、開発も完了したら、システムテストの実施に着手します。テスト実施については何か特別な施策をしているわけではありませんが、スムーズなテスト進行のための工夫として、私は以下を心がけています。
- 機能として大事な部分であり重大度の高いバグが見つかりやすい優先度Highのケースから実施
- 実施中に一人で考えて詰まることがないよう、Gatherなどでいつでもエンジニアに不明点を聞けるような環境作り
- 実施やリリーススケジュール全体に影響を出さないよう、ブロッカーとなるバグは優先度高く対応してもらうようにエンジニアに依頼
実施を進めバグ修正の確認がすべて終わった後にリグレッションテストを回し、リリースブロックになるものがないと判断できれば、QA完了報告をして品質レポートを作成するまでが一連のサイクルです。
その他の業務
システムテスト以外のQA業務でどれだけ会社に価値貢献できるかもQAチームでは大事にしています。その中でも現在進行形で取り組んでいることを紹介します。
E2Eリグレッションテストの自動化
今年からE2Eのリグレッションテスト自動化のため、MagicPodを導入しました。各プロダクトごとにリグレッションテストケースを整理し、それを元にMagicPodのケースを作成しています。導入して間もないため、現時点で運用を開始できているプロダクトはまだありませんが、今後CI連携によりPR作成時に自動でリグレッションテストを回せるようにし、開発サイクルに組み込むことを目標にしています。
この自動化ツールの運用で業務がどう変わったかについては、今後別の機会にブログを書きたいと思います。
QAチームの業務改善
QAチームでは、以下のツールを業務で利用しています。
- テストケースの管理：Googleスプレッドシート
- バグチケット、タスク、ナレッジの管理：Notion
プロダクト毎に合った使い方をしているので、テストケースフォーマットやバグチケットフォーマットでこうした方がいいとアイデアがあったら週一で開催しているQA Weekly MTGに持ち込んで意見を出し合ってます。採用するかどうかはともかくみんなが意見を言いやすいチーム作りを大切にしているので、会社に遅れをとることもなくQAチームが成長しているのを感じています。
enechainの目指すQAとは
"QAチームはシステム開発の品質担保における最後の砦" と言われることもありますが、我々は品質担保のオーナーシップをQAチームが担うのでなく、プロダクトチームが担っている状態が目指すべき理想だと考えています。システムテストでバグを発見・修正できれば良いというスタンスは、高コストなシステムテストへの依存を高め、品質担保にかかる工数の増加に伴うリリースサイクル長期化の要因の1つになり得ます。
そうならないためにも、各プロダクトに1人ずつ専任のQAエンジニアを配置し、プロダクトチームに深く入り込んでPdMやエンジニアとともに開発ライフサイクル全体で品質に取り組みんでいくのが、enechainの目指すQAの姿だと考えています。
現実的にはまだまだ目指すQAの姿には遠く、今はまだシステムテスト中心の業務にはなっていますが、目指す姿に近づくため、自らプロダクトチームを巻き込み、一緒にプロダクト品質に取り組んでいきたいと考えています。その中で仕様策定から関与していき、PdMレベルで仕様を理解できるような存在になっていきたいと考えています。
今後の展望
enechainの目指すQAの姿に近づくために今後取り組もうとしている施策の一部を紹介します。
E2Eリグレッションテスト自動化の促進
先ほども触れましたがE2Eリグレッションテストを自動化することで、リリース毎にマニュアルで実施するE2Eリグレッションテストの工数を削減し、リリースサイクルの短縮を目指しています。
MagicPod以外にもエンジニア中心にPlaywrightを用いた自動化を進めているプロダクトもあります。これら2つの自動化ツールをどう使い分け、どう運用していくかを整理し、エンジニアと協力して取り組んでいきます。
ハッピーパステスト
前段でも書いた通り、開発サイクル全体で品質に取り組むことで、システムテストへの依存を下げていくことを目指し、そのための施策を今後さらに加速していきます。
そこで、その施策の効果を測るための指標として、システムテスト着手前のハッピーパステスト実施における平均通過率を設定しました。
私の担当プロダクトでは、ハッピーパステストのケースとして、Spec Documentのユーザーストーリーを用い、各ユーザーストーリーのハッピーパスがすべて通ることをシステムテスト前にPdMと一緒に確認していきます。このハッピーパステストのOK率の目標値を90%以上と定め、これが90%未満だった場合には、エンジニアを交えて今後の改善について議論し、施策を実行していきたいと考えています。
これ以外にもバグ分析や、成果・ナレッジの横展開等でQAメンバーのQAレベル底上げを定常化していけるような習慣を色々試していきたいと思っています！
最後に
ここまで私の普段のQA業務と何を意識しているかについてお話ししました。
今回書かせていただいた自分もやれる事はまだまだあると思うので、今後もQAエンジニアだからこそ出来ることを増やしていきたいです。
この記事が立ち回りに悩んでいたり、我々と同じようなフェーズにいるQAエンジニアの方にとって少しでも参考になると嬉しいです。
最後までお読みくださりありがとうございました！
enechainでは各種ポジションを積極採用中です。少しでもご興味をお持ちいただけましたら、カジュアル面談からでもお気軽にご応募ください。
