blog/
Zenn での技術記事一覧。各記事をテスト結果カードとして表示。クリックで Zenn に遷移。
-
article.spec.ts › #01 PASS Playwrightのテストタグを乱立させないために、ルールを先に決めた話
テストが増えてくると、だいたいこういう声が出てくる。 「注文履歴まわりのテストだけ流したいんだけど」 「CSV関連だけCIで分けたい」 「メール送信のテストは除外して回せないかな」 Playwrightにはタグという仕組みがあって、@smoke みたいに @ 始まりの文字列を付けておけば --grep "@smoke" で絞り込める。やりたいことはこれで全部できる。できるんだけど、タグが、乱立する。 文字列タグは自由すぎる Playwright標準のタグは、test.desc
-
article.spec.ts › #02 PASS QA不要論に、エビデンス文化のほうから返事をする
「QAって、もういらないんじゃないですか」と言われて、たぶん半分は同意できるんですよね。 AIがテストコードを書いて、AIがブラウザを動かして、AIがレポートを整形してくれる時代になりました。手で叩いていた工程は、確かに半分くらい持っていかれている気がします。「QAエンジニアという肩書き、5年後に残ってますか」と問われたら、正直に言って「半分残ってないかも」と思っています。 ただ、残り半分は、自分はどうしてもこっち側にいたいなと。 これは反論ではなく、返事です。QA不要論にう
-
article.spec.ts › #03 PASS Attention Driven Test というアイデアの話
Attention Driven Test というアイデアの話 最近「テストケースって、コードの複雑さからは結構議論されてるけど、ユーザーの認知負荷からはあんまり議論されてなくない？」って思って、ぼんやり考えていたことを書き出しておく。 呼び方を Attention Driven Test (ADT) と勝手に名付けた。実装の話というよりは、テスト設計の方法論として育てたいアイデアのメモ。 出発点: 既存のテスト戦略はだいたいコード側を見ている リスクベーステスト、変更頻度ベ
-
article.spec.ts › #04 PASS テスト設計の標準が、いま効いている話
最近、テスト設計をAIに頼むこともだいぶ増えてきました。 ただ、最初の頃にやってみて気づいたんですけど、なんとなく「このシステムのテストケース出して」と頼むだけだと、返ってくるのはハッピーパス中心の、なんとも当たり障りのない一覧なんですよね。 それが「JSTQB準拠で、同値分割と境界値分析を使って」と一言添えるだけで、ぐっと網羅性が立ち上がる。境界の漏れが減って、デシジョンテーブルでお願いすれば条件の組み合わせが整理された形で返ってくる。状態遷移ならそれっぽく状態とイベントを
-
article.spec.ts › #05 PASS QAナレッジを Copilot / Claude にアプデさせれば腐らない説
TL;DR AI に E2E の auto-heal を任せていると、ナレッジ側の腐敗が事故の引き金になる 解は「GitHub Issue で失敗を起票 → AI が triage → 週次 cron で .github/instructions/ に昇格」のループを回すこと Markdown PR で直接更新する運用は、起票コスト・非エンジニア参加・昇格基準暗黙化の3つの壁で止まる。Issue ベースに変えるとここが抜ける triage も昇格も GitHub Models
-
article.spec.ts › #06 PASS QAナレッジが腐るとAIが暴走する ─ AI4QA は "プラットフォーム化" へシフトする
TL;DR E2Eテストの auto-heal を AI に任せていると、ナレッジ側の腐敗が事故の引き金になる .github/instructions/ Markdown だけでも gh issue だけでも腐る。両方が必要 「Issue で起票 → ラベル分類 → instructions/ に昇格」というループを回す方向にシフトしませんか、という話 試作として qa-knowledge-platform を出していますが、これはあくまで方向性の一例 AI4QA で勝負を
-
article.spec.ts › #07 PASS QAエンジニアのためのAI時代Playwright実践ガイド
Playwright未経験のQAエンジニアが、Page Object Model + Fixtures Patternで メンテナブルなE2E回帰テスト基盤を作り、Claude Codeで「書ける/直せる」を 仕組み化し、最終的に夜間auto-healで失敗テストの修正PRを自動生成するところ まで届くハンズオン書。`docker compose run`で動くテンプレートリポジトリを クローンしながら章ごとに進められる。
-
article.spec.ts › #08 PASS 人間が寝ている間にClaude CodeがPlaywrightのE2Eテストを直してPRを出す
nightlyで実行しているPlaywrightのE2Eテストが落ちたとき、翌朝その原因を調べて直して、PRを出して...という作業が発生します。 人間が法的に働けない時間に失敗が積まれて、翌朝それを片付けるのは単純に時間がもったいない。 あと面倒。 だったらその時間にClaudeに修正案を考えてもらって第一案を練ってもらえばいい、と思いました。 全体の流れ E2Eテストは毎晩GitHub Actionsのスケジュール実行でまわしています。テストスイートは現在85本のspec
-
article.spec.ts › #09 PASS 社内勉強会をCI/CDで回す仕組みにカイゼンした話
勉強会って、やりたいのに続かない。 何がしんどかったか 30分の発表もしんどかったのですが、そのためめちゃ時間かけて資料を作るのもしんどいな～と。 なんか気合いが入っちゃうんですよね。「社内に共有するんだから、ちゃんとした資料にしないといけない」みたいな謎の義務感があって。発表の準備をすること自体がコストになると、ネタがあっても「今ちょっと忙しいし……」って先送りになります。 ほんで、「忙しい」という状態は一生付きまとうので、結果的に一生続かない。 聴く側も微妙でした。Tea
-
article.spec.ts › #10 PASS MagicPodでテストを書く人に伝えたい、ロケータとAssertionの話
自動テストを運用していると、「なんでこのテスト落ちてるんだっけ？」を調べる時間がじわじわ積み上がっていく。 今回はMagicPodでテストを書いていて気づいた、ロケータの取り方とAssertionの粒度に関するtipsをまとめます。実際に起きた失敗事例を元に解説するので、少しでも参考になれば。 ① 前提条件の確認は soft assertion にしない 何が起きてたか 設定画面でいくつかのオプションをドロップダウンで選択・保存する機能があって、タイミング問題で1回目の保存が
-
article.spec.ts › #11 PASS E2E自動テスト基盤にPRの複雑度判定を導入した
とある1on1で「PRの複雑度を判定して、複雑度が低いものはAIレビューで完結しても良い、というルールにしたら副次的にPRサイズが小さく/シンプルになった」という話を聞きました。 プロダクトコードにおいては、スコープをかなり絞りやすいですが、E2Eテストではどうしてもspecファイルが大きくなってしまったり、Page Objectなどのデザインパターンによって作成されるファイルや変更が大きくなりがちです。 さらに、specファイルを1つ追加するだけのPRもあれば、共通のfix
-
article.spec.ts › #12 PASS AIテストへの期待88%と現実12%のギャップ
最近、QAの現場でもAIの話題を本当によく耳にするようになりました。 「すごい便利になるぞー」っていう期待感と、でも「で、結局どうやって使えばいいの？」っていう戸惑いが、なんとなくごちゃ混ぜになっている。 2/19にこんな記事が出ているのを目にしました。 https://finance.yahoo.com/news/study-finds-ai-priority-software-130000089.html 「AIをテスト戦略の優先事項と考える組織は88%」もあるのに、「実
-
article.spec.ts › #13 PASS GitHub Actionsのワークフローを可視化するツールをvibe codingで作った
はじめに GitHub Actionsのワークフローファイル、皆さんはスムーズに読めていますか？ シンプルなCI/CDパイプラインであれば問題ありませんが、if による条件分岐が増えてきたり、needs でジョブ間の依存関係が複雑に絡み合ってくると、YAMLを目で追うだけでは全体像の把握が難しくなってきます。特に always() や failure() を使った条件分岐、&& や || を組み合わせた複合条件が登場すると、「このステップはどの条件で実行されるんだっけ？」と混
-
article.spec.ts › #14 PASS テストコードに集中するための工夫(fixtures設計)
この記事は以下2つのアドベントカレンダーの12/10投稿分です。 https://adventar.org/calendars/11977 https://adventar.org/calendars/12262 Tsukuba.specアドカレ(12/9)にて、PlaywrightのFixturesについて少し触れました。 https://note.com/ydn_/n/n3cfd7fbe04dc 今回はこの記事で言及していたfixtures設計について、テストコードに集中
-
article.spec.ts › #15 PASS Skillnoteにジョインして1ヶ月でやったこと、これからやりたいこと
https://adventar.org/calendars/11977 Skillnote Advent Calendar 2025のトップバッターを務めます、QAエンジニアのyudenです。 普段はnoteしかやらないのですが、今回のアドカレを機にZennのアカウントを作成しました。 さて、前職の日本ナレッジを10月末で退職し、11月からSkillnoteにジョインしました。 https://note.com/ydn_/n/nbeca8a3ae620 そこで今回の記事では