アジャイルとテスト計画
ソフトウェアテストアドベントカレンダーの9日目です。
halspringです。宣伝ではないですが、独りアドベントカレンダーを書いていて正直キャパシティオーバー気味ですが頑張りますよ(｀･ω･´)ゞ
前日の記事はこちら。
今回はアジャイルにおけるテスト計画についてざっくり書きたいと思います。
アジャイルに依らない(関係のない)部分もありつつ、アジャイルならではの部分もありつつで読みにくいかもしれませんが、しばしお付き合い願います。
みんなだいすきJSTQB
JSTQBにアジャイルのシラバスがあるのはご存知でしょうか？
それが『Foundation Level Extension シラバス アジャイルテスト担当者』です。
シラバスはFoundation Levelの内容を理解していることを前提としているため、読んでいてアジャイル以外の文脈で詰まることが多ければ一度Foundation Levelのシラバスに目を通してみることをオススメします。
アジャイルとドキュメント
アジャイル開発において、
ドキュメントは軽視され、コードが優先されることがあります。
( もちろん本当は「軽視」していいわけではないですし、それはおそらくアジャイルではないですが。 )
より価値のあるものを優先することや、変更に対して柔軟でスピードを求めると、
テスト計画書を作るのは確かに手間も時間もかかりますし、後々の変更の量も膨大になってしまうかもしれません。
テスト計画書を更新する運用コストを考えると、ドキュメントとして残さない選択は自然かもしれません。
計画することと計画書に書くこと
テスト計画をすることと、テスト計画書に書くことはイコールではないと思っています。
また、決めたことと書くことの粒度も等倍である必要はないと思っています。
「こう書かないとテスト計画書じゃない」といったルールがあるわけではありません。
計画は自分達がよりよい方向に進むためにあるものなので、
自分達にとって必要だと思うものを必要なだけ決めて、必要なだけ残せば良いです。
ですので、はじめからガッツリと「テスト計画書かくぞ！」ではなく、メモ程度から始めるでも構わないと思っています。
ただ、はじめから何をすれば良いのか判断するのは難しいと思うので、ヒントといいますか参考程度に「こういうものがあるよ」を挙げていきます。
プロジェクトの概要/目的
当たり前すぎて意外と話し合わなかったり文書に残さなかったりすることがあります。
プロジェクトが進むに連れて、方向を見失ったりズレていることがありますが、事前に話し合っておけばスタート時のベクトルを揃えることができ、文書にしておけば後からズレに気がつくことができます。
テストレベル/テストタイプ
テストレベルを考えるとき、盲目的にV字モデルを前提としてしまいがちです。
単体テスト、結合テスト、システムテスト、受け入れテスト、これらはよくV字モデルとセットで説明されています。
それらが、自分達の開発プロセスに適している根拠はどこにもありません。
スタンダードな用語や定義、モデルにこだわることなく、自分達にあったものを考えていくべきだと考えています。
（もちろん、独自のものを用いるのであれば、スタンダードなものも知っておくべきだと思いますが。）
同様に、テストタイプも自分達で考えて定義すべきです。
「パフォーマンステスト」「性能テスト」「負荷テスト」「ストレステスト」
これらのテストタイプの意味や目的を無作為に集めた複数のプロジェクトメンバーにそれぞれ述べさせたとき、その答えが一致するのはおそらく天文学的確率です。
言葉の認識にズレが生じることで、テストの目的にもズレが生じ、そのズレは徐々に徐々に多くの影響を及ぼします。バタフライエフェクトのように。
用語を定義してメンバー間では認識が揃うようにしておくことが重要です。
自動テスト/回帰テスト
アジャイルでは回帰テストが非常に重要なファクターであり、またそれらは可能な限り早い段階で自動化されているべきだと思います。
小さいリリースがたくさん行われるため、スコープ外へ影響がないことを確かめる回帰テストを行う割合が自然と高くなります。
何度も実施されるテストは、工数やテストの再現性を考えると手動で行う割合を減らしたいものです。
なので、どのテストを自動化し、どこを手動で担保するのかを考えておきます。
もちろん、いきなり自動化が難しければ、最初は手動で徐々に自動化するで構わないです。アジャイルなので。
また、それらは基本的にどこまで確認すればよいのかの判断が難しいです。（ テスト全てにおいてそう言えますが。 ）
判断が難しいので、
ミッションクリティカルになるところを重点的に見るだとか、
自動テストではAPIの入口と出口をおさえてUI部分は探索的テスト(や目視)で確認だとか、
回帰テストの戦略が重要になります。
コミュニケーションのルール
こちらも案外忘れがちです。
知らないところで仕様が変わっていても困りますし、仕様が変更されたことを知らせる場所を決めておいたり、
緊急で重要な報告を誰に行えばいいのかなど、もしもに備えた情報もあると困りません。
また、新しくアサインされたメンバーが朝会や夕会の場所やルール、その他の定例やチャットで用いるルームやチャンネルなどを把握するのにも役立ちます。
バグの起票基準/ルール
バグ票を起票する際のルールについても大事です。
重要度(優先度)をいつ誰が決めるのか、その基準はなにか、といったプロジェクト進行上のルールもありますが、
他にも、自由にラベルを付けてしまうと表記揺れが生じて分析が大変になったり、上記のテストタイプ然り認識がズレてしまうこともありえます。
必要になってから考えるでも良いので、決まったことはその都度追記することが大事です。
おわりに
ここまでお読み頂きありがとうございました。
見当違いなことを書いていたら申し訳ありませんが、
それでもなにかを考えたり話し合ったり議論する材料にでもなれば幸いです。
引き続き、アドベントカレンダーをお楽しみください。
