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