『ソフトウェアテストをカイゼンする50のアイデア』読書会を聴く会に参加してきた

connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

一人だと多くのことを考えることが難しい？

一人では無尽蔵にアイデアは出ないという記述に対して、これは限界が変わるという話なのか？という話を聴いていきました。

仮に限界が変わるとして、二人でテストしたとしても良くて2観点にしかならないので、果たしてそれで良いといえるのだろうか？みたいな話も出ていました。

また、新しいアイデアがぽんぽん出てくるというのも怪しいということで、関さんは知っているバグしか出てこない感覚があるという話もありました。

時間と脳の無駄遣い？

テストしていない人がメモを書いてテストをしている人を観察するという行為が、時間と脳の無駄遣いという表現がありましたが、これは本当かな？という話をしていきました。

俯瞰しているからこそ気がつくこともあるし、観察して手が回っていなそうな部分や自分も確認したほうが良さそうな部分をサポートすることは実際の現場でもあるそうですが、時間と脳の無駄遣いをしている感覚はまったくないそうです。

テストの限界

テストの限界という感覚がよく分からないという話を聴いていきました。

あるユーザーストーリーに対して、「1000個テストケースを出してね」と言われたときに、300個しか思いつかないとかであれば「限界」という単語のイメージはつくものの、普段は「ここまで見れればいいでしょ」という部分をすべてテストするので、なかなかイメージがつかないということです。

miwaさん咳さんチームにおけるモブ

miwaさんはみんなで観点を相談したりとかは普通にするけれど、「みんな今からモブやるよー！」みたいなイベント的な感じでモブを行うことはないというお話がありました。

また、このアイデアでは4-8人をモブとしているようですが、miwaさん咳さんのチームは20-30人くらいで仕事することをモブと言っている(イメージしている)ので、4-8人をモブと言われると「お、おう...」となってしまうようです。

コンセンサス

リスクと品質に関するコンセンサスを取得できるという話から、コンセンサスを取得することって果たして良いのだろうか？という話になりました。

コンセンサスを取得すれば、「こういう風に合意しましたよね？」ということが言えるため、仕事を早く終わらせることができる一方で、良いプロダクトを作りたいという目標からは遠くなってしまうのでは？(良いプロダクトは何回も作って触って作り直すを繰り返す)という話がありました。

予備知識がない方が自由で根本的なテスト設計ができる？

他部署といった予備知識がない人を呼ぶと自由で根本的なテスト設計ができるという記述に対して、これはさすがに嘘では？という話が出ていました。

現場でもたまにこういった主張をする人はいるそうですが、「じゃあその人達(他部署)にテストを任せようよ」というと途端に嫌な顔をされて主張を取り下げられるということで、実現した試しがないそうです。
また、予備知識がない人にテストしてもらうというのは、ラッキーパンチに近いテスト(「こういうバグを見つけるぞ」のような狙いがないテスト)になってしまうのも気になるという話も出ていました。
更に、この主張が本当に正しければ、プログラムも予備知識がない人に書いてもらったりした方が新しい発見があるということにもなるので、「テストは誰でもできる」みたいな思い込みも隠れていそうだという話もありました。

ただし、miwaさんは、新しく来た人に対して説明しながらテストしているときに「これってなんでこうなんですか？」と言われて、自分が触りすぎて当たり前に思っていることを気づかせてくれるという経験はあるそうで、「自由で根本的なテスト設計ができる」は流石に言い過ぎだけれど小さな気づきをもらえるという効果はあるのかもしれないと言ってくれていました。

テストに入ってもらうタイミング

システムに対して深く理解している人たちのほうが良いテストができるのは間違いないけれど、バグまみれのプロダクトをテストする際は、「細かいことに気がつく人は少し後のタイミングでテストに入る」という工夫をすることはあるという話がyoshitakeさんからありました。

全体を通した感想

フラッシュモブという単語は確かにあるなあと思いつつ、モブでやると言われると20-30人で仕事することをイメージするという話は、すごく面白かったです。

予備知識がない方が自由で根本的なテスト設計ができるというのは個人的にも今ひとつよく分からなかったので、成功体験を持っている人がいたらぜひ話を聞いてみたいなあと思いました。