第4回 テスト観点を語る夕べに参加しました
こんにちは。まつやま改め、カルバートです。
第4回 テスト観点を語る夕べに参加してきました。
当日のtogetterはこちら。
はじめに
まずは登壇者のなそさんが作成されたマインドマップがどーん！
めちゃくちゃ文字が綺麗で、美しいマップです。
何を食べたらこんな綺麗な文字が書けるのでしょうか…羨ましいです。
参加型ワークショップ
当日はまず前回のおさらいから始まり、その後はにしさんのファシリテートを受けて、なそさんのマインドマップに加筆修正が行われていきました。
そのサービスのコアバリューは何か
今回のワークショップでは、connpassというサービスを題材に、サービスのコアバリューを列挙し、それを親要素としてテスト観点をブレイクダウンする手法が取られました。ここで重要なことは、機能や操作(※)といった、ソフトウェアの構造上の「わかりやすいポイント」に最初に飛びつかないことです。
(※ connpassの例でいえば、「検索」や「申込」などが該当すると思います)
僕はこれまで、要求や要件を親とするアプローチや、機能や操作を親とするアプローチを多く経験してきましたので、これは個人的に新鮮でした。
いつでもどこでも
コアバリューの例としてなそさんが挙げられたキーワードに「いつでもどこでも」がありました。connpassは勉強会ポータルですから、いつでもどこでも好きなときにイベントを登録できること、参加申し込みができること、キャンセルができること、あるいはサイトに繋がるといったことが重要なバリューになります(と、この勉強会では解釈しました)。
コアバリューを分解する
次に、コアバリューを分解していきます。ここでひとつ、注意点があります。それは、いきなり具体的なキーワードを書かないということです。子ノードを作成するときに、「いつでもどこでも」から連想する具体的なワード(例：ログイン機能)を書きたくなってしまいますが、一歩立ち止まって我慢が必要になります。子ノードを作成する目的は、今すぐにわかりやすいテストケースを作成することではなく、親ノードの持つ「意図」を分解することです。
「いつでもどこでも」を親とするならば、次の子ノードの例は「いつ」と「どこ」になります。これ以上いきなり細かくしてしまうと、MECEや継承関係が後から確認しづらくなってしまいます。
思考がアンカリングされていることを意識する
子ノードを出すときのもうひとつの注意点として、思考のアンカリングがあります。今回は、「いつ」というキーワードの意図を紐解いていくと、「トラフィックが増えたとしても、それに耐えられること」という意図が浮かび上がってきました。このとき、参加者は全員「トラフィックの増加って、つまりどういうことだろう？」と、具体的なユースケースや、システムのアーキテクトを想像しはじめます。
僕の場合は、「某人気イベントに人が殺到したけど、あの重たさは許容範囲内だったんだろうか」とか「トラフィックと一口に言ってもいろいろあるし、内部構造を知っているか知らないかでも気にするポイントは変わるな」といったことが頭に浮かびました。
こういった状態では、脳は「トラフィックが増えたとき」のことをどんどん深く考えてしまいます。それは決して悪いことではないのですが、この状態で他の「意図」について考えようとしても、「トラフィック」思考にどうしても囚われてしまいます。これが「思考がアンカリングされている」状態です。
この対処としては、アンカリングされている間は頭が空っぽになるまでアウトプットを続け、空っぽになったと思われるタイミングで次に移ることが有効だそうです。このメソッドは、ブログを書いたりするのにも使えそうですね。
ここまでのまとめ
・コアバリューを起点に、子要素をブレイクダウンする
・子要素をブレイクダウンするときは、いきなり具体例に飛びつきたくなる誘惑と戦う
・思考がアンカリングされていることを意識する
当日はこのほかにも色々お話があったのですが、一旦ここまででまとめとさせていただきます٩( 'ω' )و
