freeeのQAチームに所属する、テスト師匠のyumotsuyoです。
freeeに入社したのが2019年7月1日なので、早いものでfreeeに入って8ヶ月になります。入社してすぐに、「ぶっちぎりのコア品質」というOKRの達成のための活動の1つを頑張って欲しいと言われました。
この活動を通して、freeeのプロダクトの良い点はいくつもありますが、「ぶっちぎりのコア品質」とは品質面でも他より抜き出てfreeeを使いたいと思ってもらえるようなプロダクトにするってことだと理解しました。
8ヶ月経ち、QAチームのみんなでいろいろ話をしていく中で、現時点で私が思うfreeeのQAはここを目指していくべきだと考えていることをいったん共有していろいろ意見を聞きたいので、何回かに分けて書いていくことにします。
- freeeの開発においてQAの目指すべきこと
- １のQAが目指すべきことを実現させるためのfreeeの開発体制
- 考えられるアクション
まずは、「1. freeeの開発においてQAの目指すべきこと」について、要はTo-beとして私が考えることを以下に書いていきます。
traditionalなQAを続けることの問題点
freeeの開発の良さは、過去のしがらみにとらわれることなく、今の時代のニーズにあった開発ができることだと思います。
今の時代のニーズって何かと言うと。。
世の中の変化が激しく、何が本当に求められているかが刻々と変わる可能性があり、変化のスピードに合わせてプロダクトをアウトプットしなければビジネスチャンスを逃してしまうこと
だと思います。
そこに必要なのは、trial and errorの開発スタイルだと思います。ソフトウェア開発のトレンドとしても、それを実現するために様々な技術が生まれ、カルチャーを育んでいるのだと思います。
trial and errorを実現するためには、スピードが大事になるのですが、traditionalなQAのスタイルである、リリースの前に全部を集めて一気にテストするやり方にはいろいろ問題がありそうです。 freeeの中でも「QAのテストケースが多すぎる」「テスト要員が足りなくてQAが始められない」「定期リリースに載せるタイミング待ちになる」といった理由で開発のスピードやリズムに対する阻害要因になっているということを聞きました。
freeeの開発においてQAだけがtraditionalなやり方を続けることでボトルネックになってしまうのだとすれば、それは大問題で、なんとしても変えていかなければならないのではないかと思うようになりました。
今の時代に合った開発にするためにQAが変わらなければならないこと
4つあると思うので列挙します。
- 今時の開発をするための考え方に、開発に関わる関係者がみんな同じチームに入ることがあると思います。QAもそうなるべきです。QAの担当者がチームにいてもいいですし、開発者がの誰かがQAを兼務しても良いと思います。 QAチームに依頼していたE2Eの手動テストや自動テストも自分たち（チームに内在するQAメンバーでもよい）で行い、最終的に、チーム自身が品質に対する判断をするようにしていければと思います。
- 品質リスクの許容度合いは、すぐに修正／リリースできればよいハッピーは許容するアプローチに変えていきます。 そうすると、すぐに修正／リリースできれば良いハッピー（バグ: freeeでははバグをハッピーと呼んでいます）QAとしてのE2Eテストでは確認するのは必須ではなくなります。与えられた時間に合わせて必要なテストのみ行うという理由が明確になります。
- リリース前に大量にテストをする「ビッグバンテスト」をやめます。QAのために行うテストにも松竹梅がありますが、なんでもかんでも一番高価でゴージャスな松を選ぶのではなく、品質リスクとの兼ね合いをチームで合意した上で、梅にしてもよいという選択肢が必要です。 そのためには、テストに対してチーム内の意識を共有して合意することを最初にやるのが大事になります。 また、QAのためのテストを梅にするために予防テストが重要です。予防テストはリリース直前にバグによる手戻りが発生しないようにテストをすると定義します。単体テストやサービスレベルのテストをしっかり行うこともこのコンテキストでは予防テストです。
- 最後に、リリース可能な品質にあることを様々な証拠をもとに第三者が判断する品質保証を不要にしたいです。行うことは、全員がリリースとは関係なく常に品質をよくしていく継続的品質改善です。
freeeの開発においてQAの目指すべきこと
以下の図のように整理しました。
- チーム自身QAが浸透すると、少人数でQAできるようになると思います。
- 予防QAを行い、QAになる前の品質を確保し、QAがテストするレベルでハッピーが出なくなると開発期間短縮ができます。
- リグレッションテスト自動化は、主にインパクトリスクを軽減するための施策です。
- これまでの経験で言うと、QAで時間がかかるテストは、バグが出る可能性は低いが万が一バグが出たら大問題になるところのテストです。これらは単純作業であることが多く、また数も多くなりがちです。そういうテストは機械に任せるべきです。
すでにいっぱい書いた気がするので、一旦ここで終わりにします。
