学校塾プロダクトのQA、２年目を迎える
ライフイズテックで１人QAを担当しているotkyskです。いつもブログをご覧いただきまして誠にありがとうございます。
２０２３年７月からライフイズテック学校塾プロダクトのシステムQAを開始してから２年目を迎えましたので今までのシステムQAと今後について投稿します。
学校塾プロダクトのシステムQAが始まる前
PoC版をリリースする事を最優先にしていた事が背景にあり、シンプルにまとめると以下のような状態でした。
テストがロクに動いていなかった
外注先にテスト観点だけを丸投げしていたのでバグが出なかった
既存機能のデグレが発生していた（自動テストが回っていない）
作れば作る程、悪化の一途を辿っていて、作業工数が増大していたという実情でした。
それではシステムQAを始める
何とか安定期を迎えたので、システムQAを始める事にしました。ただ、いきなりダイナミックに行うよりもスモールスタートで始めるようにしました。
とにかくテストを管理して動かす
エンジニアの実装した観点でテストを実行する
自動テストを実装し、既存機能のデグレチェックを継続する
外注コストの見直し、適正化を行う
テスト設計をする事でテスト仕様書の明確化を行い、テストにかかる工数の精度を上げる（外注費を垂れ流しにしない）
ポイントはテスト仕様書を作成して、テストを見える化し、尚且つ、既存機能に対しては自動でテストを行うようにし、更にテスト会社に外注する際のコストを把握する事です。半年程、上述した観点でシステムQAを進めてきました。
システムQAの更なる飛躍を遂げるために
システムQAを始めて日が経ち、関係者（特にエンジニアと自分）が気付いた事は、「第三者検証が出来ていない」という点でした。また、PdMが仕様書を書き始めてくれた事による恩恵を受けて、システムQAの質を上げるよう以下の取り組みを行いました。
エンジニアマターとなっていたテスト設計をQAが要件定義・仕様策定に入り込んでテスト設計する（シフトレフト）
エンジニアが倒れてもテストは可能な状態にする
実装とテスト設計が並行する事で、仕様に対する齟齬や認識のズレが生じた場合に未然にバグの混入を防ぐ事ができる
第三者観点でのテスト設計になる事から、エンジニアが正義だという状態よりもバグが出しやすくなる
テスト自動化の継続ならびに拡張
新機能から既存機能になった機能（主にAIドリルの解答関連）は自動テストにして、なおかつ、項目数を拡張していく事でデグレチェックを継続＋拡張して安心感を得られるようにした
システムQAを始めてから半年の期間よりも「仕様策定時のバグ発見」、「エンジニアの思い込みが間違った方向に進んでバグに繋がった」と、バグを検出できるようになりました。
また、テストの自動化もプロダクトが成長する事によって、既存機能やサポート環境が増えていく事から率先して自動化するようにしたので、デグレチェックも継続的に行えたかと考えられます。(下記参照）
＊左はテスト仕様書の項目数。端末の増減で山谷が出る
＊右は自動化率。端末の増減で山谷が出る
＊青はテスト仕様書の項目数
＊オレンジは自動化率
飛躍したシステムQAの今後を考える
と言っても、ダイナミックな飛躍をするよりも、継続する事が大事だと考え、以下の観点でシステムQAに取り組んでいきたいと考えました。
学校塾プロダクトは来年の共通テストに向けて、新機能が実装されていきますが、その新機能で大きなヘマをこかないようにする為にコツコツ経験値を重ねて、３年目を迎えたいかと考えています。
シフトレフトによるテスト設計の継続
自動テストの拡充と継続
適正なコストでのテスト外注の継続
以上となります。
今後とも、よろしくお願いいたします。