以前、海外のソフトウェアテスト系Webマガジンの紹介をしました。
少しずつ読んでいるのですが、ちょっと面白い記事があったので紹介します。前回のエントリーで、全訳することのツラさを思い知ったので、今回はサマリで。。
ご紹介する記事は、Matthew Heusserさんという方の、「Taking the Risk: Exploration over Documentation」という記事で、Webマガジン『BETTER SOFTWARE』の2013年4月号に掲載されています。Webマガジンの他、Hersserさんのサイト (PDF)でも読めるみたいです。
タイトルの通り、「リスクをとる」ことについての記事のはずですが、この中に「Where Do Bugs Come From?」という節があります。直訳すると「バグはどこから来るのか」ですが、内容は「何をもってバグだと言うのか」というものです。
たとえば画面上の要素が重なり合って読めない場合、それは明らかにバグでしょうが、「そうなってはならない」ことはあまりドキュメントに明示されません。では何を根拠にバグと言っているのか。
筆者は、その根拠を「consistency heuristic」（ヒューリスティックな不一致）と呼んでいます。consistency heuristicにはたとえば、以下のようなものがあります。
要求との不一致
これはドキュメントに明示されている要求事項と一致しないものであり、もっともわかりやすいバグです。
過去の経験との不一致
前に使ったときと違う！というものです。変更に関する要求がないことは、変更がないことを要求されていると考えることができるでしょう。
言葉のルールとの不一致
誤字脱字、文章がおかしいといったものですね。こればっか指摘するテストエンジニアは呪われますが。（でも明らかに文章として腐ってるメッセージとかあるよね！）
ユーザインタフェースの標準との不一致
メニューバーの一番左にあるのは「ファイル」って、Windowsユーザなら体に染みこんでますよね。テキストエディタのメニューバーが、左から「ヘルプ」「編集」「ファイル」って並んでたら・・・「う、うおーっ！」ってなりますよね、ドキュメントに書いてなくても。
代替製品との不一致
オンラインの表計算ソフトを作ろうとしたら、その動きはExcelに似ているべき。テストオラクルってやつですね。
当然のこととの不一致
この「当然の」とは、「claim」を無理に訳したものです。これはちょっと理解しづらかったのですが、本文の例によると「ブラウザが落ちない」という、ユーザが当然期待していること。「当たり前品質」的なものでしょうか。
同じような話がこちらのスライド(PDF)にもありました。developsense.comというサイトの右エリア、「Past Presentations」のOctober 2009を辿ってください。
こちらでは、次の8つを合わせて「HICCUPUS」としています。 hiccupとはしゃっくりのことですな。
- History
- Image
- Comparable Products
- Claims
- User Expectations
- Purpose
- Product
- Statutes
具体的な内容は、パワポを読んでみてくださいね。
ユーザビリティ系の欠陥(仮)を見つけたときの分類の参考になるのと、逆にこれらをユーザビリティ・テストの観点として、ドキュメント以外からテストケースを検討するのに使えそうに思えますが、いかがでしょうか。
