実行者育成計画仮

この記事は「書きたかった一人アドベントカレンダー、リキッドルームに」3日目の記事です。

ここでいう「実行者」は「ソフトウェアのテストの仕事に置いてテストを実行する人」の意味です。

去年もテスト実行者について書いていました。
どちらかというと実行者のソフトスキル寄りの内容です。

今年はもう少し違う視点で書いてみようと思います。

「どうなったらいいと思っているか」「何がおかしいか」を伝える力をつけて欲しい

仕事の特性上「この動作じゃあもしかしてダメなのでは・・」を伝える仕事なので、「どう思ってて」「どうおかしいか」を伝えてもらうことが大事です。
なにも不具合の伝え方に限った話ではなくて「この実施方法はこれがおかしいのでは？」など、とにかく「疑問に思った内容」を「具体的」にすることが業務において日常茶飯事なので、XXだからXXだよ、を書けるようになってもらえると嬉しいです。

具体的には「XXがおかしい」から一歩進んで「XXだからXX」を書けるようになってほしい。
不具合表を書くときも「こうなるべき（と思っている）動作」を書けるように。

例.
下記のようなフォームがあったとします。

ちょっと頑張ってほしい例「画面がおかしい」
もう少し頑張ってほしい例「ラジオボタンがおかしい」
こう書いてほしい例
ラジオボタンに両方ともチェックがついている。
期待される動作：ラジオボタンはどちらか片方だけチェックが付く
NGと思われる動作：ラジオボタンに両方ともチェックが付く

同じようなものが不揃いなことに違和感を抱く力をつけて欲しい

同じような機能が2つあるとします。
動作がバラバラだったときに、それを不思議に思う力をつけて欲しいです。
動作がバラバラなことが正解な日もありますが、大体は揃っていた方が嬉しいです。

例.
下記のようなフォームがあったとします。

「カートに入れる」を押した時に表示されるダイアログがこれだとします。

「購入する」を押した時に表示されるダイアログがこれだとします。

「はい」と「いいえ」は同じプロダクトなら何か事情が無い限り向きは揃っていた方が使いやすいように思えます。

この例は極端ですが「揃っていた方がいいこと」は思いのほか色々なところに散りばめられています。

この「不揃いに違和感を抱く」をできれば、テストする人としては結構いい感じ（だと自分は思ってます）

プロダクトを作る側も注意は払っているでしょうが万能ではないため、それをテスト作る人やテストする人が気づければ、それが本望だと思うので。
スイスチーズモデル的なイメージで
「プロダクト作る人」→「テスト作る人」→「テスト実行する人」で、関わる人それぞれですり抜けるバグを減らせればよいと思います。

この能力を応用して何かの不具合が出た時、それに似たようなことをどんどん確認して、類似の箇所に気づいてほしいです。

明らかなテストケースの作成間違いに気付ける人になって欲しい

行間を読むという言葉が個人的にはあまり好きじゃないです。
ですが、これは誤記ではないのか、を経験を積んで気づける人は「おーありがたい」と思います（どこ視点だろう）

最後めちゃくちゃ抽象的に書きましたが「ルールや経験則から逸脱を導き、学習して、そこから導かれる違和感を言葉にできる」
多分、これをしてほしいんですね。

これだけでもないんですが、（プロダクトの動作なりなんなりの）ルールを読み取れる人はありがたいです。
なので、テストの実行の仕事に入る人は上記に挙げたようなことを出来るようになってくれれば、と思います。