システムテスト仕様書は、システム開発プロジェクトの最終テスト工程で作成するドキュメントです。

良質な書き方で作成したシステムテスト仕様書は、システムの品質に直結します。

高品質なシステムは、顧客の満足と開発者の成長を実現する、良いサイクルを生み出すきっかけになります。

この記事ではシステムテスト仕様書の書き方を、通販システムを例に挙げながら解説しますので、参考にしてみてください。

システムテスト仕様書とは

システムテスト仕様書とは、動作が正常かや狙った効果を得られるかなど、さまざまな観点からシステムを検証するために用いる書類です。

仕様書を作成する目的は、システム要件が実現できていることを確認するためです。

目的を達成するためには、仕様書を適切な方法で書かなくてはなりません。

書き方のポイントを外してしまうと、要件が実現できているのを確認できない仕様書になり、商品やサービスのクオリティを損ねてしまいます。

例えば、通販システムは不特定多数の利用者からアクセスされますので、セキュリティ対策を必要とします。

不適切な仕様書では、対策を正しく確認できないままシステムがリリースされ、顧客の不満足を生んでしまいます。

仕様書を適切に作成することでシステムの完成度を高められ、顧客満足の高いプロダクトを提供可能です。

システムテスト仕様書に書くべきテストケースの内容

テストケースには、テストの対象・テストの観点・テストの条件・テストの実装手順・テストの期待値を書きます。

テストの対象

テストの対象にはシステムテストで確認したい要素を書きます。

確認すべき要素はシステムのジャンルによって幅広く、動作に関連するものから見た目の影響が大きいものまでさまざまです。

テスト対象を明確に書くと、後から仕様書を見たときに迷うことなく検証が可能です。

テストの観点

テストの観点は、検証したい要素を最適な形でテストするために必要不可欠です。

「確認すべきシステムの振る舞い」を明確にし、高い確度をもって検証するためにシステムテスト仕様書に書き記します。

テスト観点が不足した仕様書では、検証すべき要素が足りなくなる恐れがあり、結果にも悪影響となります。

求めているデータがとれず、プロダクトの改善や発展にも活かすことができません。

テストの観点は綿密に抽出し、仕様書に盛り込んでおきましょう。

テストの条件

テストの条件には、テストを行う際に必要な条件を書きます。

プロダクトの利用上考えられるさまざまなケースを想定し、データとして用意するのが一般的です。

ユーザーがとる行動を予測して、検証すべき条件のデータを記載しましょう。

条件としてよく登場するものに、基本となるマスタデータ、日々蓄積されるトランザクションデータがあります。

通販システムなら、前者は商品マスタ、後者は検索履歴です。

条件には、テストの観点で登場した「確認内容」に合わせて、システムに対して入力するデータを書きます。

必要な条件を書くと、テスト担当者がテスト実行前に整えるべきものが明らかになります。

テストの実行手順

テストの実行手順には、どのような順番でテストを実行するかを書きます。

システムテストは、仕様書の作成者とは別の人が行う場合があるからです。

実施者が迷わずに実行できるよう、具体的かつ明確に手順を書きます。

通販システムの例で言えば、以下のようになります。

良質なシステムテスト仕様書には、明確な実行手順が必要です。

テストの期待値

期待値には、テストの合格基準を書きます。

テストの対象から実行手順までをどれだけ正しく書いても、合格基準が書かれていないと合格・不合格が判定できません。

実施者が結果に対する合格・不合格を迷わず判定できるよう、具体的かつ明確に期待値をシステムテスト仕様書に書きます。

期待値を明確にすると、実施者が迷わず結果を判定できるシステムテスト仕様書ができます。

【サンプルあり】システムテスト仕様書の書き方

システムテスト仕様書の項目と書き方は目的から考えるのがポイントです。

この章ではテストの概要・実施環境・テストケース・日程・参加メンバーの記述をサンプル付きで解説します。

テストの概要を書く

テストの概要には目的・背景・プロセスを書きます。

目的・背景の役割は、システムテストで絶対に外してはならないゴールを書き、参加メンバーの意識を統一することです。

プロセスでは、システムテストをどのような段取りで進めていくのかを書き、参加メンバーが好き勝手に仕事を進めることが無いように押さえます。

システムテスト仕様書は、ソフトウェア開発プロジェクトで発生する、関係者全員の考えのバラつき・走っている間の迷いを押さえるのが役割です。

テスト概要サンプル

テストの実施環境を書く

