テスト仕様書 作成：書き方 設計方法は？

テスト仕様書 作成 支援
テスト仕様書の書き方は？設計方法は？

---

システム開発の精度を上げるテスト仕様書
結合テスト、受入テストも支援可能

テスト仕様書 とは、システム開発において、テスト対象がどの箇所であるかを明確に決めて、テストの方向性や、テストケースを具体化し、テスト設計の仕様となるドキュメントです。このテスト仕様書に紐づいたテスト内容の作成があってこそ、システム開発においてのテスト内容が明確になり、開発したシステムの精度が改善されていきます。

クロトでは、このテスト仕様書の作成を代行させていただき、御社のシステム開発の結合テストや、受入テストをサポートさせていただきます。

テスト仕様書において、決めていくべきポイントは、

1. どこをテストするか？
2. どんなテストをするか？
3. いつやるか？（スケジューリング）
4. どんな方法でテストするか？

といった4点が、テスト仕様書 作成の要のポイントです。

簡単に解説すると、システム開発で、仕様書がある場合とない場合とでわかれます。

仕様書がある場合。この場合は、仕様書に基づいて、テスト対象を洗い出して、表示や各機能についてのテスト項目を記載していきます。

その際、テストの内容は、仕様書に紐づいて作っていきます。

どんなテストをするか？は、環境や、PCなのか？タブレットなのか？スマートフォンなのか？といったデバイス、そして、入力内容やアップするファイルの内容はなんなのか？を明確にして、テストを行えるように、テスト仕様書を作っていきます。

続いて、仕様書なしで開発している場合。この場合は、テスト項目の洗い出しは、網羅的には難しくなります。

そこで、まずは、画面単位で、テストする対象を洗い出していきます。そして、作った機能について、発注書や、エンジニアからヒアリングをして、テストする機能を見つけます。これができない場合は、テスト仕様書 作成は難しいですね。テスト対象が明確にならない上に、どんな内容をテストするのかが、判断できないからです。

ただし、一般的なテストレベル、動作テストをするくらいは可能かと思いますので、稼働状況をテストするように、テスト項目を作って、動作テストをしていくようになります。あくまで、想定レベルなので、テスト結果にブレが出てしまう可能性があるので、この場合は、テスト仕様書の作成よりも先に、仕様書自体の作成を進めた方がいいですね。

テスト仕様書を作るメリットは、明確です。

1. システムの精度向上
2. テスト内容の明確化
3. リソースの削減

この3つがテスト仕様書を作るメリットです。

テスト内容が明確になることで、テストを行う人員や期間も明確になります。その結果、何を改修すべきか？バグなのか？仕様なのか？などの判断ができ、プロジェクトの円滑な進行に貢献できます。

テスト仕様書を作らないで、テストを進めると、こういった弊害がありました。具体例として、テスト仕様書がなく、テストをして、失敗した事例です。

• テストがされていない
• テスト結果が人によってマチマチでバグかどうか不明
• テストの報告ができない、報告書にまとめられない
• 成果物の品質が著しく悪い
• エンジニアが疲弊して、退職、定着しない

こんなかんじで、テスト仕様書を作らずにテストをした？進めたデメリットは、たくさんあります。実際に、結構、テスト仕様書作らないでテストを進めるパターン、見かけますが、結構、危険です。

ここからは、テスト仕様書の作成方法について書いていきます。

テスト仕様書の作成方法としては、

1. 実現可能なテスト計画を立てること
2. 入力→処理→出力結果の中身を把握すること
3. テストの条件やテストの手順、期待値をテストケースに記載すること
4. テスト結果を伝えるフォーマットを決めること

この4点がテスト仕様書の作成方法として、やっておくべきことですね。

テスト計画が、実現不可能な計画を挙げる人がいます。めちゃくちゃ細かい粒度のテストで、数か月もかかるようなテスト。テストケースの作成で、システム開発よりもコストがかかるような計画。こういう、テスト仕様書の作成は、やめましょう。

