はじめに

情報システム部１年目の佐藤と申します。私はソフトウェア開発の試験工程に携わっており、日頃から試験業務を専門的に対応いただいている方に試験の基本的な考え方についてレクチャしていただく機会がありました。本記事では、そのレクチャで学んだ内容と業務で実際に試験を経験して感じたことを交えながら、試験の流れと各工程で気を付けるべきポイントについて記載していきます。

試験の流れ

まず、試験工程の概要を説明します。

１試験計画

　試験計画では、スケジュール立案を行います。スケジュール立案は「どの試験をどの優先度でいつからいつまでに実施するか」をまとめるものです。以下の内容を検討し、計画表に記載します。

各試験の開始日と終了日
期限
難易度
優先度

また、試験項目書の作成をします。項目書では以下の内容を記載します。

開発内容に対して必要な試験項目
前提条件
手順
期待値
環境（OS、スマートフォンの機種）

２試験準備

　試験準備では、試験に使用するスマートフォンのOS変更やアプリケーションのバージョンアップなどが必要になります。ただし、OS変更には時間がかかるため、試験で使用するスマートフォンのOSを確認し、OS変更作業が必要か事前に判断しておく必要があります。

３試験実施・不具合記録

　試験は、試験項目書に沿って実施し、結果が期待値と一致する場合OK、異なる場合はNGとして記録します。また、結果と合わせて試験日時や試験者名も記録しておきます。

　試験結果がNGの場合、バグ発生時には不具合の切り分け、ログ収集を行い、レポートを作成します。レポートは、他の人が再現できるように抜け漏れなく記録する必要があります。そのため、試験項目ごとにバグの内容や対応期限、使用したスマートフォンの機種名、OSのバージョンといった記録すべき内容事前に定義し、決められた項目に沿って不具合を記録します。また、バグの種類に応じて動画や画像の取得をすることで文字情報だけでなく視覚的な証拠を残し、不具合の再現性を重視した記録にします。

次に、レクチャ内での演習と実務での気づきを交えながら、試験計画と試験実施のポイントを記載していきます。

試験計画

＜レクチャでの演習内容＞

　試験スケジュール立案の演習では、開発スケジュールや各試験の生産性、テスターの人数といった資料をいただき試験実施開始と終了日を検討しました。テスターの人数/休暇・試験難易度・バグ発生時の対応・並行試験・レビュー期間・環境メンテナンス日・強化試験（不具合の改修部分に対して行う試験）など多くのことを考慮しておく必要があります。

　実際にスケジュール立案を体験させていただきましたが、多くの条件や情報を把握して整理する必要があり、膨大な資料から必要情報を探すのに時間がかかりました。時間内では情報の抜け漏れもあり、試験計画には知識や経験が不可欠だと感じました。

＜実務での気づき＞

　続いて、レクチャで習った内容が実務でどのように役立ったか、そして実務経験を通じて感じたポイントについて紹介します。まず、計画の重要性を再認識した経験についてです。一度、スケジュールを考えずに試験を実施してしまったことがありましたが、試験の順番を考えられていなかったため予想以上の時間をかけてしまいました。（下表：スケジュール1）試験の中には、結果が出るまでバッチ処理などの影響で数日待たなければならないものもあります。レクチャでは、実施に時間がかかる項目やバグ発生の可能性が高い項目は早めに実施することを学びました。そのため、時間のかかる試験を先に行い、結果待ちの間に別の試験を進めるようスケジュールを立てることで試験全体の時間を短縮できました。（下表：スケジュール2）

　一方で、レクチャで学んだように計画では多くの要素を考慮する必要がありますが、実務ではすべてを網羅することは難しく、スケジュール通りに進められないこともありました。情報共有の体制や管理方法を工夫することはもちろん必要ですが、不測の事態に備えて余裕を持ったスケジュールを組むことが重要だと感じました。

＜ポイント＞

資料整理/管理の重要性

→情報の抜け漏れを防ぎ、計画・実施時間の削減につながります

計画は細かく考えすぎない＋余裕を持たせる

→ 計画は予定通りに進まないこともあるため、工数は×1.1程度で見積もり、後から調整できる余裕を持たせると良いです

試験実施・試験結果記入

＜レクチャでの演習内容＞

　レクチャでは、スマートフォンを使ってアプリの試験を行いました。下表にあるような試験項目書に沿ってアプリの初期設定から試験を行いました。

しかし、初めて触るアプリであったため、試験項目書に記載された実施手順や前提条件を正確に読み取るのに時間がかかりました。試験項目書の内容を適切に理解し、正確に試験実施を行うためには経験や知識が必要だと感じました。また、試験実施者に経験が少なくても正確に試験実施ができるよう、手順や前提条件を不足なく項目書に記載しておく必要があると思いました。

＜実務での気づき＞

　実務でも前提条件を把握しきれていなかったことが原因で試験結果をNGとしてしまったことがありました。しかし、先輩に相談し、条件を確認した上で再試験したところ、結果はOKとなりました。この経験から、最初からすべての条件を項目書から把握しておくことは難しく知識や経験も必要になると感じました。

＜ポイント＞

試験項目書の記載精度が重要

→実施者に伝わるように記載することが大切です

適切な判定には知識・経験も必要

→条件を把握した上で試験実施をしないと誤った判定をしてしまう可能性があります

→試験の実施経験が浅い場合には他者に再確認すると良いです

自動化試験の活用

　最後に、自動化ツールを使用した試験の効率化についてご紹介します。自動化試験は「早く・安く・多く」実施するために導入されますが、構築コストや技術的課題もあり、すべてを自動化することはできません。自動化のメリットが出やすいのは、同じ内容の試験を繰り返し実施する必要がある試験です。一方で、画像や文字の位置、音声の確認、移動を伴う試験などは自動化することができません。

　実際に自動化された試験を見学した際、最初に実行ボタンを押すだけで次々と試験が進み、結果が自動で記録されていく様子を確認しました。手動での実施と比べて、圧倒的なスピードの違いを実感しました。

＜ポイント＞

目的は「効率化」

→自動化することを目的とせず、適切な範囲で自動化を実施する必要があります

自動と手動を適切に分担

→繰り返し実施する試験で効果が大きく、画像・音声・UI確認は手動が必要になります。

まとめ

　今回のレクチャを通じて、試験は多くの要素を考慮して計画から実施まで行っていく必要があることを実感しました。そのため、項目書などの資料を作成する際には認識齟齬が起きないように相手に伝わりやすい表現を心がけること、チーム内外でコミュニケーションを積極的に取っていくことが必要になると思います。本記事が、試験の基本を知るきっかけや試験方法を振り返る参考になれば幸いです。最後までお読みいただきありがとうございました。