8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

同値分割、境界値分析、デシジョンテーブル、状態遷移テスト……
「テスト技法」を一通り学んだのに、いざ実際のプロダクトでテストを書こうとすると手が止まる。

  • 本や研修のサンプルだと書けるのに、実務になると書けない
  • 「どの技法を使えばいいのか」そもそも判断できない
  • 気合でテストケースを列挙しているだけで、技法を使った“感”がない

そんなモヤモヤを感じているなら、多くの場合、問題は「テスト技法」そのものではありません。
足りていないのは、その手前の 「テスト分析」 です。

この記事では、

  • テストを作るときの流れ(分析 → 設計 → 実装)
  • 「テスト技法はどこで使うものなのか」
  • そして「なぜ分析をしないと技法が使えないのか」

を、シンプルな例を交えながら整理していきます。

テストは「分析 → 設計 → 実装」で作る

まず、テスト作成はざっくり3つのフェーズに分けられます。

  1. テスト分析

    • 仕様・要件・画面・API などがどう振る舞うのか
    • どんな入力・状態・制約があるのか
    • それらのテスト観点は何か決める
  2. テスト設計

    • 分析で整理したテスト観点を元に
    • その確認に必要な因子水準を洗い出し
    • 因子水準の組み合わせを決める
      → ここで テスト技法 が登場します
  3. テスト実装

    • テスト観点と因子水準を元に
    • 具体的なテスト手順や期待値を定め
    • 実際にテストが実行できる形にする

しかし、多くの人がやりがちなのは、こんな流れです。

  1. 自分の作った機能だから「テスト分析」しない
  2. いきなり「テスト設計」をしようとする
  3. いっそ具体的な手順や期待値を書き出して実質「テスト実装」を始めている

つまり、テスト分析をほとんどすっ飛ばしている 状態です。

この状態で「さあ、同値分割を使おう!」「境界値分析だ!」と思っても、そもそも

  • テスト観点がないので、大量にあるデータの何を同値分割、境界値分析するべきかわからない
  • 適切に分割していないので、デシジョンテーブルがデカくなる
  • 状態遷移テストをどこまで広げればよいかわからない

などなど、テスト対象の整理がされていないので、技法の使う先が見えなかったり、
どこまでもテストのサイズが膨大になっていき、収拾がつかなくなります。

テスト技法は「設計」で使う道具

テスト作成のフェーズを端的に言うと以下の通りです。

  • テスト分析 … テストしやすいサイズに分割し、テストするべき内容を洗い出す
  • テスト設計 … テストするべき内容の、検証に必要なデータを洗い出し、過不足を無くす
  • テスト実装 … 決まった内容を元に、テストケースを作成する

テスト技法は 「テスト設計」でデータを整理する技法 です。

逆に言うと、前工程である「テスト分析」をしていなかったり、
「テスト設計」でデータの洗い出しを行っていないと、
技法を当てはめる “対象”がそもそも存在しない となります。

テスト技法を学んでいた時のテキストや例題を思い出してください。
そこで書かれているソフトウェアや機械には、多くの機能や使い方がありますが、

  • こういう目的のテストをしてくださいね
  • 今回のテストでは、この機能たちだけを使って
  • その機能の仕様のすべてはこれらです

と、テスト技法を使う前の「テスト分析」と「テスト設計」のお膳立てが終わっているのです。

実務では、今までされていた、このお膳立てを自分で遂行できてから、
はじめて「この技法ならこういう感じで使える」が見えてきます。


「テスト分析」はどう勉強すればよいのか?

では、その肝心の「テスト分析」とはどう勉強すればよいでしょうか。

テスト技法の勉強ができる本はありますが、
テスト分析やテスト設計を重点的に解説、勉強できる本を私は見かけたことがありません。

「じゃああなたはどうやって身に着けたんですか?」
と聞かれたら、
「テストケースをたくさん、たくさん見てきて、たくさん、たくさん作ったからですね」
と言うしかないです。

なぜならば、あまりにも臨機応変、ケースバイケースなスキルであるからです。
分析する対象の機能は無限にあり、一つとして同じものはありません。
そして、どう分析するのかは、その時のチケットの内容や状況、どんなテストをするのかで変わります。

料理に例えれば、
「食材(機能)の種類やサイズはその時々で違います」
「料理(テストする目的)の内容は都度変わります」
「では、料理(テストする目的)に合わせて食材(機能)を適切な大きさに切ってください」
もうこれは、経験値を積んでレベル上げて慣れてください、としか言えない領域です。
「Sサイズ~3Lサイズの[hoge]の、各サイズごとに[fuga]切りを解説」
のhogeとfugaは無限にありますし、もちろん新しく生まれます。
アイスプラントとか、ここ十数年出てきたんですよ。
あなたが全く新しい食材(機能)を適切なサイズに切ることもあるでしょう。
これはもう「経験を積む」としか言い表せません。

これこそ、慣れない初めの方はAIに聞いてみて参考にするのがいいかもしれませんね。

まとめ:テスト技法だけではテストは書けない!「分析 → 設計 → 実装」

整理すると、ポイントは次の通りです。

  • テストは「分析 → 設計 → 実装」の 3 ステップで作る
  • テスト技法は「設計」で使う道具 であり、「分析」の結果に対して適用する
  • 多くの場合、「技法が使えない」のではなく 「分析をしていないから技法を当てる対象がない」

この記事が、「テスト技法がわかったけど、実務でどう生かせばいいの?」という悩みを持っている方の、次の一歩のヒントになれば幸いです。

8
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?