Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

アジャイル開発になったらQA担当者はどうなるの? 〜「実践アジャイルテスト」で学んだこと〜 その5

こんにちは、品質マネジメント部の磯です!

書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその5になります。

www.shoeisha.co.jp

前回は「アジャイルテストの自動化戦略」について書きました。

appresso.hatenablog.com

今回は「コーディングとテスト」のうち、バグの取り扱いについて学んだことを出力していきます!

まえおき!

従来型の開発スタイルであれば、我々QA担当者は発見した全てのバグをもりもりとバグトランキングシステム(BTS)などに登録するのが一般的なアクションかと思います。しかし、あとあと見返してみれば何年も前の課題が未だに対応されず残っている・・・。なんてことはありませんでしょうか。

未対応のまま残されている課題はそのまま管理し続けるのに値する何かがあるのでしょうか。もちろん中には残しておくことに意味があるものもあるでしょう。 しかし、それなりの数の課題が経緯もわからず残っているだけだったりしないでしょうか。

アジャイルなアプローチにおいてはBTSに登録しないという方法もあります。これは選択肢が増えた、ということを意味します。たとえば実装担当者に発見したバグを口頭で伝え、付箋でタスクを管理し、対応が完了すればそれで終了。という方法もとることができます。ときにQA担当者は発見した課題をBTSに登録するまでが仕事であると思いがちです。QAはQuality assurance = 品質保証の略であり、それが達成されることが最も重要なミッションです。

なにが対応するべきバグなのか

(P414 18.6 「バグに対処する」より)

さて、上記ミッションを達成する上で、対応すべきバグとは何でしょうか。意図しないエラーを修正するなどはもちろんですが、顧客とのやりとりから生まれた課題を取りこんでいく必要もあります。顧客が優先順位と価値を決めます。それを満たすのに必要なものは全て実行していく必要があります。(もちろん優先順位が変わればスコープからこぼれ落ちる機能もあることでしょう・・・)

また、技術的負債についてもバグの一種と考えることができます。これらが残ることによって潜在的なバグが残ってしまったり、柔軟性やチームのモラルに負の影響を及ぼすこともあるかもしれません。

バグの管理

(P417 18.7 「選択のすべて」より)

では、これは対応すべきバグだ!とした事象はどのように管理していくべきでしょうか。 これは前述のとおり多くの選択肢があります。たとえば・・・

  • 発生したバグを付箋に書き、タスクボードに貼り付ける
  • 機能と同様にひとつのストーリーとしてスケジューリングする
  • BTSにバグとして登録していく

チームの練度が高ければ、単純にひとつのタスクとして対応していくというのも良いでしょう。はたまた遠隔地のエンジニアとリモートで共同作業している場合では、BTSに登録して共有していく必要があります。そのときそのとき、環境によって最適な対応を検討していくいきます。

しかし、もし可能であるならばバグのレポートは作成しないことを推奨されます。プログラマが正しい方向に変えられないときだけ、レポートを作成するのです。

どのバグを記録するのか決める

とはいえ、レポートの作成が必要なのか否かについてはそうそう決められません・・・。そこで著者は以下のような例を提示しています。

  • 単体テストのエラー(ここではCIにて繰り返し実行されているテストを指している)
    • 記録すべきではない。冗長で時間の無駄となる
  • 概要レベルの反復テストのエラー
    • 失敗したテストがレポートと同等のものと捉えられる
    • ただし効果的な修正により多くの情報が役に立つ場合もあるため、レポートを作成する場合もある
  • 現在の反復でのストーリーのバグ
    • プログラマと協議し、すぐに修正できるものであれば記録しない
  • 反復の後のバグ(あるいは、すぐに修正できないバグ)
    • 記録する
    • これはプログラマはすでに別のストーリーへと作業が移っているため
  • レガシーシステムから
    • 記録が前提となるが、長らく使われていた中で問題となっていないのであれば無理に記録する必要はない
  • 本番で見つかるもの
    • 全て記録する

いつバグを修正するかを決める

対応すべきバグが見つかった、ではいつ修正するか?については以下の3つ選択肢があります。

1. いま直す

バグは開発が進めば進むほど、修正に対するコストが増大していきます。見当がついているのであればすぐに対応することが望ましいですが、既存機能への影響などが考えられる場合は、顧客に対応への優先順位をつけてもらうこともあります。

2. あとで直す

発見したバグはチームで対応する前に顧客に優先順位をつけてもらう、対応すべきか否かを見当としてもらうというスタンスです。

3. 全く直さない

実装してはみたものの機能そのものがなくなる、または大きな変更が行われると考えられるときは対応しない選択肢もあります。 このとき、記録したレポートがあればオープンのままにしておかずクローズしてしまうことが推奨されています。

まとめ

今回はバグの取り扱いについてアウトプットしてみました。 まとめると・・・

  • バグの内容や状況によって、対応は様々である
  • どんなアクションをとるのが効果的か、はたまたとらないほうが良いのかの検討が必要

といったところでしょうか。

次回予告

次回も今回と同様にバグの取り扱いについてについてアウトプットしていきたいと思います。

ではまた!