QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QAにて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。
質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。
本記事ではテストマネジメント改善に関する質問に回答します。
発表概要の紹介
改めましてこんにちは！ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。
私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。
発表スライドは下記となります。
また、当日の配信内容はYoutubeにアーカイブとして残しています。45分弱の発表となりますので、興味があればこちらもご覧ください。
ありがたいことに、この発表に対しては計60問の質問をいただきました。
そこで3つの記事に分けて、いただいた60問の質問を発表の構成に沿った下記の順番で回答します。
- テスト設計の改善（質問1〜質問22の計22問）←前回の記事にて回答
- テストマネジメントの改善（質問23〜質問32の計10問）←本記事の対象
- 改善結果（質問33〜質問44の計12問）←次回の記事にて回答
- 発表以外の部分（質問45〜質問60の計16問）←次回の記事にて回答
また、質問の回答前には、今回の発表内容の補足説明も記載していますので、興味のある部分だけでも読んでいただければと思います。
テストマネジメントの改善に関する発表内容の抜粋
発表ではテストマネジメント改善の取り組みについてお話ししました。質問回答を記載する前に、発表内容の概要をお伝えします。
まず、全体の進捗を把握するために、進捗表を作成しました。実績値の記入は自動化をしました。進捗表を作成した結果、「QAチームの工数が不足してテスト実施が完了できていない」と「開発起因でテストが実施できていない」の区別を付けるために、消化と改修確認でフェーズをさらに分割しました。
次に、各QAメンバーの負担を分散する取り組みとして、プランニングポーカーを用いました。チケット数で割り振りをせず、プランニングポーカーを付けたポイント数で割り振ることで、負担が均一に近くなるようにしました。また同時に、自分が担当しないチケットに対しても、ある程度の把握ができるようになりました。
以降では、このテストマネジメント改善の取り組みに対する質問に回答していきます。
テストマネジメント改善についての質問の回答
【質問23】バグがあった場合、テストの阻害になることがあると思いますが、テストを最初に消化しきるときの工夫点などあるのでしょうか？一部テストのやり直しが発生する可能性があると思うのですが。
ここでいう「テスト消化」では、テストの阻害があった場合も消化としてカウントしています。あくまでも、QAチームの業務として消化できるものが残っているかを見るためのものです。
【質問24】テストを消化した後に影響範囲内にバグが見つかった場合にテストをやり直すという可能性があると思うのですがその場合は消化率は元に戻しますか？それともそれは消化したものとして扱いますか？そうするとバーンレートがぶれないですか？
消化したものとして扱います。そのため、消化率の変化はありませんが、改修確認完了の進捗率は元に戻します。バーンアップチャートがぶれるとは思いますが、バーンアップチャート導入は「過去のデータから正確な完了日を求めたい」という目的ではなく、あくまでも「完了の目安を知りたい」という目的のため、ぶれることによる問題は発生していません。特にテストの完了については、開発者の改修という外部要因に大きく左右されるので、絶対的にバーンアップチャートの数字を信じて進むことはありません。
【質問25】「テスト消化」と「改修確認」に分けた取り組みについてです。 言い換えると、「テスト消化を優先し改修確認を後回し→次のテスト設計と並行作業」というやり方に切り替えたという理解であっていますか？
いえ、少し違います。
「テスト消化」と「改修確認」に分けた目的は、テスト消化を優先したことではなく、テスト実施進捗率という値だけでは表現しきれなかったテスト消化率を明示化したことです。テスト実施の方針については何も変わっておらず、進捗率の集計方法を細分化しただけです。
なので、テスト消化の期間中でも改修が行われた場合は改修確認も行います。
【質問26】進捗率の自動化と関連して、進捗表に使用しているツールを教えて下さい。
進捗表はGoogleスプレッドシートを用いています。Google Apps Scriptを用いて自動化を行なっています。
【質問27】プランニングポーカーの参加者の「全員」とはどこまでですか？QAメンバーやテスターだけなのか、開発者も含むのかetc
今回の発表で紹介したプランニングポーカーでは、（開発者は含まずに）QAメンバー全員が参加して、テスト工数の観点で開発チケットをプランニングしたものとなります。開発者が開発工数を見積もりするプランニングポーカーは、今回紹介したプランニングポーカーとは別に行なっています。
【質問28】なぜプランニングポーカーではフィボナッチ数を用いているのですか？
プランニングポーカーでは、相対値でポイントを付けることで、どれぐらいの工数なのか意見を出してもらい、それを全員ですり合わせることを大切にしています。
その時に、フィボナッチ数を採用して単純な2倍の数値を外すことで、もう一度深く考えることを促しています。
例えば、ポイントを3にしたチケットAと、チケットAの2倍程度の工数がかかりそうなチケットBがあるとします。
その時に、フィボナッチ数ではなく単純に1 2 3 4 5 6 7 8の中から選べてしまうと、チケットBは6を付けやすいと思います。
一方、フィボナッチ数にして1 2 3 5 8の中から選ぶようにすると、チケットBは6を選びたいところですが、6はフィボナッチ数に無いため、2倍よりも小さい5を選ぶか、2倍よりも大きい8を選ぶ必要が出てきます。そのどちらを選ぶかの過程で、もう一度深く考えることができます。
このようにして、単純な2倍を選べない仕組みにしたいためにフィボナッチ数を採用しています。
【質問29】プランニングポーカーをする際の参加者のテスト対象の事前知識が大事のような気がしますが、事前にどこまで読み込んでいますか？それによっては多くの時間がかかったりしそうですが。
プランニングポーカーの直前（30分〜1時間前）に全てのチケットを読む程度です。
プランニングポーカーで出した数値は絶対的なものではないので、たくさんの時間をかけて読み込みはせず、その時点でのテスト工数の見積もりをします。その時点で「複雑だな」「テスト工数がかかりそうだな」と感じて付けた見積もり値は、その後に業務を行なっていても大きな差がない状態の工数になります。
【質問30】プランニングポーカーをチームに導入してみた時、“1"をどのように定めるかで揉めてしまったのですが、“1” はどのように定めていますか？（“1"ということにするチケットを毎回決めるのか、何らか"1"を定めるための指標や基準を定義しているのか）
チケットを事前に読んだ時に、一番工数が小さいと感じたチケットに「1」を付けるようにしています。
【質問31】自分の属しているチームはQAメンバー間でスキルの差があるのですが、プランニングポーカーで工数感をすり合わせる際、スキル差によるポイントの差のようなものは発生しましたか？また、発生していた場合はどのようにすり合わせていったのでしょうか？
スキル差による大きなポイントの差は発生していません。若手のQAメンバーだと絶対値の見積もりは甘くなったりするかもしれませんが、ここで示しているのはあくまでも相対値なので、スキル差による大きなポイントの差は発生しません。
相対値で差が出る場合でも、大抵は1段階の差（例えば3と5や、8と13）なので、その場合は数値を出した理由を話すことで、容易にすり合わせることができます。
【質問32】リモートでおすすめのプランニングポーカーのツールがあればご教示ください。
我々はGoogleスプレッドシートを使っています。 「せーの」の掛け声で、同時に数値入力をする方法を取っています。
おわりに
今回はテストマネジメント改善について紹介していきました。QAチームがテストの工数を見積もる時にプランニングポーカーを用いることが珍しかったため、プランニングポーカーに関する質問が多かったです。
なお、今回の発表内容および質問回答を見ていただければ分かる通り、QA基盤推進室には「現状の業務でやりづらいことを自ら考え、改善をしていくことができるQA」が集まっています。
本記事を読んで少しでも興味を持った方がいましたら、ぜひカジュアル面談をして、お互いにQAについての考え方を共有できればと思います。
皆様のご応募をお待ちしております！
