思ってたんと違う!をふせぎたい。Mitsuyuki.Shiibaスマートフォン用の表示で見るMitsuyuki.Shiiba2015-12-02テスト呑み。思ってたんと違う!をふせぎたい。Testingテスト呑み昨日はこざけさんとぽざさんとテストの話をしようと集まってデータベースの話をしてました。(あれ?)二人のおかげで色々頭の中が整理できてきたので。今、自分がやってることを出力しておこうかなと。どこから話をしたらいいのかな。開発の流れに沿ってみようかな。Spec最初にプロダクトオーナーチームが機能概要のドキュメントをConfluenceに書きます。僕のチームではこれをSpecと呼んだり、FeatureSpecと呼んだりします。ビジネス側の人が「こんなことができるといいな」って、ざっくりとした想いを語ってくれていて。それをプロダクトオーナーチームが、FeatureSpecという開発可能な単位に落としこみます。プロダクトオーナーチームは、ビジネスオーナーとプロデューサーとディレクターとエンジニアで組んでてプロデューサーが取りまとめてる感じ。このSpecには「なぜ作るの?」と「何を作るの?」が書いてあります。誰が、何をすることができる機能なのか。それでその人は何が嬉しいのか。それをその人が使ってくれることで、会社としては何が嬉しいのか。中で、今回システム化するターゲットはどこか。作るものそのために、何を作るのか。指標この機能をリリースすることによって、どのような数字が、どうなるはずなのか。そのために追いかけるべき指標は何か。SpecTestそして、このSpecに対する受け入れテストを考えます。「作るもの」のテストかな。いうところがこうなってたらOKだと言えるよね?っての。あと、こういう指標が取れますよ、っての。ここはプロダクトオーナーチームとの認識合わせのためのテストなのでシステム化とか自動化とかしてなくて、Confluenceに書いてます。技術的な詳細にはここでは踏み込まずに、あくまでもビジネス目線で考えます。実際のビジネス運用を担当される方や、プロデューサーの目線で見て意味があるテスト。「こういうの作るってことで良い?」って一緒に読み合わせします。できるだけ具体的なデータを使って、実際の運用を想像できるようにしてます。あと、気になることがある場合はその部分をわざと強調したデータにしたりします。したら「あれ?ここちょっと認識違ってた!」みたいなんがポロポロと出てくるので潰していきます。最終的にはみんなが「これがOKだったらOKだね」って言える状態にしていきます。SpecTestの実施まずはプロトタイプを見てもらってテスト。受け入れテストって「やってもらうの難しいなー」って思ってたんだけど、最近は「やってもらう」から難しいんかなって考えるようになって「一緒にやる」って感じにしてます。スプリントレビューのときに、そのページを見せながらアプリを見せて、これOKですね?これもOKですね?これは思っていた通りですか?もっと良い案が思い浮かびましたか?みたいな話をします。したらだいたい「あー、この前はこう言ったけど、実際に見てみたらこういう感じがいいかも」とか出てくる。このプロトタイプでOKだなってなったら本実装に入ります。