今回からはテスト入門ハンドブックで解説している「品質とは何か」「品質を上げるためには」を紹介したいと思います。
魅力的な品質を提供する大切さ
システム品質を向上する手段として第三者によるテストおよび検証サービスが重要な役割を担っています。というのは、開発者視点でのテストの“思い込み”リスクを回避し、第三者が標準手法に則りテスト項目を作成・実施することがシステム品質の維持・向上につながるからです。 システム品質が悪いとどうなるか。「レスポンスが遅い」「使いにくい」「動かない」「機能が分からない」などのクレームになります。クレームは解消しなければいけませんので、システムのバグや不具合の改修を行うことになります。 ちなみに、システムのバグに気付くタイミングと、それを修正するためにかかるコストは「1：10：100の法則」があるといわれています。それは、設計の段階でミスを修正したコストを1とすると、テスト時に見つかったバグを直すコストは10倍に、運用時にバグが発生し、それを修正するには設計時の100倍かかるというものです。つまり、開発の初期段階でバグや不具合を排除しておけば、無駄な修正コストと工数がかからなくなることがわかります。
システムの品質とは
それでは、「システムの品質」とは何を指すのでしょうか。品質といっても様々な捉え方がありますので、共通の認識が必要になります。そこで私たちが提供する「ソフトウェアテストのコツ ハンドブック」では、国際規格のISO/IEC25000：2005、ISO/IEC9126が定義している品質特性を利用しています。そして、IT利用者が享受する「利用時の品質」とシステム保持者（ユーザー）と開発者向けの「外部および内部品質」をベースに解説しています。 まず利用時の品質を見てみましょう。それには「有効性」「生産性」「安全性」「満足性」の4つの能力を定義しています。IT利用者がソフトを業務で使用したときに、有効性は「業務上の目標を達成できる能力」、生産性は「有効性に掲げた品質を達成する能力」、安全性は「リスクの許容水準を達成する能力」、そして満足性は「ユーザーを満足させる能力」を表します。 一方の外部および内部品質として「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」の6項目がありますが、例えば機能性はソフトウェアがユーザーニーズを満たす能力をいいます。保守性はバグの修正や実行環境の変更、機能変更などにおいて保守のしやすさを指します。
品質の定義
品質特性を定義したとしても、どうしても品質は感覚的かつ抽象的に捉えられてしまうものです。なぜならシステムによって千差万別で「これが正解」というものがないからです。そこで品質の内容を「当り前品質」「魅力的品質」「一元的品質」「無関心品質」「矛盾品質」といった形で表して、品質に対するある程度の捉え方を明確にしようという動きもあります。具体的には、当り前品質は不充足であれば不満を感じるが、充足されても当り前と感じる品質項目－など、できるだけ品質の要素を分かりやすく捉えようというわけです。そうすることで発注者であるユーザーにもテストの項目をイメージしやすくし、品質向上への取組みがわかるようにしていきます。 これらは詳しくはハンドブックで解説していますので、興味のある方は＜ダウンロードページ＞からダウンロードしてください。
次回はテストで品質を向上できるかについて触れてみます。 ありがとうございました。