ホーム » ソフトウェア品質 » 「不具合管理」を見てみる

「不具合管理」を見てみる

記事の納期に遅延が発生して申し訳ありません。

1. はじめに

本稿は、「SQuBOK V2読破会」メンバによるAdvent Calendar 2015になります。
http://www.adventar.org/calendars/1020

今回が第11日目となります。
メンバ執筆も、2週めに入り、温まってきた・・・のだろうか?

筆者は、バグレポートを改善を目的としたコミュニティに所属しています。
https://sites.google.com/site/swworstpracticesite/

コミュニティの活動成果などを、JaSSTSQiPシンポジウムなどで発表してきました。そのなかでいろいろな文献などを調査してきました。このようなことから、今回は、SQuBOK V2のなかの「不具合管理」の記載を見てみるとともに、実際に業務で有効に使うために役に立ちそうな書籍や文献を考えてみたいと思います。

2. 「SQuBOK V2」のなかの「不具合管理」

「不具合管理」については、「2.11 構成管理」(142ページ)の中で説明されています。「構成管理」の中にくくられており、「変更管理」「バージョン管理」とならび、「不具合管理」(146ページ)と説明されています。146ページから147ページのなかの半ページほどという程度の説明になっています。「不具合管理」について以下のように説明されています。

1. 現象の再現と調査
2. 対応時には変更管理とバージョン管理を同時に行う

さらには、「不具合管理」ではステータス管理が必要であることが述べられています。また、不具合は、複数検出されることが多いため、対応の優先順位を決める必要性も説明されています。
ところで、「構成管理のアンチパターン」が参考文献として紹介されています。書籍は入手し読んでいます。まだ熟読はできていないのですが、「不具合管理」そのものというより「構成管理」のアンチパターン(やってはいけないパターン)についての説明に思いました。「不具合管理」の参考文献としてあげられているのはどのような理由か、少し気になりました。

3. お仕事で使うために

SQuBOK V2の中では、上記2章のように説明されていますが、お仕事で活用するためには、この記載だけでは十分ではないように思います。そこで実際にお仕事で役に立つと思われる文献などを示したいと思います。

3.1 「ソフトウェアエンジニアリング基礎知識体系(SWEBOK V3)」

SQuBOK V2の関連文献として、紹介されています。SWEBOK V3では、大きく2か所
に、「不具合管理」に類する記載があるように思います。
まず、「第4章 ソフトウェアテスティング」「5. テストプロセス」の「5.2 テストアクティビティ」で、「5.2.6 問題報告/テストログ」「2.6.7 欠陥追跡」の項に説明があります。
もう1つは、「第6章 ソフトウェア構成管理」「3.1 ソフトウェア構成コントロール」です。SQuBOK V2と比較すると、テスティングの時の「不具合管理」が、もう少し詳細に記述されているように思います。
「ソフトウェア構成コントロール」は、SQuBOK V2とほぼ同じ内容を表現を変えて説明されている印象でした。テクニカルタームが、SQuBOK V2よりやや多い感じなので、人によっては少し読みにくいかもしれません。
SQuBOK V2の「不具合管理」には、「テスティング」との関係が明示されていないように思います。「不具合」の定義に含まれていて抽象度をあげているように思います。そのあたりが、SWEBOK V3では少し掘り下げられているように思いました。SWEBOK V3を合わせて読むともう少し深く理解ができると思います。

 3.2 「ソフトウェアテスト 293の鉄則」

個人的には、テスティングに関わる人すべてが読む本だと思います。「第4章 バグ報告」が「不具合管理」に関係が深いと思います。
読み物に近いため、BOK(知識体系)のように、規格や文献などの話は薄いのです。しかし経験ベースで書かれているものが多いため、実務に役立つTips的な事例、テストエンジニアとしての心構え、振る舞いが詰まっている内容だと思います。

 3.3 「Bug Advocacy」

「3.2 ソフトウェアテスト 293の鉄則」のオリジナルの著者の1人である、Cem Kanerらが著した書籍です。バグ報告に関する改善、注意点、ふるまい、心構えなどの講義資料などをまとめた内容になっています。一言で強引にまとめると、「「ソフトウェアテスト 293の鉄則」の「第4章 バグ報報告」を、論理的に体系的に説明している内容」と思います。バグレポートにかかわる人すべてが一度は目を通す本だと思います。
バグレポートの報告や改善の重要なポイントとして “RIMGEN” としてまとめられています。ちなみに、R(Replicate),I(Isolate),M(Maximize),G(Generalize),E(External),(Neutral)の頭文字になってます。また、開発者に調査を渋られる、拒否されるバグレポートはどのようなものか、やそれらの取るべき対応などがまとめられています。

 3.4 「TPI NEXT ビジネス主導のテストプロセス改善」

テストプロセス改善について書かれている本です。テストプロセスを16のキーエリア(領域)に分けて、それぞれのキーエリアについて評価を行ない、キーエリアの改善することでテストプロセスの改善を行おうとするものです。16のキーエリアには、「テスト戦略」「テスト組織」「コミュニケーション」「メトリクス」「テストケース設計」「テストツール」などがあります。こうした中に「欠陥管理」という領域があり、これが「不具合管理」にかかわるものと考えます。
「TPI NEXT」では、レベル(「コントロールレベル」、「効率化レベル」、「最適化レベル」:右に行くほど成熟度が高い)が定義されています。「欠陥管理」では、「バグが管理されているか?」「バグの特徴分析ができているか?」「バグの未然防止に利用できているか?」という内容になっています。
また「TPI NEXT」には、「基本クラスタ」というものが定義されており、まずこれに沿ってテストプロセス改善を進めたらどうか?というプロセス改善モデルがある。その基本クラスタにおいて、「欠陥管理」は、「コントロールレベル」の2ブロックに位置されています。これは、「欠陥管理」はかなり早期に改善を行なうべき重要なキーエリアであると考えられます。バグレポートの改善を行なう際には参考になる点が多いと思いました。

 3.5 JSTQB Advanced Level シラバス

