しっかりとテストをし、利用者からいいねをもらえるようになるといいですね。
業務アプリ開発 はじまりから運用までの１６ステップ～ indexはこちら
アプリというと、BtoC、つまり一般ユーザが利用するゲームやSNSなどのアプリを想像するかもしれませんが、今回は、業務系アプリを開発する場合、かつ開発を外部委託する場合を前提として説明しています。
今回は、12番目のステップ「受け入れテスト」です。
12.受入テスト
受け入れテストとは、その名のとおり、アプリ開発会社が作成したアプリを受け入れるためのテストです。この名称は違いがある場合もありますが、納品されたアプリのテストという意味で必ず行うことに変わりありません。
前回のステップ「テスト準備」で、テストの準備について書きました。その準備に基づいて、テストを開始します。
テストの心構え
まず、テストを開始するにあたっての心構えをご紹介します。
大切な考え方として、不具合があることを問題とするのではなく、不具合を見つけることに意義があるということです。
テストが終われば、間もなく本番リリースで利用が始まるわけですが、不具合は運用が始まってから発見されるよりも、始まる前に見つかった方がいいに決まっています。そして、ソフトウェアの不具合というものは残念ながらゼロにはならないため、運用開始後も発生をゼロにできません。しかし、限りなくゼロにすべく、テストで不具合をつぶしていくのです。
正直なところ、不具合が出れば気持ちがいいものではありません。しかし、そこは気持ちを入れ替えて、テストで見つかってよかったと考え直すようにしましょう。
とは言え、不具合が出ればいいというものではありません。
言うなれば、許せる不具合と許せない不具合というものがあります。
アプリを起動した瞬間にクラッシュする。入力項目にエラーがないのに、登録ができない。これらは許せない範疇の不具合です。不具合と言っても、質の善し悪しがあるのです。これについては、以前書きましたので、こちらを合わせてご覧ください。
（ご参考）不具合（バグ）にも質がある
テスト実施と不具合管理
テストを実施すると、不具合が発生します。
不具合は、エクセルやGoogleスプレッドシート、その他開発ツールなどによって管理します。
具体的には、いつ、誰（テスト者）が、何をしたとき、何が起こったか。そして、その時のOSのバージョンや、利用したデータを記録します。
この不具合のリストに対して、アプリ開発会社は、修正を進めて行くのですが、その際、優先順位付けが重要になります。
その不具合を解決しなければ、次のテストに進めないものは優先順位を上げ、テキストの誤り程度の不具合は優先順位を落として対応してもらいます。もちろん、両方を遅延なく解消できるならば全て進めて構いません。その時点で、発生している不具合の量と、不具合を修正する担当者のリソース状況にて判断します。
デグレードに注意
デグレード、時に先祖返りとも言うこの言葉は、以前修正した不具合が、何かしらのタイミングでまた復活することです。（当社も起こしたことはあります。恥ずかしながら・・・）
修正に修正を重ねていくと、プログラムのバージョン管理でミスを起こし、前回修正版のソースコードを失ってしまったりすることがあるのです。
そうすると、せっかくテストを終えた機能なのに、再テストを行わなければならなくなるのです。
これも起こしてはならないミスではありますが、このようなことがあり得ることは頭に入れておいてください。但し、もし、こんな現象が頻発するようならば、一旦テストを中止し、アプリ開発会社へ再テストを申し入れる必要も出てくるでしょう。
テストはアプリ開発会社が十分行って当然なことではある一方。発注側も自社の要件通りになっているかを確認する重要な工程です。本番で不具合を起こさないことを念頭にテストに臨んでください。
スマホアプリを使った業務システム構築のことなら
株式会社クラボードへお気軽にご相談ください