Introduction
Openlogiではメジャーリリース前のリグレッションテストの８割の自動化を１年で実現しました。
しかし、ただ自動化しただけでは開発に伴う変更に自動テストを対応させるコストが想像以上に掛かってしまっていました。
ここでは自動化実現と運用にあたって生産性向上に必須のテクニックについて書きます。
最初は各項目の自動化にそれなりに時間が掛かるものの、進めるうちに複利的効果を発揮します。
自動化ツール
Ghostinspector を使用
よく使う機能
-
レコーディングツール
Chrome addon でテストレコーディングツールが提供されているので、ベースとなるテストステップはコードを書かずに作成することができる。 -
Condition(分岐)
ページ内の要素の状態による処理の分岐をJavascriptを使って設定することができる。 -
変数
変数を自由に定義し、任意の値やページ内の指定した要素の値を変数に格納することが可能。
シーケンシャルなテストスイートを組むことで変数とその値を後続のテストに引き継ぐことが可能。
生産性を上げるために重要なこと
タイトルにある複利的に効果を発揮するE2Eテスト自動化方法はずばりモジュールの利用です。
ですが、闇雲にモジュールを作ってもメンテナンスコストを下げることができません。
以下にポイントを記します。
- 汎用性の高いモジュールにすること
- 柔軟性をもたせること
汎用的で柔軟性の高いモジュールにするには
1. 重複するテストステップはモジュール化する
まず重要なのが、全てのテスト項目から何度も実施しないといけない重複項目を洗い出します。
この時扱う値が都度変わったりすることもあると思いますが、それは変数で対応できるのでそういった項目もモジュール化の対象にします。
2. 分岐ごとのテストステップを作成する
最大公約数的に重複するテストステップを求めるとモジュールがとても小さくなります。そうなるとメンテナンスコストが思うように低減できなくります。
ですので、ある程度の分岐まで含めてモジュール化します。
画像は tab に数字が表示される画面で数字があれば処理を実行する分岐処理です。
↓
let tab = document.querySelector("#warehousing_detail_main_tab-tab-size > span > span");
return tab !== null;
こういった分岐を作っておけば tab の数字を変数にして任意に設定することで、たとえば tab に「2」が表示されたら実行するようにすることも可能です。
let tab = document.querySelector("#warehousing_detail_main_tab-tab-size > span > span");
return tab === {{tabNumber}};
3. 変数の設定場所のマネジメント
変数のマネジメントの詳細については過去の記事に記載してありますので、ここでは汎用的なモジュールで変数を扱い易くする方法を書きます。
モジュールはテスト内で呼び出すことになるので、あまり階層の高い場所に変数を設定してしまうとテスト毎に変数を設定し直さないといけません。その手間を避けるためには、モジュールを呼び出すテスト内で変数の値を設定します。
こうすることでテスト毎に変数の値を調整することもできるので、テストをコピーして変数の値を変えるだけでパターンの異なる自動テストを実施することが可能になります。
汎用的で柔軟性の高いモジュールを多用することのメリット
モジュール化されていないとどうなるか？
メリットを語る前に、まずはモジュール化していないとどうなるかお伝えします。
自動テストは開発するコストもありますが、システムの成長に伴って発生する変更に対応するコストも地味にQAリソースを奪っていきます。
特にいざリグレッションという時、リリースされる新機能によって既存要素に変更があった場合テストがFailしてしまって至急対応方法を決めないといけないなんてことがよくありました。
そこで新たに開発する自動テストは汎用性の高いモジュールの開発に力を入れるようにしています。
最近は変更にAIがよしなに対応してくれるサービスもありますが、オープンロジではAIの教育方法やどういった動作をするかがブラックボックスになると考え、手動で管理できるツールとして Ghostinspector を選びました。
自動テスト運用コストが下がる！！
開発に伴う変更に自動テストを対応させるための修正箇所がモジュール内に収まることで、運用コストは確実に下がります。
最初はそれほど効果を実感できませんが、１つの変更によって影響を受ける範囲が広い場合は、重複している行程としてモジュール化されている可能性も高まります。結果として変更箇所がモジュールだけになることが増えていきます。
合わせてUIに変更が入る開発はQC後にE2E自動テストも実行することで、リグレッションテスト時には変更に対応できているよう運用を改善しました。こういった対応が機能するようになってようやくリグレッションのテスト工数を大幅に削減することができています。
Conclusion
高い汎用性と柔軟性のモジュールを開発するにはテストシナリオの分析、分岐や変数の設計などそれなりにコストが掛かりますが、使っていくことでコスト削減効果を実感することができます。
自動化はできたけど運用が大変という方は一度試してみてはいかがでしょうか。
PS
【オープンロジイベント情報】
<12/15(木)19:30〜>
「CTO・VPoEぶっちゃけトーク！ 〜失敗から学ぶエンジニア組織論〜」
過去の失敗談をセキララに語りつつ、オープンロジでどんな組織をつくっていくかが語られる予定なので、ご都合合う方は是非ご参加ください！
https://openlogi.connpass.com/event/265230/