転職のテンサゲから始まった自動化入門⑩〜AI伴走で7日間、自動化を動かしてみる Day6〜
※ これまでの自動化入門シリーズはこちら 🙆♀️
転職のテンサゲから始まった自動化入門 ～自動化できない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
転職のテンサゲから始まった自動化入門⑦ ～AI伴走で7日間、自動化を動かしてみる Day3～
https://note.com/miyu1928/n/n47a22c812136?sub_rt=share_sb
転職のテンサゲから始まった自動化入門⑧ ～AI伴走で7日間、自動化を動かしてみる Day4～
https://note.com/miyu1928/n/n2c3119cf3a07?sub_rt=share_sb
転職のテンサゲから始まった自動化入門⑨ ～AI伴走で7日間、自動化を動かしてみる Day5～
https://note.com/miyu1928/n/n9405c8fc9105?sub_rt=share_sb
今日のテーマは：
全部は自動化しない
だった。
自動化を学び始めた頃は、
自動化した方が良いものと、人が確認した方が良いものの切り分けができていなかった。
でも今日整理してみて、
自動化するかどうかは「できるか」ではなく、「どちらが継続的に品質を守りやすいか」で考えるものなんだなと思った。
自動化で本当に考えるべきこと
大事なのは、
何を継続的に守りたいか
だった。
自動化対象を考える時も、
自動化できるか
ではなく、
壊れると困るか
で考える。
自動化したいもの
今回整理した中で、
自動化したいと思ったのは：
ログイン成功
ログイン失敗
URL遷移
だった。
理由はシンプルで、
サービス利用可否
に直結するから。
ここが壊れると、
ユーザーはサービスを利用できない。
だから継続的に監視したい。
人間が見たいもの
一方で、
手動確認したいと思ったのは：
説明文の分かりやすさ
入力しやすさ
導線
違和感
だった。
理由は：
利用者が目的を達成できるか
に関わるから。
自動化とUXの違い
自動化が得意なのは、
YES / NO 判定
である。
例えば：
表示された
URLが変わった
ボタンが押せた
ログイン成功した
など。
逆に苦手なのは、
体験品質
である。
例えば：
分かりやすい
使いやすい
導線が自然
違和感がない
など。
getByText() から見えたこと
今日は、
page.getByText('Your password is invalid!')
についても理解が深まった。
最初は、
完全一致
だと思っていた。
でも実際は、
文字列を含む要素
を探している。
例えば：
Your password is invalid! ×
でも取得できる。
逆に、
Your password invalid!
になれば、
期待値との差分
として検知される。
ここで改めて、
Playwrightは：
正しいものを探す
より、
期待値との差分を見つける
ツールなんだと理解した。
エビデンスの考え方も変わった
手動試験では、
やった証拠
を残す。
一方で自動化では、
壊れた時の解析
が重要になる。
つまり、
PASS時よりも：
FAILした時に
どこで壊れたか
が分かることが大事。
Playwrightでは、
スクリーンショット
動画
Trace
なども残せる。
これは、
失敗時の解析性
を高めるためなんだと理解した。
自分の課題も見えた
今日いちばん大きかった学びはここかもしれない。
最初、
ログイン失敗
という観点を考えていた。
でも自動化では、
何をもって
ログイン失敗と判断するか
まで分解する必要がある。
例えば：
エラーメッセージ表示
URL維持
ログイン後画面非表示
など。
気づいたのは、
自分は普段：
業務単位
で考える傾向があること。
でも自動化では、
機械判定可能な単位
まで分解する必要がある。
Day6終了時点の感想
今日理解したのは、
自動化 = コードを書く
ではなく、
観点を分解し
期待値を明確にする
こと。
そしてそれは、
普段QAで行っている
観点整理
↓
期待値整理
↓
品質判断
の延長線上にあった。
明日は最終日。
Playwrightを触った話ではなく、
QAとして自動化をどう捉えているか
を整理して締めたいと思う🙆♀️