また、仕様を理解してこそ、テスト仕様書の作成は進みます。なぜなら、テスト対象に対して、どんなテストをして、それがどんな結果だったかを伝えることが必要だからです。エンジニアが後で、この不具合、再現しない？みたいな状態に陥るような、テスト仕様書の作成は、良くないです。エンジニアの疲弊につながりますし、お客様にも混乱を与えてしまいます。

テスト仕様書の作成で、大事なことを申します。テスト結果を伝えるフォーマットを、あらかじめ決めておくことです。

テスト手順がなんであるか？がテストケースに書かれていると、テスト結果を伝える際には、とても楽です。テスト結果として、画面キャプチャだけ、張れるようにして、何が、期待値と異なるかを書けばいいだけになります。ですが、そこで、口頭で終わらせず、テスト仕様書作成をそれでいいか？を資料化して、きちんと、関係者、テスト承認者に許諾を取りましょう。

ちなみに、テストする際のデバイスや、ネットワークの入り方、テストデータの規定なども明確にしておくといいです。テスト項目によってはバリデーションチェックが必要なケースが出てきますので、明確にしておくと、間違いが減ります。このとき、javascriptが動く環境かどうかなどの仕様はあらかじめ聞いておくといいと思いますので、ご注意ください。

テスト仕様書の作成は、機密情報の取り扱いをすることがあります。それゆえ、お見積り時に、NDA（機密情報保護）の締結を進めさせていただきます。NDAのひな形をご用意することも可能ですので、お声がけください。

システム開発や、プロジェクトマネジメント、システム開発コンサルティングを15年以上行ってきたクロトですから、テスト仕様書の作成なども、ご支援しております。成功の事例、失敗の事例も、たくさんシステム開発の現場で見てきました。こういったノウハウを元に、クロトは、お客様に、テスト仕様書の作成や運用などを通して、プロジェクトの成功をご支援しております。開発してきたシステム、コンサルティングをしてきたシステムなど、携わってきたシステムは、BtoCビジネス、BtoBビジネス向け、社内、社外向け、さまざまなシステムと、多岐に渡ります。RFPの作成支援なども行っています。アジャイル開発や改変のないクラウドシステム利用以外では、クロトでシステムを開発する際には、仕様書などの資料も作っており、その結果、リピートしていただくケースも多いです。

テスト仕様書の作成がよくわからない。テストの設計とか、何していいいか、つかめない。受入テスト面倒です。テストのリソースが足りない。こんなとき、クロトにご相談ください。テスト仕様書 について、ご検討の際は、お問い合わせフォームより、実施したいシステムや、そのURL、webサイトのURL、相談事項、実施予定時期、ご予算、ご依頼範囲などの具体的なお話を教えてください。担当者より、ご連絡いたします。オンラインでのお打ち合わせなども行っております。NDAなど締結後、詳細を進めていきましょう。

 

---

テスト仕様書 作成 支援 サービス詳細

テスト仕様書 作成 支援 における、クロトで対応可能なサービス詳細です。ここでは、テスト仕様書 作成 支援 で、実施してきたことなどを掲載をしています。

• ヒアリング、お打ち合わせ
• DB調査
• 仕様書の確認
• テスト仕様書 作成
• テスト仕様書 チェック
• テスト計画 草案 作成
• テスト実施
• テスト結果報告フローの草案策定
• テスト結果報告
• テスト結果報告書作成
• コンテンツ作成
• テスト用データ作成
• テスト結果 アンケート作成
• テスト方法のウェビナー開催

など

実際の業務内容は、契約、担当範囲、内容などによって、都度変動します。

テスト仕様書 作成 支援においては、最初にシステム開発の仕様書自体の有無を確認しております。仕様書がない場合、想定仕様でのテストになりますが、ご了承ください。

ただ、費用はかかりますが、テストしながら、テスト仕様書を作成するケースもございます。規模感にも寄りますので、都度ご相談ください。

