0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

「テスターちゃん」で学ぶソフトウェアテスト⑤

Last updated at Posted at 2020-04-04

#1. 「テスターちゃん」について
初心者(新人)向けに描かれたソフトウェアテストの漫画になります
たまたまJSTQBについて調べていた時に見付けたブログの記事がきっかけで読むようになりました
JSTQBを取るメリット5選

今でも更新がある度にチェックしたり、書籍版を読み返したりしたり、とテスト関連の資料として活用しています

Blog
書籍版

#2. LOG
「テスターちゃん」で学ぶソフトウェアテスト①
「テスターちゃん」で学ぶソフトウェアテスト②
「テスターちゃん」で学ぶソフトウェアテスト③
「テスターちゃん」で学ぶソフトウェアテスト④
「テスターちゃん」で学ぶソフトウェアテスト⑤ :point_left_tone1:イマココ
「テスターちゃん」で学ぶソフトウェアテスト⑥
「テスターちゃん」で学ぶソフトウェアテスト⑦
「テスターちゃん」で学ぶソフトウェアテスト⑧

#3. テストの7原則
どのようなテストにも共通する原則がある
この原則を頭に置いておくことで、効率的にバグを見付けるヒントとなったり、リーダーになった際に効果的なテストのアプローチを練るヒントとなったりする

##3.1 ①テストは欠陥があることは示せるが、欠陥がないことは示せない
欠陥=バグのこと(フォールトともいう)
人のミス(エラー)によって、バグ(欠陥)を埋め込んでしまうイメージ

例えば
テストケースを100件実施してバグが見つからなかったとする
これだけやって見つからないのだからシステムにバグはない、と言えるか?

:x: 言えない

そのケースではバグが見付からないだけで、他の場所にバグがあるかもしれないから

つまり
ない≠見付からない

・システムにバグがあることを示すのなら、1つバグを見つければいい
・だけど、ないことを示すのは非常に難しい
 ⇒ないとは言い切れない

##3.2 ②全数テストは不可能
全てのパターンをテストして欲しい
⇒全パターンって何をどこまでテストすればいいの!?

テストを知らない人は「とにかく全部見て欲しい」と言う
⇒だけど、完全に全組み合わせは不可能
 パターンが爆発するから

時間は無限ではないので、テストケースを絞る必要がある
⇒テスト設計技法を使ってテストケースを減らす

システムの目的や使われ方・想定されるリスクに着目しどこを重点的にテストするのか戦略的にテストを行う必要がある

テストは工夫次第でかなり効率的に出来る
だけど、無限に非効率にすることもできる…

##3.3 ③早期テストで時間とコストを節約

例えば、嫌いな食材があるので抜いてくれと言ったが、その食材を入れた料理が出来上がってしまった
・話を聞いた時
・その食材を調理している時
・鍋やフライパン等に入れる前に
気付ければ抜くことが出来た

問題は気付くのが遅れれば遅れるほど、修正に手間がかかる
そのため、早い段階からテスト(確認)が大切

##3.4 ④欠陥の偏在
つまり、バグの集中について

例えば、シンプルな草原にも虫がいる
だけど、生命系が複雑な森の方が虫がたくさんいる

=システムも同様
シンプルな場所に比べ、複雑な場所の方がバグが多い傾向にある

バグは均一にあるわけではなく、特定の場所に集中し易い

・忘れがちな処理のある場所
・間違え易い処理の場所
・不慣れなメンバーが作った場所
・他部署が作った機能
 ※その部署に聞かずに進めていて、考慮漏れが発生することもある
・テストも全て均一に行っていると注意する場所に時間を割けなくなることがある

【対策】
・過去のテスト結果やバグ分析からテストを厚くする場所を絞り込む
・開発に「不安なところはないか(不安な箇所、開発でテストできない場所、やって欲しいことなども)」と聞く
など

##3.5 ⑤殺虫剤のパラドックスにご用心
無足は同じ殺虫剤を使い続けるとその殺虫剤に耐性がついて死ななくなる

つまりテストにも同じことが言える

同じテストばかりだと新たなバグが出せなくなってくる
⇒出たバグは修正され、そのテストの耐性が出来るからである
テストでバグを出すには**絶えず視点を変えることが重要**

【自動化の場合】
自動化テストは同じテストを繰り返すことになる
⇒目的がデグレならいいが、新しい発見にはほぼ繋がらない

つまり、自動化テストを使う場合、
・デグレがないことを確認したいのか
・新しいバグを見つけたいのか
をよく考えること

##3.6 ⑥テストは状況次第
同じようなアプリをテストする場合、置かれた条件で取るべき手法が変わってくる

扱うモノが変わったらテストも異なるものが必要となる
ほぼ同じモノのテストにしても状況や環境でやり方は変わる

テストの基礎知識を身に付け、状況によってそれらを組み合わせ対応する必要がある
*闇雲に一つのやり方にこだわらない

注:テスト期間に割とバグ修正期間が考えられていないこともある

##3.7 ⑦バグゼロの落とし穴
あるアプリは入力系のバグは全部対応した
文字入力が半角数字1つのみしか入力を認めないと言う条件
⇒だけどそれ以外の入力を試してみたい
 対策によって物足りなくなってしまった

バグ報告があったからと言って修正し制限をかけすぎたため使い難くなる
小さなバグを直すために複雑な処理を通したため反応が遅くなる、と言ったことが多々ある

木を見て森を見ずにならないように気をつける
⇒部分に集中してしまったため、他に気が回らないようなことにはならないように

##3.8 まとめ
テスト7原則を知らなくても、テストは出来る
だけど、知っていた方がテストの攻め方が変わってくるし、工夫・方針・対応も変わってくる

**テスト7原則はテストの根っこの考え方**である

*テストエンジニアが守る範囲は膨大なので、普通にやっても上手に守れない
そのため、どうやって守っていくのかテストの創意工夫が必要となってくる

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?