LayerXのQAへの取り組み〜アイスクリームの誘惑に負けるな〜

初めまして！LayerXの遊撃隊員、kaji(@kajicrypto)です。

今日は目下実践中のテスト自動化への取り組みについて書いていきます。

MVP開発からPMFに向かう間の、ソフトウェアテストに対するアプローチの変化をお伝えできればと思います。

手動E2Eテストで担保したMVP開発

定石：テストのピラミッドは下から登れ

あるべきソフトウェアテストの姿として「テストのピラミッド」がよく持ち出されます。

単体テストを土台とし、その上に複数層をまたいだロジック検証のためにAPI/統合テストが存在し、それでもカバーできないユーザー体験を守るためにUI/E2Eテストが求められる。

土台に近いほうが実行速度が早く、高頻度で実行でき、エラー原因を特定しやすい。もちろん、離れるほどその逆である。

それゆえ、テストは土台である単体テストから先により多く実装すべきと言われています。

優れた開発組織では単体テストの実装率が8割に達するとか、テスト全体における実装比率が土台から7:2:1の割合がよい、なんて話も聞いたことがあります。

リリース時：テストのピラミッドは下から登らない！

LayerX インボイスは、昨年秋の開発から数ヶ月でβ版をローンチ、そして1月には正式リリースをしました。

事業部発足時に作成したインセプションデッキでは、やることの第一に「スピード！スピード！スピード！」を掲げ、「ちゃんとしすぎない」ことも決めて初期プロダクトを開発してきました。

※ もちろん「経理」という領域を扱うプロダクトですのでちゃんとしているのですが、テスト駆動開発で100%テストを書くとか、急に入ったアルバイトでもテストできるほどQA表を詳細に書いたりはまだしない、ということです。

リリースから2ヶ月経過した時点でも、顧客の声を聞きながら機能追加を爆速で続けています。テストは致命的かつ人間による検証が難しい部分にしっかり書いてはいるものの、割合としてはリリース前の手動E2Eテストで大部分のバグ回収を行うことで品質を担保してきました。

とにかく顧客に求められるシステムを、実際に顧客に見て頂きながら作っていくDDD（Demo Driven Development）を貫くことで、紙芝居レベルの時期からたくさんの課題やフィードバックを得られ、早期にMVPを完成させることができたのです。

事業開発目線ではスピードを優先して正解だったと確信しています。

アイスクリームコーンからの脱却

一方、テストの視点ではこの状況はよくある”アンチパターン”とされており、その姿はアイスクリームに例えられています。希少なリソースであるエンジニアがテストを書かずとも、手動E2Eテストによって品質を守ることができるという甘〜い誘惑です。

時間の経過とともに、機能追加が続くほどに、テストにかかる労力と工数は比例して増加します。一口ぺろっとするにはとても美味しいけど、ついつい食べ過ぎていつの間にか太ってしまう。

どこかでこの誘惑を断ち切らないといけないわけです。

脱却のきっかけは2ヶ月ほどたった機能追加リリースの時でした。

本番リリース直後に3件のバグが見つかってしまったのです。ヒューマンエラーによる手動E2Eテストのすり抜けや、テスト後のhotfixによる影響箇所の確認漏れでした。幸い顧客に直接的な影響はなかったものの、3件も出してしまった・・・という感覚がありました。

MVPが受け入れられ導入顧客が増えてきて、引き続きPMFに向けて更なる機能追加が予定されています。このまま走るとどこかで致命的なバグが発生し顧客に迷惑をかける可能性がある。

E2Eテストも900項目まで育っており、stagingへのデプロイからproductionリリースまで2日を保っているリリースサイクルも崩れる可能性がある。

これをきっかけに、開発リソースの「2割」を品質に充てよう、テストを書いていこうとチームとして決断をしました。

スピードを保ちながら品質を担保するために

単体テスト7割を目指す？

さて、テストを書くと決めたなら定石のとおりテストのピラミッドを下から登り、まずは単体テスト実装率7割を目指すべきです。一方、僕らのフェーズで「本当に7割目指しますか？」と聞かれるとやはりNOだと考えます。

7割を目指す状態というのは、プロダクトが市場の中で「勝ち確」で、QA専属メンバーの採用が十分に済んでいるフェーズだと考えます。もしくは後戻りしにくい業務系システムや、1つのバグが致命的となる医療や行政、選挙に関するシステムなどでしょう。

SaaSは日々の業務フローに密接にかかわるため、事業が継続しないと、導入いただいた顧客に大きな迷惑がかかることになります。品質はプロダクトにとって超重要ではありますが、バランスを間違えて良い機能追加や改善ができないことは、結果として顧客の体験を損なうことになり、事業を継続できなくなる可能性をはらんでいます。

夢いっぱいのスタートアップではエンジニアリソースは常に不足しています。バグやデグレの対応に時間を取られ、結局テストを書いたほうが開発スピードが早かったよねとなるラインを見極めながら進める必要があります。

僕らは何割とは定義せず、代わりにバグやデグレが起こりやすい、また起こると致命的である箇所を機能単位で洗い出し、そこに対して2割のリソースをかけ続けて単体テスト・APIテストを実装していくことにしました。

それ以外については引き続きE2Eテストが担うことで、スピードを保ったまま一定の品質を担保できると考えています。

E2Eテスト自動化プラットフォームの導入

単体テストの実装と並行して、肥大化したE2Eテストもなんとかしないといけません。2日間で900項目を手動テストするのはもう限界ですし、開発チーム以外にも手を借りることで負荷がかかってきました。

そこで、ノーコードE2Eテスト自動化ツールを導入しました。いわゆるキャプチャーリプレイと呼ばれるもので、E2Eテストの動作を記録しておき自動実行してくれるツールです。

使ってわかったのは、ノーコードE2Eテスト自動化ツールは従来のテストのピラミッドの登り方を変え、組織リソースの配分を変えることができるツールだということです。従来は全てのテストはエンジニアが書かないと実装できないものでした。そうするとピラミッドは下から登るしかなかったわけです。

一方、ツールがあると、エンジニアがピラミッドを下から登りつつ、同時に非エンジニアが上からピラミッドを降りていくことが可能になりました。更に単体テストを代用できる箇所も出てきて、その分エンジニアは攻め続けることができるようになります。

「キャプチャーリプレイは使うな」という話もありますが、便利そうだからといって安易に頼るな、甘い甘いアイスクリームだと認識しておくべしということだと考えています。自動化するとはいえE2Eテストであることに変わりはなく、壊れやすく、遅く、エラー原因は特定しにくいものです。その上でツールやSaaSは最大限に活用するのがLayerXスタイルです。