※発表を聞きながら取っていたメモを元にしているため、誤りがあるかもしれません。あくまで個人のメモということでご了承いただければと思います。修正が必要な場合はDiscordのid:yocajiまでお知らせいただければ幸いです。
登壇者
Gojko Adzicさん
導入
測定できる(しやすい)メトリクスではなく、意思決定を起点として必要なことを測定するべき。
バグがないから品質が良いとは言えなくて、バグがあっても価値あるソフトはある。昔のWindowsとか。
品質のピラミッド
SUCCESSFUL
私たち(組織)にとってのアウトカム
USEFUL
ユーザーにとってのアウトカム
USABLE
PERFORMANT SECURE
DEPLOYABLE FUNCTIONALLY OK
すべて定量的に測定可能
1~2はデプロイされないと測定できない
たとえば2ではユーザーにどれだけ使われているかなどを見る
3~5はデプロイ前に測定可能
品質が十分と言えるラインがあり、それ以上上げても意味がない
QAはSUCCESSFUL、USEFUL、USABLEを測定する部分に関わらなくてはならない。ただし意思決定とは別で、プロダクトの意思決定はプロダクト側が行うべきで、QAは必要な情報を集め、意思決定をサポートする。
まとめ
MEASURE PRESENCE, not absence
測定するべきは存在することであり、存在しないことではない
Describe multiple QUALITIES
一つの品質(メトリクス)にとらわれず、複数の品質を見る
Trade-offs are a PRODUCT DECISION
トレードオフはプロダクトの意思決定
Shape priorities with a MODEL
モデルを使って優先順位をつける
VISUALISE and ACT
情報を可視化して行動する
感想
「リアルタイム」ってリアルタイムじゃないんかい、っていう行き違いの話がちょっと面白かった。こういう言葉の行き違いはどこでもある話なんだ。