品質基準をコントロールする？
「普通にテストするだけでも大変なのに、コントロールなんてできるのか？」
という疑問を持たれることもあるかもしれませんが、テストのボリュームは
設計とポリシーに依存するため、ここのバランスをコントロールしたうえで
調整するというやり方もあります。
今日はそんなお話です。
目標を決める
"品質は、経営者が決定するもの"、とは古くから言われてきましたが、
理由は、品質はタダではなく、保証にお金がかかるものであり、
そのリソースに出資するかどうかは経営判断だから、ということでもあります。
これを軽視したあまり、事故になってしまった例もあります。
また、国際的なソフトウェアカンパニーにおいても、QAを解散した結果、
品質がガタ落ちし、 1か月後に再度QAチームを編成し直した、
という話を聞くこともあります。
では、経営とも切っても切り離せない品質について、
どうやって目標を決めるのでしょうか？
これには、いくつかの基準があると思っていて、
- 最低限お客様が使えればよい
- 多種多様なお客様が使えなくてはならない
- 社内の人間が使えればあとは困らない
など、製品のユーザーに対しての品質要件から、必要なクライテリアを設定します。
例えば、一瞬見れば仕様としては足りるものであれば、複雑な操作はいらないかも
しれませんし、 十分に知識のあるエンジニアが使うのであれば、
すべてのコンパチビリティ環境で動作しなくてはいけないような、
過剰な品質はいらないでしょう。
ユーザーにとって必要十分な品質を想定し、それを守るための戦略を組み立てます。
その一つが、以前記述した、[自分のテストフレームワークを作ろう！]
にも載せた、マップがそれで、これはテストストラテジーに合わせてどういった
テストを当てるかのマップです。
（このマップは、どちらかというと戦術に近いものになります。）
どうやって品質をコントロールするか
さて今日のテーマの、「どうやって品質をコントロールするか」ですが、
最初にやることは、「守るべき品質を定める」です。
これには、
- 当たり前品質か、できれば品質か（狩野モデル）
- 夜も眠れない心配な事（インセプションデッキ）
など、テストしようとしている内容が、どのくらいシステムにとって
重要かを見通しておきます。
リスクコントロール
リスクを許容できる、「やらないこと」を決めることも大事です。
これは、IEEE29119でも重要視された内容です。
私は、
- プロジェクトリスク
- プロダクトリスク
- カンパニーリスク（29119外）
の3つを、テスト計画を作る際に決めています。
IEEE29119の説明は、このリンクが良いでしょう。
「やらないこと」を決めるということは、やらないことによるリスクを
判定しているわけで、 これをステークホルダーに共有し、合意を得ます。
スクラムの開発現場では、長い連携の中で、合意が重なって
不文憲法のような決まり方をしている場合もあります。
各チームのやり方で、守るべき品質と、守らない場合のリスクを整理しておきます。
リソースとの兼ね合いを見極める
こうして、「守るべき品質」が決まったら、実際に守っていく戦略を立てます。
これには、自分たちの手持ちのリソースの分析と、実際に手を動かしながら調整する
テストコントロールが鍵になります。
チームのテスト消化のスピードを確認する
とはいえ、無限に風呂敷を広げてテストを増やすわけにはいかないため、
どうしても守らなければいけないものを考えます。
普段のテスト消化率、スピードを把握し、全体のパフォーマンスを
母数として持っているうえで、以下の要点から、全体のQA活動を調整します。
テストの内容・かかる時間は不定ですから、私はシンプルに、
テストケースの消化数と時間の相関関係、テストの個別の難易度を、
テストの種類ごとに、普段のチームのパフォーマンスから見ています。
これと、作業に使える時間を計算して、どのくらいのテストができるかの
総量を見積もります。
テストの階層と品質の関係を見極める
クオリティコントロールのポイントの一つに、組み合わせテストの階層をどこまで見るか、
というのがあります。単純に、組み合わせが多いと、"組み合わせ爆発"という言葉が
あるように、テストの工数が膨大に膨れ上がってしまいます。
一方で、Web系製品の不具合は、複数の原因から起こる不具合が多いという
特徴がありますので、単純に減らすわけにはいきません。
組合せテストと、ユースケースのテストのバランスで、ボリュームを整えます。
そして、守るべき品質を確保するのに期日が足りない場合、
テストを削るか、スケジュールを伸ばすかの選択を求められるでしょう。
この際に、リスクを合わせて説明し、決定するための資料を作ることが
できるようになります。
テストの進捗をコントロールする
実際のテスト実行フェーズでは、意図せずインフルエンザが流行したり、
家族の体調不良など、不測の遅延リスクが発生することは通常の事です。
このため、テストケースの優先順位をつけて対処したり、リカバリープランを
常に柔軟に用意することになります。ここでも、先に決めておいたリスクについての
合意事項が判断の役に立ちます。
テストコントロールは、QAエンジニアとしては、わりと上級のスキルとなるでしょう。
こうして、クライテリアと現実的なリソースをコントロールしながら
リリースまで進めます。
用語解説
狩野モデル
QAエンジニアの間では、あまりにも有名。
品質には、当たり前に守られるべきものと、製品を使う動機になるような、
魅力的品質があるというお話。 論文は数千円から買えます。
https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB
クライテリア
ここでは、開発で守ると定めた基準。