『テスト担当者を悩ませる、10の難題克服法』 その10

完走まであと少し！

テスト担当者を悩ませる、10の難題克服法

10章 難題第3位 動いている的を射ること

僕が日々携わっているゲームのQAは、まさに、動いている的を射る仕事である。

テスト期間に入っても仕様が固まらないなど、日常茶飯事だ。外部要因だと、プラットフォームのOSのバージョンが変わったり、新しいハードが出たり、ガイドラインの変更があったり、ミドルウェアのアップデートがあったりと、変化の要素には事欠かない。

まずゲームなので、仕様変更はしょうがない。「最初の案より、こっちのほうが面白い」と判断したなら、そうした方がきっと良いゲームになる。そして、仕様を変更が入った場合は、ちゃんとそのリスクを伝えるのがQAの仕事である。ここで何も発言せずにいると、無茶なスケジュール組まれて残業地獄となるか、不十分なテストでリリースせざるを得ない状況となり、障害のリスク(と責任)を負わされるかもしれない。

外部要因への対処は、回帰テストが中心となる。ただ、回帰テストはテスターにとっては退屈な仕事の一つなので、ただ、テストケースを消化するだけではなく、なにかしらのゲーム要素を取り入れたほうが、テストの質は上がる気がしてます(消化速度だとテストがおざなりになるので、見つけた不具合数とかの方が効果的)。

あとは、なるべく無駄な項目を削るために(ボリュームの多い回帰テストほど、テスターのやる気を削ぐものはない…)、回帰テストのテスト項目には優先度をつけたり、影響範囲を把握するためにコンポーネントの関連図を用意しておくのも効果的。

ゲームのQAをやるならば、変化に文句を言ってはいけません。変化を許容し、変化によるリスクを正確に伝えるように心がけたいものです。

以下メモ

・過去においては、「要求の変化をいかにして抑えるか」が問題であったが、今となっては、「変化する要求に如何に対処するか」が問題である。

・変更には、回避不可避なものと回避可能なものが混在している

・変化は避けられないのであるから、変化に驚くよりも、むしろ変化を計算に入れるべきである

・テストの目的は一連の固定的な基準に基づいて、何かを評価することである。

・変更を許容するのでも記録するのでもなく、管理すべし

・回帰テストを実行するには、正確性が求められる(なので、自動化が望ましい)