Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

More than 5 years have passed since last update.

探索的テストのすゝめ

Posted at

皆さんこんにちは
バルテック3年目の土屋です

バルテックアドベントカレンダー2017の15日目です

今年参画したプロジェクトにて、**「探索的テスト」**というテスト手法に出会い
個人的にかなり衝撃を受けたので、今回はそれをテーマにしようと思います

探索的テストとは?

事前・直前のテスト結果をもとに次のテスト内容を決めていくようなテスト手法のことを言います
探索的テストでは基本的にテストケースを作成するようなことはしません
テストを実施しながら、その挙動を見て次のテスト内容を考えて、また次のテストを実施しながら…を繰り返していくイメージです。

テスト結果だけでなく、ソースコードや仕様書等から得た情報をもとに探索的テストを行う場合もあります
皆さんのなかにもソースコードを眺めていて「あれ?ここおかしくね?(or どうなってるの?)」
と感じ、軽く動作確認してみるとバグを発見した、なんて経験ありませんか?
これも一種の探索的テストといえるかもしれません

ちなみに私達が普段行っているような、あらかじめテスト内容を考え、テストケースをドキュメントに記述し、テストケースに従って網羅的に行うテストのことを 「記述式テスト」と呼びます

探索的テストのメリット・デメリット

探索的メリット・デメリットをあげていきます

メリット

・テストケースを書かなくて良い

単純明快です
テストケースを書く工数がかかりません

・ユーザー観点でのテストがしやすい

記述式テストは予め用意されたテスト項目通りに実施するのでどうしても機械的になりがちですが、
探索的テストは考えながら実施するので、操作性などのよりユーザーに寄り添った観点でテストしやすくなります

・工数に対するリスク軽減率が高い

これがおそらく一番大きなメリットだと思います
記述式テストでは、バグが潜む確率が低い箇所についても他の箇所と同じ工数を割いてテストを行う必要がありますが、
探索的テストはテスト内容を臨機応変に変更できるため、
バグが多く潜みそうな箇所バグが存在すると重大な損失につながり得る箇所を重点的にテストすることが可能になります
これにより、うまくハマれば少ない工数でかなりのリスクの軽減が期待できるでしょう

デメリット

・工数を見積もりにくい

テストケースを書かないので、具体的なテスト項目数等の指標がなくなり、工数を具体的な数値で算出しにくくなります

・品質を保証するエビデンスとはなりにくい

上記とほぼ同様の理由です
「この量・粒度のテストを実施しました」という具体的な数値が提示できないのです

・属人的になりやすい

テストケースがドキュメントで存在しないのでレビューというものが存在しません
なので、テストそのものの品質がテスト実施者のテスト技量やテスト経験、システム理解度などに大きく左右されやすくなってしまいがちです

探索的テストの運用法

上記のように探索的テストにはメリットも多いですがその分デメリットも多く、網羅性にも欠けるので、
テストフェーズにおいて「探索的テストのみを実施する」というのは現実感がありませんし、効果もあまり見込めないでしょう
記述式テストと探索的テストを両方行い、相互にデメリットを補完するのが重要だと一般的に言われているようです
私が探索的テストに出会ったプロジェクトでもそのような運用がされていました

何が衝撃的だったのか

ここまで探索的テストについて紹介してきましたが、なぜ紹介したかったかといえば、
冒頭に書いているとおり、探索的テストに出会ってかなりの衝撃をうけたからなのです
エンジニアとしての価値観・意識が変わったと言ったほうが適切かもしれません

具体的に言うと、テストに対しての意識がとてもポジティブになりました
(以前までは自分の中でテストは「ただ面倒な工程」でしかなかった)
探索的テストでは具体的なテスト項目数が存在しないため、評価基準は**「バグ発見数」になります
つまり
バグを発見すればするほど評価されるので、必然的に探索的テストを導入しているプロジェクトは「バグを発見すること」に対してポジティブになります
もちろん私もそのプロジェクトに参画していたので、その雰囲気に次第に影響されていきました
「テストフェーズ中にバグが発見されるのはむしろ歓迎されるべきことで、リリースされる前に見つかるのは幸運なことだ」
と次第に考えるようになり、
最終的には従来の
記述式テストに対する意識までポジティブな方向へと変わっていきました**
そして、テスト工程は成果物の品質を保証する最後の砦であることに気が付き
テスト工程ほど重要な開発工程はないと思うまでになりました

この意識の変化は私にとって今年イチの変化であると言っても過言ではありません

最後に

エンジニアとして働いていると、どうしても新言語やフレームワーク等に関心が向きがちですが、
たまには「テスト」について関心を向けてみませんか?

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

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?