やらかした話をします先週、こんなことをやってました。# コードを書く$ cat src/calc.ts# AIに「このコードのテスト書いて」って頼む$ # ...Copilotにお任せ...# テスト実行$ npm test# ✓ All 8 tests passed!# 「よし！完璧！」…本当に完璧だと思ってたんです。テスト全部通ってるし。でも翌日、先輩に見せたら一言。「このテスト、意味ある？」 何が起きてたかAIが書いたテストを見直してみると、こんな感じでした。// src/calc.tsexport function add(a: n...

こんにちは、SODAでQAエンジニアをしているokauchiです。先日、こちらのイベントでE2Eテスト自動化について登壇しました。https://findy.connpass.com/event/384201/登壇では話しきれなかった部分を、補足する形でブログ記事にしていきたいと思います。https://www.slideshare.net/slideshow/e2e-e2e-fake-real/286318477概ね以下のようなことを話をしました。・E2Eテスト自動化は推進者がいる・推進者の頑張りでテスト自動化が運用（定期的な実行がされる状態になる）・さらにスケールする...

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

今回は、第5回の「営業」の回に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。 そのテーマとは、「品質」です。 QAエンジニアと名乗る以上、「品質」と...The post 【第8回】幕間：「品質」という言葉に向き合う first appeared on Sqripts.

多くのチームは「品質が低い」と言われますが、実際にはチームの状態は段階的に変化します。このnoteでは、私が現場で見てきた品質状態を13段階の進化モデルとして整理しました。このnoteに書いてあることは、すべて自分が実際に目の当たりにしたチームの姿です。その時々の状態を観察し、それに応じて、対策を考えて改善を実施してきました。インシデント対応に追われて機能開発ができないチーム。チェックリストを増やし続けるのに何も変わらないチーム。仕様を誰も把握していないまま実装が進むチーム。続きをみる

はじめに前回の記事では、toxの概要と「まず動かしてみる！」を中心に紹介しました。今回は続編として、toxを使いこなす上で欠かせないtox.ini の設定項目についてまとめました。私自身、設定項目に何があるか、どういうことができるか、迷った経験があったので、この記事が少しでも参考になると嬉しいです！ この記事で扱う範囲tox.ini の項目を、次の2つに分けて紹介します。[tox]: プロジェクト全体の挙動を決める項目[testenv]: 各実行環境（テスト、lint、型チェックなど）の項目想定している読者は「toxを一度動かしたことがある」方です。もしt...

「QAって、AIに置き換えられますよね？」後輩にそう聞かれたのは、ちょうどCopilotが開発現場に広まり始めた頃だった。その問いに、自分はすぐに答えられなかった。否定する言葉が見つからなかったのではなく、簡単に「大丈夫だよ」と言える状況ではないと感じたからだ。実際、AIの進化を見ていると、なくなると思えてくる部分は確かにある。 AIで何が変わっているか自分は開発・検証・運用の三つがスループットを決めると考えている。今、AIが加速させているのはこのうちの①と②の一部だ。要件を渡せばコードを書き、テストコードを生成し、テストケースを作り、自動で実行する。そういう世界が現実になり...

「QAって、AIに置き換えられますよね？」後輩にそう聞かれたのは、ちょうどCopilotが開発現場に広まり始めた頃だった。その問いに、自分はすぐに答えられなかった。否定する言葉が見つからなかったのではなく、簡単に「大丈夫だよ」と言える状況ではないと感じたからだ。実際、AIの進化を見ていると、なくなると思えてくる部分は確かにある。 AIで何が変わっているか自分は開発・検証・運用の三つがスループットを決めると考えている。今、AIが加速させているのはこのうちの①と②の一部だ。要件を渡せばコードを書き、テストコードを生成し、テストケースを作り、自動で実行する。そういう世界が現実になり...

@media only screen and (max-width: 600px) { .body { overflow-x: auto; } .post-content table, .post-content td { width: auto !important; white-space: nowrap; }}This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.By Bartosz PapisTest-Driven Development (TDD) is the practice of working in a structured cycle where writing tests comes before writing production code. The process involves t

自動テストを入れたのに、むしろ運用コストが増えている。この状態を放置すると、品質改善どころか現場の負担だけが積み上がります。自動化を「ツール導入」ではなく「設計とプロセス」で立て直せたのがこの本でした。ソフトウェアテスト自動化の教科書 〜現場の失敗から学ぶ設計プロセス...

執行役員CTO（非常勤）としてご支援をしている「株式会社NDKCOM様（長崎県長崎市）」ですが，京セラグループのエムオーテックス様と協力してサイバーセキュリティ分野で世の中やお客様への貢献に取り組んでいくこととなりました […]

はじめに本記事内では、テストの自動化や、オフショアによるテスト実施などは出てこない。記事の途中で、上記の2つは選択肢として十分ありえる。続きをみる

