今期、長年勤められてきた当社の社長が社長職を降り、会長職となられました。社長（普段は社長とは呼ばずに一人の人としての尊敬を込めてお名前で呼んでいます。現在は会長となりますが、当時の思い出なのでここでは社長と表記します）は、ぼくが中部に異動になったころに就任されました。当時、ぼくは7年くらい勤務していた客先で、少しメンタルを壊してしまい、中部に異動したところでした。心機一転、中部で頑張ろうとしていたころ、当時はまだ社長になりたてか、なる前ぐらいで、ぼくが新しい取り組みを中部地区の全体会議で発表したときが最初に社長をお見かけしたと記憶しています。その発表で盛大な盛り上がりを見せた後、会議が終了し、会場から退出しようとしたときに一人の男性が微笑みながらぼくの方を見ている視線を感じました。その方が社長だったようです。続きをみる

概要こんにちは、booostのバックエンドエンジニアのma_meです。今回はこちらの記事から着想を得て、個人開発で AI、DevTools Recorder、playwright-cli の３ツールを組み合わせてe2eテストを書いてみたところ、作成とメンテナンスが楽になる手応えを感じましたので、その方法を紹介します。https://dev.classmethod.jp/articles/automate-manual-creation-chrome-devtools-recorder-ai/ 全体の流れ① ブラウザで操作を録画（Chrome DevTools Record...

この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。 2026春QAエンジニアリレーブログの、4本目の記事です。 こんにちは！GaroonのQA（品質保証）エンジニアをしている福元です。 普段はGaroonのTsukimi（インフラ移行）チームで、テスト設計・実施やテストマネジメントを担当しています。2022年に新卒入社し、今年で5年目になります。 社内カンファレンスの1レーンとして、「テスト実施以外の、QAエンジニアの活動」というテーマでQAエンジニアによる発表があり…

この記事は、2022年4月に等身大のT-Penで公開した記事を、QAを楽しむ者向けにリライトしたものです。等身大のT-Pen続きをみる

はじめにこんにちは！TOKIUMでQAチームに所属している富田です。この度、弊社QAチームとして新しいテスト自動化の取り組みを行ったのでその紹介をさせていただきたく思います。TOKIUMでは、E2Eテストの自動化は以前から進めていました。しかし、新機能開発に対するシステムテストの自動化には手をつけられていませんでした。ここでいう「システムテスト」とは、E2Eテストや受入テストの前段階で行われる、開発から渡された新機能が要件どおりに動くかを確認するテストを指します。リグレッションテストのように既存機能を広く通すのではなく、新たに実装された機能に対して、テストケース単位で細かく検...

はじめにDjango / Django REST Framework でテストを書いていると、実装そのものよりも Factory・fixture・関連モデルの扱い でハマることがあると思います。自分もユーザー作成APIのテストを書いていたときに、次のような問題でかなり詰まりました。auth_group_name_key のユニーク制約エラーでテストが落ちるget_or_create() の戻り値の扱いをミスる.set() を使う相手を間違えるFactory と fixture の責務がぶつかるSerializer のバリデーションテストが整理しきれないこの...

シリーズの位置づけ1本目でQDHEフレームワークを設計し、AI人狼のバックエンドをテスト凍結+FMEAで作った。352件テスト全GREEN、ロジックバグ0件。2本目でフロントエンドと結合したら、375件テスト全GREENなのに1回も遊べなかった。9件のバグを分析し、5つの改善提案を出した。3本目ではQDHEを改善せず同じ条件で再実行した。バグは9件→5件に減少したが、まだ遊べなかった。4本目でv2.1を投入。状態遷移表のStep 2統合、3段階レベル設計、スモークテスト必須化等を導入した。正常系が1発で動くようになったが、今度はAIがさぼり始めた。本記事は4本目のv2.1か...

スクレイピングのテスト設計【pytest・モック完全ガイド】!本記事で紹介するテスト手法は、スクレイピングコードの品質向上を目的としています。実際のスクレイピング実施時は対象サイトの利用規約・robots.txtを必ず確認してください。 はじめにスクレイピングのコードにテストを書いていますか？「テストを書こうとしたけど、毎回実際のサイトにアクセスするのは遅いし、サイトの構造が変わるたびにテストも壊れる」「そもそもスクレイピングってどうテストすればいいのか分からない」——そう感じてテストを諦めた経験があります。以前、社内でスクレイピングツールを運用していたとき、テストが...

