この記事は MICIN Advent Calendar 2023 の 13 日目の記事です。
前回は新藤さんの『App Mesh の導入とカナリアリリース』でした。
はじめに
こんにちは、佐藤です。普段は MICIN の DCT 事業部にて MiROHA という治験アプリケーションを開発しています。
最近は機能をガツガツ実装というよりは他メンバーが開発を進める上で大きな障害となる課題の解決や開発生産性の向上など本線開発がスムーズに進められるような支援をしています。
Team Toplogies で指すところのイネーブリングチームの活動に近いのかなと思いますが、チームではなく個人での活動なのでちょっと定義が難しいところです。
そんな活動の中で、今回は QA ボトルネックの解消という話をしたいと思います。
前提条件
- プロダクトチームは合計 10 名のメンバーで構成
- PdM2 名(1 名正社員・1 名業務委託)・エンジニア 5 名(4 名正社員・1 名インターン)・QA2 名(業務委託)・デザイナー 1 名(業務委託)
- 治験という人の命にも関わるドメイン特性上、他のプロダクトに比べ品質基準は高め
QA ボトルネックとは何か
ひとことで言えば、QA プロセス がリリースの足かせになっている状態です。
開発プロセスは、
要件定義 → 設計 → 実装 → QA→ リリース
というサイクルが一般的かと思いますが、このうち QA プロセス に占める時間が想定以上にかかってしまう事でリリース遅延が発生することを意味しています。
QA ボトルネックを解消するには人・成果物・コミュニケーションなど様々な観点からの改善が必要になるのですが、私たちのチームでは QA ボトルネック解消の達成基準の指標として、
実装完了からテスト実施開始までの待ち時間ゼロ
を目標に掲げました。
なぜなら、この待ち時間が平均 1-2 週間程度あり、2 週間毎にリリースをしている私たちのチームにとっては約 1 回リリースが遅れるという意味で非常に大きな損失であったため、ここを解消できれば QA プロセスのうち最も工数がかかるテスト設計の完了 と同義であり、結果として QA プロセス がリリースの足かせになっていないと判断できるためでした。
実装完了後にすぐにテスト実施ができない
実装完了後すぐにテスト実施ができる
このプロジェクトは現在進行形のため最終結果、つまり QA ボトルネックが解消されたのかについては残念ながら共有できないのですが、様々な施策を打ち出し検証・改善していくことで直近リリースした機能に関しては実装完了からテスト実施開始までの待ち時間ゼロを達成しています。[1]
エンジニアの僕が QA ボトルネック解消にこだわる 3 つの理由
ここまで読まれて「課題自体はよくある話だよね、でもそれって QA チームがやることではないの？エンジニアには関係ないのでは？」と思った方もいらっしゃるかもしれません。
個人的には以下の 3 つの視点でエンジニアにも関係ある話だと思っています。
- リリースされて初めて機能は価値になるから(=エンジニアにとっても損失になる)
- 品質保証は QA チーム だけでなくプロダクトメンバー全員に責務があるから(=エンジニアにも責務がある)
- エンジニアリングは QA プロセスに適用できるから(=エンジニアのスキルが活かせる)
ここがこの記事の中で最も伝えたいポイントでもあるので、それぞれの理由を詳しくお話していきます。
リリースされて初めて機能は価値になるから
当たり前のことではあるのですが、リリースをしないと価値にはなりません。
ビズリーチで有名な株式会社ビジョナル CTO の竹内さんが書かれた Note がとても分かりやすく言語化されていたので引用します。
大きな開発組織になると、意外と Deploy がされないブランチ（新機能など）が出現したりします。外部要因の変化などでちょこちょこ発生することがあります。生産性という観点で考えれば、本番適用されないものは、究極生産されていないことと等しく、また Deploy 権限と執行が Product Manager の意思とリソースのみで行うことができない場合、やはり開発チームが Deploy まで責任を持つことが大切です。
リリースが 1 日遅れるということは顧客への価値提供・価値検証が 1 日遅れることを意味します。
プロダクト開発という形で事業のインプットを提供する我々エンジニアにとっても給料や予算の削減など直接または間接的な形で損失になるため、リリースの遅延は QA チーム 事ではなくプロダクトチーム事の話ではないかと思っています。
品質保証は QA チーム だけでなくプロダクトメンバー全員に責務があるから
品質保証は誰の責務か？という話ですが これもまた QA チーム だけでなくプロダクトチーム全体で持つべきだと考えています。
先も述べたようにリリース遅延をしない、すなわちリリースを安定化させるためには品質を段階的に仕上げていくことが一番出戻りが少なくスピードと品質を担保できる戦略だと感じたからです。
よく自動化テストの文脈で用いられるテストピラミッドの概念が有名ですが、逆ピラミッドにならないようにするためには実装プロセスでも品質を保証することが求められます。
以前私たちのチームでは不具合確認プロセスが長くリリース遅延の大きな要因となっていました。
原因を追求していくと不具合として起票されたチケットのうち既に要件定義に記載済みだがシステムに反映されていない、いわゆる実装漏れが多くあることに気がつきました。
そこで改善策として「QA 前仕様チェック」というサブタスクを作成し、実装を担当したエンジニアが QA チーム に渡す前に要件定義書に書かれた項目を全てステージング環境で満たしているか必ず確認するという仕組みを設けました。
ストーリーチケット作成時に「QA 前仕様チェック」というサブタスクを自動作成
するとテスト実施で検出された不具合の数が大幅に減少し、不具合確認プロセスが長いことによるリリース遅延のリスクも減少しました。
また不具合の数だけでなくクリティカル度(システムに与える機能の緊急度のこと。一般的に正常系であるほど高く、エッジケースであるほど低い)も減少したため、品質とスピードを両立する上で段階的な品質保証が有効であることが分かりました。
QA プロセスの完了はリリースできる状態のプロダクトであるという判定がクリアなものに対し、実装の完了は後続に QA プロセス があるため曖昧になりがちです。それぞれのプロセス毎に「完成の定義」[2]をプロダクトのドメイン特性・品質特性を踏まえながら定義してみると、PdM・エンジニア・デザイナー・QA という役割による期待値のズレが減り、無駄のない開発プロセスが構築できることでしょう。
QA チーム だけが品質保証をするのではなく、プロダクトメンバー全員が一定の責務を持ち各プロセスで品質を仕上げていく。そんなマインドセットが大事だと思っています。
エンジニアリングは QA プロセスに適用できるから
QA プロセスは一般的に、
テスト計画 → テスト観点 → テスト設計 → テスト実施 → 不具合確認 → 自動化
という流れで進みますが、自動化はエンジニアリングと親和性が高い領域になっており、エンジニアのスキルやナレッジが活かしやすいです。
Selenium や Cypress などコードベースで E2E テストを書く場合は勿論ですが、Autifyや MagicPod といった GUI の E2E テスト自動化 ツールを用いる場合でも JavaScript でコードを書く必要があるケースがテストケースによっては存在します。
実際、私たちのチームでは E2E テスト自動化に Autify を使っていますが、複雑な選択操作やリスト内の要素選択などロケーションが実行毎に変わるテストケースに関しては JavaScript で DOM 操作に関するコードを書くことでカバーしています。
自動化は短期的な視点では、手動テストで代替できる内容であるため自動化のキャッチアップコストやメンテナンスコストを考慮すると優先度は低く後回しになりがちです。しかし、長期的な視点ではリリースの度にサニティテスト等のテスト範囲は拡大するため自動化に投資しなければ手動テスト工数も拡大していきます。品質面でもとテスト範囲が大きくなればなるほど人為ミスが発生する可能性があるので、その際の不具合検知漏れも考慮に入れる必要があります。
短期的・長期的双方の性質を理解した上で、いかに自動化を QA プロセスに組み込んでいくかが品質とスピードを両立していく上で大事な QA 戦略になると考えています。
私たちのチームでは テスト自動化率が元々 12%程度でしたが約 3 ヶ月でそのカバー率を 20%以上広げ現在は 35%程度になりました。まだまだ自動化可能な範囲はあるので改善余地はありますが、長期的なテスト工数の短縮に向けた投資をしています。
終わりに
より早くより価値あるものをユーザーに届けるためにこれからも邁進していけたらと思います！
MICIN ではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
Discussion