TestLinkを運用して気付いたことpart11~お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト
Nakaさんからテスト手法について聞いたのでメモ。
以下メモ書き。
【参考】
TestLinkを運用して気付いたことpart8~みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索
TestLinkを運用して気付いたことpart9~後追いテスト: プログラマの思索
TestLinkを受入テストで運用する方法: プログラマの思索
【1】お試しテスト
お試しテストとは、テスト対象モジュール・テストケース・テスト実施者などを対象として、本格的なテストを実施する前に味見するテスト。
例えば、携帯電話の実機とそのプログラムをテストする場合、本格的なテストをする前に、いくつかの基本的なテストを実施して、発見されるバグが多すぎるなら、テストしても無意味だから開発チームへ送り返す。
業務システム開発ならば、要件定義や詳細設計などの上流工程が穴だらけのまま何とか開発して動作できるようにしたものの、異常系のテストがボロボロみたいな状況の場合、テスト不能として送り返す。
これらの状況の場合、テストケースをきちんと準備してテストを開始すると、いきなり重大なバグが出て、後続の依存するテストケースが殆どブロックになってしまって、テスト不能に陥った状態があげられるだろう。
つまり、テストを続行しても、テストに耐えれる品質でない場合が多いだろう。
あるいは、テストケースをお試しテストの対象とした場合、テストで殆ど潜在的なバグを見つけられないなら、テストケースの品質が良くないと評価して、テスト仕様書を作り直す。
この状況の場合、テストケースの品質が良くないため、バグ出しできていないので、テストケースが要件や仕様を網羅しているか、漏れている仕様はないか、などの観点で作り直す時が多いだろう。
あるいは、テスト実施者(テスター)をお試しテストの対象の場合、テスターがテスト作業に向いているかどうかを判定するために使う。
実際のテスト作業は、仕様を理解して、テストの事前条件のためのテストデータを揃えて、エビデンスをきちんと採取して、細かい部分まで検証する作業が多い。
そういうテスト作業に向いていない人もやはりいる。
だから、お試しテストでふるいにかける。
いずれの場合にしても、本格的なテストを行う前に、モジュール・テストケース・テスト実施者の品質がクリアされているかどうかを早めに検知して、開発チームへフィードバックすることを目的とするわけだ。
【2】フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト(ストレステスト or 負荷テスト)
フールプルーフテストとは、フールプルーフの機能をシステムが満たしているかどうかのテスト。
つまり、ポカよけできているかどうかのテスト。
よくある例は、電子レンジのふたを開けたら発熱を止める機能があるだろう。
例えば、医療機器や家電製品の場合、ユーザが誤動作しても安全に動作しないと、人体や社会に大きな影響を与えるから重要なテストになる。
開発者がテスターになるよりも、開発に携わっていない人がテストすると、マニュアル通りの操作をしないので、ポカよけできているかどうか判断しやすい。
多分、結合テストやシステムテストの一部として含まれる時が多いだろうと思う。
似たようなテストとして、モンキーテスト、探索的テスト、フェイルセーフテストもある。
モンキーテストとは、特に目的を定めず、猿のように操作を行うテスト。
Webシステムなら、テストの最後に、実際にユーザが初めてシステムに触れることを想定して、何も考えずにテストする時が多いだろう。
探索的テストとは、経験者がテスト仕様書から離れて、特定の機能を深堀してテストしていくこと。
テストの例としてよくあげられるが、実際のテスト作業としては難易度が高いと思う。
理由は、バグが出たとしても再現させるのが難しかったり、仕様を深く理解していなければテスト工数の無駄になりがちだからだ。
前者の対策としては、バグを再現させるために、作業ログが重要。
昔は紙に作業ログを書きながら、少しずつテストしていくしか無かったけれど、今は操作を動画で採取するのが非常に簡単になった現状もある。
フェイルセーフテストは、フェイルセーフの機能をシステムが満たしているかどうかのテスト。
つまり、故障が発生したとしてもシステムが安全に稼働しているかどうかを検証する。
実際は、ある部品や機能が壊れたとしても安全に動作するように冗長化されているか、などの観点が含まれるだろう。
最近は、組込製品の安全性が品質要件として重要になってきた傾向があるので、フールプルーフテストやフェイルセーフテストもテスト工程に含める時が多くなっているだろう。
フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索
ラッシュテスト(ストレステスト)は、特にWebシステムの負荷テストのこと。
下記の記事のように、システムが大量のアクセスに耐えれるかどうかを検証する。
最近は、JMeterなどのツールを使って、性能要件を満たさないボトルネックを見つけて、サーバーの設定を変えたり、メモリを増やしたり、RAIDにして冗長化するなどの対策を取る時が多いだろう。
負荷テストとは 「ストレステスト, ラッシュテスト」 (stress test): - IT用語辞典バイナリ
Webシステムのリリース作業とフォールトトレランス: プログラマの思索
TestLinkで上記の観点のテストを含める場合は、テスト計画単位にアサインする手法が良いと思う。
つまり、お試しテスト、フールプルーフテスト、フェイルセーフテスト、ラッシュテストのテスト計画を作って、それぞれのテストケースを割り付けて、五月雨式にテストしていくやり方。
テスト計画をイテレーションに紐付けて、イテレーション単位にアジャイルにテストしていく手法が良いと思う。
理由は、プロジェクト後半という限られたテスト工数しか確保できない状況では、テストの目的を明確化してテストした方が効率が良いからだ。
但し、モンキーテストや探索的テストは特にテストケースが無いため、除いている。
テストはやればやるほど奥が深いと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
コメント