「テスターちゃん」で学ぶソフトウェアテスト⑤
「Qiitaに書いてた記事をnoteに移行しよう」シリーズと言うことで、Qiitaに投稿している記事の掘り起こしとなります。また、内容の整理も行う予定のため、Qiitaに投稿した記事をそのまま移行する形とならない場合もあります。ご了承ください。
■Archives
■テストの７原則
どのようなテストにも共通する原則がある。
この原則を頭に置いておくことで、効率的にバグを見付けるヒントとなったり、リーダーになった際に効果的なテストのアプローチを練るヒントとなったりする。
・原則１：テストは欠陥があることは示せるが、欠陥がないことは示せない
欠陥＝バグのこと(フォールトともいう)。
人のミス(エラー)によって、バグ(欠陥)を埋め込んでしまうイメージ。
※JSTQBでは下記のように定義している。
エラー＝間違った結果を生み出す人間の行為。
欠陥(バグ/フォールト)＝作業成果物に存在する、要件or仕様を満たさない不備or欠点。
故障＝コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。
例えば
テストケースを100件実施してバグが見つからなかったとする。
これだけやって見つからないのだからシステムにバグはない、と言えるか？
❌ 言えない。
何故ならそのケースではバグが見付からないだけで、他の場所にバグがあるかもしれないから。
つまり
ない≠見付からない
・システムにバグがあることを示すのなら、1つバグを見つければいい。
・だけど、ないことを示すのは非常に難しい。
→ないとは言い切れない。
・原則２：全数テストは不可能
全てのパターンをテストして欲しい。
→全パターンって何をどこまでテストすればいいの!?
テストを知らない人は「とにかく全部見て欲しい」と言う。
→だけど、完全に全組み合わせは不可能である。
何故ならパターンが爆発するから。
時間は無限ではないので、テストケースを絞る必要がある。
→テスト設計技法を使ってテストケースを減らす。
システムの目的や使われ方・想定されるリスクに着目しどこを重点的にテストするのか戦略的にテストを行う必要がある。
テストは工夫次第でかなり効率的に出来る。
だけど、無限に非効率にすることもできる…。
・原則３：早期テストで時間とコストを節約
例えば、嫌いな食材があるので抜いてくれと言ったが、その食材を入れた料理が出来上がってしまった。
・話を聞いた時に、
・その食材を調理している時に、
・鍋やフライパン等に入れる前に、
気付いていればその食材を抜くことが出来たはずである。
問題は気付くのが遅れれば遅れるほど、修正に手間がかかる。
そのため、早い段階からテスト(確認)が大切。
また、動的テストだけではなく、レビュー等の静的テストも組み合わせて行うことも早期テストとして重要となってくる。
・原則４：欠陥の偏在
つまり、バグの集中について。
例えば、シンプルな草原にも虫がいる。
だけど、生命系が複雑な森の方が虫がたくさんいる。
＝システムも同様である。
シンプルな場所に比べ、複雑な場所の方がバグが多い傾向にある。
バグは均一にあるわけではなく、特定の場所に集中し易い。
・忘れがちな処理のある場所。
・間違え易い処理の場所。
・不慣れなメンバーが作った場所。
・他部署が作った機能。
※その部署に聞かずに進めていて、考慮漏れが発生することもある。
・テストも全て均一に行っていると注意する場所に時間を割けなくなることがある。
【対策】
・過去のテスト結果やバグ分析からテストを厚くする場所を絞り込む。
・開発に「不安なところはないか(不安な箇所、開発でテストできない場所、やって欲しいことなども)」と聞く。
など…
・原則５：殺虫剤のパラドックスにご用心
虫は同じ殺虫剤を使い続けるとその殺虫剤に耐性がついて死ななくなる。
つまりテストにも同じことが言える。
同じテストばかりだと新たなバグが出せなくなってくる。
→出たバグは修正され、そのテストの耐性が出来るからである。
テストでバグを出すには絶えず視点を変えることが重要。
【自動化の場合】
自動化テストは同じテストを繰り返すことになる。
→目的がデグレ(リグレッション)ならいいが、新しい発見にはほぼ繋がらない。
つまり、自動化テストを使う場合、
・デグレ(リグレッション)がないことを確認したいのか
・新しいバグを見つけたいのか
をよく考えること。
・原則６：テストは状況次第
例えば、フライトゲームのテストをしたことがあるからと言って、本物の飛行機のテストもそのゲームと同じテストを実行出来るか？
類似のアプリでもテスト期間に余裕のある時と全くない時で同じペースでテストが出来るか？
ネットショップのWebサイトと医療機器のソフトウェアで同じテストを使うことが出来るか？
もちろん出来ない。
同じようなアプリをテストする場合、置かれた条件で取るべき手法が変わってくる。
扱うモノが変わったらテストも異なるものが必要となる。
ほぼ同じモノのテストにしても状況や環境でやり方は変わる。
テストの基礎知識を身に付け、状況によってそれらを組み合わせ対応する必要がある。
＊闇雲に一つのやり方にこだわらないこと。
テスト期間に割とバグ修正期間が考えられていないこともあるので、注意すること。
・原則７：バグゼロの落とし穴
あるアプリでは入力系のバグは全部対応した。
文字入力が半角数字1つのみしか入力を認めないと言う条件となっている。
→だけどそれ以外の入力を試してみたい。
条件があるせいでテストとしては物足りなくなってしまった。
バグ報告があったからと言って修正し制限をかけすぎたため使い難くなる。
小さなバグを直すために複雑な処理を通したため反応が遅くなる、と言ったことが多々ある。
木を見て森を見ずにならないように気をつける。
→特定の部分に集中してしまったため、他に気が回らないようなことにはならないように。
■まとめ
テスト７原則を知らなくても、テストは出来る。
だけど、知っていた方がテストの攻め方が変わってくるし、工夫・方針・対応も変わってくる。
テストの７原則はテストの根っこの考え方である。
＊テストエンジニアが守る範囲は膨大なので、普通にやっても上手に守れない。
そのため、どうやって守っていくのかテストの創意工夫が必要となってくる。
■個人的な考えだけど
個人的には、JSTQBのFoundation Levelのシラバスの第1章の内容については雇用形態問わず新人研修の最初の段階で教えた方がいいと思っています。
知っているのと知らないのとでは、その人の心構えや取り組み方等が違ってくるのではないかな。
テストの7原則とかもうちょっと早く知りたかったよ…。