収録問題 40問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
新規サービスの品質計画を作る際、最初に行うべきことはどれですか？
答え： 利用者・事業・技術上の品質リスクを整理し、優先順位を決める
品質活動は、障害時の影響と発生可能性を含むリスクに応じて配分します。品質目標、対象、技法、環境、完了基準は、その優先順位から具体化します。
単体・結合・システム・受入テストを分ける主な理由はどれですか？
答え： 対象と目的を変え、部品から業務価値まで異なる失敗を検出するため
各テストレベルは対象と目的が異なります。単体は部品、結合は接続、システムは全体の振る舞い、受入は利用者・事業要求への適合を確認します。
テストピラミッドの考え方に最も合う構成はどれですか？
答え： 高速な単体テストを厚くし、結合・E2Eは重要経路へ絞る
高速で原因を特定しやすい下位テストを多くし、遅く壊れやすい上位テストは重要な統合・利用者経路へ絞ると、速度と信頼性を両立しやすくなります。
年齢18歳以上65歳以下を受け付ける入力へ同値分割を適用する。代表クラスの組合せはどれですか？
答え： 17以下、18から65、66以上
同値分割では、同じ振る舞いを期待する入力領域を有効・無効クラスへ分け、各クラスから代表値を選びます。境界そのものの確認は境界値分析で補います。
数量1から99が有効な項目を境界値分析する。最も適切な値の組合せはどれですか？
答え： 0、1、2、98、99、100
境界値分析は、下限・上限の直前、境界、直後を重点的に確認します。範囲判定の比較演算子やオフバイワンの誤りを効率よく検出できます。
会員種別、購入金額、クーポン有無の組合せで割引率が変わる。適したテスト技法はどれですか？
答え： デシジョンテーブルテスト
複数条件の組合せと、それに対応する結果を表にすると、ルールの欠落・矛盾・未テスト組合せを整理できます。
注文が受付済み、支払済み、発送済み、取消済みへ変化し、状態ごとに許可操作が異なる。適した技法はどれですか？
答え： 状態遷移テスト
状態遷移テストは、現在状態、イベント、遷移先、許可・禁止動作を確認します。無効遷移や特定順序でだけ起きる欠陥にも有効です。
OS、ブラウザ、言語、権限の全組合せが多すぎる。少数で相互作用を広く確認する技法はどれですか？
答え： ペアワイズ法で因子間の2因子組を網羅する
ペアワイズ法は、全組合せを大幅に減らしながら、任意の2因子の値の組を少なくとも一度含めます。重大リスクの組合せは別途明示的に追加します。
探索的テストを効果的に実施する方法はどれですか？
答え： チャーターと時間枠を決め、学習・設計・実行を並行し証跡を残す
探索的テストは無計画な操作ではありません。探索目的を示すチャーター、時間枠、観察記録、発見事項と未確認領域の共有によって再現性と説明可能性を高めます。
リスクベースドテストで優先度を決める際、最も重要な情報はどれですか？
答え： 障害の発生可能性と、利用者・事業への影響
リスクは一般に発生可能性と影響度から評価します。変更量、複雑性、過去欠陥、利用頻度、金銭・安全・法令影響などを根拠に優先順位を更新します。
要求からテスト結果までのトレーサビリティを持つ主な利点はどれですか？
答え： 要求ごとの検証状況と変更影響を追跡できる
要求、設計、テスト条件、ケース、結果、欠陥を関連付けると、未検証要求、変更時の回帰範囲、リリース判断の根拠を確認できます。
良い受入基準の特徴はどれですか？
答え： 利用条件、操作、観測可能な結果を具体的かつ検証可能にする
受入基準は関係者の共通理解とテストオラクルになります。曖昧な形容詞ではなく、例や測定値を含む観測可能な振る舞いとして合意します。
要求仕様レビューで『速やかに応答すること』という記述を見つけた。最も適切な対応はどれですか？
答え： 対象操作、負荷条件、測定区間、許容応答時間を明確にする
曖昧な非機能要求は、測定対象、条件、指標、閾値を定義して検証可能にします。静的レビューで早期に見つけるほど手戻りを減らせます。
再現しにくい欠陥を報告するとき、最も有用な情報はどれですか？
答え： 環境、ビルド、時刻、前提状態、操作、期待・実際結果、ログや相関ID
再現性が低いほど、実行条件と観測証跡が重要です。時刻や相関IDは分散ログ・トレースとの照合を助け、発生条件の絞り込みに使えます。
欠陥の重大度と優先度の違いとして正しいものはどれですか？
答え： 重大度は影響の大きさ、優先度は事業状況を含む修正の緊急性を示す
重大度は障害が利用者・システムへ与える影響、優先度はいつ修正するかの判断です。公開時期、回避策、利用頻度、契約などで組合せは変わります。
同じ種類の本番欠陥が繰り返される。品質保証として有効な対応はどれですか？
答え： 原因分類と流出工程を分析し、レビュー観点・設計規約・自動検査へ予防策を反映する
品質保証は個別製品の検出・修正だけでなく、再発しにくいプロセスを作ります。なぜ作り込まれ、なぜ早期工程で検出できなかったかを分けて改善します。
変更後の回帰テスト範囲を決める最も適切な方法はどれですか？
答え： 依存関係、データ流、利用経路、過去欠陥を分析し、影響範囲と重要経路を選ぶ
回帰範囲はコード差分だけでなく、契約、共有データ、設定、下流利用者への波及を含めて決めます。高速な全自動テストがあれば併用し、重要経路を落とさないようにします。
デプロイ直後に主要機能が最低限動くか短時間で確認したい。適したテストはどれですか？
答え： スモークテスト
スモークテストは、ビルドやデプロイが詳細テストに進める最低限の安定性を持つか、主要経路を短時間で確認します。
期待結果を決めるテストオラクルとして最も信頼できるものはどれですか？
答え： 要求、業務規則、標準、合意済み例から独立して導いた期待結果
実装と独立した根拠から期待結果を作らないと、同じ誤解をテストへ写してしまいます。複雑な計算では別実装、既知例、性質による検証も組み合わせます。
本番相当の個人情報をテスト環境で使う必要がある。最も適切な対応はどれですか？
答え： 目的を限定し、合成データまたは不可逆な匿名化・マスキングを使い、権限と保管期限を管理する
テストデータでも最小化、目的制限、アクセス制御、保管期限、削除を適用します。参照整合性や分布を保つ合成データを優先し、実データ利用は必要性と法的根拠を確認します。
テスト環境と本番環境の差による見逃しを減らす方法はどれですか？
答え： IaCやコンテナで構成を版管理し、差分を可視化して本番相当条件を再現する
環境構成をコード化し、OS、Runtime、依存、設定、外部サービス契約の差を追跡すると、再現性を上げられます。本番秘密情報はコピーせず安全に差し込みます。
CIで時々だけ失敗するテストを改善する最初の対応はどれですか？
答え： 失敗時のログ・乱数Seed・時刻・環境を保存し、共有状態、時間依存、非同期待機を切り分ける
不安定テストは信頼を損ない、本物の回帰を隠します。証跡を残して再現条件を特定し、固定Sleepではなく状態待機、時刻注入、データ分離などで決定的にします。
並列実行すると互いに失敗させる統合テストを分離する方法はどれですか？
答え： テストごとに一意なデータ・名前空間を用意し、後処理または破棄可能な環境を使う
テストは順序や他テストの残存状態に依存させません。一意ID、トランザクション、専用Schema、使い捨てContainerなどを対象に応じて使います。
外部決済APIをMockした単体テストだけでは不足する主な理由はどれですか？
答え： 自分たちが想定した契約には通っても、実際のSchema・状態・エラー仕様とのずれを検出できないから
Mockは自コンポーネントの分岐を速く確認できますが、誤った前提も再現します。契約テスト、Sandboxでの統合テスト、少数のE2Eで実際の境界を補います。
Consumer-Driven Contract Testの主な目的はどれですか？
答え： Consumerが実際に依存する要求を契約化し、Provider変更で破壊されないか検証する
Consumerが必要とするRequest・Response例や制約を契約として共有し、ProviderのCIで検証します。未使用機能の完全再現ではなく、利用中の互換性を早期確認します。
UI自動テストの要素指定を保守しやすくする方法はどれですか？
答え： Role・Labelなど利用者向け意味を優先し、必要なら安定したdata属性を契約として使う
利用者が操作する意味に近いLocatorはアクセシビリティも検証し、構造変更へ比較的強くなります。専用data属性は意味で特定できない要素に限定します。
非同期UIテストで固定の5秒Sleepを多用すると起こる問題と改善策はどれですか？
答え： 待ち不足では失敗し、十分すぎると遅い。必要な要素・状態・通信完了を条件付きで待つ
固定待機は実行環境の速度差に弱く、遅延と不安定性を同時に生みます。観測可能な完了条件を適切なTimeout付きで待つと、早く決定的になります。
Property-Based Testingが例示ベースのテストを補完する点はどれですか？
答え： 大量の入力を生成し、常に成立すべき性質を検証して最小反例を探す
個別例だけでは思いつきにくい境界・組合せを生成し、逆変換、順序不変、範囲制約などの性質で検証します。重要な具体例は別途残します。
Mutation Testingで分かることはどれですか？
答え： ソースへ小さな変更を入れ、テストがその誤りを検出できるか
演算子や条件を意図的に変えたMutantがテストを通るなら、実行されていても結果を十分に検証していない可能性があります。等価Mutantは分析時に考慮します。
コードカバレッジが100%なら欠陥がないと言えない理由はどれですか？
答え： 実行されたことは示しても、Assertionの妥当性、欠落要求、組合せ、非機能品質までは保証しないから
カバレッジは未実行領域を見つける補助指標です。期待結果が弱いテストでも行は通り、仕様から漏れた機能はコード自体がないため測定対象にも現れません。
想定ピーク負荷で応答時間と処理量が目標を満たすか確認するテストはどれですか？
答え： 負荷テスト
負荷テストは予想される通常・ピーク条件で性能目標を確認します。ストレステストは能力限界を超えて劣化・破綻・回復を調べます。
平均応答時間は良好だが、一部利用者だけ極端に遅い。確認すべき指標はどれですか？
答え： p95・p99などのPercentileと分布を負荷条件別に確認する
平均は少数の遅い応答や分布の形を隠します。Percentile、Histogram、エラー率、処理量を時系列と負荷段階で合わせて確認します。
セキュリティテストをShift Leftする実践として適切なものはどれですか？
答え： 脅威分析、Secure Coding Review、SAST、依存検査を早期CIへ組み込み、後段の動的テストも行う
早期活動は修正費用を下げますが、一つのToolで十分ではありません。設計・コード・依存・Runtimeを異なる技法で確認し、秘密情報は安全に注入します。
アクセシビリティテストとして最も適切な組合せはどれですか？
答え： キーボード操作、Focus順、名前・Role、Contrastを自動・手動で確認し、必要に応じ支援技術でも試す
自動検査は一部の機械判定可能な問題を効率よく見つけますが、操作順、文脈に合う名前、読み上げ体験などは手動確認が必要です。
ユーザビリティテストで有効な観察方法はどれですか？
答え： 対象利用者に現実的な課題を依頼し、誘導せず行動・発話・完了率・つまずきを観察する
代表的利用者が現実的な目的を達成する過程を観察し、成功率、時間、誤操作、理解、満足度を収集します。介入した場合は記録して結果を分けます。
障害復旧機能のテストで最も重要な確認はどれですか？
答え： 障害注入後、検知・切替・データ整合性・復旧時間・通常状態への復帰を確認する
復旧性は実際の障害条件でEnd-to-Endに検証します。RTO・RPO、切替中の処理、重複・欠損、復旧後の監視解除まで確認します。
リリース品質ゲートとして適切な条件はどれですか？
答え： 重大リスクのテスト結果、未解決欠陥、性能・セキュリティ基準、残余リスクと承認を確認する
品質ゲートは単一件数ではなく、事前合意したリスク別の証拠と残余リスクで判断します。例外承認には理由、期限、回避策、責任者を残します。
Defect Removal Efficiencyを改善に使う際の適切な見方はどれですか？
答え： 本番流出を含む欠陥の発見工程を見て、早期検出・予防施策の効果を傾向で評価する
流出を含む検出工程の傾向は、レビューやテスト改善の効果を見る手掛かりです。分類基準、重大度、開発規模、計測期間を揃え、指標操作を招かないよう複数指標で見ます。
品質ダッシュボードで避けるべき指標の使い方はどれですか？
答え： テストケース実行数だけを品質そのものとして目標化する
活動量だけを目標にすると、細かいケース分割や低価値テスト増加を誘発します。利用者成果、リスク、検出力、安定性など複数の観点で意思決定を支援します。
テストを通過した変更を安全に本番へ出すための方法はどれですか？
答え： 段階公開し、技術・利用者指標とガードレールを監視し、異常時に停止・切戻しできるようにする
事前環境では本番のデータ・負荷・依存を完全再現できません。CanaryやFeature Flagで曝露を制限し、エラー率、遅延、業務KPIを比較して継続判断します。