とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けする「とことんDevOps」では、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果、TipsなどDevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、コンテナ開発、IaCなど

開催予定の勉強会

読者登録と各種SNSのフォローもよろしくお願いいたします。

イベントレポート 第19回とことんDevOps勉強会「テストから始めるDevOps ~面倒なテスト工程を自動化しよう~」

今回のとことんDevOps勉強会は「テストから始めるDevOps ~面倒なテスト工程を自動化しよう~」と題して、mabl(メイブル)のおだしょーさんにご登壇いただきテストの自動化についてお話しいただきました。

単体テストの自働化は徐々に一般化しつつありますが、それ以外のテストに関してはなかなか自動化が進んでいないのが現状です。しかし、最近では単体テスト以外のテストでも自動化し、さらにCI/CDに組み込んで実行するためのツールが増えてきました。今回はそんなツール群の中からmablを題材にテストの自働化についてお話をいただきました。mablでは主にWebのUIテスト、APIテスト、パフォーマンステストといった領域をカバーしていますが、今回はWebのUIテストを例にテストの作成からCIへの組み込みまでのプロセスを紹介していただきました。

振り返りも兼ねて当日の配信の様子をYouTubeでアーカイブしていますので、是非ご覧ください。当日参加できなかった方も、これを機会にとことんDevOps勉強会に興味を持っていただければと思います。また、当日いただいたQ&Aに関してもこちらのブログでまとめていますので、ぜひご覧ください。

セミナー動画 - YouTube Live アーカイブ

www.youtube.com

発表資料 - Speaker Deck

speakerdeck.com

Q&Aまとめ

Q: 開発を巻き込んでDevOpsを現場に導入したいと思っているが、QAが率先して推進することが難しい

 

A: テスト設計を早い段階で行うことを促すのが良いかと思います。ウォーターフォール開発ではどうしてもテスト設計を後回しにしてしまいがちです。そうではなく、こういった機能を作るので、こういったテストが必要になると早い段階で想定し共有して、自動化する箇所はどこか?という議論に持ち込むことで、QAとしてシフトレフトの実現を促し、DevOpsを推進できるのではないかと思います。

Q: ウォーターフォールからアジャイルに変えていきたいが、何から始めたらいいか分からないので、テスト工程から変えた方がいいなどのどこから変えて行った方がいいなどありましたら教えていただけると幸いです。

 

A: mablというテストソリューションの会社という立場もありますが、自分たちがやらなければいけないことを想定して逆算していくという考え方をもつことが必要だと思います。ウォーターフォール開発で最後のフェーズになってから慌ててテストを行うと、テストを通すことが目的となりがちです。アジャイルに限ったことではないですが、あくまでテストは品質を上げるための手段なので、自分たちがやらなければいけないことのゴールを設定し、そこから逆算してテストをどうすべきかを早い段階で検討することが重要です。

Q: 単体テストに比べて、重くなりがちなe2eをDevOpsに持ち込もうとした場合、リスクベースで優先順位付けなどが必要になると思われますが、開発者視点でのリスクとQA視点でのリスクを、合意形成する良い手はありませんか。

 

A: 発表資料の7枚目のスライドのように、量的な面で言うと、単体テストは膨大な量がありますし、E2Eテストはそれに比べれば少なくあるべきだと思います。では、どういった形で絞り込むかと言う観点ですが、これから始めるのであればハッピーパス(正常系)から始める、クリティカルなところに絞るべきだと思います。まずは視点を定めて、それを実現するためのテストはどれかと言う判断をおこなうようにすべきです。ある程度レベルが上がってきた段階で、他の視点からのバリエーションを増やしていけばよいです。そのような基準を設けて、合意形成をしていくのが良いかと思います。

Q: 頻度の観点でコミットごとに実行してしまうと、どうしても時間がかかってしまったりすると思うのですが、その辺のプラクティスなどはありますか。

 

A: そのためにローカル実行を使います。テストをするのはMainのブランチにバグを持ち込まないのが一番の目的なので、Mainのブランチへのマージの際にクラウドでテストを実行して、コミットをするような局面ではローカル実行でテストするといったやり方が良いかと思います。

Q: どのタイミングからmablのテストを行うようにすべきなんだろうか。開発の初期段階だと、アプリを作ってみた後にすぐ仕様が変わったりすることもあるので、テストの作り込みのタイミングが難しい。作ったテストを直していく手間がどれぐらいかかるのかも気になる。

 

A: テストの自動修復機能がどれくらいの精度かという点がポイントだと思います。従来でも80%程度の精度で変更点を見つけてくれていたのですが、現在ではLLMを活用するようになり95%まで精度が上がっています。その結果、テストが壊れる可能性はかなり下がりました。もちろん、作るアプリやプロジェクトによって変わってくるので検証は必要になりますが、検証も含めて早い段階から検討するのが良いと思います。

Q: 開発チームの中でもテストに対する認識や知識、経験がバラバラなので、テスト技術についての標準化を図りたいのですが、よい教科書的なものはあるでしょうか?

 

A: JSTQBというテストに関する認定資格団体があり、公開されているドキュメントなどが参考になります。標準化という観点ではJSTQBの基本資格の取得を目標に据えるなどをして、チームのレベル感を調整してみてはいかがでしょうか。

jstqb.jp