転職のテンサゲから始まった自動化入門⑦〜AI伴走で7日間、自動化を動かしてみる Day3〜
※ これまでの自動化入門シリーズはこちら 🙆♀️
転職のテンサゲから始まった自動化入門 ～自動化できない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分の復習～
https://note.com/miyu1928/n/nb044de60aaad?sub_rt=share_sb
転職のテンサゲから始まった自動化入門⑤
〜AI伴走で7日間、自動化を動かしてみる Day1〜
https://note.com/miyu1928/n/n6f2e4788a3c1?sub_rt=share_sb
転職のテンサゲから始まった自動化入門⑥
〜AI伴走で7日間、自動化を動かしてみる Day2〜
https://note.com/miyu1928/n/n86bd5f98d0c6?sub_rt=share_sb
昨日は、
「期待値をどう機械判定するか」
を理解した。
そして今日はそこから進み、
「失敗時にも期待値がある」
を学習した。
今回はかなり、
「QAと異常系テストが繋がった日」
だった気がする。
codegen を使ってみる
今日はまず、
Playwright の codegen を起動。
実行したコマンドはこちら。
npx playwright codegen https://the-internet.herokuapp.com/login
すると：
Playwright Inspector
自動操作対象ブラウザ
が起動。
昨日までは、
既にあるコードを読んでいたけど、
今日は実際に操作を記録するフェーズへ入った。
codegen は「操作記録」
今日かなり大きかった理解がこれ。
最初は、
「自動でテストを作ってくれるもの」
みたいなイメージだった。
でも実際は違った。
理解したのは：
codegen = 操作記録
ということ。
つまり：
ボタン押下
入力
クリック
などの
「操作」
は記録してくれる。
ただし、
「何を保証したいか」
までは自動で決めてくれない。
ここ、
かなりQAっぽい。
未入力ログインを試す
今回は異常系を確認。
実施した内容はこちら。
username 未入力
password 未入力
↓
Login押下
すると：
Your username is invalid!
というエラー表示。
異常系は「壊れること」ではない
ここ、
今日いちばん大きかった理解。
最初は、
異常系 = 壊れる
みたいなイメージがあった。
でも実際は違う。
異常系とは：
「正しく失敗すること」
を確認するもの。
つまり、
未入力
不正入力
エラー発生
そのものが問題ではなく、
「想定した失敗になっているか」
を確認する。
ここ、
かなりQAと繋がった。
Loginボタン押下コードを見る
codegen が生成したコードはこちら。
await page.getByRole('button', { name: /Login/ }).click();
これは：
Loginボタン押下
を意味している。
最初はかなり呪文っぽかったけど、
少しずつ読めるようになってきた。
getByRole() が面白かった
ここも今日かなり印象的だった。
getByRole('button')
これは：
「buttonという役割」
で要素を探している。
つまり、
見た目
ではなく、
role（意味）
で探している。
そのため：
UI変更に比較的強い
ことを理解した。
ここ、
「見た目」より「意味」で見る感じが、
少しアクセシビリティとも繋がっていて面白かった。
codegen のままだと「確認」になっていない
次に生成されたコードはこちら。
await page.getByText('Your username is invalid! ×').click();
最初は、
「あ、エラー確認してるのか」
と思った。
でも違った。
これは：
エラーをクリックした操作
として記録されていた。
つまり：
codegen は操作記録
であり、
「何を保証したいか」
は自分で整理する必要がある。
QA視点でコードを書き換える
そこで修正。
await expect(
page.getByText('Your username is invalid!')
).toBeVisible();
これは：
「エラーメッセージが表示されること」
を機械判定している。
ここでかなり、
「QA視点で期待値を定義する」
感覚が繋がった。
今日作成したテスト
今回作成したテストはこちら。
test('empty login shows username error'
内容としては：
ログイン画面へアクセス
↓
未入力でLogin押下
↓
エラーメッセージ表示確認
を自動化。
つまり、
「正しく失敗すること」
を保証している。
実行結果
実行コマンドはこちら。
npx playwright test --headed
結果：
3 passed
成功。
さらに：
chromium
firefox
webkit
全ブラウザで成功確認。
ここでかなり、
「異常系も継続確認できる」
感覚が見えてきた。
今日理解したこと
今日いちばん大きかった理解は、
自動化は「操作記録」だけでは足りない
ということ。
必要なのは：
「何を保証したいか」
をQA視点で定義すること。
つまり：
どのエラーを出すか
何を正常とするか
どこまで保証するか
を整理する必要がある。
Day3終了時点の感想
今回かなり、
「手動試験でやっていること」
と、
「自動化コード」
が繋がってきた。
今までは、
「コードを書く世界」
に見えていたけど、
実際は：
「普段やっている確認を
期待値として整理している」
感覚に近い。
少しずつ、
「自動化は別世界」
ではなくなってきた。
次のテーマは：
「コード型自動化」
予定内容は：
fill
click
expect
locator
「操作記録」から「自分で書く」へ進む
Day4へ続く🙆♀️
