収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
新規サービスの品質計画を作る際、最初に行うべきことはどれですか？
答え： 利用者・事業・技術の品質リスクを整理して優先順位を決める
品質活動は、障害時の影響と発生可能性を含むリスクに応じて配分します。品質目標、対象、技法、環境、完了基準は、その優先順位から具体化します。
単体・結合・システム・受入テストを分ける主な理由はどれですか？
答え： 対象と目的を変えて部品から業務価値まで異なる失敗を検出するため
各テストレベルは対象と目的が異なります。単体は部品、結合は接続、システムは全体の振る舞い、受入は利用者・事業要求への適合を確認します。
テストピラミッドの考え方に最も合う構成はどれですか？
答え： 高速な単体テストを厚くし結合・E2Eは重要経路に絞る
高速で原因を特定しやすい下位テストを多くし、遅く壊れやすい上位テストは重要な統合・利用者経路へ絞ると、速度と信頼性を両立しやすくなります。
年齢18歳以上65歳以下を受け付ける入力へ同値分割を適用する。代表クラスの組合せはどれですか？
答え： 17以下、18から65、66以上の3クラス
同値分割では、同じ振る舞いを期待する入力領域を有効・無効クラスへ分け、各クラスから代表値を選びます。境界そのものの確認は境界値分析で補います。
数量1から99が有効な項目を境界値分析する。最も適切な値の組合せはどれですか？
答え： 0、1、2、98、99、100の6値
境界値分析は、下限・上限の直前、境界、直後を重点的に確認します。範囲判定の比較演算子やオフバイワンの誤りを効率よく検出できます。
会員種別、購入金額、クーポン有無の組合せで割引率が変わる。適したテスト技法はどれですか？
答え： デシジョンテーブルテストで条件の組合せを確認する
複数条件の組合せと、それに対応する結果を表にすると、ルールの欠落・矛盾・未テスト組合せを整理できます。
注文が受付済み、支払済み、発送済み、取消済みへ変化し、状態ごとに許可操作が異なる。適した技法はどれですか？
答え： 状態遷移テストで状態ごとの操作を確認する
状態遷移テストは、現在状態、イベント、遷移先、許可・禁止動作を確認します。無効遷移や特定順序でだけ起きる欠陥にも有効です。
OS、ブラウザ、言語、権限の全組合せが多すぎる。少数で相互作用を広く確認する技法はどれですか？
答え： ペアワイズ法で2因子の組合せを網羅する
ペアワイズ法は、全組合せを大幅に減らしながら、任意の2因子の値の組を少なくとも一度含めます。重大リスクの組合せは別途明示的に追加します。
探索的テストを効果的に実施する方法はどれですか？
答え： チャーターと時間枠を決め学習・設計・実行を並行して証跡を残す
探索的テストは無計画な操作ではありません。探索目的を示すチャーター、時間枠、観察記録、発見事項と未確認領域の共有によって再現性と説明可能性を高めます。
リスクベースドテストで優先度を決める際、最も重要な情報はどれですか？
答え： 障害の発生可能性と利用者・事業への影響
リスクは一般に発生可能性と影響度から評価します。変更量、複雑性、過去欠陥、利用頻度、金銭・安全・法令影響などを根拠に優先順位を更新します。
要求からテスト結果までのトレーサビリティを持つ主な利点はどれですか？
答え： 要求ごとの検証状況と変更の影響範囲を追跡できる
要求、設計、テスト条件、ケース、結果、欠陥を関連付けると、未検証要求、変更時の回帰範囲、リリース判断の根拠を確認できます。
良い受入基準の特徴はどれですか？
答え： 利用条件・操作・観測可能な結果を具体的に書く
受入基準は関係者の共通理解とテストオラクルになります。曖昧な形容詞ではなく、例や測定値を含む観測可能な振る舞いとして合意します。
要求仕様レビューで『速やかに応答すること』という記述を見つけた。最も適切な対応はどれですか？
答え： 対象操作・負荷条件・測定区間・許容応答時間を明確にする
曖昧な非機能要求は、測定対象、条件、指標、閾値を定義して検証可能にします。静的レビューで早期に見つけるほど手戻りを減らせます。
再現しにくい欠陥を報告するとき、最も有用な情報はどれですか？
答え： 環境・ビルド・前提状態・操作・期待と実際の結果・ログ
再現性が低いほど、実行条件と観測証跡が重要です。時刻や相関IDは分散ログ・トレースとの照合を助け、発生条件の絞り込みに使えます。
欠陥の重大度と優先度の違いとして正しいものはどれですか？
答え： 重大度は影響の大きさ、優先度は事業状況を含む緊急性を示す
重大度は障害が利用者・システムへ与える影響、優先度はいつ修正するかの判断です。公開時期、回避策、利用頻度、契約などで組合せは変わります。
同じ種類の本番欠陥が繰り返される。品質保証として有効な対応はどれですか？
答え： 原因分類と流出工程を分析しレビュー観点や自動検査へ反映する
品質保証は個別製品の検出・修正だけでなく、再発しにくいプロセスを作ります。なぜ作り込まれ、なぜ早期工程で検出できなかったかを分けて改善します。
変更後の回帰テスト範囲を決める最も適切な方法はどれですか？
答え： 依存関係・利用経路・過去欠陥から影響範囲と重要経路を選ぶ
回帰範囲はコード差分だけでなく、契約、共有データ、設定、下流利用者への波及を含めて決めます。高速な全自動テストがあれば併用し、重要経路を落とさないようにします。
デプロイ直後に主要機能が最低限動くか短時間で確認したい。適したテストはどれですか？
答え： 主要機能を短時間で確認するスモークテスト
スモークテストは、ビルドやデプロイが詳細テストに進める最低限の安定性を持つか、主要経路を短時間で確認します。
期待結果を決めるテストオラクルとして最も信頼できるものはどれですか？
答え： 要求・業務規則・標準から独立して導いた期待結果
実装と独立した根拠から期待結果を作らないと、同じ誤解をテストへ写してしまいます。複雑な計算では別実装、既知例、性質による検証も組み合わせます。
本番相当の個人情報をテスト環境で使う必要がある。最も適切な対応はどれですか？
答え： 目的を限定し合成データか不可逆な匿名化を使い権限を管理する
テストデータでも最小化、目的制限、アクセス制御、保管期限、削除を適用します。参照整合性や分布を保つ合成データを優先し、実データ利用は必要性と法的根拠を確認します。
テスト環境と本番環境の差による見逃しを減らす方法はどれですか？
答え： IaCやコンテナで構成を版管理し差分を可視化して再現する
環境構成をコード化し、OS、ランタイム、依存、設定、外部サービス契約の差を追跡すると、再現性を上げられます。本番秘密情報はコピーせず安全に差し込みます。
CIで時々だけ失敗するテストを改善する最初の対応はどれですか？
答え： 失敗時のログとシードを保存し共有状態や非同期待機を切り分ける
不安定テストは信頼を損ない、本物の回帰を隠します。証跡を残して再現条件を特定し、固定スリープではなく状態待機、時刻注入、データ分離などで決定的にします。
並列実行すると互いに失敗させる統合テストを分離する方法はどれですか？
答え： テストごとに一意なデータと名前空間を用意し後処理を行う
テストは順序や他テストの残存状態に依存させません。一意ID、トランザクション、専用スキーマ、使い捨てコンテナなどを対象に応じて使います。
外部決済APIをMockした単体テストだけでは不足する主な理由はどれですか？
答え： 想定した契約は通っても実際のスキーマや状態のずれを検出できないから
Mockは自コンポーネントの分岐を速く確認できますが、誤った前提も再現します。契約テスト、サンドボックスでの統合テスト、少数のE2Eで実際の境界を補います。
コンシューマー駆動契約テストの主な目的はどれですか？
答え： コンシューマーの依存を契約化しプロバイダー変更で壊れないか検証する
コンシューマーが必要とするリクエスト・レスポンス例や制約を契約として共有し、プロバイダーのCIで検証します。未使用機能の完全再現ではなく、利用中の互換性を早期確認します。
UI自動テストの要素指定を保守しやすくする方法はどれですか？
答え： ロールやラベルを優先し必要なら安定したdata属性を使う
利用者が操作する意味に近いLocatorはアクセシビリティも検証し、構造変更へ比較的強くなります。専用data属性は意味で特定できない要素に限定します。
非同期UIテストで固定の5秒スリープを多用すると起こる問題と改善策はどれですか？
答え： 短いと失敗し長いと遅いので必要な状態を条件付きで待つ
固定待機は実行環境の速度差に弱く、遅延と不安定性を同時に生みます。観測可能な完了条件を適切なタイムアウト付きで待つと、早く決定的になります。
Property-Based Testingが例示ベースのテストを補完する点はどれですか？
答え： 大量の入力で常に成立すべき性質を検証し最小反例を探せる点
個別例だけでは思いつきにくい境界・組合せを生成し、逆変換、順序不変、範囲制約などの性質で検証します。重要な具体例は別途残します。
Mutation Testingで分かることはどれですか？
答え： ソースへ入れた小さな誤りをテストが検出できるかどうか
演算子や条件を意図的に変えたMutantがテストを通るなら、実行されていても結果を十分に検証していない可能性があります。等価Mutantは分析時に考慮します。
コードカバレッジが100%なら欠陥がないと言えない理由はどれですか？
答え： 実行の有無は示すがアサーションの妥当性や欠落要求は保証しないから
カバレッジは未実行領域を見つける補助指標です。期待結果が弱いテストでも行は通り、仕様から漏れた機能はコード自体がないため測定対象にも現れません。
想定ピーク負荷で応答時間と処理量が目標を満たすか確認するテストはどれですか？
答え： 想定ピークで応答と処理量を測る負荷テスト
負荷テストは予想される通常・ピーク条件で性能目標を確認します。ストレステストは能力限界を超えて劣化・破綻・回復を調べます。
平均応答時間は良好だが、一部利用者だけ極端に遅い。確認すべき指標はどれですか？
答え： p95・p99のパーセンタイルと分布を負荷条件別に確認する
平均は少数の遅い応答や分布の形を隠します。Percentile、ヒストグラム、エラー率、処理量を時系列と負荷段階で合わせて確認します。
セキュリティテストをShift Leftする実践として適切なものはどれですか？
答え： 脅威分析・セキュアコーディングレビュー・SASTを早期CIへ組み込む
早期活動は修正費用を下げますが、一つのツールで十分ではありません。設計・コード・依存・ランタイムを異なる技法で確認し、秘密情報は安全に注入します。
アクセシビリティテストとして最も適切な組合せはどれですか？
答え： キーボード操作・フォーカス順・コントラストを自動と手動で確認する
自動検査は一部の機械判定可能な問題を効率よく見つけますが、操作順、文脈に合う名前、読み上げ体験などは手動確認が必要です。
ユーザビリティテストで有効な観察方法はどれですか？
答え： 対象利用者に現実的な課題を頼み誘導せずに観察する
代表的利用者が現実的な目的を達成する過程を観察し、成功率、時間、誤操作、理解、満足度を収集します。介入した場合は記録して結果を分けます。
障害復旧機能のテストで最も重要な確認はどれですか？
答え： 障害注入後の検知・切替・整合性・復旧時間を確認する
復旧性は実際の障害条件でEnd-to-Endに検証します。RTO・RPO、切替中の処理、重複・欠損、復旧後の監視解除まで確認します。
リリース品質ゲートとして適切な条件はどれですか？
答え： 重大リスクの結果・未解決欠陥・残余リスクと承認を確認する
品質ゲートは単一件数ではなく、事前合意したリスク別の証拠と残余リスクで判断します。例外承認には理由、期限、回避策、責任者を残します。
欠陥除去効率（DRE）を改善に使う際の適切な見方はどれですか？
答え： 流出を含む発見工程を見て早期検出施策の効果を傾向で評価する
流出を含む検出工程の傾向は、レビューやテスト改善の効果を見る手掛かりです。分類基準、重大度、開発規模、計測期間を揃え、指標操作を招かないよう複数指標で見ます。
品質ダッシュボードで避けるべき指標の使い方はどれですか？
答え： テストケースの実行数だけを品質そのものとして目標化する
活動量だけを目標にすると、細かいケース分割や低価値テスト増加を誘発します。利用者成果、リスク、検出力、安定性など複数の観点で意思決定を支援します。
テストを通過した変更を安全に本番へ出すための方法はどれですか？
答え： 段階公開して指標とガードレールを監視し異常時は切り戻す
事前環境では本番のデータ・負荷・依存を完全再現できません。カナリアやフィーチャーフラグで曝露を制限し、エラー率、遅延、業務KPIを比較して継続判断します。
レガシーシステムを大規模リファクタリングする前に、仕様書にない現在挙動を壊していないことを確認したい。適切なテストはどれですか？
答え： 現在の入出力を特性テストとして固定し意図的な変更だけ見直す
Characterizationテストは既存システムが実際に行う挙動を安全網として記録します。不具合らしい挙動も無断変更せず、仕様判断と影響確認を経て更新します。
現在時刻とランダム値に依存する単体テストが時々失敗する。適切な設計はどれですか？
答え： クロックと乱数生成を依存として注入し固定値やシードで制御する
非決定的な外部入力を境界へ切り出すと、境界時刻、期限切れ、ランダム分岐を再現可能に検証できます。シードは失敗報告にも記録します。
外部サービスのテストダブルで、実際に近い軽量実装をメモリ上に持ち、状態を使ったテストをしたい。適切な種類はどれですか？
答え： 軽量な実装を持つフェイク
フェイクは本番向けではない簡略実装ですが、動作する機能と状態を持ちます。Dummyは値を埋めるだけ、Spyは呼出し記録、Stubは用意したレスポンスを返す用途です。
ローリングデプロイと同時にデータベースマイグレーションを行うテストで、最も重要な互換性確認はどれですか？
答え： 旧・新アプリが移行途中のスキーマを同時に使えること
ローリングデプロイではバージョン混在期間があります。実データ量に近い環境でExpand-and-contract、ロック時間、再実行、部分失敗、旧バージョンへの影響を検証します。
公開APIのレスポンスへ任意フィールドを追加する。後方互換性テストとして適切なのはどれですか？
答え： 旧クライアントが未知フィールドを処理でき新クライアントも欠落時を扱える
分散配信ではクライアントとサーバーのバージョンがずれます。コンシューマーマトリクスと契約テストで少なくとも旧新の交差組合せを確認します。
短時間の性能テストは通るが、数時間後にメモリとレイテンシが悪化する。適切なテストはどれですか？
答え： 想定負荷を長時間続けてヒープやGCの傾向を見るソークテスト
Soakテストはリーク、プール枯渇、キャッシュ肥大、ログ蓄積など時間依存の劣化を見つけます。定常状態と終了後の回復も評価します。
オートスケーリングが急激なトラフィック増加へ追随できるか確認したい。適切な性能テストはどれですか？
答え： 負荷を急増・急減させるスパイクテストで遅延と回復を測る
スパイクテストは検知、プロビジョニング、ウォームアップの遅れと、Scale-in後の安定性を確認します。Stressテストは限界や破壊時挙動を調べる別目的です。
在庫引当でまれに更新消失が起こる。並行性テストとして有効な方法はどれですか？
答え： バリアで読取と更新を意図的に重ねて反復し不変条件を検証する
競合状態はタイミング依存です。競合ウィンドウを同期機構で広げ、シード、Schedule、トランザクションIDを記録し、在庫非負などの不変条件を検証します。
JSONパーサーを想定外入力で壊れにくくしたい。Fuzz Testingとして適切なのはどれですか？
答え： 入力を自動変異させクラッシュやハングを監視し失敗入力を縮小する
ファジングは大量の生成・変異入力から境界欠陥を探索します。コーパス、シード、タイムアウト、サニタイザーを使い、発見した最小ケースを通常テストへ加えます。
正解値を直接計算しにくい画像変換処理をテストしたい。Metamorphic Testingの例として適切なのはどれですか？
答え： 360度回転した結果が元画像と許容差内で一致することを検証する
Metamorphic Testingは個別の正解が不明でも、入力変換前後に成立すべき関係をオラクルとして使います。数値Toleranceや適用条件を明示します。
確率的なAI分類機能のリリース判定として適切な受け入れ基準はどれですか？
答え： 独立データで適合率・再現率の閾値と信頼区間を定義する
AI出力は統計的に評価します。利用用途の損失に合うメトリクス、独立テストSet、サンプル数、信頼区間、サブグループ別性能、非機能安全性をリリース前に合意します。
巨大なリグレッションスイートの実行時間を短縮するテスト影響分析として適切なのはどれですか？
答え： 変更ファイルと依存関係から優先テストを選び定期的にフルで監査する
影響分析はリスクに基づき速いフィードバックを返しますが、マッピング誤りによる見逃しがあります。フル実行、ランダムサンプリング、本番欠陥から精度を継続評価します。
不安定なテストを一時隔離する際の適切な運用はどれですか？
答え： オーナーと期限を設定し可視化したまま原因を直してゲートへ戻す
隔離はフィードバック信頼性を守る短期措置で、修正の代替ではありません。Flake率、影響範囲、期限超過をダッシュボードで管理します。
静的解析導入時に既存警告が数万件あり、新規欠陥が埋もれる。適切な改善はどれですか？
答え： 既存警告をベースライン化しリスク順に減らし新規コードは増加を防ぐ
Clean-as-you-codeとリスクTriageにより、新規Debtを止めつつレガシー負債を管理可能に減らします。Suppressionには理由、範囲、期限を持たせます。
プルリクエストレビューで欠陥検出力を高める方法はどれですか？
答え： 変更を小さく保ちリスク別の観点で作者の説明とテスト証拠を確認する
Staticレビューは早期欠陥検出に有効です。小さい差分、明確な目的、リスク観点、独立した視点、確認可能なテスト結果がレビュー品質を高めます。
本番へ流出した欠陥の分析として、再発防止につながる方法はどれですか？
答え： 混入・未検出・流出の段階に分けて制御のギャップを特定する
欠陥エスケープは作り込み原因と検出制御の両方を分析します。個別回帰テストに加え、同型欠陥を早期に防ぐプロセス・設計改善へつなげます。
品質コストを改善する投資判断として適切なのはどれですか？
答え： 本番失敗コストが高い領域へ予防・評価のコストを配分する
品質コストは予防、評価、内部失敗、外部失敗を総合します。全欠陥除去を狙うのではなく、事業リスクと失敗コストに対し投資効果を最適化します。
アクセシビリティ自動スキャンが0件ならWCAG準拠と言い切れない理由はどれですか？
答え： 自動判定できない基準がありキーボードや認知面は手動評価が要るから
アクセシビリティ評価は自動・半自動・手動テストを組み合わせます。実際の支援技術と障害当事者を含むUsability評価が、機械判定できない問題を補います。
本番で合成テストを実行する際、安全な設計はどれですか？
答え： 専用アカウントと識別可能なデータを使い副作用を限定して清掃する
合成監視は利用者経路を継続確認できますが、本番副作用を持ちます。専用アイデンティティ、低頻度、データラベル、クリーンアップ、コスト上限、セキュリティレビューを設計します。
『品質はQAチームだけの責任』という体制で欠陥修正がリリース直前に集中する。適切な改善はどれですか？
答え： プロダクト・開発・運用・QAが品質リスクと完了条件を共有する
Whole-team Approachでは品質を要求、設計、実装、運用まで組み込みます。QAはテスト専門性とリスク可視化を提供しますが、品質判断と改善はチーム全体が所有します。
Playwright Testで expect(locator).toHaveText("完了") を呼びましたが、awaitを付けていません。検証完了前にテストが終わる問題を防ぐ修正はどれですか？
答え： 非同期アサーションをawaitし、その完了を待つ
toHaveTextは条件の成立を待つ非同期アサーションです。await expect(locator).toHaveText(...) として、成否が決まるまでテスト処理を待たせます。async関数にするだけでは、個々のPromiseの完了は待ちません。
保存ボタンを押した直後に「エラー表示がない」とだけ確認したテストが、後から保存失敗になる画面でも通りました。改善として適切なのはどれですか？
答え： 保存完了の状態を待ち、保存内容とエラー有無を確認する
処理開始直後の不在は、処理成功を意味しません。完了通知や保存結果などの観測可能な条件を待ち、その後に期待値を検証します。固定時間の経過だけでは完了の証明になりません。
UI変更後に多数のスナップショットテストが失敗しました。リリースを急ぐ場合でも、基準画像や期待ファイルの更新前に必要なのはどれですか？
答え： 差分を意図した変更と照合し、承認した変更だけを更新する
スナップショット更新は現在の出力を新しい期待値として承認する行為です。レイアウト崩れや文言欠落を混ぜて承認しないよう、差分を確認し、意図しない変更は実装側を修正します。
CIで初回失敗したテストが自動再試行では成功しました。最終結果だけを成功として集計すると、どの問題がありますか？
答え： 初回の不安定さが隠れ、原因調査や悪化の検知が遅れる
再試行は一時的な失敗の影響を和らげても原因を除去しません。初回成功率と再試行で救済された件数を分け、最初の失敗ログやトレースを残して調査します。
if (a && b) の判定で、テスト入力は(a=true,b=true)と(a=false,b=false)だけです。判定全体の真・偽を通っていても不足する確認はどれですか？
答え： aが真でbが偽の場合の、bによる不成立を確認する
判定全体の分岐を網羅しても、個々の条件を十分に検証したとは限りません。短絡評価ではaが偽のときbが評価されないため、この2件ではbが偽として評価される経路が欠けます。
OS・ブラウザ・認証方式の全ペアを網羅したテストが通りました。しかし特定の三つが同時に組み合わさった場合だけ不具合が出ます。適切な理解と対応はどれですか？
答え： ペア網羅では三要因を保証せず、該当組合せを追加検証する
ペアワイズは2要因の組合せを網羅する技法で、すべての3要因相互作用を保証しません。障害を回帰ケースに追加し、リスクに応じて3-wayなどの組合せ強度を検討します。
Mutation Testingで残った変異について、許可された全入力で元の実装と同じ観測結果になると確認できました。扱いとして適切なのはどれですか？
答え： 等価変異として根拠を記録し、検出可能な変異と区別する
許可入力で観測可能な違いがない等価変異は、正しいテストで区別できません。等価性の根拠をレビューして扱いを明示します。単に生存しただけの変異を等価と決めつけてはいけません。
負荷テストで各仮想ユーザーが応答を待ってから次を送ると、サーバー遅延時に到着要求数も減りました。毎秒100件の流入が続く状況を検証する改善はどれですか？
答え： 到着率ベースのモデルを使い、未開始処理や生成能力も監視する
閉鎖モデルでは応答遅延が次の送信を遅らせます。到着率を独立させる開放モデルで対象負荷を与え、負荷生成側の資源不足や開始できなかった反復も確認します。
入力仕様は「UTF-8で最大12バイト」です。ASCIIだけで12文字と13文字を試すテストに追加すべきケースはどれですか？
答え： 日本語などを含め、符号化後のバイト数で境界を確認する
UTF-8では文字によって必要なバイト数が異なります。たとえば「あ」は3バイトなので4個で12バイト、5個で15バイトです。12バイト直前・一致・直後になる混在文字列も使い、文字数と混同しないことを検証します。
税額計算のテストで、期待値も本番と同じ計算関数を呼んで作っています。本番関数に丸めの誤りがあってもテストが通る問題への改善はどれですか？
答え： 合意した仕様から独立に求めた期待値と境界ケースを使う
同じ実装で期待値を作ると、同じ誤りを両側で共有します。仕様上の丸め規則や具体例から独立に期待値を求め、端数の境界を検証します。期待値を作る側にもレビューが必要です。