ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

テストに関するチケットに何を書いておくとよいのかのメモ

A return ticket to Hell"A return ticket to Hell" by aslakr is licensed under CC BY 2.0

 スクラム開発におけるチケット管理のベストプラクティスというものについて不勉強のまま書いた記事です(免責)。

 実装を行う人とテストを行う人が(ざっくりとでも)分かれている*1場合は、チケットも分けておくのがよいと感じています。
 あるフィーチャーの追加についてすべての作業を1つのチケットにまとめてしまうと、そのチケットの担当者がスプリント内で変わっていくことになります。特にテストをする人にとって、スプリント開始時点で「自分にアサインされる見込みのチケット」全体像が見えないのはものすごく不安です。
 よって、たとえば大まかに「設計・実装・ユニットテスト」と「それ以降のテスト」のようにチケットを切っておいて、チケットの担当者がなるべく変わらないようになっているのが好みです。

 ここでは簡単に、「開発チケット」「テストチケット」と呼ぶことにしましょう。

 開発チケットでは、自分たちの作ろうとしているフィーチャーの概要や受入れ基準を明確にしますよね。
 同じようにテストチケットでは、そのフィーチャーに対しどのようなリスクがあり、どのようなテストを重点的に行うかを表現して、スクラムチーム内で議論・合意をしておくのがよいと考えます。

 テストチケットに載せておきたい情報を、とりあえず3つ挙げてみました。

見積もり工数

 そのテストにかかる、またはかける工数です。

 実装する人は、作ったものの複雑さや難易度に応じて、テストにかかる工数のイメージを持っているかもしれません。しかし、開発の工数とテストの工数は、必ずしも比例するわけではないでしょう。
 実装する人とテストする人で、テストに要する工数の想定に大きな乖離があるとまずいので、スプリントプランニング、あるいはその後なるべく早く、想定工数について意識を合わせておくことが重要だと思います。

 工数の見積もりは、「これだけのテストを全部やると、これだけの時間がかかる」というボトムアップ型と、「今スプリントにおけるテスト工数のうち、このテストチケットにはこれだけの工数をかける」(よってカバレッジをここまでとする)というトップダウン型がありますね。
 後述のリスクに応じて、どこにどれだけの時間を投入するかを決めます。

リスク

 対象のフィーチャーに対し、設計・実装をする立場と、テストをする立場それぞれで、

  • やらかしていそうな欠陥
  • 起きてもらっては困る事象

の認識を合わせます。これはちょうど、「リスク発生確率・影響度マトリックス」の、発生確率と影響度に対応しています。
 テストをする人は、開発チケットから把握できる仕様だけでなく、設計・実装した人の直感や不安をテスト設計に反映できると、ベターなテストができると思います。

テスト観点

 リスクに基づいて、考えられるテスト観点を列挙します。具体的に適用できるテスト設計技法があれば、それも併記しておくとわかりやすいでしょう。
 より詳細なテスト設計やテストケース作成は、チケットの外で行ってもいいと思います。モデリングツールやスプレッドシートの活躍する領域なので。

 また観点を挙げる際、非機能要件への考慮が漏れないようにしたいものです。
 画面遷移などの性能、回線遅延発生時のリクエストのリトライ、ユーザに見せるメッセージのわかりやすさなど、メイン機能の外にあるふるまいの観点を忘れないようにしましょう。

スプリントプランニングにおけるQA

www.mindfulqa.com

 『スプリントプランニングにおけるQAの役割』(The Role of QA in Sprint Planning)という記事では、QA*2がスプリントプランニングに入るべき理由を5つ挙げています。

  1. 見積もり
  2. 受入れ条件
  3. テストケース
  4. デバイス/ブラウザのカバレッジ
  5. 優先度付け

 この5つは、上で述べた見積もり工数、リスク、テスト観点に対するインプットになりそうです。
 4.だけちょっとドメイン特有に思えますが、より一般的には「どの程度のテストカバレッジを狙うか」ということですね。

 なおこの記事の前提は、「QAは通常、スプリントプランニングに入らないけれど・・・」なんですよね。自分の周りを見ている限り、スプリントプランニングにQAが入るのがごく当たり前のことのように思えます。

Some tickets in the sprint will also require advanced planning from QA. For example, they may need to write test cases, review design files, or ask followup questions. QA will be more prepared if they know which tickets are in a sprint from the beginning – instead of near the end.
スプリントにおいて、チケットによってはQAが事前の計画しておかないといけないことがある。たとえば、テストケースを書き、設計ファイルをレビューし、フォローアップの質問をしたりといったことだ。スプリントの終わりに近づいてからでなく、始めからチケットの内容を知っていれば、QAはしっかり備えることができるだろう。

 some ticketというか、ほとんどの開発チケットについて、QAの計画って必要じゃないでしょうか・・・?

おわりに

 以上、とりあえず自分の思いで書き出してみました。テストの自動化についての情報は、また別のチケットになるのかな。

 すでに実績あるチケットテンプレなどあるかもしれないのですが、うまく検索できず。
 「ここ読んでから来いや!」という素敵な情報源があれば、教えてください。
 いやそもそも、テスト計画書の規格を読み直せって話かな・・・。

*1:この時点で怒られそうで怖い。

*2:この記事では、QAとテスターが使い分けられているのか同じ意味で使っているのか、よくわからない。