私のテストはバグを出すことが中心ではなくて
— リナ? (@____rina____) 2017年8月9日
エンジニアが作るプロダクトの細部まで意図があるかどうか、お客さまに提供できるかを確認するための時間
て感じなんだと思う(その中にバグも探すけどそこに重きを置いてないかも)
ふんわりと書いてしまったので、(・∀・)イイネ!!してくれた方それぞれの想いがあるんだろうなと思っています。
私自身が思っていることを今回エントリしてみようかな。と思います。
エンジニアが作るプロダクトの細部まで意図があるか
意図ってなんだろう
色んな意図があるかなーと思います。たとえば、
- 各画面タイトルの命名規則が一定であるか
- タイトルとメニューの関連性に一定の規則があるか
意図って、「これって何でこんな作りにしてるんだっけ?」て質問にエンジニアが答えられるかどうか
「何となくつくりました」ではない答えがあるかどうか かなー
そのためには「なんで」と思う力が私には必要かもしれないし
なんでの答えが明らかなものは聞かないとか
ある程度予測できる疑問まで落とし込めるか(issueになんでなんでじゃエンジニアも困っちゃう)とか
この例の場合、「上のメニューはXXの視点で見ると、この名前がいいと思ってつけた」とか「つい左メニューは上メニューのことを考えずにつけちゃった」とかあると思うので
テストするときに、そのどちらかなんだろうなーと思えるようになることが大事だと思っています。
(もちろん外すときもあるけど)
お客さまに提供できるか
数値目標やメトリクスで一目瞭然なのかもしれませんが
まずは、私が最初の利用者として提供してもいいレベルかどうかを体感しています。
(といっても、私は出荷判断をしていません)
例えば、なんか動き(UIかな)が変って思ったときに、
お客さまが使うなら、どういう動きだったり、配置だったり、色だったり、言葉だと
やりたいことができるかな?と考えます。
考えながら動かすときと、変だなと思ったときに「どうあるべきか」を考えてIssueに書きます。
そこまで最初から設計書にあると悩む時間がもったいないかもしれません(なので、最近は画面レビューもするようにしています)
テストが終わった時点でそのプロダクトのファン1号はきっと私
私は自社が提供するプロダクトの8割前後をテストしています。
分母が難しいけど、新規プロダクトで機能テストが必要なものの場合は
ほぼ私は一度は触っているはず・・・です。
上に書いたように、私が満足するためのことを可能な限り詰め込んだプロダクトができあがっているはずなので
リリースや納品するときに、私はそのプロダクトのファン第一号であることが大半であると思っています。
とはいえ、リリースする頃には他のプロダクトのテストをしているので
エンジニアに私のプロダクト愛があんまり届いてないなぁと前前から思っていました。
私自身も、プロダクト愛あるんだけどなーなんでだっけー?と思っていたので
今回気持ちの整理ができました。
これはQA活動とか品質マネジメントというのか
うーん、わからない
きっと一部ではそうかもしれないし、そうでないかもしれない。