品質のレイヤーとテストとQA

「品質」について話すときに、人によって言ってることが噛み合ってない感じがしてもどかしくなることはありませんか？

自分なりに、品質には階層があって、どう影響し合うかというのを絵にしてみたくなりました。

で、テストがQA的になるって話に繋げてみます。

※ ここから下に書いてるのは、「私はそう考える」ってだけでどこかで定義されたことではないですのでご注意ください。

で、描いてみた絵がこのツイートです。

pic.twitter.com/7Gok0MahMX

— yttelab_official (@yttelab) October 16, 2021

ユーザの品質体験
　

→例：狩野モデル　
　　魅力的品質とか当たり前品質とかです。ググると狩野モデルについてはいっぱい情報あると思います。

この品質は、時間とともに変わります、最初は魅力的品質に相当することでも時間が経てば、当たり前品質になります。例えばスマホのスワイプ入力とかフリック入力って、出た当初は「スゲー」ってなりましたが、今では当たり前です。

プロダクトの品質　

→例：ISO25010、FURPS＋　
　　機能、性能、セキュリティ、フォールトトレランス、ユーザビリティ、保守性とか

ユーザーの品質体験とプロダクトの品質は単純に１：１にはなりません。例えば、「新しいこの機能がサクサク動く」というような機能性と性能の組み合わせで品質体験が良くなるといった感じです。つまり、プロダクトの品質の組み合わせでユーザの品質体験が変わります。

開発の品質作り込み段階

　→要件品質、設計品質、コード品質とか。

コードでロジックミスをしない、設計でモジュール間のデータの受け渡しの不整合が出ないといったことで最終的に機能性が充足されます。つまり開発の各段階の品質の積み重ねでプロダクトの品質が変わります。

品質作り込み段階の最上位にある要件の品質だけでプロダクトの品質は決まりません。機能や性能のように、要件品質で決まるものもあるし、保守性やテスト容易性のように、設計品質やコード品質で決まるものもあります。

そして、プロダクトの品質と品質の作り込み段階も、単純に１：１にはなりません。例えば、性能要件は、要件としてちゃんと定義されていることで品質が確認できますが、処理を速くする責務をどこに持たせるかという設計品質が要件品質を実現する重要なカギになったり、SQLを書くときの副問い合わせの書き方で決まる場合（つまりコード品質）もあります。

品質の作り込みの段階に合わせたテスト

これをテストレベルやテストピラミッドっていいます。

この段階ごとに作り込まれる品質を適切なタイミングで確認することをテストレベルとか言います。コードに問題があるかどうかはコードを書いた直後にテストした方が誰が書いたコードかがすぐ分かり（統合しちゃうと誰の書いたコードのせいなのか切り分けが必要になりますし、それを誰がやるの？ってなります）、そのエンジニアも書いたコードのことをよくわかっているので原因が特定しやすくなります。（コードを書いたその日であればわかることも２週間後に言われても思い出すのも大変ですよね？）修正が早くできることが適切なタイミングで確認をするということです。

これをバインディングタイムを短くすると言います。バインディングタイムを短くするとフィードバックが早くなり、結果的に手戻りが減ります。

単純に決まらないからテストも頭を使う

ただし、コードの品質が良い（段階）＝機能品質が良い（プロダクト品質）＝当たり前品質（ユーザー品質体験）が良いって単純に決まらないというのがここで言いたい話です。

もちろんコードの品質はよくしたほうがいいに決まっています。ただ、それがユーザー品質体験に直結するかは別の話だということです。おまけにプロダクトの品質にはトレードオフがあります。セキュリティを強固にしすぎると使い勝手が落ちるとか、性能を上げすぎて保守性が落ちるとかが有名です。

なので、テストレベル（ユニットテストやAPIテスト）を分けてしっかり行うことは当然大事なのですが、プロダクト品質のどれを確認しているのか？とか、ユーザー品質体験のどれを確認しているのか？ってことを決めて何をどこまでテストするって考えるのもとっても大事になります。

テストも頭を使うとQAに役立てることができる

どういうタイミングでQAのテストまで行うかを考えてチームで共有していくとリリース判断にも役立つようになります。そこまでやると単にテストをするだけではないQAとしての価値が出てくるのではないかと思っています。

例えば「このユーザー体験が今回のリリースのキモなんだよなー」っていうのがあれば、そのユーザー体験をテストできるように先に開発してもらう。そして完全にはできてなくても、そのユーザー体験がわかるのであれば、部分的に統合テスト（API通信レベルでテストする）やシステムテストをやるっていうやり方でもバインディングタイムを短くすることができます。バインディングタイムを短くするとフィードバックが早くなり、結果的に手戻りが減るって書きましたが、さらに、リリース判断を早くできるってメリットも出てきます。このユーザー体験がQAできてるのであれば、他の機能がまだできてなくてもABテストしてみよう、とか、ベータリリースしてみようって判断ができるようになります。

逆からこういう話にもできるかもしれません。ABテストから始めたい、ドッグフーディングやベータリリースとだんだんに品質をあげていきたいってときに、「どうテストを組み立てればリリース毎の品質を考えて適切な量のテストになるか」って考えるのは、テストというより、QAとしての発想なのではないかと思います。

以上