TL;DR
テストピラミッドにあるように、単体テストの自動化対象を広げることで、手動テストの工数を減らすこと、そしてテスト環境(ex. 端末、OS)の見直しがテスト工数を減らすことには効果あると思う。
はじめに
なんもないのにいきなりどえらいE2Eテスト作る話を聞いて、うむ、となってまず単体テストの考え方/使い方から読み直す。 pic.twitter.com/wiaQ29nWMJ
— Masayuki Tanaka / 田中 優之 (@masayuki5160) 2024年6月5日
きっかけはE2Eテストの導入に苦労していて、という相談を受けた。それで、いろいろ聞いたら、そもそもやりたいことはテスト工数を減らすことだった。
なるほど、テスト工数を減らしたい、というモチベーションからそのままE2Eテスト導入、という流れになるのかー、と思ったが、気持ちはわからなくもない。最近はいろいろツールもあるし、他のとこでの事例も多く聞く。あと、やっぱなんとなくやった感あるから、その方向で進むのもなるほどと思った。
うまくいくならいいけど、愚直に今テスト作業者がしてるテストケースをE2Eテストにする作業をするのはまあ苦労するだろうなと思った。ある程度はうまくいくんだろうけど。
さて、そんならどうテスト工数て減らすのがいいのかなと改めて思ったのでまとめてみる。
なお、仕事柄GUIのあるアプリケーションというかモバイルアプリのテストよりの発想になってるのでその点ご注意いただき読んでいただきたい。
アイデア1: 手動テストケースの見直し
まずはこの辺りから見直すのがいいのかな。
- テスト環境
- 組み合わせを減らせないか
テスト環境については、例えばOSや利用するハードウェアの見直し。
モバイルアプリに関していえば、OSのサポートは毎年足切りされてはいくので、ここの見直しをすると減ることはあるはず。意外にこの辺を見直しすることが遅れてることはよくある。
あと、ハードウェア。特定のハードウェアだけで発生する事象があったりすると、その後テストケースでそのハードウェアを利用することで全て計画したりするだろう。改めて整理してみることは価値があるはず。検出してみたい不具合がどういうものなのか、それはプロダクトや事業にとってどういう影響があるのか、というバランスの議論。
品質という意味でいうともちろんテストできたらいいとは思うが全数テストは不可能なので、それを踏まえた議論をする。テスト分析ですね。
なお全数テストは不可能、という話はテストの原則であって、詳細は JSTQBが提供するシラバスにも記載があるのでご覧ください。元々の出典がどこだったかはちょっと忘れました。
テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01
アイデア2: 単体テスト、結合テストの自動化およびその対象の拡大
腰を据えてしっかりやるならこれかな。
テストピラミッドにあるように基本は単体テスト、統合テスト、そしてE2Eテストを積み重ねることが大事。テスト工数と言った場合、テスターの作業工数の話になると思うけども、減らすにしても減らし方が大切。テストでしっかり不具合を発見できる状態を維持しながら減らすとしたら、このテストピラミッドを意識したアプローチが必要になるんだろう。
ちなみにテストピラミッドについては前述のJSTQBシラバスにも記載があったがちょっと文字文字していた。僕はこの件を調べ出してからテストピラミッドのことをおさらいするために"単体テストの考え方/使い方"を読み直したんですが、以下twadaさんの説明がとてもわかりやすかった。相変わらずすごすぎる。
さて、だいぶ雑いサーベイで調べたら日立の方々が出していた論文を見つけた。日本語でしかサーベイしておらずなので、だいぶ調べが不足してるのだけども、この論文の課題設定は本記事で話題としてるテスト工数削減と一致する。
藤原貴之, and 岡本周之. "大規模組込み機器向けテスト自動化拡大方式." 情報処理学会論文誌コンシューマ・デバイス & システム (CDS) 4.4 (2014): 1-10.
ちょっと全部は読みきれないので、abstractと序文、そして論文中の図をいくつか見た限りの理解だと、
- 背景と課題設定：ソフトウェアの複雑さに伴い、テスト工数も膨れている。手作業のテスト工数を減らしたい。
- アプローチ：ソフトウェア内部にテスト実行エンジンなるものを用意して、外部からテストスクリプトを流すことで様々なソフトウェアの状態を作り出し、さらにログ出力を支援することでテスト工数を削減する
- 結果：提案方法によるテスト工数削減が可能であった
という話ぽい。おそらくE2Eテスト自動化を頑張ったというよりは、一歩手前のインテグレーションテストの自動化をなんとか独自エンジンを入れることで改善した、というところなのかなと読んだ。ちょっと自信ないけど多分そんなところなのかなと思う。
興味深かったこととして、システムテストの自動化(E2Eテストの自動化のことを指してると思う)に関して、テストの複雑化や種類の多さから自動化が難しいものがあると述べている点だった。組み込みソフトウェア界隈の話が僕は疎いので読み違えていること大いにありそうだけど。
いずれにせよ、テスト工数を減らしたい、という課題に対するアプローチとして、E2Eテストの自動化でどーん、ということではなく、それより前のテストの自動化を広げていく、というアプローチをしている例とその成功事例があった。
もうちょい調べるべきだけども、テストピラミッドのこと、そしてたまたま見つけたtwadaさんの記事にも以下のように書かれていることから、やはり単体テストと結合テストの自動化対象を増やすことが妥当そうに思う。仮にE2Eテストどかっと自動化してテスト工数が減ったように見えたとて、その後、不安定なテストに翻弄されたら意味ないし。やはり正攻法はこのアプローチだろうな。
テストピラミッドが最も大事にしているのは、自動テストの信頼性を中長期的に保つことです。テストの数が少ないうちはE2EテストやLargeテスト中心でも信頼性を保てるかもしれませんが、テストの数が増すごとに非決定性やテスト実行速度の遅さが信頼性を蝕み、自動テストが破綻していきます。
そして、ここからが大事なポイントだと思っていて、自動化対象を広げた上で、今ある手動テストケースを見ながら不要なテストケースを減らす、というのが良さそう。だから、
テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了
※各工程の詳細は前述のJSTQBシラバスを参照
をやり直すことにそもそもなるんだと思う。時間がかかるけど、これが一番中長期では良いアプローチかな。
アイデア3: 品質基準の見直し
これはテスト分析の話に近い気がする。
対象のプロダクトがおかれた状況も変化するし、時間とともにプロダクトの機能数も増える。ハードウェアも新しいものが増えて、エンドユーザーが利用する端末も変わっていく。さらに、プロダクトを開発する側も状況は変わる。
これらを包括的に考えて、どこまでテストするべきかというのを改めて考えることは良いアプローチだと思う。
他方、根っこにある方針の変更になり得るので簡単には議論が進まないだろう。関係者と丁寧に話すのが大事だろうな。
まとめ
最近はテスト関係のライブラリに加え、使い勝手の良いSaaSも増えたので選択肢が多い。それゆえに、だと思うけど、もったいないアプローチを取ってしまいそうになるのかも。もちろんやってみるのはいいことだけども。
相変わらずソフトウェアのテストは簡単ではないなと思いつつ、LLMがコード書いてくれることが増えると僕らの仕事は要件定義とその検証にリソースをさくことになるんかなと改めて思った。そうすると、要件定義からテストまでのトレーサビリティが気になってくるんだけど、この辺もそんなかからずLLMがうまくやってくれるようになりそう。そしたらもう一回り楽になりそうだな。おわり。
