システムを作ったら必ずテストをしなければなりません。
何故なら作ったシステムが正しく動作をするかどうかを確認しなければ完成したとは言えないからです。
しかし、テストというのは実際にやってみると、どっから手を付けたらよいか、分からなくなってしまうのはプログラマー、システムエンジニアであれば、誰しも経験していることです。
そこで、あらためて「テストケースの作り方」を考えてみましょう。
テストケースとは
総論から言いますと、システムというのは「一つの箱」です。
そして、その箱に「何か」を入れると「何か」が出て来る、というのがシステムです。そして入れるものを入力、出て来るものを出力と言います。
もし、入れた物が「そのまま出て来る」のであればシステムの存在意義はありません。つまり入力されたものに「何等かの加工」をして出力するのがシステムというものなのです。
そして、入力には色々な種類があり、出力にも色々な種類がありますが、必ず「出力は入力に依存したもの」となります。ですので、テストケースを作るのは、まず「入力を種類別に並べること」から始まります。
とは言え「加工を行う」には一定の条件が必要です。こういった種々の条件も満たさねばなりません。
そこで、テストケースを作成する際の手順を項目として並べてみましょう。
テストの対象を決める
テストを実施するには、まず対象機能を特定します。さきほども述べましたようにシステムは「入力されたものを加工して出力」するものです。そして入力には色々な種類があるのが普通で、その種類別に「加工、出力の仕方」も変わるものです。
つまり「どういった種類の入力に対してのテストを行うか」を決めねばなりません。もちろん「全ての入力種類に対し正常に機能する」ことを確認するのがテストの目的ですから「全ての種類の入力」を洗い出す必要があります。
しかしシステム全体において、「全ての種類の入力」を一度に全て洗い出すのは、あまりにも大変な作業です。ですのでテストは、いきなり全体をテストするのではなくプログラム単体のレベルから行うのが効率的な方法となります。
つまり最初に「テストする機能を決めておく」必要があるのです。1つの機能（プログラム単体或いはいくつかのプログラム群）においても入力、加工、出力という基本的な内容は同じです。
つまりテストする機能を特定し「その機能における全種類の入力」を一覧化することからテストケースの作成は始まります。この一覧化は必ずエクセルなどを使って「次の担当者」に渡せるようにしておくことが必要です。
下記に一例を示します。
各項目の意味は以下のようになります。
- No. = 実施手順
- 大項目 = 全体操作の中の位置付け
- 中項目 = 大項目の中の順番
- 確認画面 = 出力結果
- 前提条件 = 実施した条件
- 操作手順 = 実際に操作した内容
- 期待結果 = 正常とみなされる動作内容
- 結果 = 正常か異常か
- 日付 = 実施年月日
- 確認者 = エビデンスを確認した人物の名前
- 機種名 = テストを実施したハードウェアの記載
この表を見ても分かると通り「入力」はデータだけとは限りません。
「電源を入れる」「タップして選択をする」「キーボードから入力しEnterを押す」といったハードウェアの操作も入力として扱います。
上記でいう「操作手順」の列が「色々な種類の入力」を書き込む場所です。
入力はテストするシステムが業務システムなのかゲームなのか、スマホアプリかにより色々と形を変えて登場しますので注意が必要です。
テスト観点
テストをしたら結果を記録し正常に機能していることを証明する必要があります。いわゆる「エビデンス」を残す必要があるのです。
これが無ければテストをしたことにはなりません。そして、まず最初に証明すべきは「正常な入力に対して正常な加工、出力がされている」ことを証明することです。
つまりシステムが本来の目的に沿ったものに出来上がっていることを確認するのです。
そして、ほとんどのシステムでは「システムを使う手順」というものがあります。
簡単にいうと操作手順です。当然ながらテストも、この順番に沿ってやらねばなりません。
先の表の「№」「大項目」「中項目」という列が、それを書き込む場所です。
つまり「システムの、どの部分の機能のテストであるか、を順番に沿って明らかにしておくのです。これを明示することにより「正しい手順でテストをしている」ことが証明できます。
逆に、これが無いとチェック担当者は「正しい順番で操作した結果なのかどうか」が確認できず、検証ができなくなってしまうのです。
前提条件
テストを行うには前提条件があることが、ほとんどです。
例えば本番で想定されているCPU、OS、ブラウザ、メモリー量と同等のハードウェア環境で行われたものか。また業務システムであればマスターファイルのデータは本番同様のものが用意されていたのか。そのマスターデータの内容は、どのようなものであったか、もエビデンスとして残さないとチェック担当者は結果が正しいのかどうかが判定できません。
こういった前提条件をしっかり用意しておくことも重要です。
入力データ
テストに使用する入力がデータである場合、色々なデータが入ってくることがほとんどです。そして、それは何らかの形で区別できるように設計されているはずです。
そしてテストにおいては、全ての種類のデータが正常に処理されることを確認する必要がありますので「全ての種類の入力データ」を準備しておくことが必要となります。
この洗い出しと設定は結構、大変な作業なのでプロジェクトによっては「テストデータ作成要員」が用意されることもありますが、そうでない場合は誰かが、それを調査し用意しなければなりません。
多くの場合、この作業は設計したシステムエンジニアの方が正確に用意できることが多く、かつプログラム作成工程においてはプログラマーは多忙ですが、設計したシステムエンジニアは時間があり、システムの全体像を知っているので、より適切な入力データを用意することが出来ます。
「単体テストはプログラマーが行う」と決めているプロジェクトが多いのですが、そのテストに使用する入力データは設計したシステムエンジニアが作って提供するのが最も確実と言えます。
それは次の項目である「期待する結果」にも関係してきます。プログラム作成と言う工程はスケジュールの中で最も狂いが生じやすい工程です。
そのリスキーな工程を少しでもスムースに進めるためにもテストに使う入力データは設計を行ったシステムエンジニアが用意することをお勧めします。
それは「スケジュールを守り一定以上の品質を守る」ことにもつながるのです。
期待する結果
前提条件を満たし、入力データも揃ったらテストを行いますが、事前に「期待する結果」、つまり正解を用意しておく必要もあります。
テストした結果が「期待する結果」と同じであれば「正常」であり、違えば「異常」となります。
| 期待する結果の場合 | 正常 |
| 期待する結果でない場合 | 異常 |
テストした結果が正常なのか異常なのかを、どうやって判定するのかを前もって決めておくことによりテストの信頼性はアップします。
これを用意しておかないと「まぁいいだろう」という曖昧な判断しかできず「ちょっとしたミス」を見逃してしまうこともあります。
ですので「期待する結果」は1項目単位で示していくのがベストです。そして細かく事前規定することによりプログラマーも判断しやすくなり品質もアップしていくのです。
面倒な作業ではありますが、事前に面倒な作業をすればするほど品質は上がるのです。
つまり「苦労すればするほど良い結果が得られる」のです。ですので、手を抜いてはいけません。
往々にして失敗プロジェクトは、テスト結果を「曖昧に判断した」ことが原因となっていることを覚えておいて下さい。
テストの種類
システムは全体としては「大きな箱」ですが、その中には沢山のプログラムがあり、それが連動して動いています。
従って効率的にテストを行うには以下の種類のテストを以下の順番で行う必要があります。
- ユニットテスト：モジュールのメソッド単体に対するテスト
別名、プログラムの単体テスト、とも言います。 - インテグレーションテスト：モジュール間の連携に対するテスト
別名として連携テスト、結合テストとも言います。 - システムテスト：ユーザ視点でのインターフェースで行うテスト
一般的に1と2はプログラムを作成したプログラマーが実施し、3は設計したシステムエンジニア及びシステムテスト専用要員が行います。
| テストの種類 | 実行者 |
|---|---|
| 1.2 | プログラムを作成したプログラマー |
| 3 | ・設計したシステムエンジニア ・システムテスト専用要員 |
規模が大きいシステムほどテストケースは増大しますのでシステムエンジニアだけではこなせなくなるケースもあり、そういった場合は「システムテストチーム」と呼ばれる専用のチームが作られます。
この場合、シナリオは設計担当のシステムエンジニアが作り、テストはオペレーターが実施することになります。
テストケースを作成する目的
何故、テストケースを作成する必要があるのか、という根本的な問題について触れておきましょう。
もちろんシステムの品質を確認するのが最終目的なのですが他にも利点があるのです。
必要なテストを漏れなく実施するため
システムが備えるべき機能が全て、備わっていることを証明するためには「全ての種類の入力」に対し正しい出力が行われる必要があります。
それを確認するのは当然であるからです。
不要なテストを削除するため
テストケースというのは大量になるので、場合によっては「同じ内容のテスト」が重複してしまう可能性があります。
また想定外の入力はエラーにすべきですが、これもあまりにも大量だとデータを用意する時間、テストを実施する時間がかかり、その分、コストが増大する結果となりスケジュールも消費します。
テストケースを表という成果物にまとめれば重複や「これはやり過ぎではないか」といったケースを発見、除去できるのです。
誰が行っても同じテストにするため
テストケースを作る人はシステム仕様を熟知しています。しかし本番スタート時には「それまで全く新システムを触ったことがない人達」が使います。
往々にして仕様を熟知している人は「慣れている」のでスムースに進行する一方、始めて使う人達がやってしまいそうなミスは避けて通ることができ、そのために発見出来なかった問題というのが出てきがちです。
システムというのは「誰が使っても同じ結果が得られる」ことも保証しなければなりません。ですので、テストケースという成果物を作り「全く新システムについて知識が無い人」にテストさせることも重要なのです。
往々にしてシステムテストというと「システムを熟知したシステムエンジニアが行うもの」というイメージがありますが、実はそれだけでは十分とは言えないのです。
「テストの種類」のところでシステムテストを「ユーザ視点でのインターフェースで行うテスト」と述べましたが、これはそういう意味なのです。
システムを熟知していないとテストケースを作ることはできないのですが、実際にシステムテストをするのは「システムについて白紙状態の人」の方が良いのです。
その橋渡しのためにテストケースを作ることが重要になってくるのです。
テストケースの作り方と注意すべき観点
では、具体的にテストケースの作り方と作る際の注意点について順番に述べてみましょう。
1：まず以下の4項目を規定
| 1.前提条件 | テスト対象の前提となる値や状態は何か |
| 2.手順 | どのような手順でテストをするのか |
| 3.入力値 | どのような値を入力するのか |
| 4.期待する結果 | どのような結果を期待しているか、どのような結果がでれば正常であるかを文章化したもの |
ここに「一桁の自然数同士のかけ算をする計算システム」があるとしましょう。
すると以下のような例が考えられます。
| 前提条件 | 5が既に入力されている |
| 手順 | かけるボタンを押す |
| 入力値 | 6を入力して計算実施 |
| 期待する結果 | 30が表示されている |
このシステムは「一桁の自然数同士のかけ算」ですから入力値は1～9のいずれかになります。しかし、これだけでは十分ではありません。
実際の入力値は前提である「一桁の自然数」では無いことも可能性として有り得るからです。
2：想定されていない値を入力
システムは道具であり、使うのは人間です。そしてミスをしない人間はいません。つまり、想定外の値が入力されてしまうことも有り得る訳です。
その場合、システムは一定のエラー動作を行うはずですので、それを確認するテストケースを追加します。
しかし「想定外の入力」というのは、いくらでも考えられます。そこで効率よく「想定外も含めた入力値」を割り出すための方法を次にご紹介しましょう。
テストケースを効率よく作るためには
「一桁の自然数」でない数字、というのは無限に存在します。
ですので、それらを全てテストしていたら時間がいくら有っても足りません。
そこで、或る程度に絞るのですが、その「絞り方」には、これまでの経験値から以下の方法が良いと分かっています。
- 同値分割法
「一桁の自然数」は1～9ですので数字全体をグループ分けすると「1未満」「1～9」「10以上」の3グループに分けられます。ですので、それでのグループから1つづつ選ぶ、という方法です。例えば「1未満」からは-1、「1～9」からは6、「10以上」からは11といった具合です。
- 境界値分析法
同値分割した場合、各グループの境界線に当たるものがバグを起こしやすい、と言う経験則を元にした方法です。この経験則に従うと「1未満」からは0、「1～9」からは1と9、「10以上」からは10が良いと分かります。3とか7は1、9と同じグループであるので、あらためてテストとして入力する意味が、あまり無いのです。
- ペアワイズ法
「ほとんどの不具合は1つまたは2つの要因によるものである」という経験則から考えられた方法で、沢山ある要因のうち、最低でも2つの要因の組み合わせだけは含める、という観点でケースを作る方法です。
| 前提条件 | 5が既に入力されている |
| 手順 | かけるボタンを押す ↓ ボタンを押さないに変更 |
| 入力値 | 6を入力して計算実施 ↓ 8を入力に変更 |
| 期待する結果 | 上記の操作をした結果、どうなるかを想像し表示されているはずの数字に変更 |
このペアワイズ法は、あくまで追加テスト、という位置づけで入れるべきもので、同値分割法、境界値分析法を行った上で、更に念のために行ってみる、という位置づけです。
- エラー推測
仕様を設計したシステムエンジニアには「この値が危ないかも知れない」というのが何となく予想が付く場合があります。その場合に、その値をテストケースに加える方法です。
上記のような方法を取れば「想定外の入力値」は最低限で済むことになり、テストによる工数の軽減につながります。
これらの方法を参考にしながら入力値を選択しテストケースの表を作っていけば、テストケースは効率良く出来上がっていきす。
テストというのは「やり過ぎるに越したことはない」という人もいますが、システム開発においては常にコストを意識しなければなりません。
かといってコストばかり考えテストがおろそかになるのも許されません。
コストと品質と言う両者のバランスをうまく取りながらテストケースを作っていくのが重要ですので、上記のような方法を使いテストケースを絞り込んで行くのです。
まとめ
テストケースを作るのは非常に大変な作業です。また、作ったテストケースをテスト担当者に渡し、テストを実施してもらうのも大変な労力を要します。
それだけにテストは確実に行われなければなりません。もし「やり直し」ということになったら大変なことになります。
テストを確実に進めるには「分かりやすく、簡単に」がキーポイントとなります。
エビデンスの取り方も統一した方が良いので1－2ページの簡易マニュアルを作りテスターに配布しましょう。
また複数のテスターに同時進行してもらうためには、それぞれ、別々の環境を構築する必要が出る事も有ります。
もしテスターが10人なら10人分の環境を用意する必要が出てきます。これは大変な作業となります。
つまりテストを実施してもらう側の人が苦労すればするほどテストはうまく進むのです。最もまずいのは、その苦労を嫌い簡易化を図ることです。
中には入力値を明示せず「適宜な自然数」などと記述するケースもありますが、このようなテストは実は「テストではない」のです。
しっかりゴールするためには苦労を惜しんではなりません。苦労を惜しんだ人ほど「ゴールできない」というのがテストにおける最大の経験則なのです。
