たまに「テストなんて新人にさせておけ」といったセリフであったり、そのような考え方に対する「けしからん」的発言を見かけます。
これが「テストというのは誰でもできる作業なので新人にやらせておけ」という意味合いであれば私も反対です。
一方で、新人、ここでは
- IT業界に新卒で入った人
に限らず
- そのサービスやプロダクトの開発組織に入ったばかりの人
を指すとして、そうした方にテストをしてもらうというのは一定の意味があると考えています。
新人がテストをする意味
前回の記事 探索的テストの学習側面を実感するとき - テストウフ で書いた通りではあるのですが、テストをすること、そしてテストをしながら気になる点を仕様書やチケット、ナレッジベースを漁りながら調べることによって、テスト対象に関する理解が深まります。
開発組織に入ったばかりの人が自分たちの開発しているものを理解するには、ただ漠然とドキュメントを読んだり人に話を聞いたりするだけだと効果が薄いでしょう。「テストをしよう」「バグを見つけてやろう」と思って触れることで、より集中力を高めた・認知能力を高めた状態でテスト対象を理解できると信じています。
ただ、こうした効果を期待してテストを任せるにあたって、注意点もあります。
1. スクリプトテストだけに閉じないようにする
テストを任せる際、詳細に手順化されたスクリプトテストをただ実行してくれという指示では学習効果が薄いと思います。
もちろん画面構成や機能の概要についての理解は深まりますが、より効果を得るには探索的テスト"も"やってもらったほうがいいでしょう。
『探索的テストの考え方』で言うところの、ハイブリッド探索的テストのように、テスト手順には従いつつも「気になるところは自分なりに考えて追加で見てみて」といった指示の仕方をすると、思考を入れ込む余地が生まれるのでよさそうです。（この「自分なりに」の部分で、実行者のテストエンジニアとしての力量を測ることもできますね。）
2. ベロシティを求めすぎない
上記の「ハイブリッド探索的テストのような形で思考の余地を」を実現するうえでは、実行者に対してテスト実行件数のベロシティを求めすぎないことが大事だと考えています。
私は新卒でテストエンジニアになって、同期数名とともにテストをしていたことがあるのですが、なんとなく「周りが300件終わってるのに自分は200しか終わってない」とか「自分は今日150件も実行したぞ、一番早く進んでるぞ」といった思考になったりするんですよね。若いころなのでお恥ずかしいのですが。
これは自分からそういった「競争思考」になったパターンなので、普通に指導すれば問題ないです。しかし、逆に上司や先輩の側がこうした思考を植え付ける危険もあります。
消化件数を追うような空気があると、スクリプトテストを「はやく終わらせる」ことに意識が向くので、探索に割く時間がゼロに近いほうが良くなってしまいます。そうなると、テストを行うことでの学習の要素もゼロに近づいていきます。これは良くない。
まとめ
開発チームにきたばかりの人にテストをしてもらって、対象の理解を深めるのは良い手段だと思います。
ただ、そのときに探索の要素を含めることと、探索を阻害するような進捗プレッシャーを与えないこと。このあたり意識すると、テストによる学習の効果が高まるのではないでしょうか。