テスト仕様書 作成の対象としては、主にwebシステム、EC、業務システム、基幹システム、CMS、CRM、各種webツール、webアプリケーション、スマホアプリなどを想定

※ECカートで拡張性の高い Shopify ショピファイ 構築サービス もございます
※awsなどクラウドサーバの導入、wafの導入もご提案可能
※コンテンツマーケティングのオウンドメディア制作で検索からの誘導強化も
※wordpressのカスタマイズ開発も可能
※検証環境、テスト環境構築なども構築できます
※デジタル庁 デザインシステムを活用することで、UIUXの向上も！

---

テスト仕様書 書き方

簡単に、テスト仕様書 書き方について解説します。テスト仕様書 は 書き方というよりかは、何を書くか？を理解していると、作りやすいですね。

基本的に、テスト仕様書 の 書き方としては、以下の項目をリストとして記載するようにしていきましょう。

• ナンバリング（項番）
• テスト対象の画面
• テスト対象の機能名
• テストする機能
• テスト内容
• テスト条件
• テスト手順
• 期待値
• 優先度
• 実施日
• 担当者
• テスト結果のリンクURL

個人的には、最後の、テスト結果は、Googleドキュメントにしておくことをおすすめしています。画面キャプチャなどを張りやすく、説明がしやすいからです。また権限管理もできるので、セキュリティも担保されます。

なお、事前に、テストする環境は決めておきます。テスト仕様書 を書く際に、統一しておくポイントになります。

テスト仕様書 作成 は、エクセル、スプレッドシートなど、リストで作成していくようにしましょう。

画面数が膨大な場合は、1画面ごと、あるいは、機能ごとに、テストケースを書いていくとわかりやすくなります。

アプリケーションのテストの場合、正誤データがマトリクスのようになっていると、よりわかりやすくなります。

---

テスト仕様書 メリット

システム開発において、テスト仕様書 メリット は いっぱいあります。しかし、テスト代行も含めて、そのメリットをどう稟議書に表現するのが良いでしょうか？テスト仕様書 作成 を依頼する際、何を書けばいいのでしょうか？そこで、テスト仕様書 メリットをまとめていきます。

テスト仕様書 メリットは、

1. システムの精度向上
2. テスト内容の明確化
3. リソースの削減

といった３点が、テスト仕様書 メリットです。

テスト仕様書 を作ることで、計画的な業務になりますので、リソースの削減につながるのもいいですし、あやふやな情報が流通すると、コミュニケーションコストも、高くついてきます。

テスト仕様書 を通して、社内や顧客とのコミュニケーションも円滑になりますし、開発しているエンジニアさんにとってもプラスです。テスト仕様書 を計画的に進めることはおすすめです！

---

テスト仕様書 作成 フロー

システム開発における、テスト仕様書 作成フローについて、一般的なかんじで、まとめてみました。仕様書作成から、実際の修正まで入れておきますけどね！

▼ テスト仕様書 の 作成フロー

1. プロジェクト情報の収集
   • プロジェクトの目的と範囲を理解
   • 要件定義書や設計書を確認
     
     
2. テスト計画の策定
   • テストの目的と範囲を決定
   • テスト環境の準備
     
     
3. テストケースの洗い出し
   • 機能要件に基づくテストケースの列挙
   • 非機能要件に基づくテストケースの列挙
     
     
4. テストケースの優先順位付け
   • 重要度と影響度に基づいて優先順位を設定
     
     
5. テスト仕様書のフォーマット決定
   • 会社や システム の標準フォーマットがあれば採用
   • なければ、必要な項目を含むフォーマットを作成
     
     
6. テスト仕様書の作成
   • テストID
   • テスト項目
   • 前提条件
   • テスト手順
   • 期待結果
   • 実際の結果（実行時に記入）
   • 備考
     
     
7. レビューと修正
   • 開発者や他のテスターによるレビュー
   • フィードバックに基づく修正
     
     
8. 承認プロセス
   • プロジェクトマネージャーや品質管理責任者による承認
     
     
