リスクベーステストの話をしましょう。これは取り扱いが難しいテーマです。そのため、品質分野でのキャリアは、気弱な人には向いていません。ソフトウェアを含むどの業界でも、コスト、品質、納期は常に対立しています。品質専門家は、このバランス取りで、重要な役割を果たします。そして、「アンバランス」になると、私たち品質専門家が悪者になることが多いです。少なくとも私たちはそう感じています。
長い間、私は自分を可哀想だと思っていました。なぜ私の仕事の難しさが理解してもらえないのだろう？コストや納期のために品質を犠牲にしそうな人と日々激しく戦い、真実と正義のために立ち上がって...って、悪役はいなかったので、私はスーパーヒーローではないですし、それほど劇的でもなかったんですが。品質と納期の完璧なバランスを保つのは本当に大変なんです！
でも、時間が経過し、テストに費やす時間と製品の品質の間に相関関係はないことが明らかになっていきました。気持ちが軽くなった？ そうでもないんです。品質の確保が容易になったという意味ではなく、「いつも同じようにいくわけではない」という意味です。複雑なんです。
品質保証はどれだけテストするかではなく、どのようにテストするかだということを学びました。正直、テストとは全く関係がないことがしょっちゅうです (これは今後のブログで詳しく説明します)。
Minitabでコスト、品質、納期のバランスをどの程度とるのでしょうか？ 非常に繊細にバランスをとります。私たちは毎回それを完璧に実行している、と言いたいところですが、そう言ってしまうと嘘になります。品質専門家に必要なものの1つは、厳格な正直さです。もう一度言います。品質改善専門家は、気弱な人には向いていません！しかし、Minitabは品質をとても重視しており、ここで働く誰もが継続的な品質改善に貢献しています。
この話題でたくさんのブログ記事を書けますが、リスクベーステスト (RBT) から始めます。機能やリリースには、ほぼ無限の数のテストケースがあるため、考えられるすべてのテストを実行すると、コストと時間の両方がかかってしまいます。品質専門家の役割は、どのテストを、どのぐらいの頻度で、どのように実行するかを判断することです。これは、私の製造業勤務時代にも当てはまります。抜き取り検査方式を採用していました。すべてを検査することはできませんでしたが、何を検査するかについてはとても賢明な決定ができていました。
私たちはMinitabでRBTを使用して、故障リスクに基づいたテスト戦略を立てます。故障リスクは発生度と影響度の関数で表されます。私たちの取り組みを支援ツールとして、Minitab Engageの故障モード影響解析 (FMEA) を活用しています。
私は1990年代初めに医療機器業界で働いていたときにFMEAを使い始めました。当時から大変役立ち、ほぼ20年経った今でも、私の頼りになるツールの1つです。もちろん、Engageにより、20年前よりも管理がはるかに簡単になりました。以下に示すように、FMEAは、深刻度、発生の頻度、検出の容易さに基づいて故障に優先順位を付けるのに役立ちます。この評価に基づいて、リスク軽減のための明確な戦略を特定し、実施することができます。
Minitabチームが作成したFMEAからの抜粋:
|
Step# |
Process Map - Activity |
Potential Failure Mode |
Potential Failure Effects |
SEV |
OCC |
Current Controls |
DET |
RPN |
|
10 |
Dialog Testing |
Access key validation isn’t automated for each dialog |
The hot keys are initially validated within development. If a developer makes a change that breaks a hot key assignment, it may not be immediately detected. |
3 |
2 |
Initial manual testing and follow up manual regression testing of changes for each dialog. General automated testing of access keys. |
5 |
30 |
|
Actions Recommended |
Responsibility |
Target End Date |
Actions Taken |
Actual End Date |
|
An evaluation will be done to determine if some automated testing can be performed |
JRoan (Test Architect) |
3/1/2011 |
Automated monitoring of dialog file to detect changes in assignments. |
2/15/2011 |
|
Revised metrics |
|||
|
SEV |
OCC |
DET |
RPN |
|
3 |
2 |
1 |
6 |
1) プロセスマップ - アクティビティで、各プロセス、機能、またはアクティビティの種類を入力します。上の例では、機能レベルでのダイアログテストです。
2) 潜在的故障モードで、各活動でプロセス故障の可能性がある点を特定します。多重故障モードが存在する可能性があります。上の例では、各ダイアログの各アクセスキーの機能を検証するためのテストスクリプトは実行していません。
3) 潜在的故障影響で、各故障モードの潜在的故障影響を入力します。どの故障モードでも、故障影響が複数ある可能性があります。上の潜在的故障は、(ダイアログが検証された後に) 開発者が変更を加え、その変更によってアクセスキーが破損した場合、故障が検出されない可能性があることです。
4) SEV (影響度評価) で、各故障の影響度を推定します。1～10の評価で、10は高、1は低を意味します。これは相対的な割り当てです。私たちの世界では、アクセスキーの影響度は、統計結果やグラフ結果などよりも低くなります。ここでは影響度評価3が割り当てられています。
5) OCC (発生度評価) で、原因の発生確率を推定します。1～10の評価で、10は高い頻度 (問題の継続的な発生が確実)、1は低い頻度 (発生する可能性が極めて低い) を意味します。この例では、最初の割り当て後にアクセスキーを変更する可能性は低いですが、ないわけではありません。それで、これに発生度評価2を割り当てました。
6) 現在の管理に、故障原因/モードの検出または管理方法を入力します。ダイアログテストでは、手動で各アクセスキーを検証し、アクセスキーの一般的な検証を自動化し、クイックテストを実行します。
7) DET (検出度評価) で、故障原因/モードを検出または管理するための各制御能力を評価します。1～10の評価で、10は低い検出/制御 (顧客が受け取る出力に欠陥があるのはほぼ確実)、1は高い検出/制御 (検出はほぼ信頼でき、通常、故障モード生成前に原因を発見できます) を意味します。この例では、問題が検出される確率は高くありませんでしたが、全体で手動テストが実行されたために問題が見つかる可能性があります。それで、これに検出度評価5を割り当てました。
8) RPNの評価: 危険度優先順位数 (RPN) は、SEV、OCC、DET評価の結果です。RPNは、モード/影響/原因の組み合わせの全体的な評価です。RPNが高いほど、潜在的な問題が深刻で、頻度が高く、管理が不十分で、早急な対応が必要であることを示しています。この例では、RPNは30で、自動化を実行できるかを評価し、判断することにしました。テストアーキテクトが、検出率を高める代替ソリューションを特定しました。
9) 是正処置を講じたら、新しいSEV、OCC、DET値を入力して、修正されたRPNを計算します。この例では、RPNは十分許容できる評価である6まで減りました！
Engageの優れたFMEA分析ツールを利用すれば、リスクベース評価と、その評価結果をもとに生み出されたテスト戦略を分析、管理、伝達することができます。上の例では、ファイルへの変更を品質保証に警告する自動システムが作成されました。これは、目下の問題に対する費用対効果の高いリスク軽減戦略でした。FMEAの仕組みによって、チームは分析を進め、決定の背後にある理由を文書化した記録として残すことができました。
FMEAも、このような決定の記録として保管して利用できます。これがあれば将来、「私たちがこのような決定をしたのはなぜだったか？」という話し合いをせずに済みます。品質専門家の方なら、これがどれほど助けになるか、よくわかるでしょう。私がFMEAを始めた20年前にもEngageが使えたらよかったのに！