はじめに

この内容は、テスト自動化の記事として実際にシナリオ実装を行なってくれている方が寄稿してくれています
本人の要望により、影寺さん と呼ぶびます😅

影寺さんのスペック

QAエンジニア経験

年齢はひみつ
20年に及ぶテスト現場での叩き上げ

開発経験

なし

触ったことのあるテストツール

Selenium
Ranorex
Apidog
Postman

主な保有資格

基本情報技術者
JSTQB FL

ではここから影寺さんの寄稿となります

テスト自動化作成前にやること

自動化対象とするテストケースの見直し

テストケースの設計者と自動化担当者が一緒であれば
力を入れてやる必要はありませんが、別となるとケースの行間は読めません。
記述があいまいであったり、複数の解釈の仕方ができるような書き方がされている場合は
問い合わせ業務が発生します。意外とこれが馬鹿にならない工数を消費します。
もちろん完璧にはいかないと思いますのでテストケース設計者は自動化担当者へ共有する前に一度精査をお願いしたいです。

テスト内容が自動化ツールで対応可能かの取捨選択

例えばチェック項目に｢レイアウトに違和感がないこと｣とあった場合、そのままシナリオに起こせません。それをツール側で判定できるようにチェック内容を分解する必要が出てきます。
また、｢ダウンロードしたファイルに〇〇の記述があるか確認する｣という場合でもファイル形式が非対応であればそのテストはできませんので対応不可、となります。
この場合は理由を添えてSKIPとする旨を共有しておきましょう。

テストシナリオ作成ルールの整備

自動化シナリオ作成担当者が1名であればガチガチに決めなくてもいいかもしれませんが
複数人で担当する場合、これを決めておきましょう。
集約する際苦労します。

テスト自動化シナリオ作成中にやること

同じ操作しているなと思ったら共有ステップ化
- シナリオを作成中に｢面倒くさい｣と感情が芽生えたらそれは共有ステップ化のチャンス。
  - 真っ先にやるべきなのはログイン、ログアウト一連の操作。
- シナリオ上から変数を指定したければステップ冒頭に変数に固定値を保存を設定し、それをコネクタ連結する。
- IDがない要素に対して複数行入力が必要な場合、番号が振られていれば法則性を探し、繰り返し操作にできないか検討する。
動作確認はこまめに行い、確実に動くことを確認する
- 面倒だからとまとめて行うと、想定よりも影響範囲が大きく手間になることがある。
なるべくは取得した画面、要素名はそのままではなく、
後で見返したらわかるようにリネームしておく。
画像比較の確認を安易に多用しない
- 比較する範囲を絞ることができますが、レイアウト変更に弱いことは変わらないので、これでしか確認できないという際に使った方がいいです。
安易にシナリオの修正をしない
- ｢さっきのシナリオ、こっちのがいいな｣
  これくらいの気持ちで修正すると思わぬ追加修正が入りがちです。過去の自分はその時点でのベストを尽くしている、と考えるようにしましょう
  それでも気になる場合はメモを残す。

テスト自動化シナリオ作成後にやること

複数のテストシナリオ一括実行なら通しでの動作確認
- 単独で1シナリオを動作確認してOKでも、一括実行となると思わぬ挙動が見つかることがある。
ステップ数を確認する
- ステップ数の少ないテストシナリオがあり、
  まとめても300ステップ以内に収まるなら、1シナリオに集約して作成可能シナリオ数を節約できる。
改めてリファクタリング
- 作成中に気になった点等、残したメモを見ながら取捨選択する。

(おまけ)テストシナリオ作成中に過る感情

IDあった。ありがとうございます!!
さっきはパスしたのに何で今は通らないの...?
この行全部入力なのか...共有化しよう
あ～...通しで動かすと、このポップアップ出るのか...
通れ通れ通れ...通った!
もうこんな時間なんですか...!

最後に

シナリオ作成中、動いては止まり、また止まりを繰り返していると心が折れそうになりますが全ステップが滞りなくパスしたときの爽快感は心地いいものですね。