はじめに
HRBrainでQAエンジニアをしているOです。
今回は、QAチーム全体のテスト設計スキル向上を目的に 「レビュー会をしてみよう！」 という取り組みがあったので、やってみてどうだったかについて書きたいと思います。
一言にテスト設計と言っても、スキルや経験による品質のバラツキや属人化、更に言ってしまうと個人の「センス」によるものも大きく影響している部分もあるのではないでしょうか。
個々に依存しない体制づくり、そしてQAチーム全体のスキルの底上げを目的にレビュー会を行ったので、どう有益だったのか、また課題点について書こうと思います。
レビュー会の目的と構成
１.目的
- QAチーム全体のテスト設計スキル向上
- QAテスト観点の過不足を削減して開発スピードUP
２.時間
- 30分
３.対象メンバー
今回はテスト設計者のみを対象に行いました
（※各メンバーが受け持っているプロダクトは別々）
４.メンバーのスキル感
QAエンジニア歴が1〜5年未満、または6年以上と様々で、元情シスや、一度QAに就き別の仕事を経てまたQA職に戻ってきたメンバーなど、バックグラウンドも様々。
５.心構え
- テストケースに厳しく、人に優しく
- 指摘数とその人のスキルや能力は比例しないことを忘れない
（※指摘が多い＝その人の能力やスキルが低い ということではない）
６.人数
8人程度(タスク状況により変動)
７.開催頻度
とりあえず皆一巡することを目的として、その後は不定期開催
このような感じでお試し的に開催しました。
では、どんな点が有益だったかについて書いていきます。
有益だったこと
- 普段接点のないメンバーがどんな風に観点出しやテスト設計しているのか知る事ができる
- 理解不足が洗い出せる
- ナレッジシェアの場となる
これだけ見ると「普段行っているレビューとあまり変わらないじゃん！」と思われるかもしれませんが、一度に多数のメンバーに見てもらう事でより多角的な視点が集まるという点で違いがあります。
普段接点のないメンバーがどんな風に観点出しや・テスト設計しているのか知る事ができる
レビュー会の一番の醍醐味だと思います。
最初に述べた通り、テスト設計はメンバーのスキルや経験によるバラつきがどうしても出ます。経験が浅かったりすると網羅性を重視し過ぎて冗長なケースになりがちですが、スキルや経験が豊富だとリスクベースで効率よくケース作成するのが上手いです。スケジュールが逼迫しているとリスクベースでの設計スキルが顕著に出るのではないでしょうか。
レビュー会でも、「最低限このパターンを見れば担保できるので、他パターンは極力削っている」、「ここの境界値が前後していてもお客様的に困らない、かつ実施コスパが悪いのでしない」など、ケースの削り方の考え方に「なるほど〜！」となりました。
また、仕様のまとめ方や可視化が上手かったり、表現がわかりやすい、独自の追求したフォーマットでケース作成しているなど、それぞれの個性が結構出るのでそこに触れられるのもまた非常に勉強になります。
このような点からも、普段レビューし合わないメンバーのテスト設計に触れることは非常に新鮮で勉強になります。
仕様の理解が深まる
「この場合の挙動は？」「ここも考慮した方がいいかも」など、複数のメンバーから多角的に質問が来るので、理解不足の洗い出しや理解を深めることができます。
特に私が有益と感じたのは、まだ開発途中で仕様変更がありそうなものや揺れているものなど、仕様が確定しきれていないものをあえてレビュー対象にした事です。今回私がレビュー対象にしたのは開発途中の時系列を扱う機能で、考慮漏れなどないか見てもらったところ、
「この説明文言矛盾してない？」
「これってこっちのプロダクトにも影響ありそう」
「この場合はどの時点の値を参照するの？」
などと、自分の理解不足の洗い出しに加え、影響範囲の考慮漏れやUI観点についても話し合う事が出来ました。時系列関連は過去の値や未来の値を扱うので絡む機能が多く影響範囲が広いので、多角的なレビューを行えた事は非常に良かったです。
仕様に不確定要素があるからこそ考慮すべき観点や、曖昧だった重要なリスクエリアについても話し合うことができるので、複数のメンバーからレビューしてもらうことの有益さを非常に感じました。
ここで得た観点を上流工程に活用すれば、仕様の考慮漏れを防げたり、バグの作り込み防止ができる等、サービス品質向上に加えテスト工程での不正挙動調査やチケット起票の削減など、トータルのQA工数削減にも繋がります。
ナレッジシェアの場となる
他プロダクトに似たような機能があった場合は「うちではこんな事象があったからこういうとこに注意した方がいい」や、「こういう方法でテストすると効率がいい」などの知識や経験が共有されるので、個人に依存しがちな体制だとこのような場の有益性をより感じられるのではないでしょうか。
プロダクトにより独自の仕様や要件があるためシェアされた内容がそのまま使えるケースは少ないとは思いますが、観点出しの切り口など応用できる点は沢山あると思います。
また同じ機能でも人によって捉え方や重要視するポイントが異なるため、見逃しがちなエッジケースや、UI上の細かい不具合やユーザー目線の使いづらさについても議論できるなど、それぞれのメンバーならではの視点でも話し合う事ができとても面白いです。
レビュー会をするにあたり大切なこと
１.何を重点的に見てほしいかある程度明確にしておく
「この観点について不安なので重点的に見てほしい」と機能に絞り見て欲しいのか、「全体的に過不足ないか見て欲しい」など全体的な流れや網羅性を見てもらいたいのか、どういう視点でレビューしてほしいかをある程度明確にしておいた方が限られた時間を有効に使えると思います。
あとこれは私自身の話ですが、複雑な機能を対象にしたためその説明でほとんどの時間を使ってしまったので、レビュー会の時間をちゃんと考慮しつつ何をレビュー対象にするかも大切だと思いました。
２.レビュワーの心構え
最初にも述べましたが、 「テストケースに厳しく、人に優しく」 です。レビュー会を行うにあたりこれが一番大切かもしれません。
JSTQBシラバスにもあるテストの心構えの一つ「悲観的な視点を持つ」に似たものですが、あくまで目的はサービスの品質向上のためなので、「この観点抜けてない？」など テストケースに対しては厳しい目で見て、メンバーには敬意を払い優しい心で接しましょう。
発言しやすい環境づくりが大切なので、メンバーに向けた否定的、批判的な発言はメンバーの成長を妨げる要因にもなるので注意が必要です。
これは逆も同様で、「なんでそんなこと指摘するの？」という気持ちを持たず、レビュワーに対しても敬意を持ちましょう。
課題点
１.対象者の拡大
課題というか尚良し的なものですが、今回の参加対象はテスト設計者だったので、任意参加でテスターの参加もありかなと思いました。なぜかと言うと、ノウハウ共有やスキルアップという目的ならなおさらで、テストケース実施時に「この観点抜けてそう」「ここもう少し重点的にした方が良いかも」など、テスト設計者でなくても活かせる観点や考え方など沢山学べるものがあると思ったからです。
２.レビュー会を開催したことによる効果の計測
今回はとりあえずお試しで皆が一巡することを目的としたため、レビュー会がどのように効果があったかというのを計測するまでには至っていません。このレビュー会自体がQAチーム全体のスキルUPに有効なのか、もっと内容の工夫が必要なのか、はたまた「レビュー会」という形よりももっと他に良い方法があるのか。
目的はレビュー会の開催ではなくQAチームのスキルUPなので、そもそもの部分の検討も必要です。
最後に
このようなレビュー会を有益だったと感じる背景には、私自身のスキル不足は少なからず影響しているとは思いますが、普段他の方がどんな風に観点を出し、どこに重点を置き、どう設計しているのか気になっていたのでとても面白かったです。今後も他メンバーの成果物に触れて沢山吸収して、自身のスキルUPをしていきたいと思います。
是非、QAチームのコミュニケーションの場の一環としてもレビュー会を開催してみてはいかがでしょうか。
PR
株式会社HRBrainでは、一緒に働く仲間を募集しています！
興味を持っていただいた方はぜひ弊社の採用ページをご確認ください！
https://www.hrbrain.co.jp/recruit