Blog

テストの層（どこで守るか）

• ユニットテスト：関数/クラス単位（速い・安い）
• 統合テスト：API/DB/外部連携（中間コスト）
• E2Eテスト：画面操作まで（遅い・壊れやすい）

現場でよく採用される方針

• 基本はユニット＋統合で守り、E2Eは最小限にする
• 重要フロー（ログイン/購入/申請）だけE2Eで守る
• テストデータと環境を整えて再現性を担保する

自動化の成功は、「速度」「安定」「原因追跡」の3つで決まります。

よくある誤解（失敗パターン）

• 「E2Eを大量に書けば安心」→ ❌（遅い・壊れる・メンテ地獄）
• 「ツールを入れれば終わり」→ ❌（運用/データ/環境設計が本体）
• 「自動化＝手動テスト不要」→ △（探索テストは人の強み）
• 「テストは後で」→ ❌（後回しほどコストが爆増）

自動化は“量”ではなく、守るポイントの設計がすべてです。

① 自動化戦略（どこを守るか決める）

• 品質リスクの整理（壊れたら痛い機能）
• テストピラミッド設計（ユニット/統合/E2Eの比率）
• 自動化対象の選定（ROIが高い箇所から）

② テスト実装（書く・作る）

• ユニット/統合テストの実装
• APIテスト（契約テスト含む）
• E2Eテスト（重要フローのみ、安定優先）

③ CI/CD組み込み（回る仕組み化）

• PR/マージ時に自動実行
• 並列化・キャッシュで高速化
• 失敗時の通知（Slack等）・レポート生成

④ 運用・改善（壊れない・速い・追える）

• フレーク対策（不安定テストの撲滅）
• テストデータ/環境の整備
• ログ/スクショ/動画で原因追跡

例：Webサービス（週次リリース）の場合

• 9:30：昨夜のCI失敗を確認（原因/再現）
• 11:00：重要フローE2Eの安定化（フレーク潰し）
• 13:30：新機能の受入条件を整理（テスト観点）
• 16:00：統合テスト追加（API契約・境界値）
• 18:00：レポート整備（失敗時の証跡を強化）

特徴：新規作成より、安定運用と改善の比率が高いです。

• PRのたびに自動テストが回っている
• 重要フローの自動テストがある（最小でもOK）
• 失敗時に原因が追える（ログ/スクショ/動画）
• フレークを放置していない（ルールがある）
• テストデータ/環境が再現性を持っている

2つ以下なら、まずCIで安定稼働から整えるのがおすすめです。

必須になりやすい領域

• テスト設計（観点・境界値・リスクベース）
• プログラミング基礎（読み書き・リファクタ）
• API/DB基礎（HTTP・SQL・データ設計）
• CI/CD（パイプライン、並列化、実行速度）
• デバッグ力（ログ・再現手順・原因切り分け）
• テスト容易性（作りやすい設計を促す）

評価されやすいカテゴリ

• ソフトウェアテスト基礎（テスト設計の体系）
• クラウド/DevOps（CI/CDの運用理解）
• 品質・プロセス（変更管理、レビュー文化）

“資格だけ”より、CIで毎回回ってる実績が強いです。

おすすめの順番（現実的ルート）

• 再現性のある仕組み作りが好き
• 原因を切り分けるのが得意
• “壊れない運用”を地道に続けられる
• 開発とQAの間をつなぐ調整ができる

• テスト自動化 → QAエンジニア（品質設計）
• テスト自動化 → Developer Productivity（開発効率）
• テスト自動化 → DevOps/SRE（運用自動化）
• テスト自動化 → テストアーキテクト