この記事はWHITEPLUS Advent Calendar 2022の24日目の記事です。
はじめに
こんにちは、ホワイトプラスでテックリードをしている仲見川です。
今回は本番でのコードの変更が原因となる障害が続けて発生したため再発防止策としてE2Eテストサービスの導入を検討した結果、障害対策としてはtoo muchと分かった事についてお話していきたいと思います。
事の発端
それほど日を空けずに2つの障害が発生したため再発防止策の検討を始めました。
- あるプロジェクトでお客様が特定の画面を開けない不具合（本記事ではプロジェクト1と言います）
- 別のプロジェクトでSafariのみで特定画面の表示内容が正しくない不具合（本記事ではプロジェクト2と言います）
原因の深掘り
まず、具体的な発生原因は以下の通りでした。
プロジェクト1
画面AでインクルードしているテンプレートファイルパーツAを削除したところ、関係が無いと思われていた画面Bで使用されていたため画面Bが表示出来なくなりました。
関係が無いと思われていた理由として、画面Aのテンプレートのようにみえた事があります。
簡略化していますが以下のように画面Aのディレクトリ配下に存在し、画面Aでのみ使うように感じてしまった結果影響範囲を検索などで確認するのが漏れてしまった事が原因でした。
── templates
├── 画面A
│ └── パーツA
└── 画面B
プロジェクト2
JavaScriptで実装した時限処理がSafariのみで正常に動作しないのが原因でした。 該当の画面はレスポンシブで作られている事と、このときの改修内容が一部の値を時限で変更することだった事から各種ブラウザでの確認やiOSでの確認が確認項目として含める必要が無いと判断されたことと合わせて発生しました。
具体的な対策の検討
かねてより検討していたE2Eテストサービスで解消出来るのではないかと検討を開始しました。
プロジェクトAの事象
リネットは画面の増減頻度は多くないため、画面が正しく表示されるか網羅的にリグレッションテストを行えば防げる可能性が高い。
プロジェクトBの事象
時限での切替だったためリグレッションテストでは防げない可能性が高い。
変更に伴う障害発生ケースの分析
上記の2ケースに限らず変更による障害の発生原因を深掘り、E2Eテストによるリグレッションテストでどの程度解消出来るかを検討しました。
テストケースが存在すれば、という前提にはなるのですが多くのケースで効果がある〇、限定的だが効果がある△と判断出来ました。
E2Eテストによるリグレッションテストで期待される効果
- メリット
- 変更時に認知外の不具合発生を検知
- 環境の変化（ブラウザやOSのバージョンアップ）での不具合発生を検知
- 受入れテスト工数削減
- 注文フォームなど確認項目、パターンが多い画面のテストを自動化できる
- デメリット
- テスト作成、メンテナンス
- E2Eテスト実行可能な実装にする必要がある
期待効果に対するコストの算出
この検討を行ったのが9月のため本年1月〜8月での算出となっています。
リグレッションテスト漏れに伴う障害発生と、発生してしまった場合の障害対応
- 発生してしまった場合の対応コスト、という視点では1ヶ月あたり6.4時間しか削減効果が見込めない事が分かりました
- 事前に潰せた可能性のある障害は表示の不具合といった比較的軽微な物が多いのも特徴です
環境の変化（ブラウザやOSのバージョンアップ）での不具合発生を検知
- こちら起因では直接的な障害が発生しておらず削減効果は無しと判断しました
受入れテストの負荷
- 22年1月〜8月までPJが12件、 受入れテスト実施に1人で平均2時間として12件×2時間でトータル24時間、 1ヶ月にすると3時間しか削減効果が見込めない事が分かりました
これらの事からリグレッションテスト漏れによる障害と、その復旧にかける時間は軽微であることと。受入れテストでの負荷軽減効果も少ないため障害が発生した後に対応しても対応コストは大きくないことが分かりました。
E2Eテストによるリグレッションテストを導入する場合のコスト
自前実装
E2Eテストと言うとSeleniumなどを使用してCI上で実行するのがまず思い当たると思います。当然イニシャルの環境構築、テストの作成などの工数が掛かります。また、開発を進める中でテストが壊れるため日々のメンテナンスも必要となります。
SaaS
AutifyやMagicPodといったSaaS型のE2Eテストも存在します。イニシャルの環境構築が無いわけではありませんが自前で構築するよりは低く、GUIからテストが作成出来ますし。AIを用いて軽微なテストの修正は自動的に行ってくれます。その分ランニングコストとして料金が発生します。
両者を比較
E2Eテストの保守に時間をかけてしまう場合前述のとおり防げる障害対応工数に対してエンジニアリソースが見合いません。SaaSを導入する場合削減出来るエンジニアリソースに対して料金が割高となります。
結論
E2Eテストでリグレッションテストを行っていれば防げたであろう障害が発生した際の対応コストと導入した場合のコストを天秤に乗せた場合、導入した場合のコストが上回るため。再発防止策としてのE2Eテストによるリグレッションテストの実施は見送りました。
今回の検討はリグレッションテストの漏れによる影響と、導入によって得られる時間の削減のみに焦点を絞っての検討でした。自動でリグレッションテストが行われることによる安心や事故の発生を未然に防ぐ（0に近づける）という効果については考慮していません。これはリグレッションテストが漏れたことによるお客様への影響はあるものの、料金に関わる部分や検知まで時間が掛かってしまったという物が無かったためです。
料金などコア部分は単体テストのカバレッジも高くリグレッションテストが無くても問題が起こりにくい状態に出来ていることが判断材料となっています。
まとめ
導入に消極的な訳では無く前向きに検討した結果、自分たちにとって少なくとも今必要なものではなかったということが分かりました。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！
ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。どんな会社か気になった方はオウンドメディア「ホワプラSTYLE」をぜひご覧ください。
オンラインでカジュアル面談もできますので、ぜひお気軽にお問い合わせください。
