学園祭の話とテスト自動化の導入
皆さん、こんにちは。B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャ
スト番組です。
今年もですね、学園祭のシーズンに入ってきましたね。 子供がちょっと鉄道好きっていうのもあってですね、私は様々な大学の学園祭に参加してですね、
主に鉄道研究会とかが展示しているプラレールとかNゲージを子供と一緒に行って、1日中見るみたいなことを、この学園祭シーズンの土日は結構やっています。
最近行ったところで、すごい印象深かったところとしてですね、あの提供大学の学園祭ですね、製車祭と読むんですかね。
青に紅車の車の祭りで製車祭ですかね。 ここ良かったのは、もちろん鉄道研究会の展示があったっていうのもそうなんですけれども、
それ以外にもですね、サンリオのキャラクターショーがあってですね、 自分が行った時はクロミちゃんですね、キャラクターショーおよびグリーティングが無料で行われてました。
まあおそらくこれ大学自体が多摩沿線にあるっていうところで、やっぱりサンリオピュロランドが近いっていうところ、その辺からかなと思っています。
今回はですね、本編としてはテスト自動化のピラミッドについてちょっと話していきたいと思います。
ということで今回もbtesting.fmスタートです。
テスト自動化のピラミッドと3層分類
ということで今回はテスト自動化のピラミッドについてです。
テスト自動化のピラミッドって何かっていう話をする前にですね、そもそもテスト自動化および自動テストですね。
まずどんな種類があるのかっていう話から話していきます。
いろいろな分け方はあると思うんですけれども、特にこの後話すテスト自動化のピラミッドの話をするときによく分けられる表現としてですね。
UIテストの自動化と、あとはサービスレベルのテストの自動化、特にAPIとかがそこに当たります。
あとはユニットテストの自動化っていうふうにUIサービスユニットっていう3つに分けて分類するみたいなことがあったりします。
この3つをどのように作ればいいのかっていうことを考えるときによく使われる考え方概念としてテスト自動化のピラミッドっていうのがあります。
いくつか有名な画像とかはあるんですけれども、自分がよく使うのはマーティンファイラー.コムで書かれているテスト自動化のピラミッドの図をよく使います。
その図はですね、UIサービスユニットが三角形で表現されていまして、UIのところに亀の絵が書かれていて、ユニットのところにうさぎの絵が書かれている。
UIのところがすごいドルマークがいっぱい書かれている。一方でユニットのところはドルではなくてセントですね、の記号が書かれている。
そんなテスト自動化のピラミッドがあります。これは何を表現しているかというとですね、まずUIのところに亀が書かれていますが、
これはUIになればなるほど実行が遅いよっていうのを表現しています。一方でユニットレベルのところにうさぎの絵が書いているのは、ユニットは素早く動くことができるよっていうのを表現しています。
あとお金マークのところのUIのところにドルマークがいっぱいあるのは何かというと、これはUIになればなるほど実行なりその他も含めてコストがかかるよというのを表現しています。
一方でユニットテスト自体にはコストは少ないよっていうのを表現しています。
UIテストが遅く高コストになる理由
じゃあ実際になんでUIって実行が遅いとかコストがかかるのかっていう話なんですけれども、一つちょっと考えてみましょう。
テストを実行したときにですね、ログインページを表示してユーザーネームとパスワードを入力して、それを入力した後ログイン後のページを表示して、よしこれで表示できたからOKっていうようなそういうテスト、UI
の自動テストがあったとします。
これって実際に行ってみるとどうなるかっていうと、まずセリニウム770のUIの自動テストのツールから実行を行う。
そうするとブラウザーを立ち上げて、ブラウザーが立ち上がるまで待って、所定のページが出てきて、所定のページが出てきたらユーザーネームとパスワードを自動的に入力をしていって、ログインのボタンを押すと。
ログインのボタンを押したら、その後ログインページが遷移するまで待って、遷移されたらそのページがちゃんと正しいかを見る、みたいなこういうことをするわけですね。
これってもちろん物にはよるんですけれども、テストの実行してブラウザーを立ち上げるとか、そういうところから見ると、この一つのケースをやるだけで約1分ぐらいかかるっていうことがあったりします。
これ一ケースだけだったら1分でいいんですけれども、それをすごいいろいろなバリエーション、例えばユーザーネームにこういうのを入れたらとか、パスワードが間違っているものを入れたらとか、ユーザーネームを空に
して入れたら、パスワードを空にして入れたらとか、いろいろなパターンをやると一つのケースで1分で済むんですけれども、
これはいろいろなパターンで100ケースやったら、それだけで約100分かかっちゃうわけですよね。
そうすると、じゃあ何かものを作りました。これでちゃんと動くかどうかを確認するために毎度毎度このUIの自動テストを回していると、これちゃんとコードとして組みとしていいかどうか判断するのが100分かか
ります。
っていうふうになってしまったら、大変ですよねと。それずっと待っているんですかという話になるわけですよ。それがUIの部分が亀で表現している話です。
一方でユニットのところをウサギで表現していますけど、ユニットテストって一回一つのケースを回すのってもう1秒かからなかったりするわけですよね。
なので、単純なそういうパターンのものとかであれば、ユニットテストを使って表現するっていうのも検討するといいかなと思います。
失敗原因の分析と8原則
もう一つお金マークの話がありました。UIの場合はコストがかかるよっていう話なんですけれども、これは何を言っているかというとですね。
例えばECサイトの例を考えてみましょうと。例えば500円の商品Aをカートに入れて、その後600円の別の商品Bをカートに入れました。
その後レジに進むボタンを押しました。その結果合計金額が1100円になるよっていう期待値を持っていたんだけれども、そういうふうにはならなかったからUIの自動テストとして失敗しました。
っていうものがあったとします。じゃあこれってどうして失敗したのかっていうのを考えるといろいろ考えられるわけですよね。
例えば500円たし600円が1100円になるよっていう計算ロジックが間違っていて、ちゃんと1100円って計算されなかった可能性もありますし、
あとは商品Aを入れた後に別の商品Bを入れたはずなんだけれども、商品Aで上書きされてしまっていて、その結果500円たす500円で1000円として計算されていて、1100円っていう期待値に合わなかった
みたいになっている可能性もあります。
また実際にUIの自動テストをやるときは何かしらの環境を立ち上げている必要があるので、そのテストをするための環境に、例えば1000円以上購入した場合100円引きですよっていう設定が入っていて、その結果
500円たす600円で1100円の100円引きで1000円です。
じゃあ1100円にはなってないねっていうのでテストが失敗と判断されたかもしれません。またそもそもレジに住むのボタンを押したときの住む先のページに遷移ができなかった。遷移ができなかったってことは合計金額
が1100円っていう文字列もそのページ内になかったっていうこととしてテストはNGになるみたいにそういう風になっている可能性もあります。
今パッと4つこういうことあるんじゃないかなって紹介しましたが他にもいろいろ絶対あると思うんですよね。これは何を言ってるかっていうとUIの自動テストをやるとテストが失敗したときの原因の特定にコストがかか
っちゃうわけですよね。
これはUIのコストが高いっていう話の具体的な例かなと思っています。もちろん最近ではUIの自動テストで失敗したときにその実行して失敗するまでの動画をちゃんと記録しておいてそれを送るっていうことをすること
によってテストが失敗したときにじゃあそれって何だったのかっていうのを動画を見ながら人間が判断するみたいなことはできるんですけれども。
それでもやっぱりコストが高いんですよね。一方でユニットテストの場合だと例えば500円たす600円が1100円っていうところの計算部分が合ってるかっていうところは計算部分のロジックで見るのでそれ以外の
失敗の要素はあんまり出てこないわけですよね。
一つ参考としてテスト自動化研究会というのが日本にあるコミュニティとしてあるんですがそこのテスト自動化研究会がテスト自動化の8原則というのを考案しています。
その8原則の8つ目にテスト結果分析という新たなタスクが生まれると書かれています。これがまさに先ほど言った話になります。
理想的なテスト比率と使い分け
なのでUIの自動テストだとテスト結果分析なりのコストがかかる。そしてもちろん実行するのにも時間がかかるっていうところがあるので自動テストをやるときにはUIっていうのはあまり多くしない方がいいんじゃない
かっていうふうに言われています。
ここで出てくるのが最初に言ったテスト自動化のピラミッドです。テスト自動化のピラミッドっていうのは要は三角形の形をしてましてUIの部分が一番面積として小さいところに表現していましてサービスユニットでユニ
ットが一番大きい面積を占めているっていうのを図で書いているんですが。
これは何かっていうとさっき言ったコストがかかったりとか実行の時間がかかるっていう話がデメリットとして大きいのでできるだけ自動テストをやるときにはUIは少なくしましょうと。UIのテストケース少なくし
ましょうと。一方でユニットテストは数を多くしましょうっていうふうに経験則としてよく言われています。
具体的な例として今はちょっといろいろ事情が違うんですけれども、すごい昔のGoogleの場合ですとこのUIとサービスとユニットのテストが1対2対7で作られる。それぐらいのテストケースの割合で作ったほうが
いいんじゃないかっていうのを発信していた時期もありました。
ということで、このテスト自動化のピラミッド、今回は紹介してきましたが、コストがかかるかからない、実行の時間が早い、結構時間がかかる、そういうような要因からUIをできるだけ少なく、ユニットのところで
ちゃんとカバーできるんだったらユニットテストでやったほうがいいよという話をしてきました。
エンディング
ではエンディングです。 btesting.fmではリスナーさんからのお便りを募集しています。エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。投稿フォームは番組概
要欄にあります。またエピソードの感想は、ハッシュタグBテスティング、BアンスコテスティングでXのポストもお願いいたします。
今回の話です。テスト自動化のピラミッドについて話してきました。もともとテスト自動化のピラミッドを知っていたよっていう人もいれば、聞いたことあったけど、それってこういう意味だったんだ、初めて聞いた
とか、そういう人もいるかもしれません。ぜひそんな簡単な感想でも構わないので、ぜひエピソードの感想あったらポストをお願いしたいなと思っています。
もしもこれからも聞きたいという方は、お手持ちのPodcastアプリで番組のフォローもお願いします。最新回が上がった時にすぐに気づけます。
今はですね、だいたい毎週月曜日の朝に最新回を上げているんですけれども、特に今日の場合ですとですね、ちょうど飛びし連休の中日に入っていて、気づかなかったみたいなそういうことがあったりするかもしれません
ので、ぜひフォローをお願いしたいなと思っています。そうすればすぐに気づけると思うので、ぜひよろしくお願いします。
はい、ということで今回はここまでです。それではまた次回。バイバイ。
バイバイ。