NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'22 Tohoku
HOME > 活動報告 > イベント報告 > JaSST'22 Tohoku
2022年5月27日（金） 於 オンライン + オンサイト開催
当イベントはZoomを用いたオンライン開催と岩手県盛岡市のアイーナ（いわて県民情報交流センター）でのオンサイト開催を混ぜたハイブリッド開催である。筆者はオンサイトにて参加した。会場は300名収容できる会議室で、参加者同士の距離を十分取れるように座席が配置されていた。
実行委員長の武田氏から事前アンケート回答が展開された。同氏は「オンライン・オンサイト参加者それぞれで交流を楽しんでいただきたい」と述べた。
また、「テストの問診票」と題したアイスブレイクが行われ、Discordを用いてテスト自動化にまつわる参加者アンケートがリアルタイムで行われた。最後の質問に「テストにまつわる悩み、小ネタ」があり、参加者の赤裸々な悩みが投稿された。リアルタイムでリアクションが付くため、参加者の共感度合いや悩みどころが分かる良いアイスブレイクだった。
米HeadSpin社において、シニアソフトウェアエンジニアとして活躍されている松尾氏から発表があった。概要は以下の通りである。
松尾氏は冒頭で、本講演はこれからテスト自動化を始めていこうという人向けの内容であり、「テスト自動化のスコープと実行速度の違い」と「これから自動化を学んでいくために」を扱うと述べた。
「テスト自動化のスコープと実行速度の違い」
まず、テスト自動化を議論するときに頻繁に出てくる「テストピラミッド」の図を紹介し、Unit Tests, Integration Tests, UI Testsの理想的なバランスを示した。
次に、JaSST TohokuのWebページを開く、という処理を例に、スコープに応じたテストケースの具体例を示した。また、それらテストケースのテスト実行のデモを行うことにより、テストのスコープが小さいほど実行速度が速くなることを示した。
そして、スコープの小さいテストの利点にはさらに、調査範囲が狭く原因の切り分けが容易で、結果としてバグの改修が容易になることを挙げた。
「これから自動化を学んでいくために」
これから自動化を学んでいくにあたってのアドバイスとして、以下の3点を述べた。
テストのスコープによる実行速度の違いを、テスト実行のデモによって分かりやすく解説していただいた。
テスト自動化を始めるにあたりどう学んでいけば良いのか分からない、という悩みは筆者自身も抱えているものであるが、講演の中で示されたアドバイスはどれも現実的で行動に移しやすいと感じた。
OSSへの関わり方について、筆者も不具合を見つけて修正するような関わり方しかないと思い込んでいたため、松尾氏に示していただいたアプローチにも挑戦していきたいと思った。
長期にわたってテスト自動化を効率的に運用できる方法として、江村氏のチームが6年間で出会った3つの課題とその解決方法を紹介した。
まず1つ目の課題として、「組織が大きくなると、テスト自動化の役割がさまよう」というプロセス上の課題を挙げた。これは、チームが小さいときは密にコミュニケーションを取って明確だった役割分担が、チームが大きくなるにつれて曖昧になってくるという課題である。
この課題を解決するために、「新規機能のリグレッションテストは次のプロジェクトで実装しても良い」などのプライオリティを明確にした、と述べた。テスト自動化メンバーの責務を明確にし、かつ現実的に果たせる責務にしたことで、課題を解決したという。
次に2つ目の課題として、「テスト自動化が成功し続けても、自動化の内部品質に課題あり」というスクリプトにおける課題を挙げた。これは、テストデータの肥大化やテストジョブの高依存化により、テストの待ち行列が溜まってしまうという課題である。
この課題を解決するために、テスト実行時間やJenkinsジョブの処理時間、テスト結果、Jenkinsステータスを蓄積し、スクリプト単位・Jenkins単位の実行時間の推移を可視化した、と述べた。問題のあるテストの絞り込みを行い、内部品質の低下を早期発見できるようにしたという。
最後に3つ目の課題として、「テスト自動化の運用工数が、スクリプト数に比例する」という運用上の課題を挙げた。これは、自動テストが失敗したときの調査コストが高く、そのコストがスクリプト数に比例して膨大になってしまうという課題である。
この課題を解決するために、テスト失敗時のエラーログをAIに学習させて、Auto Healing Systemを構築した、と述べた。テストの失敗原因の大半が環境要因であったため、Auto Healing Systemによりテスト失敗時の調査コストが劇的に下がったという。
発表の中で示された課題は、自動化に取り組む企業であれば必ずぶつかる課題であると感じた。解決方法も具体的で、この事例発表を受けて課題解決の歩みを進める組織も多いのではないだろうか、と感じた。
MagicPodを用いて回帰テストの自動化を進め、月1回だったリリース頻度を週1回にまで高めた事例を紹介した。
橋本氏は、冒頭で回帰テストの自動化の動機について述べた。テスト自動化の需要がリリース頻度の高まりと共に上がっており、またツールの登場でやりやすくなっているため、とのことである。
具体的に取り組んだこととして、まず、自動化ツールのトライアルや現状作業を見つめ直すことに取り組んだ、と述べた。その中で、優先度の低いテストを削ったり、手動で行っていたテストケースを自動テスト用に記述し直したりしたという。
また、プロセス改善も併せて行った、と述べた。Pull RequestのレビュアーにQAも含めることで、コードレビューと並行して手動テストと自動テストを行えるようにしたという。
次に、リリース頻度の短縮以外で、テスト自動化で得られた効果を述べた。まず、自動テストによる開発者へのフィードバックが有用だったことから、開発者からの信頼を得られたという。
また、全体のPull Request数も150%増加し、リファクタリングしやすくなったという。この背景として、テスト実行タイミングを前倒ししたことにより、いつバグが埋め込まれたかという分析作業が不要になったことや、テスターの負荷状況を気にしなくて良くなったこと、壊してしまうかもしれないという不安がなくなったことを挙げた。
さらに、回帰テストの手動実行にかけていた時間を、自動テストのメンテナンスや、より多くのテストの実行に充てることで、本番障害0件も実現したという。
最後に橋本氏は、自動テストに向き合う上で絶対にやることとして、自動テストのテストをすることを挙げた。
コードレビューと並行して手動テストと自動テストを行う、というアイデアには、その手があったかと膝を打った。
テスト自動化の効果として、リリース頻度を高めるだけでなく、Pull Request数の増加も確認されたという事例は、まさにテストが開発生産性を向上させることを示す事例であり、テスト自動化のこのような側面がもっと注目されて欲しいと思った。
テスト自動化の最初の一歩を踏み出すにあたり、心理的な壁を乗り越えていった事例を紹介した。
二河氏は、冒頭でテスト自動化の動機について述べた。リグレッションテストを実施する時間的な余裕がない状況でデグレードが度々発生してしまったため、とのことである。
テスト自動化を始める上での心理的な壁の原因として、以下の3つを挙げた。
「予算が割り当てられていない」という原因に対しては、そのとき社内で利用可能であったRPAツールを用いて、テスト環境構築の自動化から取り組んだ、と述べた。工数削減の実績から、テスト自動化ツールの予算を確保できたという。
「専任者がいないことにより、始め方のノウハウがない」という原因に対しては、ネットや書籍などからアンチパターンを収集し、独自の観点表を作成したり実現可能性調査を行ったりした、と述べた。情報収集していく中でテスト自動化の目的が明確になり、テスト自動化を想定より早く実現できたという。
「コーディングスキル等の不足による漠然とした不安」という原因に対しては、ツールベンダーを活用した、と述べた。スクリプトが必要な場合でも、ベンダーが提供するスニペットを用いることで対応していくことができたという。
テスト自動化を始める際の不安は、多くの人が抱える不安だと思う。二河氏の講演は、そういった方々に、最初の一歩を踏み出す勇気を与えるものだったと感じた。
テスト自動化に限らず、これまでやったことがない何かに挑戦する上で非常に重要な考え方が述べられていた。
JaSST'22 Tohoku 実行委員による、ゲームブック形式のワークショップであった。
ストーリー上の選択肢の選択は、Discordを用いた投票で行われた。
テスト自動化をテーマに、扱う問題の選択から参加者投票に委ねられ、テスト自動化プロジェクトの始め方やツール選定、テストケースが増えた際の対応など、様々な場面での選択肢が提示された。
ストーリーを一巡した後に、各場面の選択肢について解説が行われた。JSTQBの「Advanced Level Specialist シラバス テスト自動化エンジニア」や日経BP社から出版されている「ソフトウェアテスト293の鉄則」などを引用しての解説であった。
ゲームブックのシナリオと解説が一巡した後、一巡目とは異なるシナリオでもワークショップが行われた。
質疑応答の中で、シナリオの着想は、委員の実体験から得られたものである、と述べられた。また、教材としての妥当性はJSTQBシラバスを基にすることで担保した、とも述べられた。
参加者全員がDiscord上の投票に参加できる形式は、リアルタイム性も相まって非常に楽しいものだった。楽しみながらも、テスト自動化プロジェクトの勘所を学べる内容となっていたため、これからテスト自動化を始めようというチームや組織にとって、非常に有用な教材なのではないかと思った。
ゲームブックのシナリオにはハッピーエンドとバッドエンドが用意されていた。ワークショップの終盤で「わざと」バッドエンドに向かう一幕があり、Discord上でも会場でも大きな盛り上がりを見せたのが面白かった。
井芹氏は、冒頭で講演内容について話した。本講演の内容は特定のテストレベルやテストタイプ、ドメインに閉じた話ではなく、全般的な自動化を対象にしている、と述べた。
まず、テスト自動化の成功を論じるにあたり、スコープによってテスト自動化の目的は様変わりする、と述べた。また、目的達成に対してテスト自動化がどのように寄与するのか、またどのようなコストがかかるのかについて触れた。
次に、テスト自動化の成功を支える活動について話した。
まず、適切な目的を立てることが重要である、と述べた。井芹氏の経験上、短期間でのコスト削減など、誤った目標設定はテスト自動化の失敗要因になることが多いという。
また、費用対効果を改善することが重要である、と述べた。費用対効果を左右する活動において、井芹氏の経験上、以下が失敗要因になることが多いという。
続いて、テスト自動化を支えるチーム文化、テスト自動化を支えるチームと仕組みについて話した。
まず、テスト自動化の成功には、チームと仕組みによる下支えが不可欠であり、そのようなチームと仕組みを生み出すチーム文化が重要である、と述べた。
チーム文化について、特に持続可能性の重要性について強調した。テスト自動化が大失敗してしまうことを避け、ステップバイステップで目的達成を目指すことが重要であるという。
また、チームについて、能力を持つ人とチームを確保することが重要である、と述べた。井芹氏の経験上、能力不足がテスト自動化で最も多い失敗要因であり、開発技術がとても重要であることを強調した。
そして、仕組みについて、自動化インフラの整備や、テスト自動化の良いアプローチをプロセス化することが重要である、と述べた。
チーム文化から具体的な活動まで、テスト自動化について体系的に解説いただいた。講演の随所で、井芹氏の経験上見えてきたアンチパターンについて触れられており、テスト自動化を行っている組織のヘルスチェックにも使えるのではないかと感じた。
折に触れて本講演を思い出し、いちエンジニアとしてテスト自動化の成功に向けて邁進しようと思った。
今回はオンライン開催とオンサイト開催を混ぜたハイブリッド開催であったが、Zoomでの上映も会場での上映も終始スムーズに開催されていたと感じた。筆者はオンサイト参加が初めてであったため、各講演後の会場の拍手や、参加者同士の対面での交流に感動を覚えた。
Discordでのリアルタイム投票を用いたプログラムは参加者同士の一体感を生み、趣向を凝らしたワークショップも含め、実行委員の方々による念入りな準備と情熱を感じた。
テスト自動化に関しては、筆者もこれから挑戦していきたいという状況であったため、非常に多くの学びを得ることができた。
記：苅田 蓮（JaSST Tokyo 実行委員）