僕は、実装するペアとは別のペアがテストをするのがわりと好き。仕様からテストを設計して実施してたら、実装者が見逃してたバグを見つけられたりする。
バグを見つけるのって面白い。でも、見つけるより前に、減らしておきたい。
だから、プロジェクト全体で誰が意思決定者なのかをキックオフの段階で明確にしておきたい。誰が決めるかが分からないプロジェクトは迷走してバグが生まれやすくなる。
だから、プロダクトマネージャーには機能改修の背景を聞いてから機能の話を聞きたい。背景と機能が自分の中でつながらないときは、何か認識のズレがあってバグが生まれやすくなる。
だから、スコープは小さくしたい。スコープが大きいとバグが生まれやすくなる。
だから、関係する他チームとのコミュニケーションを最初に設計しておきたい。チーム間のコミュニケーションがうまくいかないとバグが生まれやすくなる。
だから、早い段階で動くものをステークホルダーに見てもらってフィードバックをもらいたい。実際に動くものを見ると気がつくことがある。頭の中や言葉だけだと勘違いがあってバグが生まれやすくなる。
だから、設計は誰かエンジニア1人がリードしつつも、毎日その図を見ながらエンジニア4人でわちゃわちゃ議論したい。複数の目で見ることで設計の問題に早く気づけて、バグが生まれにくくなる。
だから、実装ペアとテストペアを分けて、仕様を元に実装をするペアと、仕様を元にテストを設計して実施するペアに分かれたい。実装ペアは「テストペアにはバグを見つけさせない！」って自動テストや動作確認をしてからテストペアに渡して、テストペアは「絶対にバグを見つける！」って取り組むと、ここでバグを見つけやすくなる。
だから、システム化された部分以外も含んだ業務全体の運用をプロダクトマネージャーと一緒に考えたい。運用が回らない・ミスをしやすいというバグが見つけやすくなる。
それでも通り抜けてしまったバグを見つけるために「ただしく動いていたらどこがどうなる？」「ただしく動いてなかったらどこがどうなる？」って考えて監視を設計して実装したい。そうすると、ユーザーが気づくより先にバグを見つけて対応できる。
そんな風に全体の流れを見て、バグを生みにくくして、バグを見つけたいなと思っている。
