連載
» 2004年12月01日 12時00分 UPDATE

開発プロセス再入門(8):ソフトウェアの不具合を追跡するには (1/3)

 不具合の追跡プロセスはソフトウェア開発の下流工程では非常に重要なもので、それはそのままソフトウェア開発の下流工程を規定するものといっても過言ではありません。不具合は、一般に開発者とQAの間で、不具合報告書(PR:Problem Report)をやり取りしながら管理することになります。今回は、不具合の状態と処理方法に注目し、不具合を追跡するプロセスについて説明します。

[津田義史(豆蔵),@IT]

不具合とは

 ソフトウェアが意図もしくは期待したとおりに動作しないことを指して不具合といいます。面白いことに、ソフトウェアの「不具合」にはいろいろな別名があります。

  • 不具合
  • 障害
  • 欠陥
  • 故障
  • 不備
  • バグ
  • エラー
  • 仕様

  これらはすべて、同じソフトウェアの「不具合」を指す用語として使われることがあります。ただし、ドメインによっては、ソフトウェアの不具合の種類により、これらの別名を使い分けることもあります。仕様どおりに実装できていない不具合、実装は仕様どおりだが仕様そのものが妥当でなかった不具合、エンドユーザーにリリース後、システムが運用中のときに発見された不具合、といった側面で不具合を分類し、呼び名を使い分けるということです。

 特に、日本企業では「バグ」という言葉が嫌われる傾向にあるようです。というのも、「バグ」は顧客に対して無償の奉仕活動をして修正しなければならないもの、というイメージ(商慣習?)があるからです。確かに、その不具合が「バグ」ではなくて「仕様」だとすれば、この仕様(要求)変更に必要なコストを顧客に請求することができるかもしれません。このような観点から「バグ」と「仕様」を区別することは価値がありますが、困難を伴います。

 この問題は、私が説明したいことではありませんので、この文章中では「バグ」と「仕様」の区別についてはこれ以上言及しません。以下、ソフトウェアに潜んでいる問題を総称して「不具合」と呼ぶことにします。

不具合の発見と文書化

 ソフトウェアの中に潜在的に含まれている不具合は、これをすべて発見し、目に見える形に文書化する必要があります。この文書のことを不具合報告書といいます。一般に、文書化して管理しなければならないのは、きちんとビルド番号が管理された(つまりQAにリリースされた)ビルドの不具合だけです。開発者が開発中のビルドで見つけた不具合は、文書化する必要はありません。というのは、その不具合はその開発者の開発環境だけで発生するものかもしれないからです。開発者は、その不具合をいちいち文書化することなく、次のビルドまでにこっそり直してください。ただし、QAにリリース済みのビルドにおいても同じ不具合があると考えられる場合や、すぐに修正できるめどが立たない場合、その不具合の再現手順にテストケースとしての価値が認められるような場合もあります。このようなときは、その不具合がリリース済みのビルドでも再現することを確認したうえで、開発者が自分で(あるいはQAに依頼して)不具合報告書を記述しておくとよいでしょう。

 将来のビルドで実装予定の機能や、既知の不具合については、QAによるテストが実施されないように、開発者がリリースノートに制限事項として文書化しておきます。これにより、既知の不具合を、それを知らないQAが再発見して文書化してしまう無駄を避けられます。開発者には、未実装の機能や既知の不具合をQAに伝える義務があります。この義務を果たすために、開発者とQA間のコミュニケーションツールとして、リリースノートを利用するわけです。ただし、QAにより未実装の機能が不具合として報告されてしまっても、開発者はそれほど困りません。検証可能な仕様(テストケース)を段階的に追加・詳細化してもらったのですから、むしろ感謝すべきことです。ある機能が未実装であることを確認する手順を先に記述しておくことは、テストファーストという観点からも有用です。

 不具合を発見するための具体的なテスティングのプロセスは、この文章の中では説明しません。モデリングの技術が開発者の職人技であるのと同じく、テスティングの技術はQAの職人技に依存するものであって、複数のロールから構成され、属人的なものを排した開発プロセスとは直交するものだからです。もちろん、モデリングがそうであるように、テスティングもソフトウェア開発におけるアクティビティの1つですが、その具体的な匠(たくみ)の技はこの文章中で説明すべきことではなさそうです。これらについて詳しく知りたい方には、テストの技法に関する書籍の一読をお勧めします。

 以下、不具合報告書として文書化することができた不具合を管理するプロセスについて説明します。

       1|2|3 次のページへ

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