9. テスト仕様書の配布
   • 関係者への配布と共有
     
     
10. 更新と維持
    • プロジェクトの進行に合わせて適宜更新

このフローはシステム の規模や性質によって変えていきます。小さい システム 等の場合は簡略化できる場合もあります！

---

テスト仕様書 観点

テスト仕様書には、製品やサービスのテストを行う際に重要となる観点が記載されます。適切なテスト観点を設定することで、システムのクオリティを検証しやすくします。これによって、利用者にとって、プラスとなるシステムを提供することができます。

以下は、テスト仕様書の観点で、主なポイントについてまとめてみました。

機能要件の確認

システムが、顧客に要求された機能を正しく実装しているかどうかという観点です。この観点でテストします。これは、機能仕様書に基づいて行います。当然ですが、機能間の連携についても確認が必要です。

非機能要件の確認

パフォーマンス、セキュリティ、使いやすさ、信頼性などの非機能要件についての観点です。適切な水準を満たしているかどうかをチェックします。負荷テスト、ストレステスト、ユーザビリティテストなどですね。この観点は、言語化しにくいことも多いですし、まずは動く、という部分が多いですよね。
それゆえ、言語化にも、時間もお金もかかる箇所です。

異常系の確認

予期しない入力や環境条件下でもシステムが動作するかをテストします。不正な入力値、リソース不足、ネットワーク切断、データ欠損などの異常ケースに対する挙動を確認し、安全性とエラー処理の適切性を検証します。これも、限度をどう調整しないといけない部分で、コストに影響を与えてくる部分です。

セキュリティの確認

不正アクセスやデータ漏えいの可能性をテストしていく部分です。脆弱性テスト、ペネトレーションテスト、暗号化の確認など、セキュリティ上の要求事項を満たしているかを検証します。

互換性の確認

ソフトウェアが動作すべき環境(OS、ミドルウェア、ハードウェアなど)において、適切に動作するかをテストします。この辺は事前に定義してくべきポイントにもなります。

ユーザビリティの確認

webシステムにおいて、あとまわしになりがちな部分がここですね。ユーザインターフェースが使いやすく、直感的であるかをテスト・チェックしていく箇所です。操作性、わかりやすさ、一貫性などの観点をチェックして、UX、ユーザエクスペリエンスを検証します。

回帰/運用の確認

新機能の追加や不具合修正によって、既存機能が影響を受けないかをチェックしていくかんじです。よくあるのは、システムの場合、値の連動です。ここを触ると、あのファイルで影響が出る。みたいなところを、しっかりとまとめておきましょう。テストケースを作っておくと、このときに再度実行でき、問題がないかをチェックできます。ないと、ここは、コスト影響が高まってしますので、注意すべきポイントになります。

テスト仕様書にはこれらの観点を含め、具体的なテストケースやテスト手順、テストデータなども記載されます。適切なテスト観点を設定し、網羅的なテストを実施することで、システムをいいかんじに提供することができますよ！と、簡単に書いていますが、実際に、これができるケースは少ないかもしれません。コスト要求の観点も大きいですからね。

webシステムの場合、即時性なども要求されますので、少なくとも、ベースとなる、テスト仕様書は、作っておかないと、たいへんですよ！

---

テスト仕様書 作成 よくある質問

テスト仕様書 作成 の よくある質問 をまとめました。

---

テスト仕様書 作成 支援 / テスト 実績 事例

• 一括見積ツール
• CRM
• SFA
• webコミュニケーション ツール
• web勤怠管理ツール
• 大型CMS
• 大学向けCMS
• フォトギャラリーシステム
• 動画ポータルサイト
• 自動車 関連 ツール
• 製薬会社 CMS
• キャリア 決済 システム
• スマホアプリ
• 商品登録ツール
• イベントカレンダーシステム
• 予約システム
• メルマガ配信システム
• プレゼントキャンペーンCMS
• 予約管理システム
• ECサイト
• 在庫管理システム

など