自動テストは書いてあることしかテストしない
現在、株式会社STORYで、MagicPodを使って自動テストをしています。
テスト自動化研究会 - テスト自動化の8原則 (google.com)に、書いてあることしかテストしないという記述があります。
MagicPodで作成するテストステップは、画面に表示されるテスト対象に対して、ある操作を行なって、その結果が現れたことを検証する仕様で作成します。
この画面が、表示させる度に変わるような場合、あまり自動テストには向いていないといった評価がされることが多いですが、どうしても対象となるサービスや機能が、そのビジネスで重要な場合、且つ、人力でテストするには、操作と確認の手間が現実的では無いと判断した時、なにがなんでも自動テストを実装することになります。
自動出題と採点を自動テストする
株式会社STORYで提供しているサービスの1つに、コベツバくんというのがあり、（募集ページからの引用）学習成果を確認するためのテストが出題され、提出後に自動採点され、いくつかの分野に対する自分の強み / 弱みを視覚化しています。この時出題されるテストは、サービスを利用する度に違う出題がされて、利用者は毎回、違うテストに取り組んでは回答して採点されて、あたかも本試験さながらの真剣勝負を体験する機会を提供しているとも言えます。
ただ、これを自動テストするというのは、テスト実行都度、毎回異なるテスト対象を扱わなければならないため、自動化には向かないというのが一般的な考え方になるかと思います。
手動テストで行なわれている実態の把握と自動テストの目的の明確化
テストが手動か自動かに関わらず、まず、テストが目指すべきことを、サービスに対する知見を深めることで、何がサービスの品質保証の胆なのか、現状把握を開発者と数回にわたって1時間程度のミーティングを通じて行ないました。こちらから叩き台となる、ユーザーストーリーマッピングや状態遷移図を示して、レビューいただき、自動化にあたっての障壁について意見交換することができました。自動生成される出題についても、出題前の操作に応じて、ある程度の出題リストからの候補となり、無限では無いことがわかってきました。
現実的なテスト実装量が見えてきたとしても、やはり実装に際して初期コストは無視できません。ユーザーが、コベツバくんに取り組むことで得られることを、もう少し追加調査しました。自動採点された結果が視覚化されること以外に、取り組んだ結果、武器と呼んでいるアイテムを獲得したり失ったりする体験がサービスの特徴としてあります。ここは、学習する上でのモチベーション向上としての価値がある部分です。視覚化と並んで、品質保証の胆は、ココだ！ とふんで、いざ実装です。
MagicPodを使って、失敗ファーストでテスト実装する
自動出題される画面は、実際にはいろいろな画面要素が混在していて、単純にテキストボックスに値を入力してSubmitするといったものではありませんでした。この時に助かるのがMagicPodの失敗時の画面解析機能です。出題される画面はテストの都度異なる画面なのですが、とりあえずフワっと作成したテストステップでテスト失敗させ、自動解析された画面でテストステップを修正して、少しずつ出題リストの候補に対して失敗しなくなるまで繰り返しテスト実行と修正を行なっていきました。
テストファーストのプラクティスで聞いた事がありましたが、まずFailになるテストコードを書いて、Failになってから、Successになるように実装コードを書いていくというのに、ちょっと近いものを感じます。
MagicPodの恩恵に因るところが大きいですが、失敗しても、次は前に進めることを信じて、テスト実装もできると思います。
総括
自動テストを実装するのは、とても大変な作業でもあり、一方で、進めていく上でビジネスへの理解を深めていける楽しい時間でもあります。なんだかできそうも無いことを一人で悩んでいるような気がしてくる時もあります。どこの開発現場も課題が山積みですが、同時に、解決策も積まれていることが多いです。
最初から完璧なQA活動を展開できるとは、誰も思っていないでしょう。ヘンテコな叩き台（叩かれ台？）を提示されて、開発者が困惑することもあるかもしれませんね。
失敗ファーストで取り組んで、段々と精度を上げていくのが現実的なQA活動・テスト実装かと思います。
