mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

テスト分析・設計・実装について

 

テスト設計って実際何をやるのか?

テスト分析の次はテスト設計です。

なんとなく自分の理解を書いていこうと思います。

 

 

テスト設計とは何か

あくまで自分の理解ですが、テスト設計とは

「テスト分析において、テストすべきだと判断した項目について、テストの目的が達成されるようにテスト項目の組合せを整理すること」

といえると思います。

 

テスト設計〜テスト実装への接続(高位レベルテストケースと低位レベルテストケース)

テスト設計の成果物は「テストケース」です。

しかし、テスト実装の成果物も「テストケース」とされている場合があります。

ここで自分はかなり混乱しました。

混乱を避けるためには、「高位レベルテストケース(論理的テストケース)」と「低位レベルテストケース(具体的テストケース)」の概念を導入する必要があると考えています。

自分の理解では、テスト設計の成果物が「高位レベルテストケース」であり、テスト実装の成果物が「低位レベルテストケース」であると理解しています。

 

「高位レベルテストケース」と「低位レベルテストケース」って何?

高位レベルテストケースとは、簡単に言うと「低位レベルテストケースを作るための元ネタ」だと思っています。

例えば状態遷移表とか、決定表とか、要するにテスト分析で識別したテスト対象に対してテスト技法を適用した結果のアウトプットのことです。

で、低位レベルテストケースとの違いはどこかというと「それを使って実際にテスト実行できるか?」ということだと思います。

低位レベルテストケースの特徴は、「テストに用いる具体的な値が決定していること」です。なので、たとえ状態遷移表とか決定表でも具体的な値が決まっていてそれを見てテストを実行できるのであれば、それは低位レベルテストケースとして成立すると思います。

低位レベルテストケースは言い換えればテストスクリプト、テスト手順とだいたい同じものだと思っています。

 

要するに、テスト設計〜テスト実装への接続は、

「テスト設計において、テスト技法を用いて導出したテスト項目の組合せを、テスト実装において、実際にテスト実行できるような形に成形する」といえると思います。

 

テスト設計しなかったら何が困るのか

実感として自分が困ったことを書いていこうと思います。

自分が困ったのは、

 

入力の組合せを深く検討していないため、本来テストすべきテストケースが導かれない場合がある

 

これです。

例を挙げます。

動画作成アプリの動画再生機能をテストするとします。

すると、少なくとも

  • 動画停止中
  • 動画再生中

などのステータスが存在することになります。

ここで特に何も考えずにテストしようとすると、

「とりあえず、動画を再生する。見終わったら停止する。停止したら、動画再生画面を閉じる。」

みたいな基本パスをテストしたりします。

しかし、そのままよく考えずにいると「動画再生中に動画を中断したらどうなるの?」とかいったテストが漏れます。これを漏らさないようにするには、状態遷移図を描いてみたり制御パステストを考えてみたりしないといけません。この作業がテスト設計です。

 

テスト分析とテスト設計、先にどちらを学ぶべきか?

これについて先日のテスト酒場にて、Masskaneko氏に意見を伺いました。

結論としては、「自分の実感に合うものや、目的に合う学習をしたほうがよい」ということです。

  • どんなバグが出て困ったのか
  • そのバグをテストで除外するには、テストプロセスにおけるどの活動をしていればよかったのか

を考え、それに沿って学習をすることで目的達成に近づくことができるのではということです。

自分としても盲点だったのですが、意外と「そのバグをテストで除外するには、テストプロセスにおけるどの活動をしていればよかったのか」という議論はあまりされないように思えます。どちらかというと、「どこで作り込んだバグか」「どのテストレベルで摘出すべきバグだったか」に目が行きがちな気がします。

 

せっかく勉強するのですから、業務により直結することを学んでいきたいですね。