126. テストプロセス その⑧
さて、テスト実装です。
テスト実装では、テスト設計でハイレベルテストケース（具体的な数値などではないテストケース）をローレベルテストケース（具体的な数値などが決められたテストケース）に落としていきます。
あとは、マンガでも描いたように「テスト実行のために必要な準備を全部やっておく」プロセスです。
作者の経験上、テスト環境の準備やテストデータの準備なんかは早め早めに着手した方がいいことが多かったです。
開発者に依頼する必要があることがあったりするんですよね。
ギリギリに言うと向こうが困ることもしばしば。（大抵は「いえいえ、大丈夫ですよー」って返ってくるけど、無理させてる場合も結構ある）
他にもテストで使うツールの準備、テスト管理ツールの準備、新しく入ってきたメンバーの初期教育（テスト入る前までに基本的なアプリの知識をつけておいてもらう）みたいなこともありますね。
テストデータの準備の自動化は費用対効果が高いことが多かった
作者がweb系App系ゲーム系を周ってきてるからかもですが、大量のデータが必要だったり、特殊な状態のデータがリストが最大になるまで必要だったり……そんなことが多かったです。
これ、手で作ってるとつらいのです。。。
単純作業の連続ほど疲労するし、時間と共に効率が落ちるし大変です。
それらが単純作業であればあるほど、自動化できたりします。
そして効果が大きいです。
大層なツールを使わなくても、スプレッドシートでGASを使ってできたりとか、E2E自動テストツールの使う練習の一環として、といった感じで作れることが多かったです。
作業時間が圧倒的に縮みます。
たとえば、記事100件作る。
たとえば、キャラ100体作る。
これがサクッとできた日には感動すらします(笑)
作者は、メンバーが強いならテストケースの粒度が荒い場合もよくある
と、いうとエライ人から「どういうテストしたかわからなくなる！」「証跡として意味をなさない！」と怒られそうなわけですが、メンバーのスキルが高い場合、作者はよくやります。
その場合、テスト実行時にメンバーはテストの項目ひとつひとつをテストチャーターとして簡易的な探索的テストをします。
前提条件をガッチリ決めた時よりバグを見つけてもらえることがよくありました。
（ちなみに作者がつくるテストケースには「テストの意図（何をテストしたい項目なのか）」というはほぼ必ず書いている）
では全部のケースが粗いのかというとそんな風にもならず、単純なケースは粒度粗く、パターン分けが必要でしっかりと確認したい場合はパラメーター設計を細かく……と考えることも重要です。
あともう一つのメリットとして、作者もずっとテスターもやっているのですが、値までしっかり決まっていると「作業感」が妙に強いのですよね。
遊びがないといいいますか、淡々としているというのか、「目標をセンターに入れてスイッチ」というのか……。
それが本来は正解なのですが、メンバーのモチベが下がることもあります。
もちろんデメリットもあります。
先に書いたように、エライ人が言うようなことが発生します。
何で確認したのかが追えなくなります。
本番障害が出たときにテスト項目がPassになっていることもあるわけです。
それに、テストのスキルが浅い人がそのテストケースを実行する場合もアウトです。
「～に入力」みたいなケースがあった場合、慣れた人ならHTMLタグから長文、絵文字、空文字、改行のみなど色々試しますが、テストスキルが浅い人だと「あ」といれるか「てすと」と入れて終わります。
（ついでにいうと開発者がテストするとなぜか"test"しかいれない人が多い気がする）
