脆弱なテストスクリプトがリリース遅延を引き起こした理由と、あるチームが取った対策

問題：メトリクスに隠された脆いテスト

約15名のエンジニアからなるコンシューマーアプリチームは、200以上のテストケースを持つ、まともなQA体制を整えていると考えていました。彼らはテストケースの数でQAの健全性を測定しており、紙面上では良好に見えました。

3月にQAエンジニアが育児休暇に入ると、数か月間安定していたフローでCIパイプラインが失敗し始めました。問題は、2スプリント前のUIリフレッシュで要素が移動し、Appiumスクリプトのロケーターが移動または名前変更された要素を指していたことです。アプリはユーザーにはほぼ同じように見えましたが、スクリプトは適応できませんでした。

3人が修正を試みましたが、そのうち2人は数か月間テストスイートに触れていなかったエンジニアでした。ほぼ1週間かかり、期限が変わらなかったため、1回のリリースは適切な回帰テストなしで出荷されました。

メンテナンスの真のコスト

QAエンジニアが戻ってきたとき、彼は週の50〜60%をスクリプトのメンテナンスに費やしていることを明かしました：ロケーターの更新、UI変更後に壊れたものの修正、テストスイートの維持です。実際にバグを見つけるのに費やしていた時間は約3分の1だけでした。

チームは、間違ったものを測定していたことに気づきました。テストが崩壊しないようにするだけでどれだけの時間がかかっているかを追跡している人は誰もいませんでした。

解決策：ロケーターを超えて

チームはここ数か月、ロケーターにまったく依存しないツールを使用してテストスイートを再構築しています。テストは平易な英語で書かれ、ツールは人間のように画面を読み取ります。UIが変更されると、適応します。

QAエンジニアは、2年間で初めて、実際の仕事をする前に修正する壊れたスクリプトのリストなしで月曜日に出勤したと報告しました。

ロケーターの問題は、彼らがどれだけ速く出荷できるかに静かに上限を設定しており、それが崩壊するまで完全には認識していませんでした。