システムの開発に関わるようになったばかりの頃に「QA」という言葉を覚えました。Quality Assurance のことで、日本語では一般的に品質保証と言われます。

ものづくりをする人たちは誰でも多かれ少なかれ質の良いものをつくりたいと考えていると思いますが、ではその品質を「保証する」にはどうすればよいのでしょうか。品質保証は担当者に任せて自分は作りたいものを作ろう…と何となくQAから目をそむけてきた人(ワタシです)にこそ初めてほしいQAとは。その大切さ、その方法とは。

今回はそんなお話。

※以降では品質を保証する作業を「評価」と呼び、それをする人を「評価者」と呼びます。

評価観点という考え方

新規機能開発・機能追加・不具合修正など何らかの開発をした際に、

  1. それが意図通りに動くものであり
  2. 他の既存機能に影響を与えていない(デグレしていない)こと

を保証することが最低限の品質保証です。
これに加えて製品のポリシーがあれば(例えば「全機能のレスポンスは500ms以内」や「全機能オフライン対応」など)、それも併せて保証することが必要になります。

ここで最も大切なことは、どんな評価をすれば品質が保証されるのかという評価観点を正しく定義できているかどうかです。これをできるだけ正確で具体的に定義することで、評価をスムーズに進めやすくなります。どこをどうテストすればいいか、逆にどこはテストしなくていいかが明確になるからです。

同時に、エンドユーザーや開発者へもメリットを与えることができます。
例えば評価観点がそのままリリースノートに表記する内容になったり、テスト中にバグが見つかった場合に「このバグは今回担保する品質に含まれるものか」と立ち返り判断をすることができたりします。逆に言えば、リリースノートに「バグの改善」と曖昧にしか書かれていなければユーザーは「まだバグがあるじゃん！こっちは直してないのかよ！」と不満を感じてしまうかもしれませんし、開発者はテスト中に次から次へと出て来るバグに見境なく対応しなければならない状況に陥るかもしれません。

このように、評価観点をどれだけ明確にし、そして共通言語化できるかが、QA全体の良し悪しに大きく関わってきます。

「既存機能に影響がないこと」をどこまで確認するか

いわゆるデグレチェックというものです。これをどこまでやるかはリリーススピードとのトレードオフになると思いますが、ある程度しっかりしておいたほうがいいことが多いです。だって「今まで普通に使えていた機能が動かなくなる」というのはユーザーにとってすごく悲しいことじゃあないですか。

エンタープライズの世界では、一度リリースされた機能は業務の中で使われます。言い換えれば、その機能により業務が回っています。それがデグレを起こすとユーザーの業務がとまったり、最悪の場合損害が発生します。だからデグレを起こさないように徹底して評価することが必要になる場面があります。

逆にコンシューマの世界では、デグレが見つかったらすぐ直すことが大事だったりします。今まで使ってた機能が動かなくなった…ってTwitterで呟いたらすぐに解消された！という速度感が信頼を生むこともあります。もちろんデグレが一切なくそもそも不満を与えないことがベストですが、バグゼロリリースというのは現実的ではありませんしそのために評価に時間をかけすぎるとリリーススピードが犠牲になってしまいます。

このように状況に応じた程度の差こそあれ、デグレチェックをするということは品質を担保する上で重要なこととなります。

評価観点のつくりかた

実はこれは難しいことではありません。新規開発や機能追加であれば、その仕様を明確に定義することが、そのまま評価観点を定義することになります。不具合修正であれば、どんな問題がどうなったら解消されたと言えるのかを定義することが評価観点の定義になります。

開発者(つくる人)にできること

  • 評価観点の定義・提案
  • 影響範囲の調査
  • ディシジョンテーブルの作成

どんな評価観点にすべきかは、仕様を決めた人、仕様を満たすように実装した人が一番良く知っています。彼らが評価観点のたたき台をつくるといい感じになると思います。また、デグレチェックのための影響範囲の調査はソースを書いた人の責務です。

ソースの分岐を網羅するために必要なディシジョンテーブルの作成も、ソースを読み書きした人がするのが最適なのは言わずもがな。

評価者にできること

  • 評価観点の定義
  • シナリオの設計
  • ディシジョンテーブルの作成

機能の品質を保証することについて責任を持つ人が、最終的に評価観点を確定させることになると思います。そして評価者がもっとも考えるべきことはシナリオテストでしょう。ユーザがどのように使うかというシナリオを設計しそのシナリオが回ることで品質が保証される、という考え方です。シナリオに出てくる条件に応じたディシジョンテーブルがテストケースを書き出す上で必要になることもきっとあります。このシナリオは、企画段階のペルソナや行動パターンをより具体的・網羅的にしたもの、というイメージです。

できあがったテストケースを開発者と評価者とその他有識者で読み合って、観点や影響範囲の抜け漏れを確認したりなんかすると、より良い感じですね。和気あいあいとできたら最高です。

まとめ

大事なことは2つ

  • 評価観点をつくるといいよ！
  • デグレチェックについて吟味するといいよ！

開発者にできること

ソースを知っている人が評価観点の提案と影響範囲の調査するといいよ！

評価者にできること

ユーザのシナリオを具体的・網羅的に設計するといいよ！「十分に網羅された」と判断する基準がどこにあるかを考えると自然と網羅性が高まるよ！