TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト

Nakaさんからテスト手法について聞いたのでメモ。
以下メモ書き。

【参考】
TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkのベストプラクティス集: プログラマの思索

TestLinkのアンチパターン: プログラマの思索

TestLinkのFAQ: プログラマの思索

TestLinkを受入テストで運用する方法: プログラマの思索

【1】お試しテスト

お試しテストとは、テスト対象モジュール・テストケース・テスト実施者などを対象として、本格的なテストを実施する前に味見するテスト。

例えば、携帯電話の実機とそのプログラムをテストする場合、本格的なテストをする前に、いくつかの基本的なテストを実施して、発見されるバグが多すぎるなら、テストしても無意味だから開発チームへ送り返す。
業務システム開発ならば、要件定義や詳細設計などの上流工程が穴だらけのまま何とか開発して動作できるようにしたものの、異常系のテストがボロボロみたいな状況の場合、テスト不能として送り返す。

これらの状況の場合、テストケースをきちんと準備してテストを開始すると、いきなり重大なバグが出て、後続の依存するテストケースが殆どブロックになってしまって、テスト不能に陥った状態があげられるだろう。
つまり、テストを続行しても、テストに耐えれる品質でない場合が多いだろう。

あるいは、テストケースをお試しテストの対象とした場合、テストで殆ど潜在的なバグを見つけられないなら、テストケースの品質が良くないと評価して、テスト仕様書を作り直す。
この状況の場合、テストケースの品質が良くないため、バグ出しできていないので、テストケースが要件や仕様を網羅しているか、漏れている仕様はないか、などの観点で作り直す時が多いだろう。

あるいは、テスト実施者(テスター)をお試しテストの対象の場合、テスターがテスト作業に向いているかどうかを判定するために使う。
実際のテスト作業は、仕様を理解して、テストの事前条件のためのテストデータを揃えて、エビデンスをきちんと採取して、細かい部分まで検証する作業が多い。
そういうテスト作業に向いていない人もやはりいる。
だから、お試しテストでふるいにかける。

いずれの場合にしても、本格的なテストを行う前に、モジュール・テストケース・テスト実施者の品質がクリアされているかどうかを早めに検知して、開発チームへフィードバックすることを目的とするわけだ。

【2】フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト(ストレステスト or 負荷テスト)

フールプルーフテストとは、フールプルーフの機能をシステムが満たしているかどうかのテスト。
つまり、ポカよけできているかどうかのテスト。

信頼性設計 - Wikipedia

よくある例は、電子レンジのふたを開けたら発熱を止める機能があるだろう。
例えば、医療機器や家電製品の場合、ユーザが誤動作しても安全に動作しないと、人体や社会に大きな影響を与えるから重要なテストになる。
開発者がテスターになるよりも、開発に携わっていない人がテストすると、マニュアル通りの操作をしないので、ポカよけできているかどうか判断しやすい。
多分、結合テストやシステムテストの一部として含まれる時が多いだろうと思う。

似たようなテストとして、モンキーテスト、探索的テスト、フェイルセーフテストもある。
モンキーテストとは、特に目的を定めず、猿のように操作を行うテスト。
Webシステムなら、テストの最後に、実際にユーザが初めてシステムに触れることを想定して、何も考えずにテストする時が多いだろう。

探索的テストとは、経験者がテスト仕様書から離れて、特定の機能を深堀してテストしていくこと。
テストの例としてよくあげられるが、実際のテスト作業としては難易度が高いと思う。
理由は、バグが出たとしても再現させるのが難しかったり、仕様を深く理解していなければテスト工数の無駄になりがちだからだ。
前者の対策としては、バグを再現させるために、作業ログが重要。
昔は紙に作業ログを書きながら、少しずつテストしていくしか無かったけれど、今は操作を動画で採取するのが非常に簡単になった現状もある。

フェイルセーフテストは、フェイルセーフの機能をシステムが満たしているかどうかのテスト。
つまり、故障が発生したとしてもシステムが安全に稼働しているかどうかを検証する。
実際は、ある部品や機能が壊れたとしても安全に動作するように冗長化されているか、などの観点が含まれるだろう。
最近は、組込製品の安全性が品質要件として重要になってきた傾向があるので、フールプルーフテストやフェイルセーフテストもテスト工程に含める時が多くなっているだろう。

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索

ラッシュテスト(ストレステスト)は、特にWebシステムの負荷テストのこと。
下記の記事のように、システムが大量のアクセスに耐えれるかどうかを検証する。
最近は、JMeterなどのツールを使って、性能要件を満たさないボトルネックを見つけて、サーバーの設定を変えたり、メモリを増やしたり、RAIDにして冗長化するなどの対策を取る時が多いだろう。

負荷テストとは 「ストレステスト, ラッシュテスト」 (stress test)： - IT用語辞典バイナリ

Webシステムのリリース作業とフォールトトレランス: プログラマの思索

TestLinkで上記の観点のテストを含める場合は、テスト計画単位にアサインする手法が良いと思う。
つまり、お試しテスト、フールプルーフテスト、フェイルセーフテスト、ラッシュテストのテスト計画を作って、それぞれのテストケースを割り付けて、五月雨式にテストしていくやり方。
テスト計画をイテレーションに紐付けて、イテレーション単位にアジャイルにテストしていく手法が良いと思う。

理由は、プロジェクト後半という限られたテスト工数しか確保できない状況では、テストの目的を明確化してテストした方が効率が良いからだ。
但し、モンキーテストや探索的テストは特にテストケースが無いため、除いている。

テストはやればやるほど奥が深いと思う。