ITごはん

ITを活用したい人、ITで何か作りたい人、そんなITでごはんを食べる人のためのブログ

【テスト】発注者のためのアプリ開発のポイント⑤

はじめに

今回は「テスト」となります。

プログラムを作成した後は、必ずそれが意図したとおりの動きになっているか、 テストを行います。

開発者側で、基本的なテストを済ませた後に、 発注者側でもテストを行います。 この検収を目的とした、テストを UAT(User Acceptance Test ユーザ受け入れテスト・検収テスト ) と呼ぶことも多いです。

基本的には、開発者に依頼した要求どおりに、 アプリが動くかどうかを確認することになります。

テストの流れは、以下の様な流れになります。

1 テスト計画
2 テスト設計
3 修正等の対応

それでは、次に上記のプロセスを見ていきましょう。

テスト計画とテスト設計

まずは、テストを実施する前にテストの計画を立てましょう。 これはだれが、いつまでに、どういった、どの範囲でテストする、 といったことを決めて行きましょう。

そして、テスト設計になります。 テスト設計では、テストケースという実際に試してみる操作を整理します。

例えば、新規ユーザーがログイン→記事をお気に入りに追加する→お気に入りボックスに追加されていること のような形で、一連の操作手順(シナリオ)の用意も必要です。

規模が大きいアプリの場合は、全てのシナリオを実施することが、 出来ないこともあります。 そういった場合は、優先順位をつけて、確認するテストケース、シナリオを決めていきましょう。

テストケース作成のポイントを挙げると以下のようになります。

- 仕様書や依頼した画面イメージなどを用意して、1つ1つの項目を突き合わせる(テストの抜け漏れを防ぐ)
- 開発者側がテスト仕様書(テスト報告書)を作成した際は、テスト仕様書にテストが網羅されているか確認する
 (もし、テストに漏れがあれば、開発者にテストをおこなってもらう)
- まずは最も多いであろうスタンダードな、操作の流れを再現してみる
- そして、あまりないであろう操作の流れを再現してみる(例外系)

このようなテストケースをまとめてテストケースを作成することが一般的です。

テストの実施

次は、テスト計画やテスト設計(テストケース)にしたがって、 実機でテストとなる操作を行います。 そして、そのテストの結果が、想定した通りの結果(正常)か、 想定と異なるか(異常)かを記録していきます。

テスト後の対応

テストで問題が確認された場合は、 その対応策を考えなければいけません。 例えば、急に強制終了するとか、 登録したデータが壊れてしまうなど、 そういった場合は、致命的なバグとなりますので、 リリース前に修正を行い、再度テストをおこないます。

また、レイアウトがほんの少しズレているとか、 非常に稀なケースで画面が崩れてしまう、とか そのような場合は、一旦、対応を先送りにすることもあります。 (次回に改修する際に修正するなど)

いずれにせよ、顧客満足度や 品質、納期(リリース予定日)、費用の観点から、 対応する範囲を決定することが大切です。

また、iOSの場合、致命的なエラーが残っているケースは、 リリース申請の結果がリジェクト(申請拒否)となり、 修正が求められることもあります。

テストと修正を、問題がなくなるレベルまで繰り返して、 ようやくリリース作業に移ることができます。

今回はここまでです。 次回、リリースとプロモーションについて説明します。

Androidアプリテスト技法

Androidアプリテスト技法