クロスイデアblog

ITコーディネータの吉田聖書（よしだみふみ）です。

今回はシステム開発に関連する話題です。

皆さんはマネージャの立場で
実際にプログラムを書くといったことは
無いかもしれませんが、
部下やベンダにテストを実施させたり、
あるいはご自身がテストに協力する
といったことがあるかも知れません。

そんな時、
好むと好まざるとにかかわらず、
開発中のシステムが
想定と異なる挙動をすることを
発見してしまうかも知れません。

そういった
プログラム動作上の不備を
業界の慣例上、バグ（虫）と呼んだりしますが、
単に不備とか障害と呼ぶこともあります。

もしバグを発見してしまった際には、
プログラムの作成者に
修正してもらわなければなりません。
修正したもらうためには、
何が想定と違うのかを
正しく伝える必要があります。
口頭で伝えると、伝えるべきことが
正しく伝わらないリスクがありますので
普通は障害報告書を起票します。

それも、ただ書けば良い
というものではありません。
既に確立されたフォーマット
がある場合は別ですが、
これから決めるという場合に
私の経験を踏まえ、
含めておいた方が役に立つ項目を
ご紹介します。

(1) 再現手順

これは重要です。
何故なら
「あなたの作った機能が上手く動きませんよ」
と報告を受ける立場としては、
それを速やかに直したいという気持ちになります。
また、せっかく直したつもりが
原因が違うところにあったとなっては
直した意味がありません。

ですので、バグは発見した人と
同じ手順で再現させる必要があるのです。
もしかしたら
手順が間違っているために
バグと誤認する現象が発生した可能性もあり、
（特にテストデータの不備などの
準備不足に起因するものが多いのですが）
そういったことを未然に防げるのです。

アメリカのITコンサルタント、マット・ドーア氏は
「プログラマが知るべき97のこと」に寄せた
「バグレポートの使い方」という記事の中で
次のように述べています。

バグレポートを作成するのは、誰かと対話するためです。対話をするためには、そのバグが発生するにいたる過程をすべて相手に知らせる必要があります。同じ情報を共有しなければ対話にならないからです。
プログラマが知るべき97のこと

(2) 期待する動作

これは、テストの担当者が、
どうなるはずだ、あるいはどうなるべきだ、
と理解しているのかを知る
重要な手がかりとなります。
この項目の内容によって
テスト担当者の仕様理解度が分かり、
実はバグではなかった
と判明するケースが多々あったのです。

その場合は、根拠となる仕様書への
リファレンスを提示して
障害票はクローズとします。

逆に、
設計者がこれで良いだろうと思っていた仕様が、
テスト担当者によって、別の視点で
指摘を受ける結果に至ることもあります。
その場合、それを受け入れるかどうか
というのは別の場での協議が必要です。

(3) 実際の動作

これがいわゆるバグの現象についての記述です。
どうなってしまうというのは
言葉で説明し切れなければ、
画面スクリーンショットや
ログファイルなどを添付する方が良いでしょう。

ログファイルが大きい場合は、
見る人がすぐ分かるように、
関係のある範囲を抜粋して貼り付けた方が
親切というものです。

もし、それでも充分に伝わらなかった場合は、
プログラムの修正担当者は
テスト担当者に対して
実際にやって見せてもらうように
要求することになります。

(4) 発生頻度

これは多くの場合参考程度ですが、
時には重要な情報になり得るものです。
例えばあるバグが、
どんなに条件を変えても
毎回必ず発生するものなのか、
普段はうまく行くけれど
時々うまく行かなくなるのかという情報は、
バグの原因の特定につながることがあるのです。

言うまでもなく、
「必ず」発生するものは
原因の特定は比較的簡単です。
他には「時々」とか「稀に」とか
選択肢を用意するのですが、
「稀に」というのは環境（特にネットワークなど）
に起因することが多く、
そうなると再現させることすら難しく、
その場合は一旦クローズして
再現したら再調査するという対応にします。

(5) 発生バージョン

これは開発しているソースコードなどの
バージョン管理をしている場合ですが、
（もちろん管理してますよね！？）
実際にバグを発見したときに
動かしているプログラムの
ソースコードのバージョン番号を書きます。

何故なら、
例えば優先度を決めている場合は
優先度が低ければすぐに対応しないこともあり、
修正しようとしてバグを再現させようとした時には
既に別のバグ修正によって
直ってしまっている場合があるからです。

それであれば対応するまでもなく、
少なくともバージョンいくつ
（今確認しようとしたバージョン）
では再現しません…
ということでクローズしてしまいます。

関連記事

変更履歴はどこまで書くべきか

2020年5月18日
記事を読む

スマートなバージョン番号の付け方

2020年5月11日
記事を読む

ドキュメントは7～8割の完成度を目標に

2017年12月19日
記事を読む

経済産業省の事業で採用されたAI文書基盤LAWGUE

2021年11月15日
記事を読む

考える仕事のアウトプット

2019年10月21日
記事を読む

目的・意図を資料化することの大切さ

2017年7月3日
記事を読む

ドキュメントを読んでもらうという配慮

2017年8月14日
記事を読む