多くのユーザーを抱えるサービスにおいて、カスタマーサポート対応は避けて通れない重要な業務です。とりわけ電話による問い合わせは、対応コストが高く、待ち時間の長期化による顧客満足度の低下を招く要因にもなります。そのため企業にとっても、ユーザーにとっても、「できるだけ自己解決できる環境を整えること」が重要な課題となっています。ユーザーの自己解決を促す手段としてチャットボットやFAQなどが普及しているにも関わらず、「ツールを導入したのに問い合わせが減らない」という声が後を絶ちません。なぜこうした取り組みは期待通りの成果につながらないのでしょうか。コールセンター運営における長年の現場経験、DX推進などを通じた幅広いノウハウを持つ、ポールトゥウィン カスタマーエクスペリエンス事業部のシニアマネージャー古謝 祐希へのインタビューをもとに、問い合わせが減らない企業に共通する“構造的な課題”を紐解きます。そこから見えてくるのは、単なるツール導入では解決できない、カスタマーサポート効率化の本質です。続きをみる

こんにちは。株式会社ZENKIGEN QAエンジニアの横田です。普段はQAエンジニアとして、Webアプリケーションのテスト設計・実施・改善に取り組んでいます。今回は、開発・デザイン・QAの品質における 役割と責任範囲を明文化した「品質管理ガイドライン」 を策定した取り組みを紹介いたします。「これ、誰が確認するんだっけ？」QAが全部見る前提になっているデザイン差分をQAが拾っているでも正解が分からないこんな状態になっていないでしょうか？特に、開発・QA・デザインが分かれているチームでよく起きる問題です。本記事では、以下の内容をまとめています。直面した課題 — ...

こんにちは。株式会社ZENKIGEN QAエンジニアの横田です。普段はQAエンジニアとして、Webアプリケーションのテスト設計・実施・改善に取り組んでいます。今回は、開発・デザイン・QAの品質における 役割と責任範囲を明文化した「品質管理ガイドライン」 を策定した取り組みを紹介いたします。「これ、誰が確認するんだっけ？」QAが全部見る前提になっているデザイン差分をQAが拾っているでも正解が分からないこんな状態になっていないでしょうか？特に、開発・QA・デザインが分かれているチームでよく起きる問題です。本記事では、以下の内容をまとめています。直面した課題 — ...

ベリサーブさんでマンガ連載を続けています。 今回は「差分テスト」です。 バージョン違いの動作結果の差から問題を検出しようというアプローチです。 ご興味がある方はぜひ見てみてください～！ あまりみんなの馴染みがないような語句を取り上げて解説する趣旨のこのマンガ、最近はネタ切れ気味なので、ネタがあったら知りたいところですｗ www.veriserve.co.jp

Detecting user interface (UI) controls from software screenshots is a critical task for automated testing, accessibility, and software analytics, yet it remains challenging due to visual ambiguities, design variability, and the lack of contextual cues in pixel-only approaches. In this paper, we introduce a novel multi-modal extension of YOLOv5 that integrates GPT-generated textual descriptions of UI images into the detection pipeline through cross-attention modules. By aligning visual features w

AI活用が進む現在、ソフトウェア開発における品質保証（QA）は大きな転換期を迎えています。テスト工程の高度化だけでは、もはや品質は担保できません。重要なのは「品質を後から守る」のではなく、「最初から作り込む」という発想です。JaSST’26 Tokyoに登壇したポールトゥウィン株式会社 QAソリューション事業部 シニアマネージャーの木川広基は、開発ライフサイクル全体で品質を捉える「プロアクティブQA」の考え方と、その実践事例を提示しました。本稿では、その講演内容をもとに、これからのQAの本質と現場に根付かせるための具体的アプローチを紹介します。続きをみる

こんにちは。QAエンジニアのなおたです。 日々ソフトウェア品質と向き合っている若手エンジニアの皆さん。昨今、「生成AI」という言葉を聞かない日はないでしょう。 先日、生成AI本のベストセラー『生成AIで世界はこう変わる』...The post 生成AIはソフトウェアテストを”破壊”するのか？ ー 若手エンジニアが備えるべき「変革」と「新しいスキル」 first appeared on Sqripts.

技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。 QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪...The post 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む first appeared on Sqripts.

Understanding and explaining the structure of generated test inputs is essential for effective software testing and debugging. Existing approaches--including grammar-based fuzzers, probabilistic Context-Free Grammars (pCFGs), and Large Language Models (LLMs)--suffer from critical limitations. They frequently produce ill-formed inputs that fail to reflect realistic data distributions, struggle to capture context-sensitive probabilistic dependencies, and lack explainability. We introduce ExplainFu