2025年1月にリリースしたTMX版のオートメーションヘルパーについて、利用ケースや提供しているメソッドの使い方を「TMX Automation Helpers リファレンス」として解説していきたいと思います。今回の記事 […]The post TMX Automation Helpers リファレンス５：アクションスポット（座標値）チェック first appeared on テスト自動化ツール 『Ranorex』.

私は言語化しないと次に進めないタイプです。わからないことがあると、ずっとモヤモヤし続けます。「これはどういうことなんだろう」「なぜうまくいかないんだろう」と、頭の中でぐるぐると考え続ける。それが言葉になるまで、なんとなく落ち着かない。続きをみる

はじめにこの記事では、クリーンアーキテクチャでモックをどこまで使うべきかを整理します。主張はシンプルで、モックは必要な境界に限定した方が運用しやすい、です。この記事は、理想的な依存逆転の教科書的整理より、Go + GORM + MySQL の業務アプリで実DB integration test を前提にしたとき、どこまで抽象化とモックを入れるのが現実的かを扱います。特に次の条件のチームを対象にしています。GoGORMMySQL業務アプリRepository実装は実質1つSQLの正しさが重要実DBのintegration testを回せるこの前提では、Rep...

swift-testing の @Test(arguments:)でnilを含む配列を書くと、型推論が曖昧になり、エラーが出ることがあり、これを解決するために、型を明示したくなることがあります。たとえば次のようなコードです。@Test(arguments: [ (nil, 1), ("a", nil) ("d", nil)])func f( s: String?, i: Int?) { ...}このようにタプルで複数引数を渡す場合でも、nilが入ると型が決定できず、そのままではコンパイルできないことがあります。この記事では、...

はじめにこんにちは！TOKIUMでQAチームのリーダーをしている西田です。私たちのチームでは、テスト業務の自動化に取り組んでいます。プロダクトへのE2Eテスト導入にあたってツールの選定を行ったのですが、その過程で Playwright と Vibium という2つのツールを比較検討しました。Playwrightは2020年の登場以来、E2Eテスト自動化のデファクトスタンダードの一つとして広く使われています。Chat GPT公開以降、コーディングの壁がほぼなくなったこともあってE2EテストといえばまずPlaywright！が定番のように思います。一方、Vibiumは、Sele...

2026年も2ヶ月が経過しました。 1月の「カオスな知的探求」に続き、2月もまた、文豪パロディから育児書、そしてシリコンバレー式の思考法まで、バラエティ豊かな5冊と向き合いました。今月は特に「親としての視点」と「プロフェッショナルとしての思考法」が交差する、充実したラインナップとなりました。続きをみる

本記事では、モバイルアプリのE2Eテストツール「Maestro」の、iOSアプリにおける動作の仕組みを、Maestro自体のソースコードから調査・整理する。 MaestroでiOSアプリがテストされる仕組みMaestroでiOSアプリがテストされる大まかな仕組みを説明する。MaestroでE2Eテストを実行する方法としては、Maestro CLIやMaestro Studio、Maestro Cloudなど、複数存在する。ここでは、「Maestro CLI」を使用するケースを例とする。Maestro CLIを使ってiOSアプリをテストする仕組みの概略図を以下に示す。Maes...

