BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

テストのヒューリスティクス- テスターのように考える

| 作者: Shane Hastie フォローする 30 人のフォロワー , 翻訳者 徳武 聡 フォローする 1 人のフォロワー 投稿日 2009年10月15日. 推定読書時間: 4 分 |

原文(投稿日:2009/10/12)へのリンク

Software Education社のトレーナーが投稿するブログで  Sharon Robson氏が James Bach氏のSTANZカンファレンス(Software Testing Australia & New Zealand)での発言に言及している。このカンファレンスでJames Bach氏が提示したのは、実用に耐えうる様々なテストのヒューリスティックスについてだ。 

ヒューリスティックは形容詞であり、問題解決や、学習、発見などを支援する体験型の技術に関連して使われる言葉である。ヒューリスティックな方法とは、とりわけ、現実的な範囲で最良に近いと思われる解決策、つまり'最適解'を素早く発見するために使われる。ヒューリスティックスは "経験則"であり、根拠のある推測でもあり、直感的な判断でもあり、単純に常識である場合もある。名詞ヒューリスティックスは、ヒューリスティックな方法という意味を表す。

もっと正確に表現すると、ヒューリスティクスは入手が容易な、しかし、大雑把にしか利用できない情報を使って、人間や機械の抱える問題を制御する戦略、ということになる。

http://en.wikipedia.org/wiki//Heuristics

 Sharon Robson氏 は、James Bach氏が同カンファレンスで発表した36のテストのヒューリスティックスについて報告している。氏は次のような頭字語を提示した。cidtestdsfdpotcrusspicstmplfdsfscura これは次の4つのグループに分けることができる。
 
グループ 1 – cidtestd = 顧客(Customers)、情報(Information)、開発者の関係(Developer relations)、チーム(Team)、設備と道具(Equipment & Tools)、スケジュール(Schedule)、テスト項目(Test Items)、納品物(Deliverables)。これらは高いレベルで行う計画であり、実際のテストへ焦点をあてることを“準備”し支援します。 これらの計画は実際にテストが行われるコンテキストを設定するのに役立ちます。
グループ 2 – sfdpot = 構造(Structures)、機能(Functions)、データ(Data)、プラットフォーム(Platforms)、操作(Operations)、時間(Time)です。この頭字語について、私はKaren N Johnson氏がSan Francisco Depot (SFDPOT)で言及していたのを聞いたことがあります。この頭字語はテスト対象の環境について、テスト範囲、リソースや時間を考慮しながら理解するためのものです。テスト範囲、リソースや時間は品質の三角形を構成する重要な要素で、私の考えではテストで最も重要な部分ですが、浅く考えられがちな部分でもあります。
グループ 3 – crusspicstmpl = 能力(Capability)、信頼性(Reliability)、使いやすさ(Usability)、安全性(Security)、拡張性(Scalability)、性能(Performance)、 導入の容易さ(Installability)、互換性(Compatability)、持続性(Supportability)、テストしやすさ(Testability)、メンテナンスしやすさ(Maintainability)、移植性(Portability)、ローカライズしやすさ(Localisability)。これはシステムの性質の指標になる項目の非常に優れた一覧です。私はISO 9126 (これはもっと短い!)が好きですが、この頭字語もどんなシステムでも考えなければならない主要な要素を見事に網羅しています。私は“性(ity)”をこういう項目で使うのが大好きです。–こうすることでいつも”性”質に注意を払うことができます。
グループ 4 – fdsfscura = 機能テスト(Function Testing)、ドメインテスト(Domain Testing)、負荷テスト(Stress Testing)、フローテスト(Flow Testing)、シナリオテスト(Scenario Testing)、要求テスト(Claims Testing)、ユーザテスト(User Testing)、リスクテスト(Risk Testing)、自動テスト(Automatic Testing)。この一覧にあるテストタイプはテストのときに実行されるかもしれませんし、実際に実行できます。むしろ、した方がいいでしょう。この一覧を見れば、テスト方法はひとつだけではないということをはっきりと理解できます。この一覧からわかることは他にもあります。それは、より良いテストをするには何をどのようにテストするのかを理解する必要がある、ということです。
 
似たような文脈でQuality Tree Software社のElisabeth Hendrickson氏ヒューリスティックなチェックシートを公開している。このシートにはテストするべきアプリケーションの項目と範囲が大まかに記載されている。最近のエントリで、氏はテスターのように考えることで、リリース後に大きな問題が見つかるのをどのくらい防げるかについて議論している。
テスト技術のある人が行う本当に大雑把な探索的テストでも、そのような問題は防げるように思えます。

 
あなたやあなたのチームはどんなヒューリスティックな方法でテストをしているだろうか。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT