LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

リリース日は決まっているのに、テストがまだ半分残っている。開発要員にテストも回しているが、不具合を直す作業とテストの実施が同じ人に重なり、どちらも進まない——。開発の現場では、リリース前にこうした詰まりが起こりがちです。テスト要員とは、テストケースに沿ってテストを実施し、結果を記録する役割を受け持つ人を指します。

テスト要員を加えると、開発要員は修正に専念でき、テストの記録もそろいやすくなります。ただし万能ではなく、何を確かめるのか、何をもって合格とするのかが書かれていないテストは、加わった人に渡しても進みません。本記事では、開発を預かるマネージャに向けて、テスト要員の役割、開発要員と分ける理由、加えた人に任せやすいテスト、テスト仕様と判定基準の渡し方、そしてリリースの判定を誰が行うかを整理します。

テスト要員の役割とは

JSTQB（日本ソフトウェアテスト資格委員会）が公開しているFoundation Levelシラバス（資格試験の範囲をまとめた文書）は、テストの主要な役割を「テストをする役割」と「テストマネジメントをする役割」の2つに分けています。テストマネジメントをする役割はテスト計画、テストのモニタリングとコントロール、テスト完了の活動に重点を置き、テストをする役割はテスト分析、テスト設計、テスト実装、テスト実行に重点を置くとされています。^*1

リリース前に加えるテスト要員は、このうちテストをする役割を受け持つ人です。とくに頼みやすいのは、後ろの2つにあたるテスト実装とテスト実行です。テスト実装はテストデータなど実行に必要なものを用意し、手順を組み、テスト環境を整える作業で、テスト実行はテストを走らせて実際の結果を期待結果と比べ、記録する作業です。何をどうテストするかを決める分析と設計は、仕様を知る社内の人が先に終えておくと、加わった人がすぐに手を動かせます。

テストマネジメントをする役割は社内に残します。シラバスは、この役割をチームリーダー、テストマネージャー、開発マネージャーのいずれが担うこともあり、1人が両方の役割を同時に担うことも可能だとしています。専任がいない現場なら、開発のマネージャが計画と進み具合の管理を持ち、実行をテスト要員に任せるのが現実的です。

なぜ開発要員と分けるのか

開発要員がテストも受け持つと、リリース前は修正とテストが取り合いになります。分ける理由はそれだけではありません。シラバスは、作ったものを誰がテストするかで独立性の度合いが変わるとし、作成者本人、同じチームの仲間、チーム外だが組織内のテスト担当者、組織外のテスト担当者の順に独立性が高くなると整理しています。^*1

独立したテスト担当者は、経歴や技術的な視点、思い込みが開発担当者と違うため、開発担当者とは別の種類の欠陥に気づきやすいとされています。外から加わった人は仕様を先入観なしに読むので、書かれていない前提に気づく場面が出てきます。

ただし、開発担当者のテストが要らなくなるわけではありません。シラバスも、開発担当者は自分のコードにある多くの欠陥を効率的に発見できると書き、ほとんどのプロジェクトでは複数の独立性のレベルでテストを行うのが最善だとしています。^*1 部品ごとのテストと部品をつないだテストは開発要員が、画面や業務の流れを通したテストはテスト要員が受け持つのが一つの目安です。

加えた人に任せやすいテスト

任せやすいかどうかは、期待する結果が書かれているかで決まります。テストケース（確かめる操作と期待する結果の組み合わせ）がそろっていれば、加わったばかりの人でも同じ手順で実施し、合否を記録できます。期待する結果が担当者の頭の中にしかないテストは、書き出すまで渡せません。

任せやすいのは、まず確認テストです。シラバスは確認テストを、元の欠陥が正しく修正されたことを確かめるテストとし、その方法の一つに、欠陥のために不合格になったテストケースをすべて実行し直すことを挙げています。^*1 手順も期待結果もそろっているテストです。シラバスは、確認テストは最初にテストを行った人と同じ人が行うのがよいとも書いているので、見つけたテスト要員に直ったかどうかまで見てもらう流れにします。

