より良いエンジニアを目指して

1日1つ。良くなる!上手くなる!

JSTQB学習〜第7回模擬試験

本書の最後の模擬試験をやってみました。

29/40という結果。試験では65%、つまり26問以上が正解だと合格になります。

しかし、かなり心許ない数字です。

模擬試験と全く問題が出るわけではありません。

これまでの勉強方法とアプローチを変えて、回答するにあたって、答えだけではなく、迷ったところとかも書いていました。

40中8つが疑問を持った箇所がありました。

迷った箇所と、間違った箇所が一致するかというとそうでもなく、不運が続くと、かなりヤバい点数だったかもな、と。

テスト戦略についておさらい。

  • 分析的戦略
    • 要件やリスクなどの要因を分析した結果を用いてテスト設計する
  • モデルベースド戦略
    • 何らかのモデルを基にしてテストを設計する
  • 系統的戦略
    • あらかじめ定めているテストケースまたはテスト条件を用いてテストを設計する
  • プロセス準拠戦略
    • 企業の内外で定められているルールまたは標準を用いてテストの分析、設計、実装を行う
  • 指導ベース戦略
    • 外部のステークホルダー、ビジネスドメインの専門家、技術的な専門家からの助言、ガイダンスをもとにテストする。顧客の意見に基づいてテストする場合もこの分類となる。
  • リグレッション回避戦略
    • リグレッションが発生しているかどうかを確認できるようにテストする。自動化されたテストスクリプトや標準テストスイートを利用してテストを行う。
  • 対処的戦略
    • 事前に計画するのではなく、テスト実行時に発生するイベントやテスト結果に対応してテストを行います。探索的テストはこの分類になります。

レビュータイプのおさらい

  • 非形式的レビュー
    • 以下のような方法で行われます。
      • バディチェック
      • ペアリング
      • ペアレビュー
      • ピアデスクチェック
  • ウォークスルー
    • ウォークスルーでは、レビューミーティングにて、作成者自身が中心となって、作業成果物の内容を説明し、参加者の質疑に答えていきます。
  • テクニカルレビュー
    • 同僚やレビュー対象に関するエキスパートがレビューアとして参加し、作業成果物の要件との適合性や他の文書との一貫性を確認して、懸念事項を発見します。
    • ただし、懸念事項を発見するだけでなく代案の提示や、いくつかの異なる代替案の検討も行うのが特徴です。
  • インスペクション
    • 標準プロセスの遵守やレビュー結果の文書化を確実に行うことが求められる。
    • 主な目的は、潜在的な欠陥の検出、作業成果物の品質と評価と信頼の積み上げ、作成者の学習と根本原因分析による将来の類似欠陥の防止

デバッグはテストにて故障を特定した後の欠陥の特定から修正までの一連の開発作業を指します。いやー、忘れますね。

問題として全体をきちんと読まないとならないな、と感じますね。

適切なものであるか適切ではないものの見極めから、単純にレビューを成功させる組織的な要因、というような組織的であるか人的でであるかでまた正しい答えが違ってくるパターンがあります。