転職のテンサゲから始まった自動化入門⑤〜AI伴走で7日間、自動化を動かしてみる Day1〜
※ これまでの自動化入門シリーズはこちら 🙆♀️
転職のテンサゲから始まった自動化入門 ～自動化できない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
前回までで、
wait
assert
isolation
「動かす」と「保証する」の違い
など、自動化の考え方を少しずつ整理してきた。
そして今回は、
実際に Playwright を動かしてみる Day1。
AIに伴走してもらいながら、
7日間のロードマップを開始した🙆♀️
まずは Selenium IDE で躓く
最初は Selenium IDE を試す予定だった。
ただ、
Chrome拡張側の仕様変更で導入できず、
開始数分で停止。
正直、
「……あ、これは自動化が難しいというより、
仕様変更の壁にぶつかってる感じかも」
とは思った。
でも、
ここで感じたのは、
「目的はツール固定ではなく、
自動化を理解すること」
ということだった。
そこで、
AI伴走で Playwright 学習へ切り替え。
なんかもう、
この時点で少し現場っぽい。
Node.js を理解する
まずは環境構築から。
ここで最初に理解したのが、
Node.js = JavaScript実行環境
ということ。
Playwright は Node.js 上で動く。
つまり、
Playwright
↓
Node.js が実行
↓
ブラウザ操作
という構造らしい。
こういう「裏側の構造」を理解し始めると、
少しずつ怖さが減ってくる。
mkdir と cd を覚える
コマンド自体は案件で少し触ったことがあったので、完全に知識ゼロというわけではなかった。
今回実際に打ったのは：
mkdir automation-practice
これは、
mkdir = make directory
つまりフォルダ作成。
次に：
cd automation-practice
cd = change directory
フォルダ移動。
今まで何となく見ていたコマンドにも、
ちゃんと意味があるんだなと思った。
PowerShell と cmd の違いで詰まる
ここで最初のエラー発生。
PowerShell 側で、
npm.ps1 の実行が禁止
されていた。
最初は「？？？」状態。
ただ、
今回は cmd（コマンドプロンプト）へ切り替えて回避した。
ここ、
ちょっと QAっぽいなと思った。
理想論だけで止まるより、
「今の目的を達成するために、
まず進める」
という考え方。
完璧じゃなくても、
まず前に進めることも大事なんだなと思った。
Playwright を導入する
実行したコマンドはこちら。
npm init playwright@latest
これで：
実行環境
設定
テスト雛形
ブラウザ
などを自動構築。
正直、
「導入」ってもっと全部手作業だと思っていた。
思った以上に、
最初の土台は整えてもらえる世界らしい。
初めて Playwright を動かす
実際に実行したコマンド。
npx playwright test
ここで理解したのは、
npx = Node.js系ツールを実行する仕組み
ということ。
そして Playwright が内部でやっていたのは、
testsフォルダ内テスト検出
↓
ブラウザ起動
↓
ページアクセス
↓
クリック/確認
↓
期待値判定
↓
結果集計
だった。
つまり、
ただブラウザを動かしているわけではなく、
「確認」までやっている。
ブラウザが勝手に動いた
今回は headed モードでも実行。
npx playwright test --headed
すると、
実際にブラウザが開き、
勝手にアクセス
勝手にクリック
勝手に確認
していた。
正直かなり感動した。
QAやってるのに、
「おお……」
ってなった。
画面を見ながら、
「あ、今この確認を自動でやってるのか」
と少しずつ繋がってきた。
「動かす」と「保証する」は違う
今日いちばん大きかった気づきはこれ。
最初は、
自動化 = 人の代わりに操作するもの
だと思っていた。
でも実際は違った。
重要なのは、
期待値確認
だった。
例えば、
❌ ボタンを押した
ではなく、
⭕️ 押した後に正しい状態になったか
を確認する。
ここが、
今までの「自動化」のイメージと大きく違った。
show-report を見て理解したこと
最後にレポート確認。
npx playwright show-report
すると：
chromium
firefox
webkit
の3ブラウザで、
タイトル確認
リンク確認
が成功していた。
ここでかなり、
「ブラウザ差異確認を
継続的に自動確認できる」
ことの強さが見えた気がする。
QA視点で理解したこと
今日理解できたのは、
自動化 = 品質確認内容を
機械判定可能にすること
ということ。
つまり：
表示確認
遷移確認
ブラウザ差異確認
リグレッション確認
などを、
コード化している。
単なる「操作自動化」ではなく、
「品質保証の継続化」
なんだなと思った。
Day1終了時点の感想
まだコードを書けるわけではない。
でも今日、
「自動化が何を保証しているのか」
は少し見えた気がする。
自分の中で、
“怖いもの”から
“理解できそうなもの”へ少し変わった。
次は、
「何を期待値として保証するのか」
をテーマに、
expect / assert / wait を理解していく。
Day2へ続く🙆♀️
