テスト実装/テスト実施(実行)のプロセス
テスト実装、テスト実行は、テストプロセス全体の中の以下になります。
テスト実装
テストの準備をしないままテスト実行をすると、テストで利用するツールのセットアップができていない、外部連携用のデータが存在しないなど、思うようにテストを進められない事態が発生します。
また、テストに必要な機器を調達できない、テストデータの準備に予想外に時間がかかるといった問題に気付くことが遅れ、その影響によりテスト完了の予定日に間に合わずリリースが遅れるといったことが起こる恐れがあります。
そのため、テスト実行を始める前に必要な作業を洗い出し、それに基づいてスケジュールを作成することが重要になります。SHIFTでは、以下に紹介する3つのポイントをテスト実装工程で「テスト実行方針」としてまとめるようにしています。
ソフトウェアテストに外注の選択肢を
「ソフトウェアテストを外注すべき5つの理由とは！？」の資料をぜひご覧ください。
1.テスト実装開始前に確認すること
プロジェクト全体スケジュールの変更によって、予定していたテストの時期や期間、リリース日が変わっていることがあります。特に多いのが、開発の遅延によりテスト期間が短縮されることです。プロジェクト計画に変更が無いか、新たな制約事項やリスクが発生していないかなどを確認することが大切です。
2.テスト実施(実行)をするために必要な作業
テスト実行を円滑に進めるために必要な作業を洗い出します。
テスト環境の準備、テストデータの準備、実行手順の確認とツールの準備などの作業が該当します。テスト計画時にテスト実行準備のための作業などを決めていると思いますが、テスト設計でテスト条件やテストデータを明確にしたことで、新たなテスト環境やツールを必要とすることもあります。
テスト実行を円滑に進めるために必要な準備作業を以下に示します。
テスト環境の準備
テスト環境の準備では、テスト対象となるシステムをテスト環境で動作できる状態にセットアップするだけでなく、専用端末や通信機器、またリモートでのテスト環境や設備などテストに必要な機器類の調達も含みます。
テストデータの準備
テストデータの準備では、テストケースに記載された前提条件とひも付いたデータを準備します。データ作成を手動で行うか、ツール等で自動化するかなどを決定したうえで、テストデータを準備します。
制約事項の確認
テスト実行に影響を及ぼす制約事項を明確にします。テスト環境を使用できる期間、外部連携システムに接続できる日時、テスト環境のライセンスによる機能の制限、日またぎや月またぎといったテストの実施タイミング、本番環境とテスト環境の差異など、制約となる作業や項目を洗い出します。
テスト実施(実行)手順の決定
テスト実行の効率と、テスト対象となるシステムの機能の優先度を考慮して、テストケースを消化する順番を決定します。
テストケースを記載した順番のまま、上から順にテスト実行してしまうと、手戻りや余計な作業が発生することがあります。例えば「データの全件削除」というテストケースを消化するためにまだ実施していないテストケースのテストデータを消してしまったり、テスト条件にあわせてシステムの設定を何度も切り替えたりする場合です。
そこで、データの初期化や全件更新・全件削除をするテストケースは他のテストケースのテストデータに影響がない順番にする、同じシステムの設定で確認できるテストケースをまとめるなど、効率的にテストが実施できるように順序を考えます。
実施の効率とともに機能の優先度についての考慮も重要です。システムには、主要動作に影響するメイン機能やシステム要件を実現する機能など重要度の高い機能があります。また、多くの機能と依存関係や参照関係などを持ち他機能への影響度の大きい機能もあります。
このような機能で不具合が発生すると調査や改修、再テストにかかる時間が長くなることが想定されます。テスト実行の最後の方でこれらの不具合を検出すると、テスト実行の完了が遅れる可能性があります。
そこで、重要度の高い機能や他機能への影響度が大きい機能に関わるテストケースの実施優先度を高く設定しておきます。
作業工数の見積もり
次に、テスト実装にかかる工数と、テスト実行にかかる工数を見積もります。
テスト実装にかかる工数は、テスト実行をするために必要な作業を基に見積もります。
テスト実行にかかる工数は、テストケースごとの実施時間を見積もったうえで集計します。その際、全てのテストケースを一律で何分と見積もるのではなく、テストケースごとの違いに着目し分類して見積もることで、より精度の高い見積もりをすることができます。
例えば、以下のように分類して工数を見積もります。
・表示の確認だけで操作を伴わないテストケース：3分
・一画面内の操作で完結するテストケース：5分
・複数の画面を遷移して操作するテストケース：10分
・応答待ち時間が発生するテストケース：15分
など、テストケースの分類や、3分・5分といった工数はプロジェクトごとに決めます。
また、テスト実行には、テストケースの手順通りに実施する時間だけでなく、不具合検出時の不具合報告や修正後の確認をする時間も含めておく必要があります。
3.実行スケジュール作成
実行スケジュールを作成します。
テスト計画時にテスト作業全体のおおまかなスケジュールを作成していますが、ここではタスクを明記した詳細な実行スケジュールとなります。そのため、作業工数はテスト作業工数の見積もりで算出した工数を使用します。
スケジュールの単位についてはプロジェクトによって異なるため、プロジェクトの期間や進捗管理の目的に合わせて、時間単位または日単位といった最小単位を決めます。最小単位を決めたらテスト実行の準備作業から実施するようスケジュールし、続けてテスト実行手順を確認しながらテスト実行の作業をスケジュールします。その際、制約事項を考慮して調整を行います。
リスクが発生する可能性を考慮しておくことも必要です。綿密にスケジュールを立てたとしても、テストケースが予定通りに消化できないことがあります。
具体的には以下のようなことが発生する可能性があります。
・テストケース消化のペースが遅いテスト実行者がいる
・テスト用機器の操作の習得に想定以上の時間がかかる
・不具合が想定以上に見つかり、不具合修正や確認に時間を要する
・不具合の影響度が大きく、テスト実行を中断する
このような事態の発生に対応できるようバッファを用意しておくとよいです。また、リスク対応として、テスト作業を見直すタイミングをスケジューリングしておくことも必要です。不測の事態が起こった場合にスムーズにリカバリーできるよう備えておきましょう。
テスト実施(実行)
テスト実装でテストの準備がすべて整ったことを確認した後、テスト実行を行います。テスト実行では、テストケースに記載された手順を実施し、結果を確認します。
テストの結果がテストケースに記載された期待値と異なっていた場合には、不具合チケットを起票して不具合の情報を報告します。
テストの担当者が不具合チケットを作成する際には、開発者に正確かつスムーズに情報が伝わるように記述します。開発者が不具合を正確に把握、再現できるよう、不具合と判断した事象と仕様との相違点、再現するための手順やどれくらいの頻度で再現するかを具体的に記述します。また、再現確認や原因の特定に役立つよう、不具合が起きているテスト条件だけでなく、不具合が起きないテスト条件なども報告をします。これにより、不具合の再現確認が効率的に実施できるようになります。
不具合の報告を受けた開発者は、不具合を確認したうえで必要に応じて修正を行います。その後、テストの担当者は修正確認のためにテストを再実行します。その際、システムの他の部分に影響が無いかを確認するテストや、不具合の発生状況や判明した原因の傾向を分析し、その分析結果を踏まえた追加のテストを行うことがあります。
SHIFTでは、不具合チケットはただ「不具合を報告する」だけではなく、「開発者が正確かつ効率的に不具合を改修できるような報告をする」という意識で記述することを大切にしています。開発者が不具合の確認や修正を行う際に、情報不足や行き違いがないよう、必要な項目を不具合チケットに記述することを基本としています。
(障害報告書の書き方はこちら：障害報告書の書き方について 目的や項目、書き方のポイントをわかりやすく解説)
まとめ
テスト実行に必要な準備や実施手順は確認できましたでしょうか？テスト実行は準備を抜けもれなく正確に行うことが最も重要であることがお分かりいただけたと思います。
本コラムで触れた内容は、どんなプロジェクトにおいても共通するテスト実行に向けた準備や実施手順の一部です。もちろん実践となりますとプロジェクトの特性や目的、状況に合わせた対応が必要になるため、ソフトウェアテストの知見のあるメンバーの採用や専門企業へのアウトソースによってノウハウを蓄積していくことも必要です。
ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
資料ダウンロード/動画視聴
ダウンロード
