開発したアプリが納品されてきました。
思ったように動かない！
バグがある！
こりゃけしからん！！
単純に考えると、そうなりますよね？
いや、ちょっと待ってください。
不具合（バグ）を全て同じように括ってはいけません。不具合にも質があるのです。
バグがあるのはよくないシステム？
うまく動かないのは一緒なんだから、良いバグも悪いバグもない。そんなシステムはよくないシステムに決まっている。
ユーザー側の心理としてそう考えるの当然です。
しかし、ここは、どれだけ慎重にテストをしたところで、バグ０にはならないのが事実であること。それは、Microsoftでも、Appleでもバグがなかったことがないことにも表れています。
数百億のシステムであっても、大規模障害が起きているのも事実。
多額の費用をかけても、逆に小さいからといってもなかなかバグゼロにはならないのです。
まずは、バグはあるものだということを受け入れて頂くところから始めなければなりません。
このように分かりやすい不具合ならまだしもプログラムのバグはちょっと見だとわかりません
良いバグと悪いバグ
同じバグでも違いは存在します。
２つのアプリがあり、それぞれバグが１０存在したといったところで、同じだけ質が低いとは言えません。
良いバグとは
我々開発者側の立場としても、バグが良いということは多少語弊があります。表現を変えると、テストの際に見つかって良かった、と言えるバグという方がいいかもしれません。開発者としても、できる限りバグはなくそうと作っているわけですが、前述のとおりなくしきれないのが残念なところだからです。
話しを戻しますと、開発の過程では単体テスト、結合テスト、総合テスト（システムテスト）、受入テストなど幾つもの種類のテストが存在し、それぞれのテストでその目的に応じたテストを実施します。
通常、お客さまが参加するのは、受入テストのみ、あるいはシステムテストからですので、それ以前のテストは目に触れることはないでしょう。（そうではないケースもありますが、当記事の想定読者の方はないと思います）
受入テストでは、その名の通りアプリ・システムが、要件通りにできているか、受け入れるために行うテストです。
主に、実際の業務での利用方法に基づいて動作確認をします。
そこで、見つかるバグが実際の現場でなければ、気が付かないような作業手順を行ったため発生した不具合。
これは、良いバグの範疇です。
例えば、開発者としては、A業務を行う前には、B業務が必ず行われているはずだと思い込み作成してしまったものの、実際の業務では時として、B業務を行う前にA業務が行われることがある。そうすると、システムではA業務を行う機能にて、前提としていたB業務のデータが存在せず、不具合が発生する。このようなケースです。
（もちろん、思い込みはいけないので本来これは要件定義フェーズで解決すべきことですが、ユーザー側も現場の細かな業務に気が付かなく、「A業務を行う際は、B業務は必ず行っています」と発言してしまっていた。ということもあります）
悪いバグとは
悪いバグは非常に分かりやすい不具合です。
そもそも起動しない。
画面の表示が乱れる。
単純な計算（合計など）が合わない。
ボタンをクリックすると、異常終了する。
数値項目に文字が入る。入るのはいいとしても、エラーメッセージも出ず更新で異常終了する。
このようなものです。
これらの問題が起こる理由は「単体テスト」という、プログラム（あるいは画面）レベルでのテストを十分に行っていないからです。受入テストの段階で、このレベルのバグが多発するようであれば、テストのやり直しを指示してもいいくらいのものです。このレベルの問題が解決していないとアプリ・システムにおいて、その先の問題が解決していることはまずないと言っていいでしょう。
ですから、テストが全く進まなくなります。
再テストは勇気ある判断
単体テストレベルのバグが多発する時には、再テストを指示しても良いくらいと書きました。
しかし、これも実は勇気が必要な判断です。
こんなバグが多発するプロジェクトというのは、それなりの規模であり、要件定義が予定よりも延びた、設計が思うように進まなかったなど、上流工程で問題があり、そのしわ寄せがプログラム開発フェーズに来てしまった。つまり、設計が不十分あるいは、開発期間が短縮されてしまった。こんなケースが少なくありません。
そうすると、既にプロジェクトが遅延している中で、改めてテストの時間を取り直すのは余裕がないと考えてしまいます。
もちろん、一概に再テストということでもありません。
単体テストレベルのバグが出ているのは、ごく一部の機能に偏っているだとか、ある傾向があり、それはとりあえず目をつぶっても全体への影響がないなど、プロジェクト全体から見て判断しなければなりません。
それでも、再テストが必要となると、予算と期日を加味して考えなければならないので勇気ある判断が必要となります。
受入テストで発生する不具合（バグ）は、その質を見極め、発生してやむないものなのか、発生すべきではないものなのか、選別の上、次のステップへと進むべきものなのです。
スマホアプリを使った業務システム構築のことなら
株式会社クラボードへお気軽にご相談ください