テストの7原則ってなんだっけ？

こんばんは。ラオです。

実は来年前期に開催されるであろうJSTQBの資格を取ろうと思い

絶賛勉強中なのですが、タイトルの通り7原則を忘れていました。。。

少なくとも4年くらい前に講習を受けて勉強していたはずなのですが

すっかり忘れていました。えぇそれはもうすっかり。

この原則ってなんだっけ？ってレベルではなく

へぇ、こんな原則があるんだ！みたいなレベルです。

ということで、今回は忘れないようちゃんとアウトプットしようと思いました。

原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない

割と原則の言葉通りの意味ですね。

バグが不具合を発見したら欠陥があると示せますが、

逆にバグや不具合がないからといって欠陥がないとは示せません

って話です。

つまりは意図しない動作をするとバグや不具合があるかもしれない

みたいな感じですかね。

原則2：全数テストは不可能

あたりまえ体操！！！

入力する可能性のあるデータと条件の組み合わせを

全パターン確認することは不可能ですよって話

数パターンならまだしも多くなると何千、何万って出てくるので

流石にそこに時間をかけるわけにもいきませんね。

原則3：早期テストで時間とコストを節約

極端に言うと、リリース前とリリース後に不具合を見つけた時の

時間とコストが全然違うよねって話

リリース後に対応するとなると、リリース前にプラスで

コードを思い出す時間が必要だったり、欠陥を特定する必要がありますし

費用もものによっては回収しないといけなかったり

返金作業も入る可能性がありクソ高い損害を受けますよね

原則4：欠陥の偏在

ソフトウェアはいろんな要素から構成されているので

品質は均一されず、特定の部分に集中することが多いよねってこと。

ソフトウェアの欠陥の8割は全体の2割の箇所に集中して存在する

という話もあるらしい。知らんけど。

原則5：殺虫剤のパラドックスにご用心

実はこの単語を見た瞬間にこれ習ったことあるくね？って気づきました。

あまりにも特徴的な原則だったので。。。

で、肝心な原則についてですが

1つのソフトウェアに対して同じテストを何度も繰り返すと

最終的にそのテストでは新しい欠陥は見つからなくなるって内容です。

回帰テストなどでは有効ですが、新機能を作った際は

システムのほかの部分を狙ったテストをしてみるとか

異なったパターンを入力してみるなど視点を変える必要って話。

原則6：テストは状況次第

顧客が利用する状況や目的、ソフトウェアの作り方によって

テストの方法を変えましょうねーってこと。

これもわりと原則通りですね。

原則7：「バグゼロ」の落とし穴

これはわりと性能面に関することが多いかな？

一応仕様通り動きます！不具合ないです！となっても

このページに移動するのにめっちゃ時間がかかります！

みたいな感じになると嫌ですよねｗ

確かに動作はするけど、ストレスがたまるのは勘弁。