ソフトウェア品質シンポジウム『テスト分析の概略』 参加レポート #SQiP

SQiP 技術 勉強会

はじめに

  • SQuBOK V2には「テスト分析」はありません
  • 論文数が少ないですが、V3には載せたいと思っている
  • 若者向けに今回の資料を作った
    • けど参加者を見ると平均年齢が高め

目的

  • テスト分析がどのようなものかを知ることで、テスト設計の質を改善するため
    • テスト分析として出された論文のうち、本当にテスト分析と呼べるものは少なかった

ソフトウェアテストのプロセス

  • 次のようにテストケースを作っている人が多い
    • 仕様書を読んで、そのままテストケースを書き始める
      • これは、設計もせずにプログラムソースを書き始める行為と一緒
      • センスの良い人はこれでもテストケースを書ける人がいますが、そうでない人が大半
  • 頭のなかだけでやっていた作業を意識的に行うことでテストケースの品質が改善できる
  • 開発プロセスになぞらえてテストプロセスも書けそうだ

本セッションの説明範囲

  • 要求分析
  • アーキテクチャ設計
  • 仕事で扱うテストレベルに対応してブレークダウンさせる必要がある

JSTQBシラバスではどのようにテスト分析が書かれているのか

  • ソフトウェアテストをビジネスでやっている程度ならやっている
  • Advanced Level Test Managerで書かれていることを読んでも腑に落ちない
    • 現場に持ち込んだ時にわからなくなる
  • Advanced Level Test Analystでは、もう少し具体的に書かれている
    • 「このテスト分析の考え方は自分達が勝手にやっているわけではないんだよ」と言い張れる

テスト分析の考え方

  • あくまでも発表者の考え方
  • 次の3つの捉え方で考える
    • 視野
    • 視座
    • 視点

視野

  • テスト設計の前の工程

  • テスト設計をするために、テストケースを書くために必要な文書や情報を知る

    • テストベース（要件定義書、機能仕様書など）
    • 開発標準やテスト標準、ガイドライン
    • 過去に作成されたテストケース
      • テストケースは資産
    • テストケースのためのチェックリスト
    • 過去の不具合状況や欠陥データベース
    • テスト範囲（テスト実施すべきところの把握）
    • テスト対象に関する情報
      • 開発途中の品質状況（良さ/悪さ）
      • 母体システムの品質状況

  • テスト範囲

  • テスト対象に関する情報
    • 特に悪さに関する知識

視座

  • テスト対象に関わる人達を明らかにする
  • その人の立場に立って、テストを考える
    • 利用者、ユーザタイプ
    • ユーザ特性
    • 開発者
    • 運用者
    • 顧客のお客様
オニオンモデル
  • 要件定義をテストの段階でやらざるを得ないことが多々ある
  • 受け入れテストだとCustomer's Customer の立場に立つことがある
ご近所さんを探せ
ビジネスコンテキスト分析
  • ものの流れから対象者を見つける

視点

  • テストすべき事柄（テスト条件）を洗い出す
  • 次のステップでテスト条件を導く
    • テスト対象をある塊に分割する
  • テスト仕様書の目次通りにテストをやるとうまくいかない
  • 品質を高いものを出荷しようと考えると良くない
IPOモデル
テスト条件の洗い出し
  • 業務担当者視点だったら後工程、開発者視点だったらもっと前の話
階層化

テストアーキテクチャ設計

テスト条件の組み合わせ

時間軸

宣伝

  • テスト設計コンテストをやってます
  • 良いテスト設計は良いテスト分析がないと得点にならない

感想

  • テスト分析をもっと大きなところから見ることが出来て良かった
  • 最初に「テスト分析とテストアーキテクチャ設計を説明するよ！」と言っていたのに、テスト分析だけだった…