結論TDD は事前に設計を決め切るものではないTODO リストは設計の仮説メモとして使うRed-Green-Refactoring のフィードバックの中で再設計の方向性を見出し、育てていくテスト技法は問題の捉え方を与え、次の TODO のヒントになるデザインパターンやリファクタリングは再設計の手段になる 再読前の理解新卒 1~2 年目に「テスト駆動開発」(https://shop.ohmsha.co.jp/shopdetail/000000004967) を買ってから何度か読んではいたものの、TODO リストのうまい作り方、つまりは TDD におけるうまい設...

1. はじめに：なぜテストを書くのか？「テストコードは品質を担保するために書くものだ」教科書にはそう書いてあります。もちろん正論ですが、巨大なRailsモノリスに立ち向かう現場において、その言葉は少し綺麗事すぎるかもしれません。私が実務を通して学んだテストの真の価値。それは品質のためという建前以上に、開発者自身の心を守るためにあります。この記事では、実装ファーストで「絶望」を味わった私が、いかにしてテストコードという「武装」を手に入れ、心理的安全性を確保するに至ったかをお話しします。レガシーコードに怯えている方や、LLMのコード生成に振り回されている方のヒントになれば幸いです...

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

スクラムフェス福岡に初参加しました。多くの方が県外から来ていて驚きました。たくさんの方とお話しできて、もっと勉強しなきゃ、顧客のことを知らなきゃと熱い気持ちになれた2日間でした。写真は初日の2次会で食べた一藤のもつ鍋です、うまかった。挑戦を、楽しめ。 定員割れ高校を変えた「挑戦する文化」のつくり方続きをみる

はじめに以前、「Date.now()をIDに使ったらテストで同じミリ秒に実行されてバグった」という記事を書きました。あのときは「Date.now() + カウンタ」で解決したんですが、最近もっといい方法を見つけたので紹介します。 前回のおさらい：Date.now()の罠IDの生成にDate.now()を使っていたら、テストで複数のデータが同じIDになってしまう問題がありました。const addPet = (petData) => { const newPet = { id: Date.now(), // ← 同じミリ秒で呼ぶと同じIDに！ ....

この記事のポイントPlaywright Test Agentsは強力ですが、 プロジェクト固有のルールが適用されない ため生成コードの品質にバラつきが出ますUbieのQAチームの検証では、if文多用・マジックナンバー・ハードコードされたタイムアウトなどの品質問題が確認されています令和トラベルは Claude Code Skills でルールを注入し、プロダクション品質のテスト生成を実現しましたAI×E2Eテストには3つのレベル（L1補完/L2実行/L3自律）があり、SkillsはL2の弱点を補完する位置づけです Test Agentsに全部任せてみた → 何が起きた...

1. What is this?3/5(木)夜に開催されたセミナー 「テスト設計のAI活用 ～ 期待通りの出力を得るためのコンテキスト設計 ～」 に参加させていただきましたので、レポートを書かせていただきました！続きをみる

背景私が関わるプロジェクトでは、かねてよりJUnitを使ってAPIのテストを行っていたのですが、テストコードの流儀が人ごとに違い、レビューに時間がかかる書き方のコツが暗黙知になり、担当が固定化しやすいAIに任せても出力の品質が安定しないといった課題がありました。そこで、テストコードを極限まで削り、「データ」を中心にテストを実行する仕組みを整え、それをプロジェクトの標準としました。このようなフォルダ構造がテストケースを定めます。テストメソッドは一つのテスト対象APIにこれ一つだけです。@ParameterizedTest(name = "{0}")@TestCas...

はじめに「ファジングテスト」って聞いたことありますか？セキュリティの勉強を始めると、必ず出てくるワードなのですが、実はコンセプト自体は意外とシンプルです。この記事では、ファジングテストの基本を初心者向けにサクッと解説します。著者についてはこちら！https://zenn.dev/mapellion/articles/3dba9b94d8acca ファジングテストとは？ひとことで言うと、ソフトウェアに「めちゃくちゃなデータ」を大量に投げつけて、壊れるポイントを見つけるテスト手法です。英語では Fuzz Testing または Fuzzing と呼ばれます。"Fuzz" ...

こんにちは、SODAでQAエンジニアをしているokauchiです。先日、こちらのイベントでE2Eテスト自動化について登壇しました。https://findy.connpass.com/event/384201/登壇では話しきれなかった部分を、補足する形でブログ記事にしていきたいと思います。https://www.slideshare.net/slideshow/e2e-e2e-fake-real/286318477概ね以下のようなことを話をしました。・E2Eテスト自動化は推進者がいる・推進者の頑張りでテスト自動化が運用（定期的な実行がされる状態になる）・さらにスケールする...

この記事は、2023年7月に等身大のT-Penで公開した記事を、QAを楽しむ者向けにリライトしたものです。等身大のT-Pen今回はちょっと長文になってしまった。でも、いつかは書き残しておきたいと思っていた内容なので、しばしお付き合い頂きたい。続きをみる

こんにちは！MagicPod広報の田上です。 2026年2月27日に開催した「MagicPodミートアップ」の様子をレポートします！1. 初の試み！参加型アイスブレイクセッションに先立ち、今回は初の企画としてメンチメーター（Mentimeter）を使用した参加型のアイスブレイクを実施しました。 スマートフォンを使って、リアルタイムに回答が画面に反映される仕組みに、会場（オンライン）は大いに盛り上がりました。職種：QAエンジニアが最も多かったものの、開発者やカスタマーサクセス、さらにはCEOまで、幅広い層の方々にご参加いただきました。自動化歴：3年〜5年未満の方が中心でしたが、中には10年〜15年以上のベテランもいらっしゃいました。MagicPod利用状況：ほとんどが既に利用中のユーザーさんでしたが、「使ったことはあるが未契約」という検討中の方も3名ほどいらっしゃいました。期待すること：「Autopilotの活用法」「他社の導入事例」、さらには「MagicPodのゆるキャラ」にまで興味が寄せられました。このアイスブレイクを通じて、登壇者の皆さんも「どんな層が聞いているか」を把握でき、リラ

品質課題は、なぜ同じ組織で繰り返されるのでしょうか。改善策は提示され、ルールも整備されている。それでも、似たような問題が再発してしまう。その背景には、単なるプロセス不備ではなく、組織の構造や意識のあり方が潜んでいるケースが少なくありません。ポールトゥウィンが誇るQAのプロフェッショナル集団「Q-Force」は、これまで数多くの現場に第三者の立場で参画し、品質改善を支援してきました。ひとことで“品質課題”と言っても、その内容は組織やプロジェクトにより千差万別ですが、共通する点も見出すことができます。続きをみる