非公式で直感的なタイプの ソフトウェア 計画や文書化なしに実施されるテスト。
- 方法論： プロジェクト管理, 品質
アドホックテスト
アドホックテスト
- アジャイル開発手法, 継続的な改善, プロセス改善, 品質保証, 品質管理, 品質管理, リスク管理, ソフトウェアテスト, 検証
客観的：
使用方法：
- テスターは、アプリケーションに関する知識を活用し、システムのさまざまな部分をランダムにテストすることでバグを発見します。これは、正式なテストにかけられる時間が限られている場合によく行われます。
長所
- 正式なテストでは見逃されるバグを発見でき、準備も最小限で済み、開発サイクルのどの段階でも実施可能です。
短所
- 発見されたバグは再現が難しい場合があり、その有効性はテスターのスキルに大きく依存し、正式なドキュメントも提供されない。
カテゴリー:
- プロジェクト管理, 品質
最適な用途:
- 体系的なテストを行う時間が限られている場合に、欠陥を迅速に発見する。
アドホックテストは、ソフトウェア開発、モバイルアプリケーション、家電製品など、迅速な反復と継続的なフィードバックが最重要となる業界でよく利用されます。この方法は、開発の最終段階や製品発売準備など、時間的制約のあるプロジェクトフェーズに適しています。こうしたフェーズでは、包括的な正式テストを実施する時間が十分に確保できない場合が多いからです。このアプローチの参加者には、通常、開発者、テスター、そしてシステムを直接理解しているエンドユーザーも含まれます。アプリケーションに対する理解に基づき、構造化されたテストでは見落とされがちな潜在的な問題を特定するために、直感と経験を活用することができます。このテスト手法は、反復サイクルにおいてユーザーフィードバックに基づいて迅速な調整が必要となるアジャイル環境で特に有効です。一般的な用途としては、新機能の検証から、継続的なアップデート中の回帰テストまで多岐にわたります。アドホックテストは適応性が高いため、探索的テストセッションにおける貴重なデバッグ戦略としても活用できます。探索的テストセッションでは、テスターは事前に定義されたスクリプトを使用せずにアプリケーションを調査し、実際の使用シナリオで発生する可能性のある予期せぬ欠陥を発見することができます。正式な試験手順ほどの徹底性はないかもしれないが、即座に結果が得られるため、締め切りが迫り、チームがリスクを迅速に軽減しようとする場合には魅力的な選択肢となる。
この方法論の主なステップ
- テストが必要なアプリケーションの主要領域を特定する。
- 特定された領域内で、探索する機能や特徴をランダムに選択します。
- 入力値や相互作用を変化させながら、探索的な方法でテストを実行する。
- 予期せぬ動作、エラー、または矛盾点が発生した場合は、それらを記録してください。
- さまざまな経路やシナリオを繰り返し検討し、さらなる問題点を明らかにする。
- テスト実施中は、経験と直感に基づいてテストの焦点を定めてください。
- 必要に応じて、さまざまなプラットフォームや構成を試してみてください。
プロのヒント
- ドメイン知識とアプリケーションロジックに基づいて、リスクの高い領域に焦点を当てるために、探索的テスト手法を取り入れてください。
- 過去のバグ報告や傾向を活用して、以前に問題があった機能やコンポーネントを対象とした臨時のテストセッションを実施する。
- テスター間の協力を促進し、発見事項を即座に共有することで、多様な視点を活用したより深い探求を促す。
複数の方法論を読み比べて、 私たちは、
> 包括的な方法論リポジトリ <
400以上の他の手法と併せて。
この方法論に関するご意見や追加情報は、 以下のコメント欄 ↓、エンジニアリング関連のアイデアやリンクも同様です。
歴史的背景
（日付が不明または関連性がない場合、例えば「流体力学」などでは、その注目すべき出現時期の概算値が提示されます。）
