読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

不具合の原因を見つけること

 普段の私は、開発課でテストエンジニアとして仕様や設計の妥当性を確認する業務を遂行していますが、市場で不具合が発生したときに不具合再現するよう、開発者から依頼されることが時々あります。

 ふと不具合再現したときをふりかえると、不具合原因の手がかりを見つけるまでの時間が1~2時間後であり、どうやったら不具合原因の手がかりを短時間で察知できたのか、要因を少し考えてみようと思います。

不具合情報を入手した直後

 開発リーダから、不具合に関連した情報を電子メールで展開されます。受け取った情報から、不具合発生時の環境を裏紙で図解し、必要な機材を10分程度で列挙します。必要な機材をかき集めながら、構成や設定内容を頭の中で大まかなテストケースとして具象化します。

不具合発生時の環境を構築しているとき

 不具合再現の手順を洗い出すため、あらゆる操作やシステムの入出力の候補を2~3列挙します。同時に手順の流れを頭の中でシミュレーションします。

不具合発生手順を洗い出しているとき

 一連の操作を行い、システムの出力を監視していて「あれ?」と感じたときに手を止め、手順を巻き戻して再現できるか確認します。なお、「あれ?」と感じているときは、システムが停止して何らかの損失(金銭、時間、安全のいずれか)が発生して、不快な感情が出たときです。

不具合再現後

 インシデントレポートをまとめる要領で、開発者に報告するためのメモを作成して、開発者の目の前で不具合を再現して、開発者と不具合のメカニズムを解明するために、さらに不具合再現を進めます。

開発課に所属しているテストエンジニアの役割

 「見えないものを見えるようにする」ことが重要かなと思います。