はじめに
ソフトウェア試験を行っている皆さんとソフトウェア開発を行っている皆さんこんにちは。
先日、ソフトウェア試験を行っているメンバーと障害票について議論になったのでちょっと整理をしておきたいと思います。
障害票の書き方
公平を期するためにChatGPT先生に聞いておきます。
- 障害票とは
ソフトウェアの障害票とは、ソフトウェアが予期せぬ不具合を引き起こした場合に、その問題を報告するための文書です。一般的には、ソフトウェア開発者やサポート担当者が障害を解決するために必要な情報を提供することを目的としています。
- 障害票の書き方
ソフトウェアの障害票は、ソフトウェアが意図しない動作をした場合に、その問題を報告するための文書です。以下は、一般的なソフトウェア障害票の書き方の手順です。
障害の特定: 障害が発生した時期、頻度、場所、および影響などを特定します。具体的には、どの操作を実行したときに問題が発生したのか、エラーメッセージが表示されたかどうか、などを確認します。
現象の記述: 障害の具体的な現象を詳細に記述します。具体的には、どのようなエラーメッセージが表示されたのか、プログラムの挙動に何か異常があったか、などを詳しく書きます。
再現性の確認: 障害が再現可能かどうかを確認します。再現可能であれば、障害発生時の操作手順や環境などを詳細に記述します。
原因の推測: 障害の原因を推測し、可能な原因を列挙します。具体的には、プログラムのバグ、環境の問題、ネットワークのトラブルなどが考えられます。
対策の提案: 障害の解決策を提案します。具体的には、修正プログラムの開発、システムの再起動、データの復旧などが考えられます。
付録: 障害発生時のログやスクリーンショットなど、関連する情報を付録として添付します。
以上が、一般的なソフトウェア障害票の書き方の手順です。障害票を作成する際は、できるだけ詳細に記述することが重要です。これにより、障害の再現性が高まり、解決策を見つけるための情報が得られます。
障害票の書き方について、およその原理・原則は理解できますね。
ただ、1.の「障害の特定」という用語が内容に対して難易度が高いように見えました。
本当に「障害の特定」まで行うとすると、開発の知識が必要になると思いますので、「障害の特定」は行わず以下3点を端的に伝える程度がよさそうに思えました。
- 期待値
- 結果(期待値とどこが異なっていたか)
- 手順
例えば、「自動販売機に120円入れてオレンジジュースのボタンを押す」という手順に対して、「オレンジジュースが出てくる」という期待値があった時に、「グレープジュースが出てきた」という結果になった時の障害票には、「オレンジジュースが出ずにグレープジュースが出てきた」と事実を端的に伝えてもらえれば開発者は修正を行えます。
障害を特定しようと「グレープジュースが出てくる」手順の調査を行ったり、それを障害票に記載することはしなくても大丈夫です。
ソースを読んで調査したのでなければ 「たまたま同じ結果が出る手順」 でしかないし、それは試験担当者がする作業ではないからです。
ただし、100回に1回ぐらい再現するといった障害の場合には「グレープジュースが出てくる」手順の調査がもう少し必要になってきます。『再現手順』に何か条件が不足していることが考えられるからです。
このあたりの線引は経験を積まないと分かりづらいところかもしれないので、手を動かす前に質問するようにするとよいと思います。
開発の知識がなくても「いい感じ」の障害票を書ける？
追加で質問をしてみます。
- 開発の知識がなくても「いい感じ」の障害票を書ける？
開発の知識がなくても、障害票を書くことは可能です。ただし、障害が発生した原因や解決策についての深い知識がない場合、より詳細で的確な障害票を書くことが難しいかもしれません。
以下は、開発の知識がなくても、より良い障害票を書くためのアドバイスです。
障害の発生状況を詳しく記述する: 障害が発生した状況について、詳しく記述することが重要です。具体的には、障害が発生した時期、頻度、影響範囲、操作手順などを記述します。
障害の現象を詳しく記述する: 障害が引き起こした現象について、詳しく記述することが重要です。具体的には、エラーメッセージの内容、プログラムの挙動に何か異常があったかどうかなどを記述します。
障害を再現する手順を詳しく記述する: 障害を再現する手順を詳しく記述することが重要です。再現可能な障害であれば、操作手順や環境をできるだけ正確に記述します。
関連する情報を提供する: 障害が発生した環境や、使用しているソフトウェアのバージョン、OSのバージョン、ハードウェアなどの情報を提供することが重要です。
ログやスクリーンショットなどの情報を提供する: 障害が発生した時に取得できたログやスクリーンショットなど、関連する情報を提供することが重要です。
以上のように、開発の知識がなくても、より詳細で的確な障害票を書くことができます。ただし、障害の原因や解決策についての深い知識がない場合は、開発者やサポート担当者による追加の情報収集や解析が必要になることがあります。
開発の知識がなくても、アドバイスに従って実践していけばカイゼンはできそうですね。
ただ、具体的な質問をしないと一般的な回答しか得られなそうですね。
具体的に問題を抱えている方は是非でGPT先生に質問してみてください。
おわりに
開発者と試験担当者で円滑にコミュニケーションが取れる障害票は、「詳しい障害票」 ではなく 「開発者が障害を直しやすく、試験担当者が修正確認がしやすい障害票」 です。読む相手が仕事をしやすくなるのかどうかが大事です。
仮に障害票に試験項目書へのリンクと試験番号しか書いてなくても、それで開発者が抜け漏れなく障害を直せて修正確認も行え、チーム全体の工数が下がるのであれば、それはよくできた障害票と言えるでしょう。
逆にどんなに詳しく書いてあっても、開発者が修正ができないのであれば、それはよくない障害票と言えるでしょう。
障害票の記載が過剰な場合、コスト面で確実に悪い影響があります。ボディブローのようにじわじわダメージを与えます。それにも関わらず、それをわざわざ指摘する開発者はいません。指摘するメリットが開発者本人としては薄い上に関係性に悪い影響が出るかもしれないというリスクしかないからです。
一方で障害票の記載が不足している場合は開発者は聞くしかありません。あまりにも記載が少ない場合にはキレられるリスクはありますがお互いにとって最適な記載量に近づける可能性があります。
具体的にどのような障害票がよいのかはチームによって異なると思います。
本記事が、皆さんのチームにおいてよりよい障害票ライフを送る一助になれば幸いです。
おまけ１（新卒エンジニア向け手紙）
おまけ２（新卒エンジニア向け記事）
おまけ３（営業A短編シリーズ）
おまけ４（パイセン向け記事）
おまけ５（エンジニアのためのお仕事問題集）
2030年にIT人材が最大79万人不足するらしいので、学習用の資料をgitで無料公開してます(不定期更新)。
よろしければどうぞ。