QAとの観点共有はどこで起きるか

はじめに今回取り上げたいのはQAメンバーとの観点共有についてです。新機能をどんな観点でテストするか、テストデータや環境をどう揃えるか、探索的テストで見つかった観点をどう活かすか。こうした問いは開発チームとQAチームが言葉を交わす中で答えが立ち上がってくるものです。本記事ではそ

V字モデルを語彙として持つ — AI時代のジュニアエンジニアに伝えたいこと

はじめに本記事は、テストコードとAIをめぐるシリーズの10本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはV字モデル。要件・基本設計・詳細設計・実装と進む左側の流れと、単体テスト・結合テスト・受入テストと進む右側の流れを、Vの字に対応

ピラミッドの形に捕らわれず、何を守るかを問う — テスト戦略の見直し

はじめに本記事は、テストコードとAIをめぐるシリーズの9本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはテストピラミッド。Mike Cohn が提唱したことで知られる「ユニットを多く、統合を中ぐらい、E2Eを少なく」という階層構造の話

カバレッジ100%の先にある問い — ミューテーションテストを学ぶ

はじめに本記事は、テストコードとAIをめぐるシリーズの8本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはミューテーションテスト。1作目「AI時代にバックエンドエンジニアが磨くべきテスト設計力」の第4章で、私は次のように書きました。

フレーキーテストの正体と向き合い方 — ReRunで凌いでいた自分がいま考えていること

はじめに本記事は、テストコードとAIをめぐるシリーズの7本目です。前作「テスト名は仕様の1行 — AIに命名を任せられる環境を作るまで」と同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはフレーキーテスト(flaky test)、同じコードに対して、CIで

テスト名は仕様の1行 — AIに命名を任せられる環境を作るまで

はじめに本記事は、テストコードとAIをめぐるシリーズの6本目です。1〜5本目では「AI時代に、エンジニアの設計判断はどこに残るか」という問いを軸に、テスト設計力、ドキュメントとしてのテスト、人間が先に仕様を設計する作法、QA技法、フロントエンドテスト実践記まで扱ってきました。

【第2部】AIが書いたフロントエンドのテスト、抜け漏れは誰が拾うのか

はじめに本記事は3部構成の第2部です。第1部では、フロントエンドにテストを導入することになった経緯、Vitestの選定とスコープ定義、そして「テストを入れる、とはどういうことか」への暫定的な答えとして、観点を持つこととコードの外側の情報を内側に畳み込むことという二つの側面を書き

【第3部】AIが書いたテスト、どう評価するか — カバレッジ70%とQA技法で測る

はじめに本記事は3部構成の最終回、第3部です。第1部では、フロントエンドにテストを導入した経緯とVitestの選定、そして「テストを入れる、とはどういうことか」への暫定的な答え(観点を持つこと、コードの外側の情報を内側に畳み込むこと)を書きました。第2部では、AIエージェン

【第1部】フロントエンドにテストを入れる、とはどういうことか 🔖 2

はじめに本記事は、バックエンドエンジニアとして9年目を迎えた私が、フロントエンドのテスト導入をチームでリードすることになってからの1ヶ月間を振り返る実践記です。VitestとAIエージェント(Cursor、Claude Code)を組み合わせてテストを書き進めるなかで、何がうま

【後編】そのテスト、どう設計した? — カバレッジ100%問題への応答 🔖 2

はじめに本記事は前後編の後編です。前編では、開発者が知っているとテスト設計の思考が変わる5つのQA技法を紹介しました。同値分割と境界値分析、状態遷移テスト、デシジョンテーブル、ペアワイズ法、そして探索的テスト。それぞれが「そのテスト、どう設計した?」という問いに具体的な答え方

【前編】そのテスト、どう設計した? — 開発者が学び始めた5つの武器

はじめにテストコードは書けるけれど、「そのテスト、どう設計したの?」と問われると言葉に詰まる。「なんとなく網羅しました」以上の答えが出てこない。そんなもどかしさを感じたことはないでしょうか。本記事は、そのもどかしさに向き合うためのQA技法を、開発者の視点から5つ取り上げて紹介

"このテストが落ちたら何のバグを検出したことになる?" AI時代にバックエンドエンジニアが磨くべきテスト設計力

はじめに本記事は、テストコードとAIをめぐるシリーズの1作目です。AIエージェントによるコード生成が当たり前になった今、テストコードもAIに任せる場面が増えました。便利で助かる一方、その出力に対して漠然とした違和感を抱いたことがある方も多いのではないでしょうか。本記事ではその

"このテストが落ちたら何を検出したことになる?" — テストを"仕様の実行可能なドキュメント"として読み直す 🔖 1

はじめに前作「"このテストが落ちたら何のバグを検出したことになる?" AI時代にバックエンドエンジニアが磨くべきテスト設計力」では、AI生成テストの質を底上げするための問いを紹介しました。本記事はその問いをより開いた形に拡張し、テストコードの別の顔に光を当てます。前作の問いが

AIにテストコードを書かせる前に、人間が仕様を設計する — TDDとDDDの原則をAI時代に活かす

はじめに本記事は、テストコードとAIをめぐるシリーズの3本目です。前々作「"このテストが落ちたら何のバグを検出したことになる?" AI時代にバックエンドエンジニアが磨くべきテスト設計力」では、AI生成テストの質を評価する問いを紹介しました。前作「"このテストが落ちたら何を検出

設計ツールとして扱う「抽象の梯子」の話

はじめに設計がうまくできない全体像がぼやける局所的な対応ばかりになるこうした悩みの背景には、「抽象化」の技術や姿勢が未整理なまま設計に向き合っていることがあります。本記事では、設計の本質を理解する鍵となる概念「抽象の梯子（ladder of abstraction）

軽量＆高速なCSV処理！csv-parserのNode.js/Next.jsでの活用法まとめ

csv-parserとはNode.jsでCSVファイルを読み込むときに使用するNode.jsライブラリです。軽量でストリームベースで動作するのでファイルの容量が大きいものでもメモリ効率良く処理できます。通常、Node.jsでCSVを処理する際はJSONに変換する処理が必要に