転職のテンサゲから始まった自動化入門② ～結局、全部“期待値”の話だった～
※ これまでの自動化入門シリーズはこちら 🙆♀️
転職のテンサゲから始まった自動化入門 ～自動化できないQAの民から脱却～
https://note.com/miyu1928/n/n735526e3df96?sub_rt=share_sb
前回の記事で、私は「テスト自動化」という世界に足を踏み入れた。
Playwright、CI/CD、E2E……。
転職活動をきっかけに飛び込んだその世界は、最初かなり「コードを書くすごい人たちの世界」に見えていた。
でも調べていくうちに、
自動化って、品質を継続的に確認するための仕組みなんだな
という感覚が少しずつ見えてきた。
そして今回。
社内研修で実際にSelenium IDEを触り始めたのだが――
正直に言う。
最初は完全に呪文だった。
assert？verify？xpath？？
知らない単語が次々に出てくる。
assert
verify
xpath
locator
isolation
何を言っているのか全然分からない。
特にxpath。
最初に見た時は、
「誰？？？？」
ってなった。
Selenium IDEを触ってみたら、意外と“人間の操作”だった
ただ、実際にSelenium IDEを触ってみると、少し印象が変わった。
Selenium IDEは、ざっくり言うと「ブラウザ操作を記録する」ツール。
ボタンを押す
入力する
画面遷移する
といった人間の操作を、そのまま記録して再生できる。
最初は「自動化＝難しいコードを書く世界」だと思っていたけれど、実際には、
人間がやっている確認作業を、順番に分解している
だけだった。
これ、意外と理解しやすかった。
Excelの「マクロ記録」に少し近い感覚かもしれない。
「assert」と「verify」の違いが、思った以上にQAだった
今回、一番「なるほど」と思ったのがここ。
assert は、NGだったらそこで停止する。
verify は、NGでも続行する。
最初は単なるコマンドの違いに見えた。
でも考えていくうちに、
「その期待値が、後続確認の前提を壊すか？」
の違いなんだと気づいた。
例えば、
ログインできない
→ その後の確認に意味がない
→ assert
一方、
ラジオボタン初期表示
文言
レイアウト
などは、1箇所NGでも他もまとめて確認したい。
→ verify
つまり、
「期待値によるね」
という話だった。
これ、かなりQAっぽい。
isolationも、結局は「前提条件」の話だった
さらに面白かったのが isolation。
最初は「テスト独立性？何それ？」という感じだった。
でも整理していくと、
毎回同じ前提条件で期待値を確認するための考え方
だった。
例えば、
前回のログイン状態が残っている
データが残っている
セッションが切れていない
そんな状態だと、
「今回のテスト結果」なのか分からなくなる。
つまり isolation は、
“期待値を純粋に確認するための環境づくり”
だった。
これ、手動テストでも普通にやっていた。
xpathは「道順」だった
そして、最大の呪文だった xpath。
でも話を聞いていくうちに、
HTMLの中を辿る「道順」
だと分かってきた。
例えば、
div = 箱
button = ボタン
input = 入力欄
それらがHTMLの中で階層構造になっていて、
「どこの部品を触るのか」
を指定するためのものだった。
最初は意味不明だったのに、
「道順か」
と思った瞬間、急に理解できた。
ラジオボタンの話まで、結局“品質”だった
途中で、
ラジオボタンって複数選択できるバグ起こるの？
という話になった。
標準のラジオボタンなら、ブラウザ側で排他制御してくれる。
でも最近のWeb画面は、divやCSSで「ラジオボタンっぽく見せている」ことも多いらしい。
その場合、排他制御を自前実装していることがある。
つまり、
見た目はラジオボタン
中身はただのdiv
みたいなことも普通にある。
そして、そういう「独自実装」ほど壊れやすい。
ここでも結局、
「何を保証したいのか」
という品質の話に戻ってきた。
自動化を学んでいるはずなのに、ずっと品質の話をしていた
最初は、
自動化 = コードを書く世界
だと思っていた。
でも実際には、
何を保証したい？
どこまで確認したい？
どこで止める？
人間が見るべき？
機械が繰り返すべき？
……そんな話ばかりしていた。
気づけば、ずっと“品質”の話をしていた。
自動化は目的ではなく、
品質を継続的に守るための手段
だったのかもしれない。
……とはいえ。
しかし研修はまだ半分も終わっていない。
どうやら、自動化への道のりは思った以上に険しいらしい。