次がリグレッションテスト（変更によって、ほかの部分に悪い影響が出ていないかを確かめるテスト）です。シラバスは、何度も実行するので自動化の有力な候補になるとし、範囲を決める前に影響度分析（変更がどこに及ぶかの見極め）を行うことが望ましいとしています。^*1 ケースの実行はテスト要員に任せ、今回の修正がどこまで及ぶかの見極めはコードを知っている開発要員が受け持ちます。

探索的テストは事情が違います。シラバスは探索的テストを、テスト担当者が対象について学びながらテストケースの設計・実行・評価を同時に進めるものとし、担当者が経験豊富でドメイン知識を持っている場合により効果的になるとしています。^*1 加わったばかりの人に「自由に触って不具合を探してください」と頼んでも、同じ効果は期待しにくいでしょう。頼むなら目的と時間の枠を決め、終わったら一緒に振り返ります。

受入テストも任せる対象から外します。デジタル庁の「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110）は、受入テストは発注者側が主体となって行うもので、実際の利用者がテストに参加することが必須だとしています。^*2 テスト要員は、その手前の段階までを受け持ちます。

テスト仕様と判定基準の渡し方

シラバスは、ある活動を始めるための事前条件を開始基準と呼んでいます。典型的な開始基準として挙げられているのは、人・ツール・環境・テストデータ・予算・時間といったリソースがそろっていること、テストベース（テストの根拠になる仕様など）やテストケースがそろっていること、すべてのスモークテスト（基本の動作を手短に確かめるテスト）が合格しているといったテスト対象の初期の品質です。開始基準を満たしていないと、活動はより困難で、時間とコストがかかり、リスクも高くなる可能性があるとされています。^*1

テスト要員が着任する日も、この開始基準に合わせて考えます。着任の前にそろえるのは、テストケースの一覧と期待結果、テスト環境のアカウント、テストデータ、基本の操作が通る版のプログラムです。ログインもできない版では、加わった人は初日から待つことになります。

判定基準はケースごとに書きます。「画面が正しく表示されること」では人によって合否が分かれるので、「登録した3件が、登録日の新しい順に一覧に並ぶ」のように、見れば誰でも同じ結論になる書き方にします。

解説書は、受入テストの担当者が操作に十分習熟していない場合はシステム操作説明書などで教育してから実施するとし、不正な処理が操作ミスによるものか不具合によるものかを迅速に切り分けることも重要だとしています。^*2 途中から加わるテスト要員にも当てはまる記述です。最初の半日は操作の説明にあて、切り分けに迷ったときに聞く開発要員を1人決めておきます。

リリースの判定は誰がするのか

シラバスは、テストによる測定の結果は、より大きなプロジェクトマネジメント活動の一部として使われ、リリースの判定など、次の段階に移るための判定に貢献するとしています。^*1 テストは判定の材料を出す活動で、決めるのはプロジェクトを預かる側です。テスト要員に求めるのは、実施したケース、合否、未解決の不具合を、決めた形で報告してもらうことです。

判定の物差しになるのが終了基準です。シラバスは典型的な終了基準として、達成したカバレッジ（確かめた範囲の割合）、未解決の欠陥の数、不合格になったテストケースの数といった測定と、計画したテストを実行した、発見した欠陥をすべて報告した、といった完了の基準を挙げています。^*1 テストの前に決めてテスト要員にも見せておけば、報告の項目もそろいます。

期日が来ても終了基準を満たせないことはあります。シラバスは、時間切れや予算切れも終了基準として妥当とみなすことがあるとし、ほかの終了基準を満たしていなくても、ステークホルダーがこれ以上テストを行わずに本稼働させるリスクをレビューし、受け入れたのであれば、テストを終えることは許容されるとしています。^*1 残る不具合と影響を一覧にし、社内の責任者が受け入れるかを決めて記録に残します。この判断は、テスト要員にも開発要員にも預けません。

