見出し画像

転職のテンサゲから始まった自動化入門④～15分の復習～

もみじりんご🍁🍎私という思考回路

※ これまでの自動化入門シリーズはこちら 🙆‍♀️

転職のテンサゲから始まった自動化入門 ～自動化できないQAの民から脱却～
https://note.com/miyu1928/n/n735526e3df96?sub_rt=share_sb

転職のテンサゲから始まった自動化入門② ～結局、全部“期待値”の話だった～
https://note.com/miyu1928/n/ne619b4b45401?sub_rt=share_sb

転職のテンサゲから始まった自動化入門③～自動化テストで見えてきた「人間が無意識にやっている確認」～
https://note.com/miyu1928/n/n71654b61e655?sub_rt=share_sb

今日は回復の日にした。

転職のことや、色々なことを考えすぎて、脳みそが疲れていたからだ。

でも、完全に何もしないと、それはそれで不安になる。

なので今日は、自動化の復習を15分だけやった。

すると、思ったよりちゃんと説明できた。

もちろん教科書通りではない。

でも、

  • wait

  • isolation

  • assert / verify

あたりを、「なんで必要なのか」という観点で、自分の言葉で説明できた。

assert / verifyだけ少し調べ直したが、

「あー、そうだった」

と繋がる感覚があった。

waitは「期待値確認のための待ち」だった

waitに関しては、「何のために必要なのか」を自分の言葉で説明できるようになっていた。

自動化はCPU速度で動く。

つまり、人間より圧倒的に速い。

そのため、

click
↓
画面/API反映前
↓
assert実行

となってしまい、期待値を正しく確認できないことがある。

だからwaitは、

「次の期待値を確認できる状態になるまで待つ」

ための仕組みだった。

assert / verify もQAっぽかった

assert / verifyも、ただの構文ではなく、

「どこで止めるべきか」

の考え方に近かった。

例えば、

  • データ登録失敗
    →後続確認しても意味がない
    →止める

一方で、

  • UI崩れ
    →他も確認したい
    →続行する

など、品質リスクと結びついている。

つまり、データの連続性が必要かどうかを切り分けないと、期待値の確認ができるとは言えないのだ。

isolationも「前提条件を揃える」話だった

isolationもかなりQAっぽかった。

テストを正しく確認するためには、

  • 前回データを引きずらない

  • ログイン状態を残さない

  • 前提条件を揃える

必要がある。

そのため、

  • データ削除

  • 初期化

  • 毎回新規作成

などで独立性を保つ。

「テスト同士を依存させない」

という考え方を isolation という。

QA観と繋がると覚えられる

今回改めて思ったのは、

QA観と結びつくと覚えやすい

ということだった。

waitも、assertも、isolationも、

結局は、

「期待値を正しく確認するため」

に存在している。

自動化は、

「操作を自動でやること」

ではなく、

「期待値を継続的に確認する仕組み」

なのだと理解し始めた。

明日は環境構築ちゃんとしよう。

いいなと思ったら応援しよう！