JSTQBは、「ソフトウェアテスト技術者資格」の認定を行ない組織です。この組織が、ソフトウェアテスト技術者に必要なレベル、ロールやスキル内容をもとに学習するべき内容をきめたもの(シラバス)を公開しています。
JSTQBには、Fundationレベル、Advancedレベル、Expertレベルの3つがあります。(ただし、日本で試験が実施されているのは、Fundationレベル、Advancedレベルの2つです)。それぞれ、初級者、中級者というように分けられています。
Advancedレベルには、3つのロールがあり、それぞれ「テストマネジャー」「テストアナリスト」「テクニカルテストアナリスト」が定義されています。
「不具合管理」は、JSTQBでは、「欠陥マネジメント」が該当する個所と考えられます。JSTQB Advanced Levelでは、テストマネジャーとテストアナリストで「欠陥マネジメント」のスキルが定義されています。テストアナリストでは、「欠陥の分類体系を設計する」、テストマネジャーでは、「欠陥のライフサイクルのマネジメント、プロセス能力の評価」などが求められる内容となっています。
ソフトウェア開発のロールにおいて、どのようなスキルや能力が必要かを記載している点が「SQuBOK V2」と異なる点だと考えます。

4. バグレポート1件の報告時間はどれくらいなのか?(Twitterによる調査)

ふと、バグレポート1件にかけられる時間はどれくらいか?ということが気になりました。そこで、Twitterで最近実装された「アンケート機能」を使い、1件につきどれくらい時間をかけられるのか調査を行ないました。なお、アンケート機能は、無記名で情報を収集しています。簡易的な機能であるため、詳細な背景や情報は収集できません。組織やプロダクトの特性、ドメインなどによって様々な回答が想定できますが、今回は収集していません。
今回は35件の回答を得たました。結果は以下の通りです。

twitter_アンケート

もっとも回答が多かったのは、「10分くらい」というものである。これは予想の範囲で
ある。筆者の経験でも、それくらいの印象である。
次に多かったのは、20分以上かかるケースがあることである。これは予想外であった。もう少し、少ないのではないかと思っていた。
5分でも多いと思っている人と、20分以上かかる人の違いが気になってきました。BTSかExcelかではあまり違いはでないような気がします。Toolsそのものの問題ではない、と思います。Twitterによる簡易調査なのであまり詳しくわかりませんが、Twitter、Facebookからいただいた意見を参考にしながら考えると、以下のような要因が考えられます。

  • テストレベル
    CT(コンポーネントテスト)、IT(統合テスト)、ST(システムテスト)では  バグレポートの報告に要する時間が異なるのではないかという意見をいただいた。筆者は品質保証部門に所属しているため、総合テスト以降の上位レベルのテストにかかわっていることが多いためアンケート開始時にはすぐに思い至らなかったが、影響はありそうである。
  • ドキュメント(テストベース、テストケースの記載の粒度など)
    きちんとしていないドキュメントから、バグレポートを作成するのは、確認事項などが多くなるため、作成時間が多くなることが想定されます。
  • ドメイン
    金融系システムなどは、問題が発生したときに監督省庁などから監査がはいることがあるため、ドキュメントも監査時にわかるような内容や粒度で作成する、とどこかで聞いたことがあります。そうしたことから、関係者の多さと求められる記載レベルなどが影響を与えそうです。組込み系も、上位レベルのテストは、調査などに手間がかかり時間がかかるような気がします。このあたりは根拠がなく想定になりますが。
  • バグレポートのステークホルダーの量と質
    上述の内容と少し重複しますが、バグレポートは、だれが見るのか?見る人が理解できるのか?を考慮する必要があります。そのため、見る人の理解力やわかる用語をあわせて記載する必要があることから、ステークホルダーが多ければ多いほど記載内容や表現、エビデンスを考える必要があるため、バグレポートの作成時間に影響がありそうです。
  • その他特別な運用
    オフショア先(例えば中国、ベトナムなど)が理解できるように英訳する必要がある、という意見をいただきました。そうした、組織やプロジェクトに固有な運用ルールも時間がかかる要因になりそうです。

機会があれば、使いやすいBTSをつくることを考える、ために調査したいと思います。

5. さいごに

今回は、「不具合管理」が、SQuBOK V2ではどのように説明されているか、ということと、不具合管理を実務で使えるようにするための書籍や文献、Twitterでの調査結果を書いてました。
みなさまの「バグや問題との戦い」の参考になれば幸いです。

F.おまけ

コミュニティのメンバ全員で、バグレポート改善にまつわることをテーマとして記事を書きました。寄稿先は、Software Testing ManiaX という同人誌です。次の冬コミ(2015/12/31)に頒布されます。今回で10巻めになります。

第10巻では、以下のような記事を執筆しました。

  • 「Bug advocacy」の紹介
  • 「TPI NEXT」「JSTQB Advanced Level テストアナリストシラバス」中のバグレポートにフォーカスした記事
  • 最近の活動内容

http://circle-official.wacate.jp/#stm_10

もし、興味を持っていただける方がいましたら、12/31とお忙しい日だと思いますが、
ビックサイトでお手に取っていただければと思います。よろしくおねがいいたします。

次回は、Dj Mass さんです。

 

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中