テストの実施環境には、実施環境の構成と準備手順を書きます。

仕様書に記述された実施環境は、実施環境がどのような部品で出来ていてどういう関係性があるのかを解説し、環境構築の手順を提供する役割です。

実施環境の構成と環境構築手順を文書化すると、参加メンバーがいつでも実施環境と作り方を確認できるので、参加メンバーの時間を大切にでき、コミュニケーションの効率が良くなります。

テストの実施環境サンプル

テストケースを書く

テストケースには、テスト1つ1つを実行するために必要な情報を網羅します。

テストケースを構成するのは、テストの対象・観点・条件・実行手順・期待値です。

5つ全てが必要な情報のため、どれか1つでも欠けていると実行者はうまく検証できませんし、無理にやろうとしても目的は達成できません。

全てを書けば、どのシステム要件を確認するために、どういった仕様でテストに臨むのかが明確です。

各要件に対してテストケースを正しく定めて初めて、良質なシステムテスト仕様書と言えます。

テストケースサンプル

テストの日程を書く

日程はシステム開発・ソフトウェアに限らず、どのような仕事にも必須の情報です。

システムテストの日程は期限ありきではなく品質第一にします。

品質が担保できる段取りをシミュレーションして、実施可能な日程を見積もると、現実的な日程を組めます。

日程の検討は、要件を確認するための段取りとは何かを考えるところから始まります。

もし見通せない段取りがあれば、段取りを見通すための日程を組んで、段階的に明確化するのがポイントです。

テストの日程サンプル

テストの参加メンバーを書く

テストの参加メンバーを書くときのポイントは、役割分担と指示系統の明確化です。

役割には大きく分けて、責任者と担当者があります。

責任者は意思決定を担当します。シナリオテスト工程で問題が発生したときに対応方針を決定する権限を持つのが責任者です。

担当者は自身に割り当てられた業務を遂行し、責任者の承認を得ます。

指示系統は業務指示の経路を指します。業務指示は指示系統に従い意思決定者が行い、全体を統制します。

テストの参加メンバーサンプル

システムテスト仕様書を作るときのポイント

システムテスト仕様書には作成時に守るべきポイントがあります。

ポイントを守ると、システムテストの役割である要件の満足度を測れる仕様書が作成できます。

テストの目的を明確に伝える

システムテスト仕様書ではテストの目的を明確に書くべきです。

明確な目的はシステムテストに関わる人全てのゴールを統一する力があるからです。

目的が明確に伝わっていないと、テストがうまく進まないことも少なくありません。

まずは関係者間でしっかりと合意した目的を用意します。

もし途中で揉めた場合は、スタート地点かつゴール地点である目的を、関係者全員で見直すのが有効です。

目的を定めておかないと、関係者全員がスタートもゴールもわからないので、時間とお金を浪費してしまいます。

商品やサービスを良質にするためにも、目的を明確化した上で実施しましょう。

テストの条件をはっきり示す

システムテスト仕様書では、テストの条件をはっきりさせるべきです。

条件がはっきりしていればテストの再現性が向上し、良質なデータがとれます。

条件は対象ごとに詳細に設定し、いくつかのバリエーションをもたせましょう。複数の角度から検証することで、テストの質を高めることが可能です。

より具体的に条件を示すためには、数値を用います。「たくさん」「多く」といった曖昧な表現ではなく「5回」「10回」などの定量的な表現で条件をつけなくてはなりません。

条件をはっきりと示すことでテスト実行者が迷う恐れが減り、検証結果の正確性の向上も期待できます。

仕様書を書く際には、明瞭かつ詳細な条件の設定を心がけましょう。

テスト対象をすべて書き出す

システムテスト仕様書には、テスト対象をすべて書き出すべきです。

通販のホームページを検証するのであれば、商品の掲載ページや注文フォームなどがあげられます。

さらに細分化が必要な場合は、掲載ページの画面エリアを指定したり、項目を書いたりして詳細に対象を示しましょう。

検証したい内容であるテスト対象に漏れがあると、欲しいデータを正確に抽出できません。

不十分なデータでは目的を達成できず、商品やサービスの向上につながらなくなります。

本来の目的を確実に達成するためにも、システムテスト仕様書には対象となる要素をすべて書き出し、実施者に伝わるようにしましょう。

テストの実行手順をわかりやすくする

テストの実行手順をわかりやすく記載すれば、仕様書の作成者以外のメンバーが理解しやすくなります。

