見出し画像

完璧なテストケースの設計をしていますか?

外資系企業でソフトウェアエンジニアをしております、タロイモと言います。今日もよろしくお願いします。

開発者として、テストの作成は通らなくてはいけない道です。
最近では、テスト駆動開発なんかが流行っているので開発者の方もテストに触れる機会は多いのではないでしょうか。 

今回の記事では、完璧なテストケースとはどういうものか考えてみたいと思います。


0. バグの数は無限

バグとはコンピュータのプログラムにひそむ誤りのことなのですが、バグがないソフトウェアなんてないと考えられます。

例えば、みなさんが大好きなポケモンにもバグがありますよね。
僕が子供の時遊んでいた、ダイヤモンド・パールではチャンピオンロードの途中であることをすると伝説のポケモン「ダークライ」がにいる島に行けてしまうバグがありました。

本来、ダークライは映画を見た人しか手に入らないので、これは大きな損失ですよね。

日本でも指折りの優秀な開発者が集まるポケモン・任天堂。ゲームフリークでもこのようなバグが起きてしまうのです。

このような事実から、バグに関してよく言われる言葉として、こんな言葉があります。

Then the program is tested and the number of faults discovered is used to estimate the number of faults yet undiscovered.
ーテストで見つかったバグの数は未発見のバグの数を推定するのに役に立つ

つまり、バグって探しても探しても無限に出てくるんですね。

これは、バグが自分が開発する製品だけでなく、CPUやOS、開発環境など様々な要素が絡み合った複雑な問題に起因するからなんですね。

なのでテストケースでは、バグを探すことを目的としてはいけません。

では、どうしたら完璧に近いテストケースを作ることができるのでしょうか。

本記事では、テストケース作成をする上で考えるべき3つの大事なことを説明します。


1. 品質基準を定める

テストケースを作成する上で大事な基準を定めることが重要です。

あなたの開発する製品で大事なことはなんでしょうか?
僕が考える製品で大事なことは、

お客さんが製品に納得すること

です。
趣味でもない限り、お客さんのニーズに答えることが一番大事なことだと思います。

ではお客さんのニーズとはなんなのか?

こればかりはお客さんによると思います。
デザインを重視するお客さん、使いやすさを重視するお客さん、
何を重視するかはお客さんによります。

BtoBの製品では要件定義の段階で、お客さんのニーズを探ります。
BtoCの製品ではターゲットを定めて、マーケティング分析でニーズを探ります。

結局、お客さんが「デザインがよければ、処理にバグがたくさんあっても良い」といえば、それが品質基準ということになるわけです。
(ありえないですが)

なので、テストケース作成の最初の段階では、「この製品の目的(つまり品質基準)とは何であるか」を考えることが大事です。


2. テストをする部分を選択する

品質基準を定めたら、次はどの部分をテストするかを考えます。
ここでは、もちろん品質基準に沿ったテスト対象を定めます。

とは言っても、時間もお金も有限なので、テストケースは少ない方が良いですよね。

ここではMECEという考え方をします。

MECE(ミーシー、Mutually Exclusive, Collectively Exhaustive)とは、「漏れなく、ダブりなく」という意味でコンサル業界でよく聞かれる言葉です。

スクリーンショット 2020-06-03 23.55.04

テストケースでダブりがあると同じ部分を何度もテストしていることになるので、無駄になります。

漏れというのは難しいですが、品質基準に含まれるテストはほぼ完璧にテストするべきです。これが製品の品質を決めるのですから。


3. バグの重要度を決める

いよいよテストをし、バグがたくさん見つかりました。

しかしここで大切なのが、このバグを重要度で分けるということです。

よくテストの品質を確認するのに使われるものとして、信頼度成長曲線が使われます。

理想的な信頼度成長曲線は、時間が経つにつれてバグの新規発見数が減っていきます。

スクリーンショット 2020-06-04 0.11.33

しかし、単純にバグの総数で製品の品質を確認することができるのでしょうか。

というのも、この曲線は全てのバグを平等なバグとして扱ってしまっています。品質に重要な影響を与えるバグとあまり影響がないバグがあるとして、
品質に重要な影響を与えるバグの数は減っていないのに、あまり影響がないバグか減ることでこのような理想とされる成長曲線を描いてしまう場合があります。

なので、品質基準を担保するには、バグの重要度別に信頼度成長曲線を分けるなどの工夫が必要だと思います。


4. まとめ

以上が、テストケースを考える上で重要な3つのことでした。

結局、何が言いたいかというと

時間とお金が限られている中で、バグを全てを見つけることは不可能なので、完璧なテストケースを目指すのではなく取捨選択をし、お客さんのニーズを満たすことを目指すべき

ということです。

ご精読いただきありがとうございました。

よろしければサポートお願いします! サポートは、サービスの開発・改良や、記事を書く際の素材費とさせていただきます。 少しでも有益な情報発信をしていけるよう努めてまいります。 是非とも応援よろしくお願いします!!!🙇‍♂️