127. テストプロセス その⑨
さて、テスト実行です。
テスト実行では、今まで準備してきたことを進めていきます。
語ることも多くはありませんので、作者の経験の話を書いておきます。
作者はWeb系App系ゲーム系なわけですが、システムテストのテスト期間はおおよそ3日程度、長くて5日くらいが多い印象です。
大変だったのはゲームでした。
イベントが週替わりで回っていまして、システムテストの期間は3日間、テストケース数は1万件くらいでした。ガ〇ダムなゲームで、ステータスの反映など確認がかなりありました。テスト実行も大変でしたが項目を作るのも大変だったことを覚えていますｗ
（イベント一つずつにQA担当者1名、テスターは25名くらいの体制）
ゲームもアプリも期間も短くやることも多いですから、とにかく事前準備が命。
そこがミスっていると、もう取り返しがつかない状態に陥ったりするわけです。
さらに計画してたからといってそれ通り進むかというとそうもいかず、リーダーをやっていた時は毎朝「今日はこういう風に攻めていって、誰々さんと誰々さんにはこれを任せて、もしこうなった時はこっちの計画に移して……」と考えながら会社に通ってました。ちょっとした軍師気分ですねｗ
CPM法
コピー＆ペースト＆モディファイ法の略称です。
簡単に言えば仕様書のコピペです。
例えば仕様書に「メールを送信できる」とあった場合、「メールを送信できることを確認」と書き換えてテストの項目を作る方法です。
これは根底に「仕様通り動きさえすればオッケーだろう」思考があります。
作者が回ってきた限りですとこの現場は非常に多く、なにが悪いかもわからない人も多いかもしれません。
例を出すとしたら……
仕様書
「年齢に数字を入力すると、プロフィールページに反映される。数字以外の場合はエラーが発生」
これからテストの項目を作ると……
* 年齢に数字を入力し、プロフィール欄に遷移する→期待結果：プロフィール欄に入力した数字が反映されている
* 年齢に数字以外を入力する→期待結果：エラーが発生する
こんな感じでしょうか。
数字といっても、整数なのか、小数は許容なのか、inputboxでnumberのみの制限にしててもeは入るけどどうなる、などなど考えられます。
また、数字以外の文字も、全角の数字はどうなるのか、改行文字、スペース、そもそもnull(空白)の場合はどうなる……ということがあります。
あとは、エラーメッセージは何さ……などもあるでしょうかｗ
実は仕様書に全てを書く、ということはないのです。（現実的でもない）
そのようなわけで、上記のテスト項目では、先に挙げたようなパラメーターのテストは行われません。
前回のブログでも書きましたが、テストが不慣れな人がテストする場合、数字を試すなら1だけ入れて確認、数字以外の場合はaだけ入れて確認してOKとなるでしょう。
そんな変な入力する人はいない、という方もいますが、ターゲットにもよります。
ユーザーが1万人いれば、何かしらする人はいるわけです。
これは、テスト分析やテスト設計が全く考えられていない状態です。
仕様書をなぞればオッケーだろう思考になっていますので、もし自分がいる現場がこんな感じなら「他にテストした方がいいことはないんだっけ？」を考えるのがよいでしょう。
その昔、開発者ばかりの現場ではこれを見せました
前の現場では、テストは実装通り動くか確認する、仕様通り動くか確認する、といった認識でした。
Unit testは確かにその通りなのですが、プロダクト全体をテストするとしたらその考えのままだと本番でバグが出ます。
理由はシンプルで、バグを探すテストをしないから本番でバグが見つかるわけです。
とりあえずSpeaker Deckにあげておきます。
テストがあまり浸透していない状態の開発者向けの資料ですから「まずは考えよう」くらいの話しか書いていないですｗ