テストの参加メンバーには、実行手順の妥当性を検証する人（レビューア）・手を動かしてテストをする人（テスター）がいます。

レビューアとテスターは前提知識が異なるので、全員が理解できるようわかりやすく書くのが必須です。

実行手順の説明で不明点が多かったり、難解な表現が続いたりすると、参加メンバーに正しく伝えられません。

理解するのに時間がかかるほか、実施時の混乱のもとにもなり、本来不要だった作成者との質疑応答を生みます。

関係者の時間を浪費しないよう、テストの実行手順の書き方を関係者間で明確化し、わかりやすくすべきです。

やってはいけないシステムテスト仕様書の書き方

システムテスト仕様書にはやってはいけない書き方があります。

やってはいけない書き方をすると、システム要件の満足度が確認できず、完成に影響します。

悪い例から予防策を身につけておきましょう。

曖昧な表現が多い

曖昧な表現が多いシステムテスト仕様書は、メンバー間での認識のずれを生む要因です。

仕様書の作成者・レビューア・テスターの認識がずれて、本来の要件意図が反映しきれないシステムテスト仕様書が出来上がります。

抽象的な言葉を使っている、定量的に示していない、人によって印象が変わる要素が入っているなどは、曖昧でわかりにくい仕様書の例です。

曖昧な表現を避けるために、言い切る表現や数値を適切に使いましょう。「テストの対象」という言葉を使うなら、対象とは何かを明確に示した上で説明すればわかりやすくなります。

端的にまとめられた仕様書なら、読む人によってわかりやすさが左右されません。スムーズにテストを行うためにも必須です。

テスト内容に一貫性がない

テスト内容に一貫性がない書き方をすると読み手が混乱するほか、検証結果にも悪影響です。

システムテスト仕様書は項目ごとに一貫性を持たせ、常に目的に沿った内容になるよう記載します。

目的に沿っていない項目があったり、本来のテスト対象とは関係のない要素があったりすると、一貫性のない仕様書になりかねません。

テスト中に矛盾が起こるだけでなく、役に立たない結果ばかりが出てしまう恐れもあるでしょう。

一貫性を保つためには、どの工程でも「テストの目的を満たすのに必要か」を基準にすることが大切です。

大きなゴールを定めた上で、ゴールに向かって工程ごとに必要なプロセスを記載していきます。

一貫性のあるシステムテスト仕様書を作れば、顧客の要件を満たすテストが実行できるのです。

テストの機能と観点が結びつかない

テストの機能と観点が結びつかない書き方をすると、その後に続くテストの条件や実行手順にもずれが生じます。

機能や目的への理解が不十分だと、ずれた観点でシステムテスト仕様書を作ってしまいかねません。

まずは機能についてしっかりと理解し、目的を達成するために何を検証すべきかを洗い出しましょう。

仕様書の作成者だけでなく、第三者の視点を取り入れるのも有効です。

結びつきのずれは、作成者以外の他者の目が入らないと見過ごされやすくなります。

他者の目に触れるレビューをすると、結びつきの不自然さを修正する機会を漏れなく設けられます。

難解な言葉が多く読みにくい

難解な言葉が多く読みにくいシステムテスト仕様書は、読み手の重荷になります。

前提知識の異なるメンバーが複数いることを踏まえて、わかりやすい言葉を使うのがポイントです。

特定の人にしかわからない専門用語のほか、業界特有の呼び方や略語の多用にも気をつけなくてはなりません。

専門用語が必要な場合は適度に注釈をつけるなど、読み手が難なく理解できるような仕様書を意識しましょう。

誰もがわかる言葉を用いて端的に仕上げた仕様書なら、短時間で効率的に理解でき、テストの実行においてもミスが少なくなります。

結果、良質なテスト結果を得られ、プロダクトの品質向上にも大きく貢献するのです。

まとめ：システムテスト仕様書の書き方を押さえて開発精度を高めよう

この記事ではシステムテストの仕様書の書き方を紹介しました。

システムテスト仕様書の書き方を押さえると、開発精度が高まります。良質な仕様書に仕上げることで、プロダクトに必要な改善点がわかりやすくなるでしょう。

自社におけるメリットはもちろん、顧客への満足にもつながるので、この記事を参考に優れた仕様書を作成してみてください。

システムテスト仕様書の書き方についてわからない・相談したい、については、お気軽に株式会社Jiteraまでお問い合わせください。

株式会社Jitera