テストについて思っていること
テストコードとは
ソフトウェア開発に限らず物作りにおいてテストは大切である。新機能開発の際には要求を満たせているかを確認できるし、過去あった機能に対して悪影響ないかを保証する意味合いもある。
ソフトウェア開発においてはテストは人力でやる場合もあるが、できれば人を使わずに自動化したい。はい、テストコードの出番です。
どこからテストを書くべきか
仮にあなたが転職してテストが何もないプロダクトの担当になったとしましょう。どこからテストを書けばいいでしょうか。
テストの分類の仕方はいろいろありますが、概ね以下の感じでしょうか
- 粒度による分類
- 単体テスト
- 結合(End to End)テスト
- レイヤーによる分類
- UIテスト
- 内部テスト
UIがあるアプリケーションの場合、End to Endテストから始めるのがオススメです。最終的に保証したい部分そのものですし、内部をリファクタリングしてもテストコードを変える必要がありません。RPAツールやSeleniumのChrome拡張などを使うと実際の操作をそのままテストコードに変換することもできます。
API通信でも考え方は同じで一番よく使われる流れのパターンそのままから始めてみるというのが王道だと思います。
もちろん例えば決済系のアプリで金額があっていることが重要な場合もあるでしょう。ビジネス上や法規的な要件でロジックのテストに重点を置く必要がある場合もあります。要は大事なところからってことですね.
どこまでテストを書くべきか
反対に、どの程度の粒度までテストは書くべきでしょうか。場合によりけりですが、そのプロダクトのフェーズとテストを書く量を比例させるというのが今回の提案です.
以下適当にフェーズを分けていますが、その境界線は適宜調整してください。
- シード
0=>1のフェーズです。不恰好でも完成させることが大事です。この段階のテストはWebサービスならサーバーがちゃんと起動しているかの疎通確認だけでももよいでしょう。
- アーリー
どうやら作ったプロダクトには需要がありそうなことがわかりました。ユーザー数を増やしたり、既存ユーザーのアップセルを狙うためには新機能の開発が必要です。まだユーザー数はそれほど多くはありません。
この段階でのテストは新機能に1つ程度のE2Eテストにとどめましょう。必要に応じてテストを増やしてもよいですが、このフェーズでは仮定した仮説が外れる確率も高く、仕様はすぐ変わったり、作った機能は使われることがないかもしれません。100点の要求を1つ満たすより、70点の機能を3つ開発することが求められているかもしれません。
- ミドル
ユーザーが定着して、新規ユーザーの離脱率も減ってきました。使っている人が増えてきたため安定性が重要です。
この段階では1リクエストパターンに対して1つテストを書き、テストカバレージを増やしていきましょう。ユーザー数が増えてきたため不具合を起こした際の影響度が多いです。新機能追加時に機能後退しないようにしましょう。
- レイター
その業界でNo.1のサービスとなり、一般知名度も上がってきました。
この段階ではWebならクロスブラウザチェックの強化、アプリなら複数機種や複数OSバージョンのサポートでしょうか。
専任のQA担当、SREを置き、エラーバジェットを設定してもよいと思います。
何が何でもテストは書く必要があるのか
はい。テストはないよりあったほうがいいです。一方で、仕様の変わりやすい状況では仕様を変える=実装とテストを変えるが重荷になる場合もあり、スタートアップにおいてテストを書くのをやめた事例というのもたまに見ます。
転職が活発なエンジニア業界ですが、企業の違いだけでなく、プロダクト間のフェーズによってテストポリシーはまちまちというのは見過ごしやすいポイントだと思います。
とりわけメガベンチャーや大手企業からスタートアップに転職するケースにおいて、例のライオンの画像よろしく、全てについてテスト書かないなんてありえないというスタンスの方もままおり、そこがフィットしないこともあります。
はい。テストはないよりあったほうがいいです。テストを書く心のゆとりも許さない環境は控えめにいってやばいです。一方で何のためにテストを書くかという観点は常に必要だと思います。
最後に
CTOやエンジニアリングマネジャーはプロダクトを成功させるために開発速度と品質保証のバランスを常に考える必要があります。
オウンドメディアも活発な時代、Webではメガベンチャーの事例ほどよくヒットすることも多いです。一方で彼らのフェーズと自分たちのフェーズが全く一緒かというとそうではないわけで、他社の事例を鵜呑みにせず一呼吸おいて考えることも大事だと思う今日この頃です。
