テスト自動化の計画づくりにはコツがある #mabljapan

藤原さんが主催されたOL勉強会に参加した。
ラフなメモ。

【参考】
テスト自動化スタートダッシュ！ テスト自動化のオンボーディングや戦略、計画づくりを考える編 - connpass

イベントレポート： テスト自動化スタートダッシュ！ テスト自動化の戦略を考える編 | mabl

【1】テスト自動化をやりたい動機は色々あるが、効果を出すには、ゴール設定やスコープ設定が必要になる。
なぜなら、mablがいくら優れたテスト自動化ツールであっても、その現場の問題解決にピッタリ当てはまるとは限らないからだ。
たとえば、マニュアルテストをすべて自動化したいと思っても、実際はなかなかうまくいかない。
あるいは、テスト自動化で回帰テストを強化したり、受け入れテストを自動化したい、と思っても、効果を出すには割とギャップがある。

どうやらテスト自動化と従来のマニュアルテストの間には大きなギャップがあるらしい。
テスト自動化に合ったテストケース作成、テストシナリオ作成、テスト自動化のスコープや自動テストの粒度があるようだ。

テスト自動化の計画の話を聞くと、4つの注意点があるように思う。

【2】1つ目は、テスト自動化のゴール設定、テスト自動化で実現する品質の基準を明確に定めること。
テスト自動化で何を求めたいのか？
一口に品質向上と言っても、コストをいくら掛けてもいいわけではない。
藤原さんの言葉で腑に落ちた点は、テスト自動化をやっていると品質保証という言葉が合わない。
むしろ、どんな品質をテスト自動化で担保したいのか、を明確にすべきだ、と。

たとえば、受入テストのような手動テストを自動化したいのか、本番運用する前に品質検査するスモークテストを自動化したいのか、機能追加や機能改善してもデグレしないように回帰テストを重視したいのか、自動テストのカバレッジを上げたいのか、どれなのか、と。
あるいは、クレジット決済に関わるようなクリティカルな機能のテストは十分に自動化したいのか、本番システムの障害テストを自動化したいのか、と。

また、品質に関する基準も、マネージャや開発者、ユーザでも異なってくる。
この辺りは狩野モデルかな。
当たり前品質なのか、魅力的な品質を求めるのか。

マネージャならシナリオテストや受入テストを自動化したいだろうが、開発者なら単体テストのカバレッジを上げたり、回帰テストを強化したいだろう。
役割によって、求めたい品質は異なってくるから、そのゴールをまずは現場で合わせる必要があるわけだ。

【3】2つ目は、テスト自動化は、単体テストから受入テストまでのプラミッド型のスコープではなく、回帰テストからテストカバレッジまでの逆ピラミッドにすべきであること。
つまり、テスト自動化を導入する場合、松竹梅のレベルに合わせて、まずはテスト自動化に手を付けやすく、投資効果が大きい部分から始めて、徐々にテスト自動化の範囲を広げていくのがおすすめ。

資料のスライドでは、回帰テストの松レベルから始めて、受入テストのうち重要機能の正常ケースを網羅するスモークテストに手を付け、徐々にシナリオテストや単体テストの網羅率を広げていくような例があった。
この方法ならば、開発者も実装しやすいし、ユーザもテスト自動化の投資効果を得られやすいだろう。

【4】3つ目は、テスト自動化の実現手段は、WF型開発の各工程、アジャイル開発ならDevOpsの各プロセスによって異なること。
たとえば、単体テストならC0、C1のテストカバレッジ、結合テストなら回帰テストやCI、総合テストならシナリオテストやCD、受入テストならUIテストやスモークテストやCDなどが相当する。
つまり、テスト自動化の技術は、WF型開発の各工程、DevOpsの各プロセスによって異なる。
だから、投資効果を得たいならば、どのフェーズにテスト自動化を注力するのがよいのか、をゴール設定から見極める必要がある。

【5】4つ目は、テスト自動化を担当するロールは、現場の組織のリソースや組織構成に応じて、柔軟に対応すること。
たとえば、大規模なSaaSや大規模な基幹システムであれば、複数のチームが機能やサービス単位に分かれていて、それぞれで開発して、品質に責任を負っている。
すると、回帰テストやスモークテストを実行したい時、複数のチームをまたがってテストシナリオを作ってテスト自動化を図る必要が出てくるが、それを担当する人やチームが曖昧になりがちだ。
なぜならば、複数チームにまたがるので、その作業工数や品質について誰がその責任を負うのか、が不明確になりがちだからだ。
そこで、たとえば、複数の機能やチームを横断するテスト自動化のチームを作り、回帰テストを担当するケースもあり得ると言われた。
確かに、チーム横断、機能横断でそういうチームを作るときもあるだろう。

一方、各チームにテスト自動化の専任担当者を作った方がいい場合もあるだろうし、他方では、チーム内の各メンバーがテスト自動化のスキルを持つように能力を育成して全員が担当する、という場合もあるだろう。

やはりアジャイル開発であれば、少人数のメンバーでチームを組んで開発していきたいので、各メンバーがテスト自動化のスキルを持って実装できるのが理想だろうと思う。

【6】こういう話を聞くと、テスト自動化とは単にJUnitやSeleniumなどで実装するだけではなく、細かいの実践ノウハウが必要だと分かる。

僕は、ソフトウェア開発において、テスト自動化のスキルはシステムの品質を担保する上で重要な要素の一つであると思うので、この辺りの技術は今後もウォッチしていく。