(初心者向け)ソフトウェアテストの観点～帳票編

はじめに

業務システムでよくある帳票などをダウンロードする機能で、ダウンロードされた帳票そのものに対するテストの観点を、簡単なサンプルシステムを例にしてまとめてみました。

テスト技法を本格的に勉強したわけではなく、今まで携わった案件で、この観点でテストすればＯＫだったっていう過去の経験を思い出しながら書きました。

（サンプル）システム概要

• システム名 ：音楽コンクール採点システム

• ざっくり仕様

  • 審査員が、出場者の演奏を聴き、採点フォームに入力し登録する。
  • ダウンロード画面から、出場者の成績一覧がダウンロードできる。

• 採点画面
  採点項目は3つで各10点、30点満点で採点します。
  

• ダウンロード画面 省略

• 帳票レイアウト（審査結果一覧） 今回のテスト対象
  ただの表ですが説明用にシンプルにしました。
  

• データベースのテーブル
  

帳票のテスト観点

おおきくわけると、レイアウト と データ（DBの値とか動的に変わる部分） の確認で、別々にテストします。
不具合管理票とかでチケットを切るとき、もし1つの箇所でレイアウトとデータの値が両方不具合として見つかった場合、別々の不具合としてチケットをきります。

帳票レイアウトのテスト

要件定義で決めた通りのレイアウトで帳票が出力されるのかを確認します。

ファイル形式

• ファイル形式が正しいか（CSV, PDF等）
• ファイル名称が正しいか

項目名称関連

• ヘッダー名称が正しいか
• ヘッダーの項目の順序が正しいか

CSVのようなテキストベースのファイルはこれくらいかもしれません。

PDFとか画像データ、エクセルなどの場合

例：

• 項目の配置位置が正しいか（左揃え、中央揃えなど）
• 線の種類、太さ、色が正しいか
• 枠線がはみ出たり、切れてないか
• 項目名やデータの値が枠内に収まっているか（文字の折返しなど）
• フォントの種類、大きさが正しいか
• 列幅や高さが正しいか
• 余白が適切か
• 改ページがある場合
  • ページ番号の表示形式（1/100、No.100 とか）
  • 1ページあたりの最大表示件数

などがあると思います。
外部のお客様に提出するようなファイルの場合はけっこう細かく確認します。

テストデータ作成時の注意点

氏名、住所など可変なデータは起こりうる最大文字数のデータを作成し、レイアウトがくずれないか確認します。

• 悪いテストデータ例
  
  このデータだと、文字数確認だけでなく、姓と名が逆で出力されてた場合も不具合に気づくことができません。

• 良いテストデータ例
  姓名が各全角10文字以内の場合。
  
  わたしは10文字ってわかりやすくする為、↑の画像みたいな感じでデータを登録します。

また、nullを許容してるカラムの場合は、nullの場合は空白で表示されるかなどを確認します。
帳票にnullとかNanとか表示されないことを確認しましょう。

データ部の表示形式関連

データベースの値を何らかの形式で加工して表示する場合、表示形式が正しいか確認します。
例：

• 値の配置位置が正しいか

  • 数値は右揃え
  • 文字列は左揃え

• データのフォーマット

  • 数値 ... 金額だと￥マークがあるか、３ケタ区切りのカンマついてるか
  • 氏名 ... 姓と名が半角スペースで区切られているか
  • 日付 ... yyyy年、yy年、1月、01月、1990-01-01

などがあると思います。

データのテスト

おおまかにわけると以下について確認します。

• データベースの登録内容と、帳票の出力結果の値が等しいか
• 計算結果が正しいか

データ１行に対してテスト

テストデータ作成時の注意点

テーブルのカラムと、帳票の各項目のマッピングが正しいかを確認する為、各カラムをユニークな値で登録して作成します。

• 悪いテストデータ例
  プログラマが間違えてメロディにharmony、ハーモニーにmelodyを出力するようプログラミングしてた場合、不具合に気づけません。
  

• 良いテストデータ例
  カラムの値をユニークにしていれば、帳票の各項目にカラムの値が正しくマッピングされていることが確認できます。
  

複数データに対してテスト

テストデータ作成時の注意点１

例えば、合計点の高い順でソートして出力 って要件定義してある場合

• 悪いテストデータ例
  合計点が全部同じなテストデータだと、ほんとに合計点順になってるか不明です。
  

• 良いテストデータ例
  合計点をユニークになるようデータを作成すれば、正しくソートされたことが確認できます。
  

テストデータ作成時の注意点２

例えば、合計点が20点未満は出力しないって要件定義してある場合

• 悪いテストデータ例

20点未満の人が2人いますが、本当に20点未満の判定がされているか不安です。
プログラムでもし 合計点 <= 20 (20点以下)って判定処理書いてても、不具合に気づくことができません。

• 良いテストデータ例

合計が20点と19点になるようなテストデータを用意しておけば、20点未満の判定が正しく実装されている確認ができます。

さいごに

簡単なシステム例にしましたが、意外とたくさん観点がでてきました。仕様によってはもっと沢山の種類で確認が必要になってくると思います。

帳票に限らず、どのテストでもいえることですが、要件定義がきちんと話合われておらず仕様が漏れていた場合、その部分に関してテストが実施されない為、実装の手戻りが発生したり、不具合が発生する可能性もあります。きちんと要件定義して、テストの観点を洗い出しておくことは大切です。