初めまして。
モチベーションクラウドシリーズのアドベントカレンダー3日目を担当する坂本です。
テスト自動化を担当していますので、テスト自動化の一つであるE2Eテストについて話したいと思います。
今回は、社内外でよく質問されることをピックアップします。
技術的なことは、他の記事を参考してもらったほうがいいので、
ここでは、E2Eテストの導入と運用についてQA形式で説明させていただきます！
自動化に向いているテストはなに？
リグレッションテストです。
自動テストの役割は**「いつも通り動作している」**ことを確認することです。
逆に向いていないテストは、新機能に対するテストです。
新機能及び改修された部品のテストは、
**「インシデントが発生すること」**を前提にテストします。
そのようなテストは、むしろ、手動テストの方が向いています。
どこから自動化すればいい？
ビジネスへの影響度が高く、仕様変更頻度があまりないところから自動化するのが理想的です。
ビジネスシナリオ毎に優先度を数値化するのであれば、
個人的な見解が大分はいっっていますが、各要素ごとにレベル分け、以下のような式で考えています。
ビジネスリスク + 影響範囲 + 使用頻度 - 仕様変更頻度 - 回避策有無
- ビジネスリスク
- 生命の危機 ＞ 売上・信用の損失 ＞ 機会の損失 ＞ 時間の浪費
- 影響範囲
- 対象ユーザ数・利用ブラウザ
- 使用頻度
- プレビュー数・日次・週次・月次・年次
- 仕様変更頻度
- 枯れている仕様か・改善が求められている機能か
- 回避策有無
- 機能が使えない状態でも目的の作業ができるか
テスト自動化した機能が改修された場合どうするの？
まず、手動テストで改修された機能が仕様通りか確認します。
そのあとにテストスクリプトをそのまま実行し、
エラーになった部分が想定通りか確認後、新しい仕様に合わせて
テストスクリプトを変更します。
テスト自動化ってどうやって進めるの？
じつは手動テストと流れはあまり変わらないです。
| 自動テスト | 手動テスト |
|---|---|
| テスト計画 | テスト計画 |
| ↓ | ↓ |
| スクリプト作成 | テスト設計 |
| ↓ | ↓ |
| スクリプトレビュー | 設計レビュー |
| ↓ | ↓ |
| テストデータ準備 | テストデータ準備 |
| ↓ | ↓ |
| テスト実行 | テスト実行 |
| ↓ | ↓ |
| テスト結果報告 | テスト結果報告 |
こう並べると自動も手動の初期コストかわらないように見えますが、
自動は繰り返し実行できるテストデータを準備する必要があるため、
テストデータの検討が手動テストよりシビアある事と、
テスト実行を安定化させる作業があるので、その分工数がかかります。
テスト実行方法ってどんなのがあるの？
-
フルテスト実行
主にリリース直前(手動テスト完了後)で行うテストで、
**「問題が発生しない」**ことを前提に行います。
全てのテストケースを実行します。
テストケースが増えると、全て実行するのに5時間とかかかる場合があります。
その場合は夜間実行や、並列テストで実行します。 -
ビルド＆テスト(部分実行)
開発者が修正する度に実行します。
**「問題が発生する」**ことを前提に行います。
スプリントコードディングの為にもテスト実行時間は３０分以内になるように
ある程度、仕様を網羅できるテストケースに絞ります。 -
並列テスト
テストケースの総テスト時間が増えた時に検討します。
テストを実行するノード(端末)を増やし、テストケースを分散することで、
テスト実行にかかる所要時間を短縮する方法です。 -
本番環境テスト
本番環境に対してのテストです。
インフラ起因の障害を検知するための正常動作確認(負荷確認)や、
サードパティのシステムの影響を受けやすい場合に行います。
テスト自動化でやるUIテストは何をするの？
1. 操作が期待通り動くこと
2. レイアウトが崩れていないこと
3. 重要な値の表示に誤りがないこと
4. 入力したデータが正しく保存されたこと
5. 過去のインシデントが再発していないこと
上記以外のテストを実施したい場合、UIテストよりAPIテストや、JUNITの関数テストの方が適切です。
最後に
どうでしょうか、これでテスト自動化に対して、少しでも理解を深めていただけたなら幸いです。
テスト自動化は、人では困難テストも難なくこなして、開発者に平穏・安定を与える唯一のツールなので、どんどん使ってみてください！