「品質が良い」って、誰が決めるのでしょう。ずっとこの問いが頭を離れませんでした。エンジニアとして、マネージャーとして、QAに関わる人たちと話す中で、みんなが「品質を上げたい」と言うのに、「品質が良い状態」の定義が揃っていないことに、何度もぶつかってきました。続きをみる

この記事について1本目ではvillarを作った経緯とTauri v2 + Rustバックエンドについて、2本目ではMarkdownパイプライン（カード分割、TL;DR、Mermaid）について書きました。最終回は、テーマシステム、可読性、テスト戦略、そして2ヶ月の開発で得た教訓について書きます。https://github.com/tyler0702/villar デフォルト値を決めるのに論文を読んだフォントサイズ、行間、段落の間隔。最初は適当に「見やすいかな」で決めていました。でも自分の感覚だけで決めたデフォルトが他の人にとって読みやすいとは限らない。「まあ調べるか」...

Web applications rely heavily on hyperlinks to connect disparate information resources. However, the dynamic nature of the web leads to link rot, where targets become unavailable, and more insidiously, semantic drift, where a valid HTTP 200 connection exists, but the target content no longer aligns with the source context. Traditional verification tools, which primarily function as crash oracles by checking HTTP status codes, often fail to detect semantic inconsistencies, thereby compromising we

!リンクの紹介は目視で確認。文章ドラフトおよび調査において生成AIを利用しています。 TL;DRQA自体は不要にならないただし、「人間が手で大量のテストケースを書くこと」を中心にした旧来QAはもう苦しい生成AIで実装、観点出し、テスト生成、補助的な確認が高速化した結果、後工程で待つQAはボトルネックになりやすいこれからのQAは、シフトレフトして仕様の穴を前で潰し、AIに量産させ、人間が疑い、選び、文脈で判断する仕事に寄る特に人間に残る価値は、ブラックボックスでの違和感検知、探索的な観点や状態遷移崩し、権限や運用をまたいだリスク発見にあるジュニアQAやテスターも悲観し...

!リンクの紹介は目視で確認。文章ドラフトおよび調査において生成AIを利用しています。 TL;DRQA自体は不要にならないただし、「人間が手で大量のテストケースを書くこと」を中心にした旧来QAはもう苦しい生成AIで実装、観点出し、テスト生成、補助的な確認が高速化した結果、後工程で待つQAはボトルネックになりやすいこれからのQAは、シフトレフトして仕様の穴を前で潰し、AIに量産させ、人間が疑い、選び、文脈で判断する仕事に寄る特に人間に残る価値は、ブラックボックスでの違和感検知、探索的な観点や状態遷移崩し、権限や運用をまたいだリスク発見にあるジュニアQAやテスターも悲観し...

こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。E2Eテストの自動化を進めるなかで、「カバレッジをどう定義・計測すればいいか」という問いに直面することがあります。ツール導入の目標設定や、社内での効果説明に使いたいなど、さまざまな場面で必要となるようです。本記事では、E2Eテストにおけるカバレッジの考え方を、単体テストとの違いを踏まえながら整理します。

テストは通る。だが代償があった。==========================================結果: 363 / 363 テスト通過==========================================最高の気分でした。英語対応のテストを53件追加して、全部グリーン。完璧。「よし、次の作業に...」と Claude Code に話しかけたら、こう返されました。「ログインしてください」は？ さっきまで普通に動いてたよね？再ログインして作業を続け、しばらくしてまたテストを回す。全パス。Claude Code に戻る。「ログインしてくだ...

この記事は circa-input 連載シリーズ の第3回です。「だいたい14時」を入力できますか？ — 課題提起とコンセプト紹介circa-input 実践入門 — ハンズオンで導入・カスタマイズ3層アーキテクチャを解剖する（本記事）— 設計思想と内部構造曖昧さで最適化するアプリを作る — 実践アプリケーション構築 はじめに — なぜ3層に分けるのかcirca-input は「値 + 曖昧さ」を1つのジェスチャーで入力できるUIコンポーネントです。本記事ではその内部設計を解剖します。UIコンポーネントライブラリは、しばしば単一パッケージとして作られます。実は...

Multi-Agent LLM Systems (MAS) have been adopted to automate complex human workflows by breaking down tasks into subtasks. However, due to the non-deterministic behavior of LLM agents and the intricate interactions between agents, MAS applications frequently encounter failures, including infinite loops and failed tool invocations. Traditional software testing techniques are ineffective in detecting such failures due to the lack of LLM agent specification, the large behavioral space of MAS, and se

