本記事はゲームのソフトウェア品質向上アドベントカレンダーの6日目の記事として執筆しています。
属人化したテストケースって？
ゲームのQAを担当していると、こんな感じのテストケースを見ることがないでしょうか。
このようなテスト実施手順では、確認者に次のような条件がつきます。
- 管理ツールからイベントのランキング報酬を確認する方法がわかること
- 報酬の数を見て問題の有無にあたりがつくこと
熟練のテスターぞろいのチームであれば全員が上記の条件を理解しているかもしれませんが、そこに新規の人員が加わった場合、
テストケースを見ただけではテストをできない状態が生じてしまいます。
このような、確認者がある程度前提を理解している前提で作られたテストケースは、属人化した状態にあると言えます。
属人化したテストケースの問題点
では、テストケースが属人化すると何が良くないのでしょうか？
パッと思いつく限りでも、以下のようなデメリットが考えられます。
- 担当者不在時の支障
- 不慣れな巻取り者のミス
- 問題が発覚しにくい環境
1.担当者不在時の支障
ここは単純で、いつも担当している（＝属人化している内容を理解している）人が不在の時は、その人の業務はストップしてしまいます。
計画的な休暇など、予め担当者が居ないことが分かっているならばまだしも、急病による当日欠勤や、最悪の場合だと担当者が急に退職してしまった場合など、業務への大きな影響が考えられます。
2.不慣れな巻取り者のミス
これは1.担当者不在時の支障に関連するデメリットですが、いつもの担当者が不在の時、急遽対応の必要が生じてしまった場合は、作業に慣れていない誰かが巻き取って対応する必要が出るケースもあるでしょう。
属人化したテストケースだと、実施手順はあらかじめわかっている前提で作られているので、このような場合細部の見落としや認識の相違などで、障害が発生するリスクが高くなります。
ここで注意すべきなのは、担当者が不在の時だけでなく、キャパオーバーを起こしているときにも他者の巻取りは発生する場合があるということです。
その際、担当者はたとえ近くにいても、巻取り者の疑問や不手際に確実な対処をとれるわけではないので、不在時とリスクの大きさにそう大差はありません。
3.問題が発覚しにくい環境
テストケースが属人化していると、客観的なテストの実施状況がわかりにくくなります。
たとえ百戦錬磨の担当者でも時にミスを起こすことはあるはずですが、テストの詳細な内容や要点は他の人からはわかりにくいので、ミスを指摘することも同様に難しくなります。
また、あってはいけないことですが、担当者が意図的にミスを隠すことも容易になってしまいます。
このように、テストケースの属人化は、組織にとって望ましくないと言えます。
元インフラSEから見た属人化の排除
私は前職でインフラSEをしていましたが、例えば毎日深夜2時にサーバの保守作業をしなければいけない時、
SEがその時間に出社するのは非現実的なので、交代制で24時間365日サーバを監視してくれているオペレーターの方に作業を依頼するのが普通でした。
その際のフローを基に、テストケース属人化排除のアプローチを考えてみようと思います。
作業者が未経験者と想定する
オペレーターはチームとしていくつものお客さまの環境を監視しなければならないので、基本的には専任の担当は置けず、あらゆる作業を誰もが行う可能性があります。
また人の入れ替わりも激しいので、不慣れな作業者というのも往々にして出てきます。
SEが作業を依頼するときにも、そのことを念頭に置いた手順を作成する必要があります。
もし、上で例示した報酬の確認手順をオペレーターさんに依頼する場合、以下のような粒度になります。
ここまでの粒度で作り込めば、どんなに経験が浅い人でも報酬画面にたどり着き、内容の妥当性を判断することができるでしょう。
テスターさん向けのテスト手順においてここまでの粒度で作成する必要はないと思いますが、以下のように最低限確認箇所、比較対象、判断基準くらいは書いておけば、属人系の薄いテストケースに近づくと思います。
テストケース作成者がテスト手順を理解する
ここは私自身結構ギャップを感じた点なのですが、テストケース作成の際、作成者はあくまで設計（≒観点出し）を行い、
詳細な確認方法はテスターさん、よしなにやってね、というのが割と一般的ということがあります。
この構造は作業を分担できているという点ではすごくいいことなのですが、テスターさんがよしなに対応した確認方法を設計者が理解できない場合、属人化していたり、そもそも認識の齟齬があった際に検知できないことが問題です。
最低限、テスターさんが自分が作ったテストケースを使ってどのように検証を行ったかは理解し、手順の記載方法や確認内容に問題があるかどうかは追えるようにしておくべきだと思います。
まとめ
業務システムのオペレーターさんはルール上、書かれていないことはやってはいけない、わからなかったら夜中だろうが何だろうが電話でSEを叩き起こして聞くことが徹底されているため、SEも必死で伝わる手順を作成します。
オペレーターさんを貶めるわけではないのですが、ゲームQAのテスターさんはかなりアバウトでもなんとかしてくれることが多いので、QAエンジニア側は甘えやすい構造になってしまっているのではないかなと思いました。
今一度現場のテスターさんの努力に感謝し、QAエンジニアとしてプライドを持って仕事をしていきたいと思います！