QAマネージャーやってみての失敗談

こんにちは。freeeでQAのマネージャーをやってるでーにしです。 freee QA Advent Calendar2023 25日目です。QAマネージャーをしていて、あるあるアンチパターンを見事に踏んでいったので、振り返って良いお年を迎えたいと思います。

freeeではいくつか自動テストがありますが、一番運用が大変なのはE2Eテストになります。

E2Eテストについての詳細は、以下の記事をご参照ください。 developers.freee.co.jp

その運用が大変なE2Eテストを運用を考えずに作ってしまいました。当時の自分の経験値としては、作ったこともあるし、日々の運用もしたこともあったので、運用の大変さも味わっていたと思っています。なんで失敗したか、考えてみます。

当時のテストシステムは、テストシナリオとページ要素が密結合していました。そこで、Capybara+SitePrismによるテストシステムへの移行をすることで、テストシナリオとページ要素が疎結合になり、テストの作成・修正が簡単になったと思います。

一方で、いざリリースして並列稼働させると、以前よりもテスト失敗率が高くなりました。 Flaky Testの量産をしてしまったわけです。

ビッグバンリリースしちゃいました。少しずつリリースして、早めに失敗しておけばよかったです。

早く移行を終わらせたかったので、作成する人と運用する人を分けて、並行で進めていました。作成する人は運用時の苦しみがわからないですし、運用する人は新テストシステムのノウハウがわからない状態になりました。作成と運用は表裏一体なので、ちゃんと一緒にやっていく体制にしておけばよかったと思います。

完成度低い状態でもアウトプットしていく。自動テストに限らず、マネージャーは不確実性の高い領域に出会うことが多いので、心がけてます。

自動テストは改善が命だなーと改めて思いました。サービスの成長とともに自動テストも成長していく、そのために改善し続けられるようにしていきたいです。 SEQチームのドライブでかなり進んできましたが、まだまだ道半ばです。

不具合流出を恐れ、網羅的なテストに走ってしまった時期がありました。

網羅的なテストは時間がかかるので、QAテストがリリースのボトルネックになってきました。またテストケース数が多すぎることでテスト目的を見失ってしまい、逆に不具合流出も起きてしまいました。

僕自身、テスト多い課題はなんとなく感じているんですが、テストを削っていく、増やさない根拠を言語化できないまま、いってました。今振り返ると、ちゃんと根拠をもって言語化する力が純粋になかったんだと思います。

あの時に、このQAオンボーディング（特にテスト計画、テスト分析）があれば、全然違ったなーと感じます。 developers.freee.co.jp

当たり前のことですができてなかったので。今もできている、とキリッといえないですが、引き続き頑張ろうと思います。（網羅という言葉は思考停止になるので、使わないようにしてます）

QA組織全体の年間目標で「流出不具合を1/5にする」と掲げて、どうやって実現するかはみんなで考えよう、としちゃいました。「良い戦略、悪い戦略」という本の「悪い戦略の多くは、困難な問題を乗り越える道筋を示さずに、単に願望や希望的観測を語っている」をみて、これだっと感じました。

理想的な目標を掲げても、実現しなければ意味がないので、実現可能性（フィージビリティ）は超重要です。リードする == 理想的な目標を掲げる、と完全に勘違いしちゃってました。これで組織が前に進まなければ、意味がないです。

目標と現実のGAPが課題でどの課題を優先的に解決していくか、を考えています。（具体的なところは力尽きたので今回省略します）

翌年の2022年はちゃんとフォーカスする課題と実現性を考えてやって、組織的な課題を解決できてきたのは進捗だと思います。新しい課題はどんどん生まれてるんですが、以前と課題が違うので前進してるとポジティブに考えてます。

↑はほんと状況によって変わるので、継続してTRYできるかはチャレンジだと思ってます。

書いていて、もしかして当たり前のこと？とも思ったんですが、当たり前のことやるの難しいし、こういう言語化重要ですね( ｰ`дｰ´)ｷﾘｯこれらの失敗に気づけた、糧にして前進できたのは、ほんと一緒に働いている方々のおかげです。感謝！

振り返ってみると、QAアドベントカレンダーできるまでの組織になったのは感慨深いです。 freeeのQAの雰囲気はこのアドベントカレンダーみたらわかるので、他の記事もぜひみていただけると嬉しいです。

これからもみんなでやっていきですね！！それでは、よい品質を〜