こちらのイベントに参加してきたので、会で印象的だった話と感想を書いていこうと思います。
会の概要
miwaさん咳さんよしたけさんの3人で、「ソフトウェアテストをカイゼンする50のアイデア」の本を読んで、読んでいる様子やその感想を見ていくという会です。miwaさんが一文字一文字音読して、区切りのいいところでみんながそこに対して話し合うというスタイルで進んでいきました。(今日はP21〜を読んでいきました)
会で印象的だったこと
マインドマップのツールでそこまでテストをするか？
本書で挙がっていた例ではマインドマップツールを作っているので、使えなかった際に致命的な何かがおこるわけではないため、ネットワーク環境のせいで使えない想定まではしなくてもいいのでは？(手厚いのであるに越したことはないけれど)という話が出ていました。
ただ、使うのを前提に考えがちなので、そこで使えないことに注目することができていたのはすごいな、という話も出ていました。
また、仕様を信じてテストすると本書で改訂あるバグは出てこないので、仕様を信じなかったという意味でも偉いよね、という話もありました。
P22に誤字
P22の序盤の方に、「サポートを提供できなくなってします」と書いてあり、誤字がありました。
2つ目の洞察が出たのは面白い
P22に書いてある2つ目の大きな洞察が得られているのはよいのですが、これまでの話の流れからすると直接出てきそうな観点ではなかったので、どうやって出てきたのかは気になるし面白いね、という話がでていました。
ログを普段仕込んでテストしているか？
普段テストしているときに、ログを仕込んでいるか？という話題がありました。
よしたけさんのチームでは、本書に書いてあるような厚でみログを仕込んでテストすることはないということです。
咳さんのチームでは、ログは「この通り動きました」しか示していないので、「自分が書いたところではこういう風に動いたよ」ということしかわからず問題の本質がわからないことも多いので*1、ログさえあればいいとは思っておらずログをとにかく書くという話には懐疑的だそうですが、開発者によってはログを仕込んでいることもあるということでした。
考えやすいところに飛びつくのは危険
考えやすい部分やわかりやすい部分がはっきりと見えているのは、隠れているパターンが見逃されがちで危険だという話が出ていました。
仕様はみんなで考えて作ることができるものなので、「ここだけ考えておいてね」みたいなある種の分業は危ないよね、ということです。
ユーザー価値にフォーカスするのは探索的テストだけではない
「〜したい」ではなく、「〜するために」という部分にフォーカスするのは探索的テストに限った話ではなく、常に考えるものだよね、という話が出ていました。
これと合わせて、過程にフォーカスする重要性(どうやって1,000件という数字を出したのか？を尋ねる重要性)や、自分たちが見ているのは常にある一面上のものだけだということを意識し続けておくのは大事だという話もありました。
なお、咳さんのチームでは「ユーザー価値」という言葉は出てこないけど、「これなにが嬉しいんだっけ？」はすごくよく出てくるということです。
よしたけさん的には、「価値」はめちゃくちゃ広いフェーズで「品質」に近い言葉で、認識齟齬が置きやすいですし、話をごまかすために使われちゃう言葉なので、あんまり使いたくはないということでした。
似たよう話で、咳さんも「効率」とかは話をごまかしちゃうために使われがちなので、
「それ何分の何？」と聞いてしまうということでした。(「率」を差しているのか無駄なことをやっているのかが気になる)
会全体を通した感想
ログの部分でデグレを心配しちゃうところや、考えやすいところに飛びつくのは怪しいという話や、「価値」という言葉に怪しさを感じるところなど、今回はたくさん共感できる部分があり、頷きが止まらない会でした。
会の本筋ではない(?)のですが、「洞察が深い」とか「いい洞察だね」って言われるのはなんかドキッとしちゃうという話からお互いに言われた場合を想定するくだりも面白かったです笑
*1:ログはどうやら正常です、で調査が終わってしまうこともある