私は誰もリアクションしないあの空気感がめちゃくちゃ怖いです。新しいアイデアを出したとき、提案したとき、沈黙が返ってくる。「つまらなかったのかな」「伝わらなかったのかな」と不安に駆られる。チームで仕事をしていて、一番つらかった瞬間はいつも、あの静けさの中にありました。続きをみる

これまでのあらすじ1本目でQDHEフレームワークを設計し、AI人狼のバックエンドを作った。352件テスト全GREEN、ロジックバグ0件。2本目でフロントエンドと結合したら、375件テスト全GREENなのに1回も遊べなかった。9件のバグを分析し、5つの改善提案を出した。3本目の実行では改善提案を反映せず同じ条件で回し、UXバグは9件→5件に減ったがまだ遊べなかった。そこからフレームワーク本体を大幅改善した。状態遷移表のStep 2統合、STPA/STPA-Secの導入、3段階レベル設計（L1/L2/L3）、スモークテスト・E2E必須化、グローバルルール参照の強制。改善をテンプレ...

はじめまして、SunnySide Testingです 🌞Zennを始めました！ QA・テスト領域を専門にしているSunnySide Testingです。QAエンジニアとして20年のキャリアがあります。 これから発信していくこと 📚現在、QAエンジニア向けの本を執筆中です。【2026年上期版】QAエンジニアが習熟すべき生成AIスキルコードを書かないQAエンジニアが、今日から使える生成AI活用術をまとめたものです。テストケース作成・バグレポート・Excel作業など、QAの実務に特化した内容です。本の内容に関連した記事も、ちょこちょこ投稿していくつもりです。 生成AIとの...

はじめまして、SunnySide Testingです 🌞Zennを始めました！ QA・テスト領域を専門にしているSunnySide Testingです。QAエンジニアとして20年のキャリアがあります。 これから発信していくこと 📚現在、QAエンジニア向けの本を執筆中です。【2026年上期版】QAエンジニアが習熟すべき生成AIスキルコードを書かないQAエンジニアが、今日から使える生成AI活用術をまとめたものです。テストケース作成・バグレポート・Excel作業など、QAの実務に特化した内容です。本の内容に関連した記事も、ちょこちょこ投稿していくつもりです。 生成AIとの...

はじめにAI生成コードの45%にOWASP Top 10の脆弱性が含まれ（Veracode 2025-2026）、コードチャーンは2年前の約2倍に悪化しています（GitClear 2025）。にもかかわらず、76%の開発者が「AIのコードは人間より安全」と認識しています。この認識ギャップが、現在のソフトウェア開発における最大のリスクの一つです。本記事では、以下の3つを一気通貫で扱います。定量データ: AI生成コードの品質問題がどれほど深刻かキャリア戦略: 「ジュニアエンジニアのパラドックス」を乗り越え、監査力・設計力をどう鍛えるか実践的ツール導入: 自律型テスト...

この記事は「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。 2026春QAエンジニアリレーブログの、3本目の記事です。 こんにちは！サイボウズでQAエンジニアをしている tagashira です！ kintone システム管理/外部連携チームの機能開発のQAを担当しています。 このたび、社内カンファレンスのセッション企画にて、各チームのQAエンジニアが「テスト実施以外の、QAエンジニアの活動」をテーマに発表を行う機会がありました。 そこで私は「プロダクトエンジニア×QAエンジニアでもっと”一緒に”つくるリグレッションテス…

こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。テスト自動化を運用していると、避けて通れないのが「テストが失敗したときの原因調査」です。自動テストが増えるほど、失敗時に「なぜ失敗したのか」を確認する手間も増えていきます。スクリーンショットを一つひとつ確認したり、実行ログを確認したりしてプロダクトのバグなのか自動テストの問題なのか環境の問題かなどを切り分けるのはなかなか大変です。今回は、最近リリースしたMagicPodの「失敗分析機能」をご紹介します。実際に使ってみて「これは良いぞ」と感じたポイントや気づいたことをお伝えします。

これまでのあらすじ前編でAI駆動開発フレームワーク QDHE（Quality-Driven Harness Engineering） を設計し、AI人狼ゲームのバックエンドをStep 10まで完走させた。続編でフロントエンドと結合したら、375件テスト全GREENなのに1回も遊べなかった。9件のバグを分析し、5つの改善提案を出した。今回は、改善提案を意図的に反映せず、同じQDHEフレームワークでもう一度AI人狼ゲームをゼロから作った。ただし1点だけ条件を変えた——「バックエンドからUIまで一貫して作成し、ユーザーが遊べるものを作って」というプロンプトにした。前回は「バックエンド...

