テストの新たなアプローチ - レビュー(2)

原因と解決策を明らかにする

ここで、テストの新たなアプローチとして取り上げる「レビュー」は、、ドキュメントやコードなどの開発の成果物に対するレビューです。レビューを行う際のポイントは2つあります。1つは「テストの容易性を意識したレビュー」であり、これについては前回説明しました。もう1つは「欠陥分析結果のフィードバック」です。

皆さんは、「バグ、障害、欠陥、故障、不具合、エラー、問題……」といった言葉を使い分けているでしょうか? 開発中に見つかった問題は「障害処理票」や「バグレポート」として管理されているでしょうが、問題の構造を明らかにしていなければ、欠陥分析はままなりません。

一般にソフトウェアエンジニアリングの世界では、問題の構造を「故障～欠陥～エラーの因果関係」(図1)のようにとらえます(注:この分類は代表的なものですが、標準により異なって定義されていることがあります)。この場合、帳票の印字が間違っている、計算結果に誤りがある、特定のオペレーションで画面が固まる(あるプログラムがABENDする)など、ユーザーレベルで問題としてとらえられる現象を「故障」として扱います。

一方「欠陥」は、故障としては見えていない状況です(ただしワーニングメッセージとしてログに出力されることはあります<※2>)。

エラーは欠陥の元となるコード中の間違いやアルゴリズムの問題、データやパラメータの問題といった欠陥の芽となる要因です。単独のエラーが単独の欠陥そして故障に結び付くことがあれば、複数のエラーや欠陥が複合して故障に至ることがあります(逆に、故障に至らないこともあり得ます)。

このように、故障、欠陥、エラーには因果関係があるため、分析するといってもきちんと整理しないと、問題の構造は明らかになりません。つまり、レビューで欠陥分析結果を生かすためには、不具合(あえて抽象化するために「不具合」と表現します)がどのようなメカニズムで発生したか、どのような原因があるのかが分析できていなくてはなりません。 現実的な分析ができているのであれば、過去のテストで摘出した欠陥分析から得られた知見を、現在または将来の開発でのレビューで大いに生かすことができるようになるのです。

※2 ISTQBの用語集では「欠陥」を「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備。例えば、不正な命令またはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす」と定義しています。

執筆者プロフィール

大西建児 (Kenji Onishi)
株式会社豆蔵 シニアコンサルタント。国内電機メーカー、外資系通信機器ベンダーで培ったテストや品質保証などの経験を生かし、テスト手法や技術の普及、発展に取り組む。NPO法人ソフトウェアテスト技術振興協会(ASTER)副理事長。JaSST’08東京 共同実行委員長。著書に「ステップアップのためのソフトウェアテスト実践ガイド」(日経BP社)などがある。

『出典:システム開発ジャーナル Vol.3(2008年3月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。