テストをやってみよう ( 関連 : 8.5.3 )
目次
- 1 テストについて
- 1.1 テストに関わる立場の人
- 2 テストはプログラマーと別の人員が行うことが原則
- 3 テストにおけるV字モデル
- 4 単体テスト例
- 5 結合テスト例
- 6 システムテスト
- 7 受け入れテスト
- 8 テスト報告書例
- 9 不具合報告書
- 10 参考資料
- 10.1 Webの記事や書籍など
- 10.2 オンライン学習
テストについて
テストは、要件定義書や設計書（基本設計書・詳細設計書）とおりに作られているか確認するための重要な工程である。テストに合格しないということは、要件定義書や設計書（基本設計書や詳細設計書）といった文書に間違いがない限り、プログラマーが、システムエンジニアやプロジェクトマネージャーの指示通りに開発できていないことを示している。一般には、開発したプログラムの修正が必要である。
また、就職したばかりの新人は、テスト担当として「テストエンジニア」に配属されることがある。
テストに関わる立場の人
ITエンジニアと言われる職業のうち、システムやソフトウェア、ハードウェアの設計や開発に関係する人になる。こうした立場の人は、2 対 8 や 3 対 7 くらいで、プログラミングするよりも、文書を書く業務の方が多い。
プログラマー（PG）
部活で言えば選手の立場
テストエンジニア（QA / QC）
部活で言えば選手の立場
QA：GoogleやMeta、Amazon等、長期間にわたって自社サービスを提供し続ける企業には、QA（Quality Assurance）、つまり品質保証を担当するQAエンジニアが存在する。完成したシステムやサービスに対して、顧客の要求通りに出来ているか、耐久性に問題がないか、より良くするためのデザインや使い勝手の改善といったカスタマーサポートの領域まで含むこともある。
QC：テストエンジニアというと一般にはこちらを指す。QC（Quality Control）、つまり品質管理を意味する。開発途中の段階から、開発したものが正常に動作するか、不具合がないかチェックする役割を持つ。
システムエンジニア（SE）
部活で言えば選手の立場、状況によってはコーチのような振る舞いを行い、選手育成を担うこともある。
プロジェクトリーダー（PL）
部活で言えば、監督代行が可能な主将といった立場。プロジェクトリーダーを設置しないこともある。
プロジェクトマネージャー（PM）
時には監督、予算不足や人員不足等の事情がある場合は、プロジェクトリーダーを兼任することもある。
プロジェクトマネジメントオフィス（PMO）
部活で言えば、顧問の立場。
テストはプログラマーと別の人員が行うことが原則
１人で開発するシステムを除き、ほとんどのシステムはチームで開発する。そのためテストは、プログラマーとは別の「テストエンジニア」と呼ばれる立場の技術者が実施する。テストエンジニアの仕事は、次のようなものがある。
テスト設計
テスト工程については、「テストにおけるV字モデル」に従って、すべてのテスト工程を実施する。各テスト工程について、開発したシステムをターゲットに、どこまでテスト対象とするか決める。
テスト実行
「テスト設計」に従って、テストを実行する。
テスト結果報告
「テスト実行」について、実施結果の報告書を作り、プロジェクトマネージャーととも顧客に提出する。すべて合格になれば、テストは終わる。１つでも合格にならないものがある場合は、バグとして、プログラマーに修正を依頼し、すべて合格になるまで、テストを実施する。
システム改善案を共有
テスト中に考えた改善案を開発担当のプログラマー等に共有することで、品質向上に役立てる。「テストエンジニア」のこの行動次第で、開発するシステムの品質が下がることもあれば、上がることもあり、改善案の共有は、開発に関わるすべてのステークホルダーにとって、重要な仕事である。組織であれば、年２回の賞与（ボーナス）に影響するくらいに重要。
テストにおけるV字モデル
図の左側は、開発工程であり、上から下に順に進めます。図の右側は、下から上に進める。左側の開発工程と右側のテスト工程はそれぞれ対になっている。V字モデルの左右を見比べることで、実施されるテストがどのレベルの開発内容に着目するためのテストなのか確認することができる。
ここでは、単体テストのテストドキュメントを書いてみます。単体テストは、開発した個々の機能が正しく、つまり設計とおりに動作していることを確認するものである。あくまで設計通りに動いていることを確認する。設計の段階で、システムを求める顧客の要望が過不足なく含まれているものとする。抜け落ちがある場合、開発工程の「要件定義」からやり直しが生じる。
教育機関向けのMicrosoft 365を導入していない限り、Microsoft Office は無料ではなく有料であるため、予算がない場合は無料のオフィスソフトを利用する。無料のオフィスソフトウェアとしては、https://ja.libreoffice.org/ が代表的である。
https://wiki.documentfoundation.org/JA/Marketing/CaseStudy
単体テスト例
専任のテストエンジニアが取り組むことが望ましいが、人員不足や予算不足の理由から、開発したプログラマーが実施することもある。単体テストは、システム内の各機能別に行うものである。たとえば、文書作成ソフトの場合は、「既存の単語を太文字にする」でも１つの機能であり、単体テストの対象となる。原則、開発した機能の数だけ実施しなければならないため、大変手間がかかる作業であるが、単体テストをサボると、その後の結合テスト等で問題が生じるため、重要な工程である。
テストケース文書例
テスト用の管理システムを使った方が管理が楽であるが、表計算ソフトで作成することが多い。小規模なものはテスト工程の管理をExcelでやっても良いが、今後機能拡張をするような場合や複数人で共同でテスト工程を進める場合は、専用の管理システムを使った方が良い。
下記のように、テスト手順（要件に基づく動作内容）を、テストケース文書に含めることがある。「文書作成」や「タスク管理」のように、想定するシナリオ別に、テストケース文書を作成する。
単体テストの文書名の例 : UT01-xxxx-xxxxx-xxxxx.xlsx 、UTは、Unit Test = 単体テストの略称である。
テストログ文書例
テスト報告書の中のテストログ例としてサンプルを示す。
ファイル名の例 : UT01-01-log-xxxx-xxxxx-xxxxx.xlsx 、UTは、Unit Test = 単体テストの略称である。
単体テストは、各機能を１つ１つ、コツコツと実施し、「予測」をもとに「期待される成果」が一致することを「実施結果」として確認します。もし一致しない場合、いくつかの可能性が考えられます。実際に遭遇しがちなものでは、次の可能性があります。
そもそも要件定義書に緻密に作られておらず、曖昧な箇所があることが原因の場合
設計書（基本設計書・詳細設計書）が、要件定義書と乖離（かいり）している場合
「1」の場合は、要件定義書に署名しGoサインを出した顧客とプロジェクトマネージャーに確認し、今後の対応を検討することが必要です。事と次第によっては、訴訟に発展する可能性があります。
「2」の場合は、プロジェクトマネージャーに確認し、今後の対応を検討することが必要です。このケースでは、まだ開発チーム内で問題の収拾を図ることができる可能性が残されています。
結合テスト例
単体テストで確認した各機能を、２つ以上組み合わせて実施するテストが、結合テストです。結合テストには次の2種類があります。
内部結合テスト
単体テストの例として、Notion を取り上げました。「○○のページを作成し、必要な文章を書いた後、PDF形式でダウンロードを行う」のように複数の機能を組み合わせたシナリオについて確認します。
外部結合テスト
単体テストの例として、Notion を取り上げました。外部結合は、「Notion」と別のシステムを連携させるようなケースが想定される場合に実施します。たとえば、API連携でおなじみの「Zapier」を使って、オンラインフォームの「Typeform」に新しい登録があった際に、その登録情報をNotionに転記するといったようなケースです。
テストケース文書例
単体テストと同様に表計算ソフトで作成することが多い。小規模なものはテスト工程の管理をExcelでやっても良いが、今後機能拡張をするような場合や複数人で共同でテスト工程を進める場合は、専用の管理システムを使った方が良い。
大項目ごとにテストケース文書を作成する。ファイル名の例 : IT01-01-xxxx-xxxx-xxxx.xlsx 。表計算ファイルを使っているが、文書ファイルでもよく、全体をまとめるプロジェクトマネージャーの方針に従う。
テストログ文書例
ファイル名の例 : IT01-01-log-xxxx-xxxxx-xxxxx.xlsx 、ITは、Integration Test = 結合テストの略称である。
システムテスト
「総合テスト」とも言い、結合テストを終えてから行う。構築したシステムが仕様通りに動作し、機能を満たしているか検証する。また、顧客（エンドユーザー）が使用する本番環境を使ってテストを行う。実施方法としては、専任された「テストエンジニア」が担当する。テスト設計の段階で、顧客（ユーザー）側に、要件定義書通りに動作するか否かを確認する。
したがって、テスト内容も、要件定義書に書かれた内容が実現しているかどうかで、合格か不合格が判断する。この段階で、開発済みの機能については、エラーが出ることはほぼない。稀に滅多に起きないバグが見つかることもある。かつて１万分の１くらいにしか起きないであろうと予測されたバグを１回で引き当てた経験がある。
受け入れテスト
開発などを発注した顧客側（エンドユーザー）が実際の運用環境、またはそれに近い環境で、実際に使用される業務プロセスに従って動作を確認する。要件定義書が、実際に使用する顧客側（エンドユーザー）の利用者が必要とするものであれば、この時点で不合格になることはない。無事合格すれば、サービスリリース、つまりシステムが完成し、実際に運用を待つ段階に入ることができる。
受け入れテストが不合格になるとすれば、即ち、V字モデルにおける「開発工程」の「要求分析」が間違っていたことに他ならない。
ゼロから開発し直すか、一部機能の手直しで済むかどうかは、顧客側（エンドユーザー）との調整次第。「要求分析」が間違っている例として、以下を参照されたし。
なお、日本国内の多くの例では、追加予算が生じないことがあり、小さな会社の場合は、ゼロから作り直しにより、会社が倒産の危機や売却の危機に立たされることが本当にあるので、このような事態にならないように注意されたい。学生諸氏も裁判の結果、10億円の損害賠償を一括で払うとか嫌でしょう？
テスト報告書例
各テスト結果をまとめたもの。以下のように構成される。文書やスライド形式になっていることが多い。
テストの全体概要
テストの対象
テスト実機期間
テスト実施体制とテストに関わった担当者名
単体テストの実施内容と結果
結合テストの実施内容と結果
システムテストの実施内容と結果
受け入れテストの実施内容と結果
残存する不具合について書かれた不具合報告書
各テストのテストケース文書とテストログ文書のファイル名を表形式で一覧としてまとめたもの
別紙として、各テストのテストケース文書とテストログ文書のファイル
上記をすべてフルカラー印刷し、顧客側の責任者の押印をもらい、パイプ式ファイル（例 https://www.kingjim.co.jp/products/brand/super-docchi-t.html ）にまとめる。印刷すると1000ページを超えることがあるため、特厚のパイプ式ファイルを事前に複数確保しておくことも必要である。
不具合報告書
「バグ報告書」とも言う。各テストを実施する中で、想定と異なる動作となった場合、以下のように報告書を作成し、関係者と共有する。軽微なものでは、開発した機能の修正、大きなものでは、要件定義書の修正が伴う場合があり、要件定義書の修正の場合は、顧客側（エンドユーザー）と協議が必要になる。
報告書に決まったものはないが、概ね以下の項目が含まれている必要がある。原則、文書作成ソフトウェアを用いて作成する。サイズはA4サイズが一般的。
報告者名
不具合を確認したテスト作業担当者名
不具合概要
不具合の内容を端的にまとめたもの。
期待された成果
開発したものが適切に正常に動いたとして、期待していたものの内容。
発生した事象
テスト実施により、不具合が生じた結果を記述する。
発生日時
不具合が生じたテストの実施日時
不具合の再現方法
不具合の再現方法
実行環境
不具合を確認した際に使用した環境。OS（基本ソフト）やWebブラウザ等の各種バージョンを詳細に記すことが必須。
例えば、Windows 11 Home 22H2、Google Chrome バージョン: 113.0.5672.93（Official Build） （64 ビット）にて確認のように記述する。
画面ショット
不具合を確認することができる画面ショットを報告書に記載
ログ
Webブラウザで表示されたエラーメッセージやエラーコード
参考資料
Webの記事や書籍など
https://atmarkit.itmedia.co.jp/ait/articles/2205/09/news033.html
https://circleci.com/ja/blog/unit-testing-vs-integration-testing/
https://codezine.jp/article/corner/306
オンライン学習
https://www.udemy.com/ja/courses/development/software-testing/