はじめにCoding Agentを使って自動テストを書いたことがある、あるいはこれから書こうとしている人は多いと思います。実際、テストの実装そのものはかなりAIに任せられるようになってきました。ただ、そこで一つ悩ましいのが、テストの品質判断に必要なドメイン知識を、いつ自分の頭に入れるのかという問題です。AIが設計から実装まで進められるようになっても、「何が正しいテストなのか」を判断するのは人間です。従来は作業の中で自然に得られていたその理解を、どこで作るのかを考える必要があります。私は、この判断に必要な理解は、なるべく前倒しで作っておいた方がよいと考えています。従来の自動テ...

はじめにCoding Agentを使って自動テストを書いたことがある、あるいはこれから書こうとしている人は多いと思います。実際、テストの実装そのものはかなりAIに任せられるようになってきました。ただ、そこで一つ悩ましいのが、テストの品質判断に必要なドメイン知識を、いつ自分の頭に入れるのかという問題です。AIが設計から実装まで進められるようになっても、「何が正しいテストなのか」を判断するのは人間です。従来は作業の中で自然に得られていたその理解を、どこで作るのかを考える必要があります。私は、この判断に必要な理解は、なるべく前倒しで作っておいた方がよいと考えています。従来の自動テ...

Software testing research has traditionally relied on closed-world assumptions, such as finite state spaces, reproducible executions, and stable test oracles. However, many modern software systems operate under uncertainty, non-determinism, and evolving conditions, challenging these assumptions. This paper uses open-world games as an extreme case to examine the limitations of closed-world testing. Through a set of observations grounded in prior work, we identify recurring characteristics that co

この文章はそこそこ長いエッセイのようなテイストをとっています。長いので結論だけ書くと、「LLMでテストコードを書いて開発を進めるなら、テストコードのデータセットや結果セットの傾向をテストするメタテストという手法が非常にマッチしているかも」という内容です。なお、この記事の執筆にはLLMを微細な添削以外に一切使っていません。ちなみに英文の翻訳のよのな文体は筆者の手癖です。先日、ダッシュボードをAIに作らせることにした。最近はLLMの進歩によって、自分専用のダッシュボードを作るのが本当に簡単で、とても素敵なものが作れる。私が作りたかったのは、まさにJIRAのバーンダウンチャートが...

◀前の記事へ 次の記事へ▶︎続きをみる

Flutter×Supabase：CLIを活用した永続化テストFlutterアプリのバックエンドにSupabaseを採用する場合、ローカル環境でのDBテスト（永続化テスト）は、データの整合性とアプリの信頼性を担保するために不可欠です。この記事では、Supabase CLIを使用して、開発機内で完結するテスト環境の構築と、PL/pgSQLを活用した高度なテスト手法を解説します。なお、本記事はSupabaseアカウントが作成されており、かつSupabaseプロジェクトが既に作成されていることを前提にお話を進めてまいります。 1. 永続化テストの環境構築フローSupabase...

はじめにトレンドの技術記事を眺めていると「ハーネスエンジニアリング」という言葉が目に飛び込んでくることが多くなってきました。ハーネスエンジニアリング…なんだかカッコいいスタイリッシュな響きで、綺羅星のように輝く新しい専門領域が誕生した感があります。でも、中身を読んでいくうちに、ちょっと違和感。。。これ、自分が普段やっていることと何が違うんだろう。。個人的にはハーネスエンジニアリングは、まやかしで実体のない曖昧で危うさを秘めた言葉だと思っています。!「まやかし」は、言いすぎかも(汗 と自己ツッコミ言葉だけが先行して勝手に一人歩きしてる感を「まやかし」と表現してみました。定...

学生の頃、演劇を見に行くのが好きでした。いろいろな劇を見ていましたが、劇団四季も好きで「四季の会」にはいって定期的に観劇しに行くぐらいでした。結婚し、子供が産まれて行く機会がなくなっていました。それから年月がたって、子どもたちも演劇を見れるぐらいな年になり、テレビなどで「劇団四季」のCMを見る機会があり、興味を持つようになりました。続きをみる

Vitest と Bun test は 2026 年の TypeScript テストにおける主要な選択肢です。本記事では 1,000 件規模のベンチマーク実測値をもとに速度・機能・ユースケース別の選定基準を解説します。Jest が遅くて困っている方、Vitest か Bun か迷っている方に向けた実践ガイドです。!TL;DRロジックテスト（純粋な TypeScript 関数）は Bun test が Vitest の約 9 倍高速（ウォームアップ後比較。コールドスタートでは 0.12s vs 1.85s で約 15 倍）コンポーネントテストや Browser Mode が必要...