転職のテンサゲから始まった自動化入門③～自動化テストで見えてきた「人間が無意識にやっている確認」～
※ これまでの自動化入門シリーズはこちら 🙆♀️
転職のテンサゲから始まった自動化入門 ～自動化できないQAの民から脱却～
https://note.com/miyu1928/n/n735526e3df96?sub_rt=share_sb
転職のテンサゲから始まった自動化入門② ～結局、全部“期待値”の話だった～
https://note.com/miyu1928/n/ne619b4b45401?sub_rt=share_sb
転職活動のテンション低下から始まった、自動化研修もついに3回目。
今日で座学は一通り終了らしい。
……いや、普通に頭が爆発している。
前回までは、
「自動化＝継続的に品質を確認する仕組み」
という理解になっていた。
でも今回はさらに、
wait
DOM
Isolation
など、新しい概念が一気に出てきた。
正直、最初は呪文だった。
waitが分からない
最初、waitについては、
「期待値通りになるまで待つもの」
くらいの理解はしていた。
でも実際は違った。
自動化では、
「何を待てば、人間は“処理が終わった”と判断しているのか」
を明示する必要があるらしい。
例えばログイン。
人間なら、
「ログインできたね」
で終わる。
でも自動化では、
入力
↓
ログインボタン押下
↓
画面切り替わり待ち
↓
本当に次画面か確認
まで分解しないといけない。
しかも、その「待つ対象」も重要だった。
DOMが生成された？
検索結果が表示された？
ボタンが押せる状態？
エラーメッセージが出た？
何をもって「処理完了」とするのかを定義しないと、自動化は動けない。
人間は無意識に確認している
Selenium IDEを触っていて、かなり面白かった。
人間って普段、
画面変わったな
ロード終わったな
エラーっぽいな
結果表示されたな
を、無意識に判断している。
でも自動化は違う。
全部、
「どの状態になれば次へ進めるのか」
を明示しないといけない。
ここを分解しないと、自動化は成立しないらしい。
DOMという概念
これも最初は完全に呪文だった。
でも理解したこととしては、
ブラウザは画面を「DOM」という部品の集まりとして管理しているらしい。
つまり自動化は、
「画面を見ている」
というより、
「DOM上の部品を探している」
感覚に近い。
検索結果も、
検索
↓
API/DB処理
↓
DOM生成
↓
画面表示
という流れになっているらしい。
waitで待っていたのも、結局はこのDOM生成だった。
Isolationでさらに頭が爆発した
今回かなり印象に残ったのがIsolation。
これはコマンド名ではなく、
「テストの独立性を保つ考え方」
らしい。
例えば、
ログイン状態
Cookie
検索条件
DB状態
などを次のテストへ引きずらない。
つまり、
「毎回同じ条件で期待値確認できる状態」
を作るということ。
でもここで、ふと気づいた。
これ、完全に初めての概念ではなかった。
手動総合テストでも、
DB戻し
テストデータ準備
権限切替
前提条件確認
みたいなことを普通にやっていた。
自動化は「全く新しいこと」ではなかった
今回一番面白かった気づき。
自動化って、
「コードを書くこと」
だと思っていた。
でも実際は、
「今まで人間が無意識にやっていた確認を、機械でも継続実行できる形へ分解している」
感じだった。
だから wait や Isolation も、
突然現れた難しい概念ではなく、
処理が終わったことを確認する
毎回同じ条件で確認する
みたいな、今まで自然にやっていたことに名前が付いていたらしい。
なお、理解度チェックは普通にぴえん
checked と selected が混ざる
present と not present を見落とす
store attribute が呪文
など、まだまだ分からないことは多い。
でも逆に、
「何を保証したいのか」
は少しずつ見えてきた気がする。
自動化は「コードを書くこと」だと思っていた。
でも実際は、人間が無意識にやっている確認を、機械でも判定できるように分解していく世界だった。
今日で座学は一通り完了した。
あとは習うより慣れろ。
