前回は何回かに分けで１つのアプリを開発するために必要な一般的な流れ（ニーズ・企画、設計、製造）を簡単に解説しました。

作りたいアプリが出来上がった後はテストが不可欠になります。せっかく作ったのにバグだらけだったらすぐにお客様からは不信の声が上がるはずだし、会社にとっては営業利益に関する大事なことになります（損害賠償することもある大事なことです）。

設計については開発全般に於いて間違いが発覚したら随時に修正できるものです（もちろん、製造段階に入って頻繁に設計を修正するのはプロジェクトの延期や失敗に繋がる要因になるでしょう）が、これに対し、テスト段階は終わってしまえばその後はアプリを公開したり、お客様へ渡したりするので、その後に不具合が発覚したらユーザやお客様にも影響を及ぼしてしまうので簡単に済むことではないです。

マイクロソフト製の製品にですらバグはあるので、誰でも自分が開発したアプリは絶対バグがないとは言い切れないものです。できるのはちゃんと責任を持って真面目に、細かくテストを行い、「できる限り設計書通りになっている」ことを証明することです。

一般的にテストの前にまずテストシナリオを作成し、シナリオに則ってテスト項目表を作成しますが、今回のアプリは機能が単一であるためシナリオの作成は省略します。

テスト項目作成

GUIアプリのテスト項目は基本的に下記のような考え方で作成します。

・画面起動時の初期画面
・画面上の各ボタンのイベント

「GDI Changerアプリ」についてのテスト項目は下記のような感じです。

・ファイル：　テスト項目_DPIChanger.xlsx
上記excelの内容は下記のようになります。

テスト項目は詳細設計書を基に、確認すべきであるすべての点を細かく書きます。テスト項目は細かいほどテストが全面的に行われ、アプリの信頼性が向上されます。

DPI Changerはシンプリなアプリであるため、テスト項目もあんまりないですが、実際の開発現場で開発するアプリは規模によってテスト項目数も大きく変わります。

テストエビデンス作成

テスト項目ができたら、次はテスト項目通りにアプリを操作し、画面のハードコピーをexcelファイルに保存し、テストのエビデンスとします。

尚テスト結果のOK/NG状況とテスト実施者、テスト日付をテスト項目表に記入し、テスト完了とします。

テスト中に不具合を見つけた場合、不具合報告表を作成し、開発者にアプリの修正を求めます。

上記のような感じでアプリのテストが行われます。

テストシナリオ、テスト項目、エビデンス等の作成は実際の会社によってそれぞれルールが違うので、会社のフォーマットとやり方に従って行うべきです。

まとめ

DPI Changerはシンプルなアプリなので、単体テストだけで済むんですが、アプリの規模によっては結合テスト、さらに大規模システムについては総合テストなどが必要になります。

何れにしても、「テストシナリオを作成し、シナリオに則ってテスト項目を作成する」というやり方には変わりありません。

テストは会社によってそれぞれ違います。今までやってるやり方を理解し(空気読んで)、同じような感じでテスト仕様書作成したりテスト実施する必要があります。

テストのやり方についてはあんまり決まった方法がないので、簡単に解説するだけですが、いずれにせよ最後の目的は「完全に仕様書通りになっていること、不具合０であること」を実現するために行うチェック作業だという認識です。

では、バイバイ！　Have a nice day!