Blogアプレッソのエンジニアが書く技術ブログです。この広告は、90日以上更新していないブログに表示しています。その5品質マネジメントこんにちは、品質マネジメント部の磯です!書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその5になります。www.shoeisha.co.jp前回は「アジャイルテストの自動化戦略」について書きました。appresso.hatenablog.com今回は「コーディングとテスト」のうち、バグの取り扱いについて学んだことを出力していきます!まえおき!従来型の開発スタイルであれば、我々QA担当者は発見した全てのバグをもりもりとバグトランキングシステム(BTS)などに登録するのが一般的なアクションかと思います。あとあと見返してみれば何年も前の課題が未だに対応されず残っている・・・。なんてことはありませんでしょうか。未対応のまま残されている課題はそのまま管理し続けるのに値する何かがあるのでしょうか。中には残しておくことに意味があるものもあるでしょう。それなりの数の課題が経緯もわからず残っているだけだったりしないでしょうか。アジャイルなアプローチにおいてはBTSに登録しないという方法もあります。これは選択肢が増えた、ということを意味します。実装担当者に発見したバグを口頭で伝え、付箋でタスクを管理し、対応が完了すればそれで終了。いう方法もとることができます。ときにQA担当者は発見した課題をBTSに登録するまでが仕事であると思いがちです。品質保証の略であり、それが達成されることが最も重要なミッションです。「バグに対処する」より)さて、上記ミッションを達成する上で、対応すべきバグとは何でしょうか。意図しないエラーを修正するなどはもちろんですが、顧客とのやりとりから生まれた課題を取りこんでいく必要もあります。顧客が優先順位と価値を決めます。それを満たすのに必要なものは全て実行していく必要があります。(もちろん優先順位が変わればスコープからこぼれ落ちる機能もあることでしょう・・・)また、技術的負債についてもバグの一種と考えることができます。これらが残ることによって潜在的なバグが残ってしまったり、柔軟性やチームのモラルに負の影響を及ぼすこともあるかもしれません。「選択のすべて」より)では、これは対応すべきバグだ!とした事象はどのように管理していくべきでしょうか。これは前述のとおり多くの選択肢があります。発生したバグを付箋に書き、タスクボードに貼り付ける機能と同様にひとつのストーリーとしてスケジューリングするBTSにバグとして登録していくチームの練度が高ければ、単純にひとつのタスクとして対応していくというのも良いでしょう。遠隔地のエンジニアとリモートで共同作業している場合では、BTSに登録して共有していく必要があります。そのときそのとき、環境によって最適な対応を検討していくいきます。可能であるならばバグのレポートは作成しないことを推奨されます。プログラマが正しい方向に変えられないときだけ、レポートを作成するのです。どのバグを記録するのか決めるとはいえ、レポートの作成が必要なのか否かについてはそうそう決められません・・・。そこで著者は以下のような例を提示しています。単体テストのエラー(ここではCIにて繰り返し実行されているテストを指している)記録すべきではない。失敗したテストがレポートと同等のものと捉えられるただし効果的な修正により多くの情報が役に立つ場合もあるため、レポートを作成する場合もある現在の反復でのストーリーのバグプログラマと協議し、すぐに修正できるものであれば記録しない反復の後のバグ(あるいは、すぐに修正できないバグ)記録するこれはプログラマはすでに別のストーリーへと作業が移っているためレガシーシステムから記録が前提となるが、長らく使われていた中で問題となっていないのであれば無理に記録する必要はない本番で見つかるもの全て記録するいつバグを修正するかを決める対応すべきバグが見つかった、ではいつ修正するか?については以下の3つ選択肢があります。いま直すバグは開発が進めば進むほど、修正に対するコストが増大していきます。見当がついているのであればすぐに対応することが望ましいですが、既存機能への影響などが考えられる場合は、顧客に対応への優先順位をつけてもらうこともあります。あとで直す発見したバグはチームで対応する前に顧客に優先順位をつけてもらう、対応すべきか否かを見当としてもらうというスタンスです。直さない実装してはみたものの機能そのものがなくなる、または大きな変更が行われると考えられるときは対応しない選択肢もあります。このとき、記録したレポートがあればオープンのままにしておかずクローズしてしまうことが推奨されています。まとめ今回はバグの取り扱いについてアウトプットしてみました。まとめると・・・バグの内容や状況によって、対応は様々であるどんなアクションをとるのが効果的か、はたまたとらないほうが良いのかの検討が必要といったところでしょうか。次回も今回と同様にバグの取り扱いについてについてアウトプットしていきたいと思います。品質マネジメント部の伊藤です。»プロフィールid:appressoアプレッソのエンジニアが書く技術ブログです。(1)はてなブログをはじめよう!appressoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。