つまずきやすい点

一つ目は、「テストをお願いします」とだけ伝えて、ケースと期待結果を渡さないことです。加わった人は仕様を読むところから始めることになり、リリース前の日数が理解に消えます。

二つ目は、テスト要員をリリースの関所のように扱うことです。シラバスは独立性の欠点として、独立したテスト担当者が開発チームから孤立して情報がうまく伝わらなくなること、開発担当者が品質に対する責任感を失うこと、独立したテスト担当者がボトルネックとみなされたり、リリースの遅れを責められたりすることを挙げています。^*1 報告を受けて直すまでが開発要員の仕事だと最初に伝え、テスト要員も毎朝の進み具合の確認に加えておくと、孤立を防げます。

三つ目は、終了基準を最終日に決めることです。結果に合わせて基準を決めると判定の意味が薄れるので、着任の前に決めておきます。

外部に委託するときに確認しておきたい点

テスト要員を社外から迎える場合は、社内の決まりや経緯を知らない人に渡すことになります。次の5つを依頼の文書に書いておくと、着任してからの食い違いを減らせます。

• 受け持つテストの種類（確認テスト、リグレッションテスト、ケースが書かれた画面・業務の流れのテストのどれか）
• 着任の日にそろっているもの（テストケースと期待結果、環境のアカウント、テストデータ、基本の操作が通る版）
• 不具合の記録の形と、切り分けに迷ったときに聞く相手
• 報告の頻度と項目（実施したケース、合否、未解決の不具合）
• 終わったときに渡してもらうもの（実施の記録、追加したケース）

シラバスは、テスト完了の活動として、将来役立つ可能性のあるテストウェア（テストケースやテストデータなど、テストのために作ったもの）を保管するか、適切なチームへ引き渡すことを挙げています。^*1 社外の人はリリース後に離れるので、次の改修で同じリグレッションテストを回せるよう、渡す形を先に決めておきます。

結合テストで設計・実施・修正・判定の担い手をどう書くかは「外部エンジニアと進める結合テスト、テスト体制に書く4つの役割」で、テストにあたる人のスキルと人数の不足をどう分けるかは「外部エンジニアのテスト体制、IPAが定める4つの区分」で扱っています。リリース直前に開発要員そのものを増やすかどうかは「リリース前に開発要員を増員するか決める手順」を、本番の前に確かめる項目は「リリース前の確認事項、移行計画やリハーサルなど6つの項目」を参照してください。

まとめ：テスト要員で確かめておきたい3つの点

リリース前にテスト要員を加えるうえで、確かめておきたい点は3つに整理できます。第一に、テストの計画と進み具合の管理は社内に残し、テストケースに沿った実行と記録をテスト要員に任せること。第二に、テストケースと期待結果、テスト環境、テストデータ、基本の操作が通る版を、着任の日までにそろえること。第三に、終了基準をテストの前に決め、満たせないままリリースするかどうかは社内の責任者が決めることです。この3点を踏まえておけば、「人を加えたのに初日から待たせてしまい、テストが終わらないままリリース日を迎えた」という事態を避けやすくなります。テストケースは書けたのに、実行を担える人が社内にいないときは、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：JSTQB（日本ソフトウェアテスト資格委員会）「テスト技術者資格制度 Foundation Levelシラバス Version 2023V4.0.J02」（PDF）（https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf）。出典：ISTQB Foundation Level Syllabus v4.0の日本語翻訳版。1.1.2（テストとデバッグ）、1.2.1（成功に対するテストの貢献）、1.4.1（テスト活動とタスク）、1.4.5（テストの役割）、1.5.3（テストの独立性）、2.2.3（確認テストとリグレッションテスト）、4.4.2（探索的テスト）、5.1.3（開始基準と終了基準）を参照（2026年9月確認）
2. *2　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日改定）。第3編第7章「7. 受入テストの実施」の解説(2)を参照（2026年9月確認）

Tweet