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問）←本記事の対象
また、質問の回答前には、今回の発表内容の補足説明も記載していますので、興味のある部分だけでも読んでいただければと思います。
改善結果に関する発表内容の抜粋
発表では定量的・定性的な改善結果についてもお話ししました。
質問回答を記載する前に、発表内容の概要をお伝えします。
テストケース数は改善前に比べて1/3〜1/5程度になりました。
一方で、検出する不具合数は大きな変化がありませんでした。
テスト設計の工数とテスト設計レビューの工数は減少していきました。
テスト1件あたりの実施工数は減少しづらいですが、テスト設計のコツを掴むことでテスト設計工数の削減は可能です。
さらに、テスト設計の改善によってテストケース数自体が減少しているため、テスト実施工数全体も減少していました。
改善後に、所属しているQAメンバーからは下記スライドのような意見が出てきました。
チームとしてテストを行い、余裕を持ちつつ開発完了前にテスト活動を開始することで、開発者とも有意義な議論をすることができているようです。
以降では、この改善結果に対する質問に回答していきます。
改善結果についての質問の回答
【質問33】「テスト設計の工数が削減されていった」という話がありましたが、なぜそうなったかの説明が無かったように思います。要因としては、頻繁な設計レビューを行ったことで、チームがより効率的な設計を学んだから、ということでしょうか？
はい、その通りです。発表の中では「コツ」という言葉で済ませてしまいましたが、適切な技法選択、技法適用、因子水準の選定などがスムーズにできるようになったことが、テスト設計工数の削減に寄与しています。
【質問34】テストを先に考えるということで、テストパターンが多くなってしまうから設計をシンプルにしよう、というように設計にフィードバックがかかることはありましたか？
あります。テストパターンを伝えることで、開発のPlanning時点では考慮できていなかった部分を開発も認識できるようになり、再度考えた結果、設計がシンプルになったケースもあります。
【質問35】このような改善活動をしたことで「テストやりすぎじゃないの？」という声はなくなりましたか？
全体的に見て「テストをやりすぎ」という声は無くなりました。チケット別で見ると「テストをやりすぎ」という話が出てきますが、そこはテスト設計レビューで適時修正しています。
【質問36】納得感が上がったのはQA（テスト）チームだけでしょうか？開発チームはどのようなテストをするかを知ることで納得感があがると思うですがいかがでしょうか？
今回はQAチームを中心とした発表でしたが、開発チームにも良い影響がありました。テスト観点の共有や、テスト設計レビューに参加してもらうことで、開発チームの納得感が上がっただけでなく、開発チームが行うテストについても合わせて議論ができるようになりました。
【質問37】テストの実行自体は次のスプリントで行っていると思いますが、その場合に見つかったバグ等のフィードバックもしやすくなりましたか？
バグのフィードバックはしやすくなっています。テキスト上で即時のやり取りを行なっている他、Daily Scrumなどの場で伝えているチームもあります。
【質問38】スプリント終わりの振り返り1はどうしてますか？ 開発者とQAメンバーとでそのスプリントで担当している内容が違うと、振り返りにくくはないですか？
「開発チームにQAメンバーも参加するふりかえり」と「QAチーム内のみで行うふりかえり」の2つを行なっています。開発チームが開催しているふりかえり（Scrumにおけるレトロスペクティブ）では、主に「やり方」に対するふりかえりであり、今回の案件に対してのふりかえりではないので、スプリントのズレによるふりかえりのやりづらさを感じたことはありません。
【質問39】テスト設計に関する今回の改善内容は自動テストの作成にも活用することができますか?
活用することはできると考えています。
自動テストの作成でもテストパターンを削るという考え方を持っていないと、自動テストのテストコードが肥大化する原因となってしまいます。（特にE2Eでの）自動テストでは、全てのパターンをテストするのは効率的ではないので、自動テストで担保している内容を限定することが多いです。その際に今回の考え方を活用できます。
【質問40】「チームで行う活動が増えた」とのことですが、コロナ禍でリモートワークになったことでチームの活動がやりにくく感じてます。何か工夫されていることはありますか？
個人的な感覚では、リモートワークによってむしろチームの活動がやりやすくなったと感じています。
リモートワーク前だと、レビューを行うにしても、ミーティングスペースを確保しないといけませんでしたが、リモートワークになってからその心配が無くなりました。また、画面共有をすることで、同じ画面を見ているため、認識のズレも少なくなりました。
リモートワーク時の工夫としては、頻繁に同期を取ること、画面共有を多用すること、画面共有時に他の人も共有画面にペンで書き込みながら話すことなどがあります。
【質問41】「テスト観点出し」も行っておらず「テスト設計という名のいきなり実装」をしているような場合は、今回の「設計と実装を分ける施策」と「テスト観点出し」のどちらから先に取り組むと良いでしょうか？
今回の発表でお伝えした「テストの振り子」2を元に考えてみてください。
もしも、「リリースしてからのバグが多い」となっている場合は、観点を増やす意味で「テスト観点出し」をした方が良いかもしれません。
もしも、「テストが多くて工数がかかる」となっている場合は、今回の我々と同じように、設計と実装を分ける施策に取り組んだ方が良いかもしれません。
そして、テスト観点出しも行わず、テスト実装をいきなりやっている場合は、おそらくリリース後のバグの多さに悩んでいる可能性が高いと思うので、テスト観点出しをすることになるかと想像しています。
【質問42】改善するにあたって抵抗勢力はありませんでしたか？抵抗勢力がもしあったならばどのように対処しましたか？
いきなり全てのやり方を変えようとすると、今までやっているタスクにさらに新たなタスクが生まれると感じてしまうため、抵抗しようと考える人が出てきてしまうと思います。実際、初期段階では、なかなか改善の趣旨が伝わりづらいと感じることがありました。
なのでまずは、QAチーム内の改善に取り組みました。そして、QAチームの改善結果を示しながら、あくまでもQAチームに余裕ができるようになったから、開発チームに入り込むことができてきているということを行動で示しています。
【質問43】スプリントの中でセレモニー参加、仕様把握、テスト設計、レビュー会、テスト実施はかなりスケジュールがタイトだと感じるのですが、スケジュール面で大変になっていませんでしたか？
いきなり全て行うと大変なので、徐々に行うようにしました。
- 観点出し＆テスト実施（元々実施していた）
- テスト設計＆レビュー会
- 仕様把握（プランニングポーカー）
- リファインメントなどのセレモニー参加
上記のような順番で徐々に行い、だんだん余裕が出てきたらorもっと効率的に行う手段をふりかえり時に考え出したら、次の施策を導入するようにしました。
一番大変だったのは、「テスト設計＆レビュー会」を導入したタイミングです。改善前のようにテスト実施でかなりの工数がかかっている状態で、テスト設計とレビュー会を行うのはかなり大変です。今回は、開発のチケット数が比較的少なく、QAチームに工数の余裕が出たタイミングを見計らって改善を行いました。
【質問44】市場へのデプロイ時に、品質保証はどのように行っていますか？スプリントごとのテストで、デプロイのための品質保証を担保しているのでしょうか？
「市場へのデプロイ」を弊社では本番リリースと捉えています。「デプロイのための品質保証」を「仕組み」「環境」「機能」の見方があると仮定した場合、「仕組み」については、一般的なものを使用していますので、特に品質保証活動はしていません。「環境」「機能」については、ステージング環境等の本番環境に近い環境でリリース前のテストを実施してから、本番リリースしています。
その他の質問の回答
発表以外の内容や、今回の発表の前提となる組織/体制などの質問も多数いただきました。
【質問45】 この活動は設計、テスト設計者、テスト実施者がそれぞれ何人程度いたのでしょうか？
開発者は15名程度、QAメンバーは私を除いて5名です。QAメンバーはテスト設計者とテスト実施者（テスター）で区別することはしていません。QAメンバー全員がテスト設計を行いますし、テスト実施もします。
【質問46】一つの案件に対して、QAメンバーは何人ついていたのでしょうか？1人のQAメンバーが同時に見る案件は一つでしょうか？
「案件」をわたしたちの開発の基本単位である「チケット」に置き換えて回答します。
発表中に示した改善策によって1人あたり担当するチケット数が変わりますが、1スプリントで多くて4チケット程度です。
【質問47】QAメンバーは全員開発経験があるのでしょうか？全員スクリプトが書けるのでしょうか？
QAメンバーは私以外全員、パートナー会社の社員様に入ってもらっています（弊社社員ではありません）。また、私以外は全員開発経験がありません。人によっては、今までITに関わっていない人や新卒で入って初めての現場という人もいます。
今回の改善を行うにあたり、テスト経験が乏しい人も含めたQAメンバー全員に対して、私がテスト設計について改めてレクチャーしました。
【質問48】開発チームとQAチームを分けている意図ってなんでしょうか？例えばメンバーをシャッフルなどすればQAチームも仕様が分かる人が必ずいる状況になるかなと思いました。
分けている理由はいくつかあります。
- QAチームのメンバーであるパートナー会社の社員様はテスト会社の方なので、契約上、製品開発を行うことはできないため
- テスト会社は別名「第三者検証会社」と呼ばれるように、開発者自身では気付きづらい部分のテストを行なったり、テストレベルが違う部分のテストを行なっているため（開発者自身が見つけるテスト(checking)とQAメンバーならではの観点で見つけるテスト(testing)は異なるという考えがある）
ただし、Testingの考え方を開発者も持つようになり、人を分ける必要がなくなっていくのが理想的だと考えています。
【質問49】QAメンバーは横断的なスクラムチームとして存在しているのでしょうか？それとも、各スクラムチームにQAメンバーが参画している体制でしょうか？
各スクラムチームにQAメンバーが参画している体制です。ただし、現状ではまだまだステークホルダーに近い立ち位置になっています。
【質問50】ブロッコリーさんは、テスト改善についてどのような立場で関わるようになっていったのですか？
私は社内コンサルのような立場で、QAチームおよび開発チームの改善に入っていきました。なので、他のQAメンバーとは違い、組織上は今回の対象プロダクトのQAチームに所属していません。
【質問51】チームはスクラムチームですか？バックログリファインメントにはQAメンバーも参加しますか？
チームはスクラムチームです。発表資料にもあった通り、バックログリファインメントにもQAメンバーは参加しています。
【質問52】1スプリントの期間はどれくらいですか？1週間？
今回の発表のチームは2週間です。ですが、1スプリントが1週間のチームでも同様の取り組みを行なっています。
【質問53】リリースは、そのスプリント内ではなく、次のスプリントでQAが完了したあとですか？
開発スプリントの後にQAチームによるテストフェーズを踏まえて、リリースとなります。そのため、リリースも2週間ごとに行われます。
【質問54】エンジニア実装とQAをスプリントで分ける場合、スプリントレビューはどのタイミングで行っているのでしょうか？
スプリントレビューは開発のスプリントが終わったタイミングです。
【質問55】開発者はテストを行わないのでしょうか？開発側はどのようなスプリントレビューをされていたのか気になります。
今回の発表を聞くと、開発者によるテストが疎かになっているのでは？という疑問が出てくるのかもしれませんが、開発者もしっかりとテストを行なっています。 少なくとも、スプリントレビュー時に動かなくて、レビューができないという事態は発生しません。
【質問56】スプリント内で開発するチケットの内容は、どのタイミングで開発チームとQAチームで共有されているのでしょうか？
開発のスプリントプランニングでQAチームにも共有されています。
【質問57】QAチームは負荷テストも行なっていますか？
QAチームは負荷テストを行なっていません。負荷テストが必要になりそうなチケットは、事前のチケット読み込み時および開発者とのコミュニケーション時に相談したうえで、開発者に行なってもらうことがあります。
【質問58】自動テストと手動テストの両方があるプロダクトにおいてテスト設計フェーズで考えるべきことはありますか？例えばここは自動テストがしっかりしているから手動テストを削ろう、といった場面はありましたか？
自動テストではド正常系（正常系の中でも主要な部分）を自動化することが多いため、それ以外の部分を手動テストで考えるようにはしています。
【質問59】テスト自動化はどうしていますか？開発、QA、SETの誰が担当しますか？また、E2Eテストを自動化するツールの導入などは進めましたか？
テスト自動化については、今回紹介したQAチームとは別のチームが行なっています。ツールの導入に関しては、メンテナンスコストを特に考慮して選んでいます。
【質問60】手動でテストをする場合、スプリントが経過するごとにリグレッションテストの負担が増えてくると思いますが、リグレッションテストの工夫などはありますか？
リグレッションテストについては、日々、お客様と向き合う他部署の社員とも協力して、特に業務重要度の高い部分を洗い出しており、それを元にリグレッションテストで行う内容を選定していきます。
おわりに
今回は改善結果とその前提となる組織/体制について紹介していきました。本当に効果があったのか、今回のような施策を行うためにはどのような組織とメンバー構成なのか興味をお持ちの方が多かったように感じました。
なお、今回の発表内容および質問回答を見ていただければ分かる通り、QA基盤推進室には「改善を楽しみながら開発に近づいていって協働できるQA」が集まっています。
本記事を読んで少しでも興味を持った方がいましたら、ぜひカジュアル面談をして、お互いにQAについての考え方を共有できればと思います。
皆様のご応募をお待ちしております！
