はじめに
「テスト設計って難しそう…」 😓
株式会社ビットキーでSoftware QAチームに所属している鳥渕と申します。
ビットキーでは様々なプロダクトを扱っておりますが、私はその中でもモバイルアプリQAのリーダーを担当させていただいております。
日々の業務や振り返り会などのタイミングでメンバーからこのような声を聞くことがありました。
・テスト設計のレビュー指摘が多いのでなんとかしたい
・観点が思いつかない
・どうやって考えてるのか、作っているのか知りたい
モバイルアプリの品質を向上させるためには、効果的なテスト設計が不可欠です。
しかし、テスト設計は、多くのQAエンジニアにとって悩みの種でもあります。
そこで、私たちビットキーのモバイルアプリQAチームでは、テスト設計のスキルアップを目指し、様々な形式の勉強会を開催しています。
今まで3つの形式で開催したのでそれをご紹介したいと思います。
テスト設計書について
モバイルアプリQAでは、以下のようなツリー状のマインドマップとデシジョンテーブルを作成しています。
例：ログイン画面の確認方針
マインドマップでは以下の内容を記載します
①確認画面やユーザーの状態、デバイスの種類などのテスト対象の因子と水準
②具体的な操作手順と期待値
③その他確認すべきユースケースやデグレ確認の観点
デシジョンテーブルは、マインドマップに記載した因子・水準でどの掛け合わせでテストを行うかを記載します
この2つの成果物の品質を上げるべく、勉強会を実施しました
宿題形式
まず、最初に実行したのがこの形式です。
次回リリース予定のチケットから1つを選び、事前にメンバーそれぞれがテスト設計書を作成して持ち寄り、勉強会で発表する形式です。
各メンバーに上述したマインドマップとデシジョンテーブルを事前に作成してもらいます。
発表してもらった後は、足りなかった観点などリーダーが補足してあげたり、こういう観点もあるよねといった話をメンバー同士でしてもらいます。
よかった点
・考慮が足りなかったところがわかりやすい
全員自力で作成してくるので、勉強会当日の他の人の観点を見た時に、どこの考慮が足りなかったのかがわかりやすいです。
・ほぼ完成系のテスト設計書が出来上がる
完成したものを持ち寄っているため、勉強会が終わった後はみんなの良かったところを合体させるだけで完成させることができました。
良くなかった点
・勉強会までにテスト設計をする工数がかかる
勉強会までにテスト設計書を全員が完成させている必要があるため、開催までの間に作成工数がかかります。
同じテーマの設計書が人数分出来上がるため、コスパが悪い
この課題に関しては、事前に作成する箇所を絞ったり、設計する範囲を限定したりするなどの工夫が必要だと感じました。
共同作成形式
マインドマップをメンバー全員で議論しながら作成する方式です。いわゆるモブワークです。
リーダーが会議の進行と記録を担当し、メンバーと会話しながら、協力して一つのマインドマップを作成していきます。
マインドマップの作成が完了したら、リーダーからたりなかった観点の補足や、この観点が出たのは良かったなどコメントをして終了です。
よかった点
・準備が不要
宿題形式とは異なり、事前の準備が不要です。
そのため勉強会当日の工数以外は定常のテスト活動に時間を充てることができました。
・メンバー同士のコミュニケーションが活発になる
「あれが必要」「これはいらない」など考えていることを言語化して議論する時間が生まれました。
思いついたこと、考えていることをリアルタイムに言葉にすることで他メンバーの考え方が伝わりやすいと感じました。特に経験豊富なリーダーの考え方が聞けるので、とても参考になりました。
また、経験の浅いメンバーならではの新鮮な観点や意見も聞くことができ、チーム全体で品質に対する意識が高まりました。
良くなかった点
・完成まで持っていくには時間がかかる
議論に時間がかかる分、方針を完成形までもっていくには勉強会自体の時間が多く必要になります。
一部の機能に絞って作成したり、1時間で勉強会を区切って複数回実施するなど、工夫する必要があると思います。
・人によって発言の量に差が出る
経験の豊富なメンバーは自然と発言が多くなり、経験の少ないメンバーは発言が少なくなる傾向があります。また、個人の性格によっても発言の量には差が生まれることがあります。
進行をつとめる人が発言の少ない人へ意見を促したり、質問してみるなどある程度コントロールする必要があると感じました。
ペア設計形式
ペアプログラミングのように、2人1組で設計を行うペア設計
2人1組のチームを作って、話し合いながらテスト設計をしてもらう形式です。
時間を決めて自由に作ってもらい、最後にチームごとに発表してもらいます。
発表の後は、他の形式と同じようにリーダーからコメントしたり、メンバー同士で会話してもらいます。
私のチームは5名なので、2つのペアを作ることができます。
経験の長いメンバーと短いメンバー同士でチームを組んでもらい、私は話し合いの間1人でテスト観点を考えてメモ帳に記載していました。
発表後はそのメモを見ながらコメントをして終了です。
よかった点
・2人なので話しやすい
全員で行う会議形式とは異なり、2人で話し合うので発言のハードルが下がります。
そのため会議という場での発言が苦手な人でも積極的に参加することができます。
2人で対等に意見交換しながら設計を進めることができることが良いと感じました。
・ペアとなったお互いにメリットがある
経験の浅いメンバーは、経験豊富なメンバーから直接指導やアドバイスを受けることができます。
経験豊富なメンバーは、自分の知識や経験を共有することで、指導力やコミュニケーション能力を高めることができます。
良くなかった点
・設計に充てる時間がより少なくなる
話し合いの時間にプラスして、発表・共有の時間が加わるため、設計に充てる時間がより短くなってしまいました。そのため非常に狭い範囲の設計書しか作成することができませんでした。
この形式で行う場合は、設計するスコープを絞り、テスト対象のうち一つの画面のみにしたり、時間配分を決めてタイムキープするなど工夫する必要があると思いました。
まとめ
3つの形式をご紹介しましたが、それぞれにメリット・デメリットがありました
どの形式にもメリット・デメリットがあり、チームの特性に合ったものを選択していく必要があります。
例えば、比較的時間に余裕がある場合は宿題形式がやりやすいですし、メンバーのスキルや経験値に差がある場合はペア設計にして成長を促すなど
| 形式 | メリット | デメリット | 適したチーム |
|---|---|---|---|
| 宿題形式 | 多くの成果物と比較できる | 準備に時間がかかる | 時間に余裕があるチーム |
| 共同作成形式 | 準備が不要、コミュニケーションが活発化 | 発言を促すなどの工夫が必要 | チーム全体で議論したいチーム |
| ペア設計形式 | 相互に成長できる | 設計に充てる時間が少ない | メンバーのスキルに差があるチーム |
勉強会を通して、実際にチームに変化がありました
・勉強会で知った観点を、次回1人でテスト設計をするときに取り入れられた
・品質に対する意識が高まり、リリース後の振り返り会で、メンバーからまた勉強会をやりたいといった声をもらった
今後も勉強会については実施する予定で、形式について状況に合わせて選択していく予定です。
また、今回ご紹介した形式に限らず、新しいものがあれば挑戦してみたいと思っています。
日々の業務の中で時間を捻出するのは難しいと思います。
ですが、こういった勉強会という活動によって、少し遠回りになるかもしれないですが日々の業務を効率化していくことができるのかなと思っています。
Discussion