悲観的意見の伝え方
1日目の記事です。
すでに投稿時点で日付が過ぎています。まぁ、こまけぇこたぁいいんだよ。
まだネタが不足しているので、twitterやpeingからコメントやDMなどいただけると幸いです。
頂いたお題
twitterにて頂きました。ありがとうございます。
「QAの悲観的思考をポジティブ思考であるべきマネージャーや開発者にどう伝えるのがプロジェクトにとってベストなのか？とかどうでしょうか。」
技術といえば技術なようで、マインドといわれればマインドのような。
ソフトスキルのお題です。
悲観的な考え
JSTQBのFLシラバスでもテスト担当者のマインドセットとして悲観的な考えが挙げられています。
1.5.2 テスト担当者と開発担当者のマインドセット
(中略)
テスト担当者のマインドセットには、好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さ ない注意力、良好で建設的なコミュニケーションと関係を保つモチベーションが必要となる。
(引用元 : http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf)
テストをする上で「こうなってほしくない」「こんなことが起こるかもしれない」と自分達のプロダクトやサービス、プロジェクト進行についてリスクを考えることは大切な要素です。
しかし、「仕様と異なる動作がありました」「エラーが発生しました」であれば伝えやすいですが、「この仕様で問題ないですか」「エラー起きないですか」とは聞きにくいこともあります。
伝え方の工夫
自分の中で工夫をしているといいますが、気をつけていることは次の四点です。
- 決めつけない
- 理由を説明する
- 理由をきく
- 解決策も提案する
決めつけない
リスクを考えること自体は正しいことです。
しかし、「絶対に〇〇」と決めつけてはいけません。
「この仕様、絶対に問題がある」
「ユーザーにとって、このUIは絶対に良くない」
少なくとも一度はこのように感じたこともあると思います。事実、自分はそう思ってしまうことが今でもあります。
しかし、その仕様も誰かが考えて作ったものです。
もちろん、入念に考えた上でも考慮が漏れることはあるかもしれませんが、頭ごなしに否定されては修正時のパフォーマンスにも影響しかねません。
法的にルールが決まっているために見栄えや使い勝手が悪いこともあり得ますし、色々なリスクを考えた上で複雑になってしまっているのかもしれません。
理由を説明する
懸念を伝えるのであれば、理由も添えるようにしてます。
当然といえば当然に思えますが、暗黙的に「わかるだろう」と思ってしまい理由を伝えていないこともあるかと思います。
なぜそう思ったのか。どうしてそれが問題なのか。
それらの情報があることで、そのリスクをどう扱うかの判断がしやすくなります。
ものづくりの人がものづくりになるべく専念できるよう、渡せる情報はしっかり渡します。
また、理由を伝えることで他の誰かがそこから派生して新たなリスクを見つけられるかもしれません。
見えていなかったところでリスクヘッジされていた、ということもありえます。
理由をきく
一方的に伝えるだけでなく、理由をききます。
仕様は〇〇となっているが、どんな理由・意図があってそうなっているのか。
例えば設計上、そのような対応を取る必要があるのかもしれません。
「本当はそう実装したくないけれど、そうせざるを得ない」ということがそこから汲み取れます。
その情報は今後のテストでも活かせますし、リファクタリングなど改善を進める上で問題箇所として挙げられるようになります。
例えば法務部門に相談したら、そう表示しないとダメだと指摘されたのかもしれません。
自分の知らなかった法的に必要な対応があったことを知ることができます。
こちらも以後の観点として使うことができます。
といった具合に、自分の知らなかった知識や観点、設計や環境による影響を知ることができます。
解決策も提案する
「問題じゃないですか」と懸念だけを投げられるとどうなるでしょう。
1件2件ならまだ良いですが、それが何件も続くとなると「またかよ...」と精神的にも苦痛でしょう。
本来の作業を中断して対応を考える必要もありますし、正解のない問題も多々あります。
協力してプロジェクトを進め、良いプロダクト・サービスをつくることが目的であるはずです。
自分の担当、専門じゃないからと無関心ではなく、「自分はこう思っている」と伝えることが大事です。
アイデアを提案しなければ、自分の思ったとおりの修正がされないことのほうが多いでしょう。
そうなると、また「問題があります」と報告することになるかもしれません。
また、自分の思っている解決策が問題をはらんでいる可能性も十分にあります。
最終的に良いプロダクトを目指すのであれば、
相手(チーム)を尊重し、背景の理解に努め、必要な情報や自分の考えを出し惜しみせず率直に伝えることが重要だと思います。
(追記)まとめ
twitterにて「一言でまとめると？」と問いを頂き、自分ではうまくまとめられなかったのですが良いアンサーをいただけたのでこちらにも引用にて掲載します。
自分が最初に一言でまとめた言葉は、「“悲観的な考え”は否定的であってはいけない」です。
悲観的であることと否定的であることは等価ではありませんし、
(よほどの意思表示でなければ) 否定的に伝えることにポジティブな効果はないため、否定的であることを否定しようとしています。
その後まとめて頂いた言葉が次のtweetになります。
「問題を見つけるまでは悲観的な考えを持ってテストすることも大切だけれど、見つかった問題を伝えるときには自分の見落としの可能性もあるし、謙虚になって相手へのリスペクトを忘れずに伝えよう」かな。
— あきやま🍵 (@akiyama924) 2019年12月2日
一言ではなくなっているので、1番主張したいことを抜き出して一言にまとめないといけないけど。
こうして反応をいただけるだけで本当にありがたいです。
(それなりにエゴサもしていますので、反応をしていただけると喜びます。)
「不安だから」はテストをする理由にならない
ご無沙汰です、夏以来ブログ更新を怠っていたhalspringです。
特になにかあったわけではなく、ふと思い立ったのでそのまま綴ります。 変な文章になっていてもご容赦願います。
テストをする理由
テストには目的があり、テストには必ず理由があります( なければ実施する意味がありません )。 では、テストは一体なぜ行われるのか。
JSTQBのFLシラバスでは以下のように書かれています。
すべてのプロジェクトで、テストの目的は以下を含む。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 明確にしたすべての要件を満たしていることを検証する。
- テスト対象が完成し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- 欠陥の作りこみを防ぐ。
- 故障や欠陥を発見する。
- ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
- （以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する。
- 契約上、法律上、または規制上の要件や標準を遵守する、そしてまたはテスト対象がそのような要件や標準に準拠していることを検証する。
これらの目的のために、要件を満たしていない機能がないか/ビジネス上のリスクはないか/ユーザーに不利益はないか/法的に問題はないかなど悲観的な考えを持つことが重要になります。 ( JSTQB FLにもテスト担当者のマインドセットとして悲観的な考えが挙げられています。)
悲観的な考えには、不安がついて回ります。
プロダクトで起きてほしくないこと、潜んでいそうな欠陥(過去の欠陥や類似機能の欠陥など)について考えたりと、あらゆる不安を考えます。
不安だからテストをする？
さて、ではテストを行う理由は「不安だから」で良いのでしょうか。
※ここからは勝手な妄想を含みます。 特に誰かが「不安だからテストします」をしていたのを見たわけではないですが、なんとなく「起こり得るのでは？」と思っているだけです。
不安を考えることは誤りではありませんし、悪いことではないと思います。 しかし、「テストを行う理由」にしてしまうことには違和感があります。
「不安だから」は論理的ではなく、感覚的です。 感覚的なテストは果たして良いテストなのでしょうか。
特にテスト仕様書を準備するようなテストにおいて、理由として十分なのでしょうか。
不安をブラックボックスから取り出す
その不安は何に起因しているのでしょう。
不安が現実になってしまったらどんな影響があるのでしょう。
「不安だから」のままでは定量的な評価ができません。 また、際限なく不安は生まれます。
際限なく生まれてくる不安すべてをテストしていては人も時間も足りません。 工数が足りないどころか、工数を掛けるだけの価値があるのかもわかりません。
不安は不安のままでは良くなく、正体を探る必要があります。
不安を「ビジネスインパクト」「影響するユーザー(ステークホルダー)の規模」「発生する可能性」などで定量的な数字に落とし込みます。
( はい、お気付きかもしれませんがリスク分析です。 )
定量化することでテストの優先順位付けや実施する/しないの意思決定が容易かつ合理的になり、納得感も増すことでしょう。
可能であればさらに、テストで確認する必要があるのかも検討すると良いかもしれません。 別の方法でより簡潔もしくは確実にケアすることができるのであれば、最適な手段を用いるべきです。
テストで確認すると決定しても、どんなテストをどれくらい実施すればケアできるのかまで踏み込み、可能な限り合理的で効率的に設計します。プログラムと同じです。
「いい感じに実装しました」と言われてテスト側が良い顔しないのと同じように、「不安だからテストします」と言われても開発側は十分かどうか判断できませんしモヤモヤするでしょう。少なくとも自分はそうです。
プロジェクトの関係者が納得できる、そして合理的で効率的なテストができるようにするためにも不安の中身を知る必要があります。
「不安だから」で行っていいテスト
不安を理由にするのはどうなのか、と書き綴っていましたが、もちろん例外もあると思います。
例えば探索的テストのような工数を掛けずにテスト担当者の経験に基づいて実施するテストであればこの限りではないと考えています。 過去のプロジェクトから得た経験を活かしたり、視点を切り替えながら欠陥を探す活動は感覚的な一面も持っていますし、言語化の難しい不安も確かに存在するからです。
加えて、探索的テストは再現性を犠牲にしている一面があり、逆に考えるとテスト仕様書を用いるテストは再現性が(粒度はさておき)確保されています。テスト仕様書を作成した人でなくとも、一定のテスト実施ができるようになっています。 テスト仕様書を用いるテストは、実施されるテストが再現性を持つことに意味があるから行われるとも言えます。
だとすれば、再現性のためだけに言語化の難しい不安の正体を探り時間を掛けるくらいなら、手を動かしてテストしてしまった方が早いです。
おわりに
お読み頂きありがとうございました。
もしご意見ご感想等あればコメント、ツイート、DMなどお待ちしております。
——
参考までに、WACATE2013の井芹さんのリスクベースドテストに関するスライドをぶら下げておきます。
WACATE2019夏を通して感じたこと
はじめに
どうも、お疲れ様です。
WACATEのあと休みを取らなかったことでずっとテスト尽くしの12日間を終えて土曜日にたどり着きましたhalspringです。
WACATE2019夏に参加してきました(WACATEについての説明は省略します)。
この記事では自分がWACATEに参加して"感じたこと"を中心に書こうと思います。 ですので、今回のWACATEの内容については他の参加レポートやtogetterをご参照ください。
パッとしらべて出てきた参加レポートはこちら
感じることというのはその人の周囲の環境や経験、体調や気持ちによって大きく異なります。 ですので、記事に価値のある情報はほとんどないかもしれません。
興味のある方のみおもしろ半分で読んでいただければと思います。
目次
説明ができる
WACATEは2018冬が初参加で、今回が2回目です。 夏と冬でワークの時間も雰囲気も異なる影響もあるとは思いますが、冬のときよりも積極的に発言や説明を出来るようになっていた気がします。 ソフトスキルが向上した と言いたいところですが、班のほとんどが初参加者で若干頼られる存在になっていたことと、そのことを感じてある種の責任感があったのだと思います。
また、普段はチーム内でテストについてわざわざ説明を行う機会はあまりありません。組織によってはクライアントに説明をすることがあるかもしれませんが、例えば「テストレベルとは」のようことを話したりする機会は少ないと思います。( テストジョークのようなことを雑談で話したりはしますが )
普段 説明したり話すことの少ないことについても、（正しくない可能性は否定できませんが）自分なりに説明をすることができることに気が付き、1年前 やっと新卒研修を終えたばかりだった自分から成長できていることを感じられました。 ソフトウェアテストは 開発のように目に見えるアウトプットを作りにくく、成長の実感をすることも難しいと思います。 WACATEのワークショップは なにが説明できて何が説明できないのか 何を曖昧なまま使っているのか、その辺りをスッキリさせる良い機会なのかもしれません。
経験の共有
WACATE2019夏のひとつの目玉である（と勝手に思っている）テスト計画、 参加者の何人がこれまでに作ったことがあったのでしょう。 別に作ったことがあるから偉いとか、やったことがないからどうとか、そんなナンセンスなことを言うつもりはありません。
過去にテスト計画がテーマの勉強会でも「テスト計画を作ったことがある人」の質問に対して手が上がったのは半分に満たないくらいでした（手をあげるのが好きではない人もいるとは思いますが）。 テーマにテスト計画を掲げている勉強会でその割合であれば、テストプロセス全体をテーマとし若手を中心（新卒や業界1年目2年目の方も多かったです）としたWACATEでは より少ないだろうと思います。
ひとつ前で述べた責任感の話もあり、運良くテスト計画を経験したことのあるだけの自分は おこがましくはありますが、他の参加者になるべく多く自分の持っている知見を共有しなければと感じました。
全てがそうだとは思いませんが、経験できる/できないには運が大きく関わっていると思います。 しかし、経験を出来ずとも経験者から知識を得ることはできます。 当然、実際の経験から得られるものに比べれば不確かで、偏っていて、不足している情報かもしれません。 それでも自分の経験を出来るだけなぞれるように、聞いた人が咀嚼して飲み込めるように意識して伝える責任があると感じました。
経験を積めないことについては本人が悪いわけではありません。 （意図的に避けて経験を「積まない」場合は別ですが。）
自ら飛び込んでいけばいいと言う意見もあるでしょうが、飛び込んで行くにはそれ相応のリスクも必要です。 ただ本を読むだとかそのレベルなら良いですが、転職するだとか職種を変える必要が出てくると様々なものと別れる必要が出てきます。飛び込んだ先で叶うとも限りません。 自分が経験を積むために何かを捨てる必要があるとき、その決断を迷わず出来る自信は正直ありません。
ですから、運良く経験出来る立場になったら 経験出来ないけれど「せめて知識だけでも」と情報を必要としている人達に向けて共有しなければいけない、 そうしなければ、業界全体は良くならないように思いました。なにもせず良くなるとしても、したほうが格段に速いはずです。
土日にお金払って遠出してまでテストを勉強している我々です。 古臭い文化、目的のないテストが行われるような現場、QAエンジニア・テストエンジニアの価値向上、発展のために出来ることがあります。 今すぐは難しいかもしれませんが、加速していきましょう。大層なことを言ってしまったので自分も頑張ります。
リードするということ
テスト計画の経験から、計画を立てる際に班をリードして進める役に他薦して頂きました。 自分がテスト計画を立てるときに、どう考え、どんな流れで進めているのかを説明し、ひとつひとつの自分の判断に対してなるべく理由も話すようにしました。
「こんな理由から こんな感じに進めようと思うのですが、どうでしょうか？何かご意見ありますか？」と尋ね、合意を得ながら進めていったものの、「そういうものなのか」と丸呑みをさせてしまったのではないかと少し不安になっています。
ワークを進める上でなるべく全員に共通の理解を納得感を持てるように自分の意見を言う前に「ここはどう思いますか？」と先に話を振るなどもしてみました。
結果として班のメンバーから意見が出て、「こうした方が良いのではないか」「ここのリスクは◯◯なので優先度をスコープから外してもよいのではないか」と議論検討することもでき、充実したワークを楽しむことが出来ました。 しかし、全体への問い掛けでなく、もっと個人に振ればよかったのではないかと後悔もしています。 ファシリテートって難しいです。
班の方にはありがたいことに評価して頂けましたが、今後 同じような役割を担うときにもっと上手くできるように意識したいです。
リスク分析
自分はテストアプローチを考える時にまずはリスクを出してくのですが、全体のリアクションを見ていて「あまりリスク分析ってされていないのでは...？」と感じました。
意識せずにリスクを気にしている、ということは当然あると思います。無意識にリスク分析を行ってテストを設計することはもちろん不可能ではありませんが、無意識で行なっていては考慮していないもの（例えば機能）が出てきてしまうのではないかと思いました。
全体の成果物の発表を聴いていて、ほとんどの班が「リスクの大きい部分を中心にテストしました」と発表していました。 時間の都合もあって詳細までは聴くことができませんでしたが、テストする機能/しない機能の決定にロジックがあったのかなかったのか、あるならどう決定したのか、ひとつひとつの機能や複合的にどんなリスクがあるか検討していたのだろうかと気になりました。 （どんなアプローチを取っていたのか気になるので、差し支え無ければtwitterか何かでお教え頂けると嬉しいです！）
他の班としみじみアプローチや見つけた不具合について話し合う時間を取れれば良かったのですが、疲れと 人に話しかけるスキルの低さが露呈してしまいました。無念。
経験？ロジカル？閃き？
今回のワーク中、システムテストで主機能を確認、受け入れテストで全機能をシナリオベースで確認するアプローチを取りました。パフォーマンステストやクロスブラウザテストは今回のテスト計画からは外す方向で進んでいました。
ところが、班の人が使っている端末がwindows 4人とmac 2人であったため「システムテストをwin、受け入れテストをmacで実施すればある程度のクロスブラウザの担保はできるのでは？」と判断して、その方針で進むことになりました。
このようなアプローチのアイデア、これは経験から来るのでしょうか？それともロジカルに導いているのでしょうか？あるいは咄嗟の閃きなのでしょうか？
初めは閃きorロジカルから来るもので、徐々に脳にキャッシュされ経験から出せるものになるのでしょうか？ だとすると、キャッシュが古くなり過ぎないように工夫しないとなぁと感じました。
前回も思いましたが、WACATEでtwitterアカウントを開設する方や、放置していたアカウントを掘り出す方、多いですよね。 今回は時間的制約の強いワーク中心であったため、あまり活発ではなかったのかなぁとは思いますが、勉強会やイベントでは大体 誰かが 議事録的なメモ、実況、疑問、感想をつぶやいています。 WACATEに関して言えば、ハッシュタグのない裏側で有識者達がTLの内容を見てつぶやいたりもしています。
この辺りの情報も拾いながら参加すると より視野が広がったり造詣が深まったりします。 疑問をつぶやくと講演者や有識者が答えてくれたり、誤ってメモしていたり理解していることは指摘してくれたり周りを見て気が付けたりします。
界隈の方には（よほどのことがなければ）とても温かく見守って貰えますし、自分はなかなかの人見知りですが twitterから認知して頂いて話しかけてくださる人が増えたり、登壇させて頂く機会を頂けたりと良いこと尽くしです。 リアルのコミュニケーションが苦手な方はテスト用のアカウントを作るもよし、ROM専でもよしなので、情報源は増やしておくことをオススメします。
QAの需要
感覚値ですが、開発やその他職種からテストエンジニア/QAにジョブチェンジしている人が多かった気がします。 テストの重要性が少しずつ理解されるようになって来ているように思えます。
ただ、QAの求人もよく見かけるようになってやはり「必要になったものの、今まで抱えていなかったからどうすればいいのかわからない」という面が見えます。
QA人材のおおまかな獲得方法は、
- 中途で雇う
- 新卒から育てる
- ジョブチェンジさせる
の3つだと思います。 中途で雇う選択肢は、評価できる/見極めることができる人が社内におらず 採用が難しいのかなと思います。 また、必然的にQAチームの立ち上げからになるので、チーム立ち上げ型転職芸人のような熟練者は別として、応募側にとってもハードルが高くなってしまうのかなぁと感じます。
新卒から育てる選択肢も同じような理由で難しく思います。わかる人がいないということは、育てられる人がいないのです。
そうなると残る選択肢はジョブチェンジです。 元々開発をしていれば、自社のドメインには詳しいですし、テストもまぁできる、開発をより良くするにはどうすればいいのか考えることもできます。 おそらくそういった背景の下、ジョブチェンジでQAになられた方が増えているのかなと思いました。
そしてその流れが進んでいけば 開発の知識やマーケティングの知識など、品質保証プラスアルファの知識を持つ方が増えてくるのだろうなと思います。 もちろんその流れがなくともそうなのですが、QAやテスト以外の技術や知識、観点も身に付けて自身の価値を創造して磨いていく必要を強く感じました。
最終的に目指したいところは自分の価値の最大化ではなく関わる方に与える価値の最大化なので、得たものは現場やコミュニティ、業界に還元できるよう頑張ります。
おわりに
色々と生意気なことを書いてしまっていると思います。大変畏れ多いです。
夏と冬でこんなに違うのかと驚きました。 WACATEはどんな参加者にも何かを与えてくれるので本当にすごいコンテンツですね。 実行委員の方々にはとても感謝しています。 そして次回も楽しみにしております。ありがとうございました。
探索的テストで やっていること・意識していること
どうも、halspringです。時というのは早いもので とうとう2年目になりました。
こうして楽しく仕事したりテストについて考えたり発信できるのは読んでくださっているみなさまのおかげです。いつもありがとうございます。
selenium confが迫っているのに目が冴えてしまってこんなものを書いていますが、果して起きれるのでしょうか。
（追記 : 起きれました。）
さて、今回は探索的テストについて書いてみます。
Webサービスを扱う会社の経験しかないため、現場によってここで述べる内容に合う合わない等あるかもしれませんがご容赦下さい。
毎度の如く書いておりますが、
あくまで個人的な見解であり、独自の解釈や考えを述べておりますので、鵜呑みにせず 調べたり試したり自身の経験・考えと比較して見てください。
興味を持っていただき、テストを学ぶきっかけとなれれば幸いです。
探索的テストとは
探索的テストとはテストのスタイルのひとつで、
テストケースを作らず、状況に応じて学習を繰り返し 頭の中でテスト設計をしながらテストを行います。(簡単なドキュメントは用意したりします。)
テストケースを起こさずに実施できるため、効率的にテストを行うことが可能です。
しかし、テストの再現性が低いことや、担当者によってテストの結果が変わること、マネジメントやスケジューリングが難しいといった特徴も挙げられます。
ここでの説明はこれくらいにしておきますが、
興味のある方、詳しく知りたい方のために 参考資料を置いておきます。
- JSTQB ALTAシラバス( 3.4.3 : 探索的テスト )
- 探索的テストってなんですか？ アジャイル時代のソフトウェアテスト
- やってみよう！探索的テスト ～ハイクオリティな妄想の高速ループ～
そして、ここだけは誤解せずに しっかりと使い分けてほしいのですが、
探索的テストはモンキーテストやアドホックテストではありません。
現場からは以上です。
どんな運用をしている？
「探索的テストはアジャイルに向いている」といった説明を目にします。
確かに効率的なテストでスピード感があり、その意見は正しいと感じています。
しかし、だからといってそれだけではダメで 個人的には他の基本的なテストプロセスに加えて実施するべきだと思っています。
探索的テストは網羅性には乏しいですし、
先ほど挙げた『探索的テストってなんですか？ アジャイル時代のソフトウェアテスト』にも注意点として "探索的テストに100％頼らない" と述べられています。
どんな準備をしている？
自分が探索的テストを実施するときに準備するもの、あった方が良いと思うものは以下の通りです。
ディスプレイ
書くまでもないかもしれませんが、画面は多い方が良いです。
すぐにログを残せるようにしたり、仕様書を横で開いておいたりします。
バグの情報
ここまでのテストプロセスで見つかったバグのリストを用意して、事前に概要だけでもいいのですべて見ておきます。
件数が多い場合はざっと どの機能や画面にバグが多いかあたりをつけ、頭の片隅に入れておきます。
件数が少ない場合は拾える情報は可能な限り拾っておきます。
ここで軽くでも見ておくと、後々 テストをしているときに違和感に反応しやすくなると思います。
仕様書・テストオラクル
自分は用意したサブのディスプレイに表示させておきます。
手間をかけずに正しいかどうか比較できるもの（現行版の画面など）を用意しています。
違和感を感じたところや 仕様にそぐわない箇所、画面からはわかりにくい処理の多い箇所や複雑な箇所を確認しながらテストしています。
メモ
紙のメモをそばに置いています。
どこを見ようと思ったか、どんな違和感を感じたかのログ用です。
ログを残す方法として紙にこだわる必要はないので、残しやすい形で残せばよいと思います。
自分はちょっとしたリフレッシュがてらアナログを挟んでいます。
イヤホン
思考に集中するために、外部の音を遮断します。
音があると集中できない方はノイズキャンセリング機能だけを使うと良いと思います。自分はがっつり音楽をかけて精神を隔離しています。
また、イヤホンを着けていれば「あ、なんか話しかけるの忍びねぇな...」といった雰囲気が生まれるので急ぎの用事でない場合 話しかけられるリスクを軽減することができます。
他にも思考を妨げる要因に通知が考えられますので、ブラウザのタブからslackを排除し、カレンダーには【BLOCK】とスケジュールを入れてしまいましょう。
お菓子・飲み物
テスト中、テスト後、疲れます。
また、「喉が渇いたな」という雑念で思考が止まることを避けるためにも、
そばに水分や糖分を確保しておきます。
どんな流れ？
探索的テストをどんな流れで行っているかを説明します。
自分の場合は、
事前にスケジュールに何か追加されないようにタスクをセットし、
調べたバグのリストとオラクルになる資料や情報を別のディスプレイに表示、
どんな箇所を見るか・どんな操作がしたいか 事前にまとめたメモをそばに置き、
イヤホンを装着、ガンガンに音楽を掛けたらようやく準備完了です。
探索的テストを開始してからは、
メモを基に試す内容をざっくりと決定し、操作をしていきます。
UIに違和感を感じたら大体はそこにバグが潜んでいるので、徹底的に叩きます。
オラクルと比較し、なにに違和感を感じたのか正体を探ります。
勘違いであってもメモに残し、その違和感は思い出せる状態にしておきます。(変だと感じた場所には仕様漏れがあったりするので)
基本的にはこの作業の繰り返しになるのですが、
「あ、今なんも考えてなかったな」とか「あれ、さっきと同じことやってるな」と思ったら一度中断しています。時間的・精神的・肉体的な限界を迎えています。
長時間ひたすらだらだらと続けていても効率的とは言えず むしろコスパが悪いので、
短期間しか持たなくても、その短期間を集中して成果を出せばいいんです。
休憩ついでに実施した内容や見つけたものをログにまとめ、頭を整理するとより良いと思います。
探索的テストは学習をしながら進めていくテストなので、このサイクルが大事だと思っています。
(ノリノリの状態が続いていればそのまま続けても良いと思いますが、キリがないので時間で終了のタイミングを決めておくと良いです。)
具体的にはどんなことしてる？
ログ
見つけたバグの内容は紙に書いています。
特別に理由があるわけではありません。
デスクにガラスペンだとか良いペンを置いているのですが、使うとモチベーション上がるからです。(紙のほうが関係性など書きやすいということもありますが)
XSS、SQLインジェクション、ファイルアップロードなどを簡単に
セキュリティを考慮して実装していたり、ツールなどを使って脆弱性診断を行ったりすることが一般的だと思いますが、万が一があったら嫌なので確認しています。
画像ファイルに偽装してスクリプトファイルをアップしようとしてみたりすると結構楽しいです。
異常値
変な文字列を入力できないかをよく見てます。
仕様書に書いてある内容はテストケースでカバーしているのですが、仕様書に書かれていないけれど必要なバリデーションがあるといったことは良くあることだと思います。
他にもフロントで制御するバリデーションだけでは怖いので、異常値を無理矢理POSTしたりもします。
漏れを見つけられる可能性があるほかにも、フロント側とサーバー側でバリデーションが違ったりすることもあるので、そのへんも見ちゃいます。
主に、どんな実装をしてるのか、自分ならどの辺の実装が面倒だと感じるかを考え、ミスをしそうな機能を狙います。
一度の文字列に大量の変な文字混ぜ過ぎると結果から分析しにくかったりもしますが、ひとつひとつやっても効率悪いですし 網羅的な内容はテストケースで見れば良いと思うので異常がないかだけ確認できればいいと思います。
ただ、どの文字列がダメだったか程度ならともかく、
一斉に送ってしまってどのフォームでエラー吐いたのかわからないくらいのやり過ぎは良くないです。基本は忘れずに。
連打
連続でPOSTリクエストが飛ぶと大体ろくなことになりません。
しっかりと制御されていることを確認しています。
裏でたくさん処理してそうなところも連打して意地悪したりもしますが、環境によってはほどほどにしましょう。
JSで実装されている部分なんかも連打のねらい目です。
矛盾する組み合わせとか
結構 意地悪です。
工数や優先度から多くの場合に実装されないであろう選択の組み合わせの制御部分を見ています。
これは正直「仕様です」の返事はわかっている上での行動で、
そうなることはわかっていて、それでも「この選択肢が選べちゃうのってあまり好ましくないのでは？」「ユーザーにとって親切ではないのでは？」と今後の検討リストに追加されたらいいなぁと想いを込めてやっています。
もちろん、自分はユーザビリティの専門家でも企画のプロフェッショナルでもありません。
フィードバックを送れる位置にいることを利用して個人の意見をぶつけているだけなので、ほどほどにしておきましょう。
paramをいじる
URLにparamが見えたら触ってみます。
検索用のクエリが入ることが多いと思いますが、変な文字入れるとなんらかの処理を失敗させたり 攻撃できたりすることもあるので、念入りに確かめています。
その他
マインド
ゲームをしている感覚でテストしています。
ただ、ゲームにも色んなプレイスタイルがあると思います。
自分は開発者の作品への愛やこだわりを感じながら隅々まで見たいタイプです。
具体的には「村人とは台詞がループするまで会話する」「ループしても会話するキャラや内容によっては3回くらい粘る」「装備してって言われた装備をすぐ外す」「使ってって言われたアイテムをくれた人に使ってあげる」「装備全部外してパラメータ上 全裸の状態にしてみる」「ステージの最初は必ず後ろから見る」などなど
「こんなことしてもなにもないだろうなぁー...お？ おおおぉぉっ！！」ってなる楽しみ方です。
世界観を重視してるゲームに対してよくやっています。
ゲーム性を重視してるゲームに対しては、ルールをひとつ無視できたらどうなるのか考えて「バランスの取り方うまいなぁ」と考え込まれた仕様を感じるのが好きです。
といった具合に、開発者がどんなところまで考慮しているかを意識するようにしています。
プロダクトに込めた想いを感じ取りましょう。
この手の作りこみをゲームで体験したい方は、
- undertale, deltarune
- Doki Doki Literature Club!
- OCTOPATH TRAVELER
- シルフェイド幻想譚
- The Stanley Parable
あたりをオススメします。
※かなり個人的な趣味嗜好が入っています
ログどこまで書くのか問題
自分の考えとしては、どんな意図でどんなテストをしたのか説明できなきゃいけないと思っています。
これは探索的テストに限った話でなく、すべてのテストにおいてです。
説明ができないなら、それは探索的テストの「頭の中でテスト設計をしながら」に反しています。
説明のできないテストをしてもほとんど意味はないと思いますし、その場で偶然バグが見つかっても 今後も同じようなバグを見つけられる可能性は低いと思います。
個人の裁量が大きいテストなので、誰にでもわかるように書く必要まではないと思いますが、自分で振り返れる程度のログは残すべきだと思います。
おしまいおしまい
と、自分が思っている・意識している探索的テストについてを述べてみました。
長々と書いてしましましたが、ここまでお読みいただきありがとうございました。
みなさんの何かしらのきっかけになれれば幸いです。
気になる部分、異なるご意見があればコメントなりtwitterなりで反応を頂ければと思います。
それではselenium confに備えて寝る必要があるので、このあたりで失礼いたします。
クラシフィケーションツリーを自分がどう書いているのか手順を追って説明します
どうも、あと1週間ちょっとで新卒一年目の肩書きを剥奪されてしまうhalspringです。
好き勝手に無責任なことを言える免罪符ともお別れです。切ない。
さて、執筆現時点で3月27日、28日にJaSST’19 Tokyoがすぐ目の前に迫っています。初のJaSST参加でドキドキワクワク過ぎてテカテカしてます。
こんなニッチな記事を読んでいる方達であれば申し込んでいる方も多いかと思います。
そして 申し込んだ方なら同じことを感じたと思います。
はい、そうですね、申し込みのパターンでクラシフィケーションツリーを書きたくなりましたね。
では早速ツリーを書いていきましょう。
どう考えてツリーを書いているのか なるべく思考の痕跡を残そうと思います。(途中で疲れていると思いますが どうか温かい目で...)
今回はツリーを作成するまでを中心に綴りますので テストケースの作り方については以前の記事や、 その記事で引用している井芹さんのスライドをご参照ください。
書いたことのない方は はじめに仕様だけ洗い出したセクションがありますので、是非一度ご自身でツリーを書いてみて比較して頂けると より一層お楽しみいただけるかもしれません。おそらくmaybe多分きっとあるいは。
あらかじめお断りしておきますが、
クラシフィケーションツリー法に関して論文を読んだり どこかで基礎からしっかりと学んだわけではないので、書き方や考え方に誤り(よく言えば我流)が含まれている恐れがあります。
この記事を鵜呑みにしてスタンダードだとは思わず、あくまで取っ掛かりとして頂ければ幸いです。
また、クラシフィケーションとたくさん書いてあると可読性が低下するかなと思ったので、因子という言葉とクラシフィケーションが混在していますが 目をつぶっていただければと思います。
最後に、明らかに誤っているところがあればご指摘いただければと思います。
(「大丈夫、あってるよ！」とか「参考になった！」などと言われると喜び悶えますのでそちらもよろしくどうぞ)
仕様把握
JaSST Tokyoの申し込みページから仕様を吸い上げます。
- チケットには参加券、チュートリアル券、情報交換会の券がある
- 参加券は27日、28日、2日券がある
- いずれの参加券も事前申し込みすることで安くなる
- 2日券の事前申し込みにはさらに早割が存在する
- チュートリアル、情報交換会のみのチケット購入はできない
- チュートリアルは27日の前半にセッションでは1,2、後半にセッション3,4があり、28日にセッション5がある
- チュートリアルのセッションは時間帯の被るものは同時に申し込みできない
- チュートリアル券も事前申し込みで安くなる
- ただし、チュートリアルのセッション5の料金は変わらない
- 情報交換会は事前申し込みでも当日券でも料金は変わらない
こんな感じですかね。
学生の招待制度については申し込みのフローが異なるため、ここでは考えないものとします。
それでは書いていきます。
クラシフィケーションツリーを書いてみる
ドメイン
書き方に王道や正解があるのかわかりませんが、自分は根っこから書いていきます。
今回考えるのはJaSSTの申し込みなので、そのまま書きます。
前回の記事でも書きましたが、せっかくsurface proとペンを買ったので活用しないといけない衝動に駆られているため手書きです。
ドメイン→クラシフィケーション
申し込めるものは、
- 参加券
- チュートリアル券
- 情報交換会
になります。
そして、参加券こそ買う必要があるものの、チュートリアル券と情報交換会に関しては任意の購入になりますので、直交しています。
つまり、ドメインからクラシフィケーションが3つ伸ばせます。
参加券
では、購入が必須 かつ 一番複雑な参加券から考えていきます。
参加券には1日券と2日券があります。
ですので、参加券のクラシフィケーションから「1日券」「2日券」のクラスを伸ばします。
そして、1日券、2日券のどちらも、より詳細な購入方法の選択があります。
- 27日の参加で事前購入
- 27日の参加で当日券
- 28日の参加で事前購入
- 28日の参加で当日券
- 27日、28日の2日参加で早割
- 27日、28日の2日参加で事前購入
- 27日、28日の2日参加で当日券
ここで、各参加券に共通する「購入のタイミング」という因子の候補が出現しました。
枝を伸ばす前にこの「購入のタイミング」を考えてます。
まず、この「購入のタイミング」という因子がどれほど他に影響を与えるのか。
出現したタイミングだけを見ても、「参加券」の末端に位置するであろう 上記の7つのクラス候補を下記の4つに減らすことができそうです。
- 27日
- 28日
- 2日早割 有
- 2日早割 無
「購入のタイミング」自体は { 事前, 当日} の2クラスで済みそうなので、合計して見ても末端となるであろうクラスを1つ削減できるため、採用しても良い感じがします。
さて、「購入のタイミング」は他にも影響を与えるでしょうか。
仕様を見返すと、
- チュートリアル券も事前申し込みで安くなる
とありますので、この因子を足すことでチュートリアル券のクラスも減らすことができそうですね。
そして、情報交換会には影響を与えないのでドメインから伸ばすクラシフィケーションとして採用して良いと言えます。
悪い影響を与えないことも採用するかどうかの判断に使います。
(この辺はうまく言語化できないのですが、ツリーを複雑にするくらいなら少しの冗長は妥協したほうが見やすくなると思ってます。)
チュートリアル
次に「チュートリアル」です。
チュートリアルは1~5まで存在し そのうち4つは27日に開催され、さらに前半・後半でわかれています。
(スペースが足らなそうなのでずらします。これがデジタルのいいところですね。)
ここにチュートリアル5を追加したいです。
1~4と5を隔てているのは日付です。27日・28日で価格も変わりますので、もう一段大きいところに「日付」のクラシフィケーションを作るとちょうどよさそうです。
情報交換会
あとは「情報交換会」に参加するかしないかのクラスを作ればツリーの出来上がりです。
情報交換会は事前購入でも当日でも料金が変わらないので、そういった情報は頭の片隅に置いておくか、近くにメモしておくと良いです。
完成！！
完成したクラシフィケーションツリーがこちらです。
いいですね、かわいいですね。
あとはこのツリーからテストケースを作成していきます。
このツリーで料金を大きく変える因子は「購入日」で、「購入日」の影響を受ける因子は「参加券」と「チュートリアル」です。
また、「参加券」と「チュートリアル」には禁則が多く存在するため、この辺りからテストケースを作っていき 残りの因子は網羅基準を満たすように配置してください。
網羅基準を満たした後は「テストの手間が増えるので "なし" を選択する」「処理が複雑で心配なので入念に」など、定めたアプローチや設計者・ステークホルダーの考えで選択してください。
いかがでしょうか、これで少しでもクラシフィケーションツリーが書けそうな気がして頂ければ幸いです。
クラシフィケーションツリーを書くのは楽しいですが、どんな場面にでも適応できるわけではないので、頭の片隅でその存在を覚えておいて ここぞのタイミングで思い出してあげてください。
きっとツリーも喜びます。
それでは、よい Classification Tree Method Life を。
なぜ自分が開発したソフトウェアのテストをするのは面倒なのか？
どうも、そろそろ1年目を名乗れなくなりますhalspringです。
「要件定義、仕様策定、設計から開発まで関わったシステム」に対して「自分でテストを設計して実施する」機会があったので、そこで感じたことや考えたことを踏まえて いつものようなテストのエモい話を語ります。
テストは面倒くさい？
この記事を読んでいる方の立場にもよって意見も別れると思います。
貴方は開発を行う立場でしょうか？
貴方はテスト設計を行う立場でしょうか？
それとも、貴方はその両方でしょうか？
恐らくですが、テスト設計をメインに行う立場の人ほど「テストは面倒」とは思わないのではないでしょうか。
そして、開発をメインに行う立場の人ほど「テストは面倒」なのではないでしょうか。
なぜ開発を行う立場に近づくとテストが面倒に感じてしまうのか、今回はそれを考えてみました。
開発するとき無意識にしていること
開発経験のない方でもイメージできると思います。
開発者はエディタを開いてプルリクを出すまでに何をしているでしょうか？
(※ 完全に私個人の見解です )
仕様を確認して、
ロジックを考えて、
コードを書いて、
コーディング規約の確認もしつつ、
動作確認をして、
問題なさそうなのでgit commitして、
プルリクを送る
これだけでしょうか？
いいえ、違います。
書いたコードが1発で正しく動作するなんてことは、よほど仕様がシンプルでない限り稀です。
大抵はうまくいかず、修正をしながらコードを書き進めていきます。
コーディングして、
動作を確認、
不安なところは念入りに、
あぁここclass名変えたんだった...、
コードを直して動作確認、
バリデーションは大丈夫だろうか、
変なメールアドレス入力してみよう、
よし大丈夫だ、次だ次...
概ね、こんな感じではないでしょうか？
ところでこれ、ちょっと何かに似ています。
テストに詳しい方ならお気付きかもしれません、そうです探索的テストです。
修正に当たる部分をissueやバグ票に置き換えるとあまり違いがないようにも思えます。
つまり開発者は、開発中に探索的テストに近いことをしているのです。
テストの順番
実施するテストには順番があります。
もちろん、プロジェクトやテスト戦略によって色々ですが、個人や会社である程度の型は経験則としても持っているかと思います。
例えば「パフォーマンステストをしてからシステムテストをするつもりです」と言われたら、耳を疑いますよね？
「探索的テストをがっつり実施してからシステムテストの設計をしてください」と言われても、気乗りしませんよね？
(スモークテスト的に行うことはありますが)
テストにはそれぞれ目的があり、適したタイミングで適した不具合を見つけることが大切です。
探索的テスト
ちなみに、探索的テストはいつ行うのが良いのでしょうか。
もちろん絶対的な正解はありませんが、
一般に、様々なテストを行った後に補完的に行われることが多いと思います。
JSTQB ALTAのシラバスにも、次のように記載があります。
優れた探索的テストは、しっかりと計画されており、相互作用的で創造的である。探索的テストは、テスト対象の システムに関するドキュメントをほとんど必要としないため、ドキュメントが存在しないか、他のテスト技法では適 切でない場合に使用することが多い。また、多くの場合、他のテストを補完したり、追加のテストケースを開発す るための基準を提供したりするために使用する。
先程も例として書きましたが、仕事でテストをしている方であれば、
「探索的テストをがっつり実施してからシステムテストの設計をしてください」と言われるとなんとなく二度手間感があったりして、面倒臭さが出てくると思います。
( 完全に私自身の見解です )
ところでこの状況、なにかに似てませんか？
そうです、先程の開発しているときの話をしました。その開発の後にテストが待っています。
開発者はコーディングする中で探索的テストのようなテストケースのないテストを行っているため、その後にテスト設計を行うことが億劫に感じるのです。
( ※ 完全に私個人の見解です。 )
では、なぜ探索的テストの後のテスト設計は億劫なのでしょうか。
テスト設計時に無意識にしていること
開発するときにどう考えているかを勝手に考えてみましたが、
次はテスト設計するときにどう考えているか考えてみます。
※ くどいようですが完全に私個人の見解です。
弊チームのボスからとある話を聞き、考えてみたところ、
自分はテスト設計をするときに、ソフトウェアがどう実装されているかを考えていました。
機能の追加や改修があれば、どんなロジックを追加する必要があって、どんなところが複雑になるかを考え、「こんな実装をしているだろう」のイメージを作っていました。
いくつかの「こうすれば実装できる」のイメージから、
・データのやり取りがありそうだから、ここをしっかり見ておきたい
・自分だったらこのあたりでミスしそう
といった感じにリスクや観点を考えています。
その後、改めて仕様書を見てリスクや観点を洗い出し、先程のリスクや観点を比較して漏れがないか考えます。
この記事を読んでいる皆様と自分で どんな流れでテスト設計をしているか異なるとは思いますが、共通して仕様書からいろいろと要素を拾い上げることはしているはずです。
ところで開発者は...
さて、時は実装前まで戻ります。
この記事のはじめにも書きました、コードを書く前に仕様を確認していますよね。
そうです、実装するまでに仕様書を読み込む必要があるわけです。
また、どう実装するか、そのロジックに至るまでも頭に叩き込んであるわけですね。
その後にもう一度 どう実装するか考えたり 仕様書を読み込んだりしたくないわけですよ！
一度頭に入った情報は材料にもなりますがノイズにもなり得ます。(私個人としてはこのノイズがテスト設計のときに思考の妨げになっていました。)
探索的テスト後のテスト設計の二度手間感も同様でここに起因していると思います。
二度手間「感」ではなく、本当に二度手間を掛けているわけです。
どうすれば面倒にならないのか
本当はここで画期的な提案ができればよいのですが、残念ながらここはまだ模索中です。
現状思いつくのはテスト駆動開発です。
ユニットテストを設計・実装しながら開発を進めることで、探索的テストライクな部分がユニットテストに置換されます。
ユニットテストも結局仕様を把握する必要はありますが、テストの順番として違和感が軽減されます。
単体テスト・結合テストを実施してからシステムテストを行うのは至って自然です。
もちろん個人・チームでのやりやすいように 納得感を持って進めていただければ良いとは思いますし、面倒に感じてしまう理由も人それぞれだと思います。
テストが面倒に感じる方は是非一度こういった観点からアプローチをかけ、少しでもテストを好きになって頂けたらと思います。
学んでみると テストは世間で思われているほど悪いやつじゃない と思えるかもしれません。
クラシフィケーションツリー法の自由さを活用する
アドベントカレンダー
本記事はソフトウェアテストの小ネタ Advent Calendar 2018 24日目の記事になります。
前日は とろさんの記事でした。沼ダイブ、自分ももっと頑張りたいです。
ご挨拶
ご無沙汰しております。 クリスマス前日、皆様はいかがお過ごしでしょうか？
どうも、こたつで猫を抱えながら細々と記事を書いているhalspring(@halspring_qa)です。 昨日中古で買ったモンハンワールドに時間を溶かされています。
12月はWebQA、AI4SE、wacateと盛り沢山でした。 去年のこの時期、暗い顔しながら卒論を書いていたとは思えません、今はとても楽しいです。
語りたいこと
今回、クラシフィケーションツリー法について書いてみたいと思います。
はじめにお断りとして、高々テスト歴半年程度で書いておりますので、技法や用語、考え方等に誤りがある可能性がございます。 どうか温かい目で見て頂ければと思います。ご指摘等もお待ちしております。
クラシフィケーションツリー法に関して前知識を準備しておきたい方は井芹さんのこちらの資料をどうぞ。
クラシフィケーション・ツリー法入門 from H Iseri
www.slideshare.net
それでは、クリスマスツリーの代わりにクラシフィケーションツリーを眺めながら一緒に愉快なクリスマスイブを過ごしましょう。
クラシフィケーションツリー法
クラシフィケーションツリー法はテスト対象が持つ要素を木構造でモデリングするテスト設計技法です。 今回はクラシフィケーションツリー法を用いてテストケースを作っていく際に、クラシフィケーションツリー法の利点をどう活かすかを書いていきます。
文章のいいところは、何度クラシフィケーションツリーと言っても噛むことがないところですね。つい必要以上に何度でも繰り返しちゃいます。
直交表との違い
テストケースを作成するフェーズになると、直交表と同じでは？と感じることがあるかと思います。 直交表では、主に2因子間の水準組み合わせを網羅するように使われています。ちなみに3因子間の網羅でも使えるそうです。
さて、この直交表のメリットは、組み合わせテストにおけるテストケース数の削減と各水準の組み合わせが均一に表れるところにあります。
この記事で語りたいクラシフィケーションツリー法のメリットは、後者の各水準の組み合わせ均一に表れるという縛りがないことにあります。 (wacate 2018冬にて中村さんが口頭でおっしゃっていて「ハッ！」となりました。ありがとうございます。解釈が間違っていたら申し訳ないです...)
クラシフィケーションツリー法のメリット
それでは、「各水準の組み合わせ均一に表れるという縛りがない」とはどういうことか説明したいと思います。
まず前提として、組み合わせを考える際にすべての水準の重要度や使用頻度が等しいことは稀であると思っています。(この前提が共感できなければ、おそらくこの記事で伝えたい内容は入ってこないかと思います...)
相互に作用する組み合わせと、仕様上独立している組み合わせを同様の比重でテストするだけで十分か？という観点で実施をします。
(もちろん業務であれば、要件としてどれくらい網羅するかの基準はあるかと思いますので、状況に応じて考えて頂ければと思います。)
実際に例を見ながら説明していきたいと思います。
テストケース作成の例
問題
テスト界隈ではそこそこメジャーらしい"ラーメン"をテーマに問題を作ります。
「あなたはラーメン屋めぐりにハマっています。あなたは検証が大好きなので、訪れるラーメン屋を見切るまで通い続けます。 しかし、次に訪れるラーメン屋は麺の太さや硬さ、スープの種類を好きに選べるタイプのお店です。 しかし、早く次のラーメン屋検証にも進みたいため、なるべく早く見切る必要があります。毎食食べるとして、何日で見切ったと言えるでしょうか？」
といった問題です。
ラーメン屋の詳細は以下の通りとします。
スープは味噌・醤油・塩の3種類
麺の種類は細麺・太麺・ちぢれ麺の3種類で、
バリカタ・かため・ふつう・やわらかめの4種類から硬さを選べます。
トッピングは著者の独断と偏見および簡略化のため海苔のみとします。
ツリーを書く
問題を元にツリーを書きだすとこんな感じになります。(気持ち程度に名称を加えてます。Surface買ったのでペンを使ってみたかっただけです。)
ツリーの形が異なる方もいるかもしれませんが、今回は説明のためこのツリーを使います。
因子と水準が洗い出せたら格子を書きます。
テストケースの作り方
ツリーが書けたら基準を決めます。
ここでクラシフィケーションツリー法の本領発揮です。
まずこれらの水準で、相互に作用するものがあるかどうか考えてみます。
例えば、「海苔の有無」と「麺の硬さ」はそれぞれに影響があるでしょうか？
自分はないと思います。
よって「この２つはペアワイズにする必要はない」と判断します。
では、相互に作用するものはなにか。そうです、麺の「種類」と「硬さ」です。
「相互に作用し、かつ重要度が高いためこの部分はしっかり網羅したい」のでペアワイズで考えます。
こんな感じです。
では、ここに先ほど触れた海苔を考えてみます。
海苔の有無は麺に影響を与えないものの、一度は食べてみないと見切ったとは言えませんね。
よって、1ワイズで網羅します。
海苔に関する網羅率はひとまずこれで十分ですね。
最後にスープや残りの海苔の有無について考えていきます。
クラシフィケーションツリー法では人の意思を介入させることができます。
水準が等しく表れる必要はありません。
よって一度の検証で余計な要素はなるべく減らしたいので、海苔はできるだけ「無」にしたいと考えます。 しかし、「海苔はスープとの相性もあるのでは？」と考えたりします。
そう感じたのであれば、そこはペアワイズを考えればいいわけです。 既に12ケースが作成されるのは必然なので その中で網羅し、必要な分書けたら残りを「無」にします。
このような具合に、テスト対象の特徴や要件に合わせて網羅基準や水準の選定基準を考えます。
- この店の主力商品はなにか？
- 自分が絶対に 食べる/食べない 組み合わせはあるか？
- もう1回 海苔を入れて試してみたくなった
などなど。
例えば今回は自分のための検証なので「ちぢれ麺は味噌以外で食べることはほとんどない」といった潜在的な情報があったりします。
このように「ユーザーはほとんどが20代～40代なので、60代以降よりも重点的に見る」や「金額表示に関わる部分なので重視する」といった基準を自分達で考えることができます。
この潜在的な情報はプロダクトによって様々で、
- 使用頻度にばらつきがあるところ
- 開発が苦戦していたところ
- ロジックが複雑なところ
- 法的に問題を起こせないところ
- 会社として守らなければいけないところ
など様々な判断軸があると思いますので、自分たちのプロダクトに合わせてテストケースを作成して下さい。
ちなみに「スープと麺の組み合わせを網羅しないとは何事だ！！」という意見は、もちろん誤りではありません。 それもまた潜在的な要件であり、今回 自分が必要としていた要件ではなかっただけのことです。
必要ならその条件を足せばいいわけですし、不要なら考えなくて良い、自由に基準を決められる利点を最大限活用してみてください。
終わりに
改めて用語や考え方に誤りや及ばない点があるかと思いますが、大目に見てくだされば幸いです。
クラシフィケーションツリー法について書かれた情報が少ないので、もう少し身近に感じてもらえればと思います。
それでは皆さん、良いクラシフィケーションツリーライフをお過ごしください。
メリークラシフィクリスマス
