元々テストのイメージは、「ひたすらゲームを遊んでバグを報告する」というものでしたが、実際は先方が用意したゲームの仕様書を確認したり、バグの報告文を詳しく書いたり、ゲームを触っている時間よりも他の作業している時間の方が多いと感じました。お客様の仕様書を理解して、不具合の現象を分かりやすく伝えるために文章を書くということは、テストエンジニアにとって大事な要素だと思っています。こちらが発見した不具合をもう一回お客様の手元で再現してもらわないといけないので、詳細な手順・環境でなるべく簡潔に書く必要があります。

同じ案件に入っているチームメンバーの成長を感じたときですね。日々、メンバーのタスク管理をしている中で、僕が思っていた以上の成果を上げてくれたり、見落としそうな不具合を見つけてくれたり、僕がテスト設計を作った段階では気づけなかった仕様について質問があったりすると「よく見てくれているな」と感じて、とても嬉しいです。そのメンバーがあげてくれた成果物がお客様に届いて、その成果物によってお客様が満足してくださると、まわりまわって自分も成長しているなと思います。

自分からアクティブに動けるような人が合うと思います。言われたことだけをやってると、見落としてしまうような不具合があったりするのですが、ゲームが好きな人であれば「本当にこれでいいのかな？」「仕様書と合っているけれど実際遊んでみると使いにくくないかな？」「この現象とこの現象を同時にやったらどういう挙動になるんだろう？」など、様々なことに気づけると思います。必ずしも好きなゲームのテストを担当できるとは限らないですが、そういう人がチームメンバーにいてくれたら心強いです。