記事を読んでくださりありがとうございます！
モブエンジニア（@mob-engineer)です！
今回は12/07（土）に参加したソフトウェアテスト自動化カンファレンス2024のアウトプット活動として、イベントレポートを執筆したいと思います。
本記事はソフトウェアテスト自動化カンファレンス2024に関するイベントレポートとなります。
誤字脱字・認識相違・整合性相違など極力ないように執筆を行っていますが、リアルタイム性を重視しているため、排除できていない場合があります。その際は温かくコメントいただけますと幸いです。
あわせて、参加者視点でのレポートとなるため、講演資料などのキャプチャは掲載しませんので、ご留意いただけますと幸いです。
・connpass公式ページ
・テスト自動化研究会公式チャンネル（Youtube）
参加したきっかけ
私自身が開発業務に携わっているので、ソフトウェアテストってどうすればより効率的になるのだろうかといった悩みを抱えていました。
そのうえで、本セッションでソフトウェアテスト自動化に関して取り上げていることを知ったので、今の開発体制への活用と開発者としてのスキルアップを目的に参加いたしました。
私が参加したセッション
専任担当からチームに還してQA全員で取り組むテスト自動化
・企業ホームページ
- 自己紹介
- hacomono専任エンジニアチームの方々
- hacomono社はウェルネス施設向けのプロダクト開発企業
- まとめ
- 属人化したテストを自動化した話
- 受け取った側のメンバーの話
- 当時の状況と課題（森島さん）
- 2週間単位で開発をおここなっていた
- 開発完了チケットをQAチームへ共有
- 自動テスト・手動テストで2～3日程度
- 自動テストの作成・運用はSETチームで実施
- 作業が属人化していた
- 自動テストの追加が難しい
- 作業属人化問題
- テストの複雑さに応じて理解が難しい
- 追加が難しい
- 属人化問題の対策として、専任を置く方向性進めていった
- 自動テスト追加に関するコミュニケーションコストがかかる
- 課題解決アプローチ（森島さん）
- 各チームに自動テストを取り組んでもらうようにする
- ローテーション制度へ変更した
- 実施できる人を増やしていくことから始める
- たたき台を肉付けしていった
- ローテーションを通じて新たな視点をドキュメントへ反映していく
- 各チームに対して自動テストワークショップを開催
- 基礎的な導入・操作会を行ってみた
- チームによって特徴が出てきた
- 続いているチームは継続的な改善を行っている
- 各チームに自動テストを取り組んでもらうようにする
- 展開された側の視点（たっきーさん）
- 前提：自動テストの作成・実行もしたことがない方
- 大変だったこと
- 作業時間の確保が難しかった
- テストケースの内容把握が難しかった
- Failed時の原因調査が難しかった
- 工夫したこと
- 自動テストへ触れる時間を増やした
- シナリオ⇒フロー⇒ステップごとに実装を理解していった
- 良かったこと
- 自分たちが実行しているテストを把握できた
- リグレッションテストの改善（≒品質向上）につながった
- 発展
- PlayWrightでテストを書くことになっているが入りやすい
- スプリント期間中にE2Eテストまで実装できる
- テスト自動化をチームで取り組んだこと（松田さん）
- 元々テストに着手していなかった
- 現在は自動化テストも作成していっている
- テスト実行
- 所感
- 手順書のクオリティが高かったので実行への抵抗感はなかった
- 失敗時のリカバリ対応が難しかった
- バグ or テスト失敗のどちらか判断するのが難しい
- テストを読み込むのに時間がかかり、原因特定が難しい
- 対策
- SETチームへ頼っていく
- 失敗原因・対策方法を都度書き出していく
- Slackでやり取りを行っているため類似事象を発見できる
- SETチームへ頼っていく
- 発見
- サンプルとして多くのテストを見つけることが出来る
- テストに関する勘所をキャッチアップできる
- テスト作成
- つまづいたとおろ
- マニュアルテストのタスクとの優先順位を付けられない
- 最初のうちはアウトプットが出せなかった
- 対策
- 毎日自動化対応の時間を設けていた
- 時間中はペア作業や気づきの共有などを行っていた
- 対策を通じて
- 自然と集まれるようになった
- 進捗状況をメンバー間で共有できる
- まとめ
- 手順書を残しておくことで引継ぎが容易になる
- コミュニケーションを重ねることが重要
- つまづいたとおろ
- まとめ
- 越境していく文化を作っていこう！
- 質問
- （質問）自動テストのフェーズは
- リリース前のリグレッションテストのイメージ
- テストドキュメントの形式は
- 手順書に近い形でドキュメントをまとめている
- テスト時間の確保方法は
- 優先度が低いタスクは捨てるといったことを行っていた
- （質問）自動テストのフェーズは
E2Eテストの作成から行うTDDの実際
・企業ホームページ
・参考資料
・牧野さんブログ
- 自己紹介
- SHIFT社で自動化テストを担当している
- 背景
- 手動テストチームのテストデータ作成支援を行っている（電文ビルダー）
- 利用者はプログラマ
- ステークホルダー向けにレポートを提出するがコードは提出不要
- 動機
- ゴールを明確にしたい
- ユーザストーリーの完了条件を明確にしたい
- 開発しているプロダクトが本当に正しいのか
- 開発へのモチベーションが低下する可能性
- リリース可否を明確にしたい
- 低コスト・高品質なソフトウェアのリリースを実現する
- ユーザストーリーの完了条件を明確にしたい
- 楽をしたい
- 人の時間を使わずにテストを完了させたい
- 機械に任せられるところは機械に任せる
- 知識がなくてもテストを完了させたい
- ユーザストーリーの成否判定は難易度が高い
- テストケースへユーザストーリーを組み込むことが大切
- 人の時間を使わずにテストを完了させたい
- ゴールを明確にしたい
- 開発フロー
- ストーリーの成否検証E2Eの作成
- いったん作成してみる
- 100％の完成基準を設けると、いつまでたっても完成しない
- ガチガチに製造しても心理的安全性が向上しない
- 作成したE2Eでテストを行ってみる
- 相談する文化をつくることで、助け合う環境を作ることができる
- ストーリーの成否検証E2Eの作成
- 最初のE2E
- 目的はプロトタイプのデモとファーストゴールの確立
- 雑なデモ用アプリを用意しておく（たたき台）
- デモ用アプリから肉付けを行っていく
- 開発速度を最優先する
- 提供速度はクオリティ
- 目的はゴールの確立
- 雑なデモ用アプリを用意しておく（たたき台）
- 目的はプロトタイプのデモとファーストゴールの確立
- ストーリーごとのE2E
- こだわらないことが重要
- 正解は一つではない
- 実物を眺めることで、新たな発見を得られる
- 場合によってはユーザストーリーを分割することも大切
- E2Eを作るだけのユーザストーリーもある
- 機能確認など
- こだわらないことが重要
- E2Eを楽にするためのポイント
- ワンコマンドでテストが完了できるようにする
- テスト環境構築が複雑だと開発が遅くなってしまう
- E2Eの範囲はユーザストーリー網羅にとどめておく
- E2Eの実行コストは意外と高い
- プログラマが気になることを反映する
- E2E成功=リリースと判定する
- ワンコマンドでテストが完了できるようにする
- メリット
- 達成度の可視化
- ユーザストーリーを並べてみせることで解像度が上がる
- 何が出来るかを経営者層に説明できる
- 開発に関する会話が行いやすい
- E2Eを通じてアイデアを出せる
- アイデアを出しやすい・取り入れやすい
- 創意工夫を通じてより良いプロダクトを生み出すことが出来る
- 達成度の可視化
クラウドE2Eテスト環境を構築してQA業務の効率化アップしたこと/できなかったこと
・登壇資料
https://speakerdeck.com/gremito/kuraudoe2etesutohuan-jing-wogou-zhu-siteqaye-wu-noxiao-lu-hua-atupu
- 実装方法の詳細・ハンズオンの解説に特にない
- 講演内容としてクラウドE2Eテストの体験談と課題について
- ターゲット
- プロダクト開発に関わっているメンバー
- 自己紹介
- フリーランスエンジニアの方
- Web開発・QA業務の経験を得て、フリーランスへ転身
- スクラムマスターとして活躍されている方
- QA視点では改善提案を行っている
- QAエンジニア勉強会なども行っている
- QAとは？
- テスト=QAではない
- テストデータ管理・プロセス改善・見積もりなど役割は多岐にわたる
- 環境ごとの品質管理を行うとなるとエンジニア並みに忙しい
- QAがかかわる範囲は？
- 品質に関わる範囲はQAが参画する
- DevOpeの場合は要件定義から参画していく
- テストが最後の砦とならないように
- テストを外注するとコストがかかってしまう場合がある
- 品質低下となる可能性もある
- テスト実施のみを外注するのは良いが、設計は開発チームで行った方がいい
- テストを外注するとコストがかかってしまう場合がある
- クラウドE2Eテストについて
- E2Eについて
- クライアントからアプリ操作を行い、製品品質に問題ないかチェックする
- UIテストと混合しがちだが、UIテストは単体テスト寄り
- クラウドE2Eとは
- ざっくり言うと、テスト自動化☞クラウド化の意味
- SaaSサービスであれば、mabiやAutfyなどが有名
- PaaSサービスであれば、Remote TestkitやAWS DeviceFarmなどがある
- クラウド化は容易だがドキュメントを適切に整備する必要がある
- E2Eについて
- 事例紹介
- Cocos2d-x向けE2Eテスト自動化ツール開発
- 背景
- Cocos2d-Xを用いたソシャゲ開発に携わっていたが、対応テストツールがなかった
- 自前でテストツールを開発したほうがいいよねとなった
- 開発経験
- 座標を前もって準備しなくてもいいように、自動取得できるようにする
- 不具合発生時の操作についてログを残すようにした
- テスターが作業内容を忘れても再現できるようにする
- 背景
- Azure Pipelineとの連携
- 背景
- リグレッションテストを自動化したいといった思いから開発
- 使用技術はAzure PipelineとJenkins
- 開発経験
- 起動テストを実行して問題なければアプリビルド⇒デプロイまで実行する
- 脱属人化が目的だったため、自動化できたことのインパクトが大きかった
- 背景
- Autify・mabi・MagicPodを通じたAIによるE2Eテスト自動化対応
- 背景
- AIによる自動更新機能を活用して、検証・計画・ドキュメント整備の工数削減
- 開発経験
- アプリインストール不要なので、導入しやすい
- IDEツールでテスト作成・管理が行えるため、誰でも実装可能
- 悩みとして、テストツールによる結果の違いがあった
- 最近だと、AIによるテストシナリオ作成も行ってくれる
- UI変更に関しては手動対応が必要な場面もある
- すでにあるテストケースを全て自動化するのは難しい
- 一部手動で残ってしまった
- 背景
- Cocos2d-x向けE2Eテスト自動化ツール開発
自動化技術を応用したデータ分析環境の構築事例
- 閑話休題
- ワーククラウドに頻出ワードを出させた
- 自動化・品質改善
- データ分析環境について
- データを自動的に収集する技術
- 今回はデータ分析に着目してみた
- 自動化技術の構成比
- Power Queryが6割
- その他、Power Automateやpythonを活用している
- データを自動的に収集する技術
- 収集から可視化までの流れ
- メールやクラウドなどのデータソースからPower Automateを通じて収集している
- PowerBIを用いてデータ集積⇒可視化を行っている
- メールやクラウドなどのデータソースからPower Automateを通じて収集している
- 事例紹介
- ワークライフ＋
- オフィスビル入居テナント向けのサービスプラットフォーム
- PowerQueryを通じて名寄せ処理を行った後、PowerPlatformを用いて処理を自動化している
- 効果
- 4人月の工数削減
- データ処理の品質向上
- 業務自動化など
- 事例を通じて、より良い影響をもたらしてくれた
- ワークライフ＋
- Shift社の取り組み
- GitHubコード眺め会
- 質問
- 20分のデータ処理件数は
- 大小さまざまだが10MBくらい
- データ集計の確認方法は
- 目視を通じて確認を行っている
- 20分のデータ処理件数は
Scalable Multibranch CICD pipeline ～自分だけのQA環境でストレスフリーなシステム開発とテストを～
・企業ホームページ
- 自己紹介
- アサヒグループホールディングス：アサヒビールなどの飲料会社
- 活動のきっかけ
- 2025年の崖：既存ITシステムを放置するリスク
- 保守管理の負担コスト増加による経済停滞
- 2025年の崖：既存ITシステムを放置するリスク
- 従来のユースケースと問題点
- 基幹システム全体がブラックボックス化している
- ビルド・デプロイが手動で行われている
- ベンダー以外がソースコードを触れない状況
- 基幹システム全体がブラックボックス化している
- スケーラブルマルチブランチCICDとは
- ざっくりいえば、QA環境・開発環境をさくっと作成してくれる
- 開発環境をリファクタリングしやすくなる
- メリット（うま味）
- 好みの環境を自動で作成・破棄できる
- 自分だけの環境を作成できる
- 技術スタック
- GitHub、AWS、Jenkins、Dockerを用いて開発
- GitHubブランチ機能・Jenkinsのマルチブランチパイプラインが連携している
- 自分の好みに合ったリソースを作成・削除してくれる
- AWSがDockerコンテナの実行・管理を担っている（Amazon ECS）
- JenkinsからEC2へGitHubコードがクローンされる
- 差別ポイント
- コードPushだけで自分だけの環境を生成できる
- 任意のタイミングでリソース作成・削除できる
- 複数のテストケースを並列して実行可能
- コードPushだけで自分だけの環境を生成できる
- ざっくりいえば、QA環境・開発環境をさくっと作成してくれる
- デモを見てみて
- GUI操作でサクサクリソース構築・削除が実現できるので、初見でも使いやすい印象
- 今後の展望
- GUIテストへの活用
- Seleniumを活用したヘッドレステストの実装
- テストケースのマネジメント
- TestRailを用いた誰でもわかる管理体制を構築できる
- GUIテストへの活用
- 質問
- 商用展開については考えているのか
- 現在はPoCベースでの検証中だが考えているう
- 技術的に複数メンバーが同時にリソース構築することも可能
- 商用展開については考えているのか
運用・保守時の無影響確認自動化に向けて考えていきたいこと
・企業ホームページ
- まとめ
- 開発時に作成したテストスクリプトの再利用に関する内容
- システムの影響確認（UIテストに限定）について話す
- 自己紹介
- 日本電気でテスト自動化を推進されている方
- 開発時のテストスクリプトの行く末
- 開発時に作ってその先のフェーズで利用されない
- リグレッションテスト・バグ発見などの限定的には利用されるが...
- アジャイル開発では利用シーンはあるが、ウォーターフォールだと少ない
- 運用保守を継続して受注すると、利用シーンはあると考えている
- 開発時に作ってその先のフェーズで利用されない
- 開発⇒運用・保守へ移行した際のニーズ変化
- プロダクト品質維持も重要だが正常性確認も重要
- あらかじめ正常性確認もスコープに入れておくことでテストスクリプトの在り方が変わってくる
- プロダクト品質維持も重要だが正常性確認も重要
- テストスクリプトの活躍シーン
- 月1回のOSパッチ当て＋四半期に1回の累積パッチ当て
- 少なく見積もっても16回は再利用する場面がある
- ISO27000シリーズでは確認方法までは指示していない
- 無影響確認テスト手順について
- 再利用視点で見るとテスト実施が当てはまる
- 回帰テスト・機能確認テスト・結合テストで利用される
- テストスクリプトを再利用することによる削減コスト
- 試算結果より、アジャイル > 運用保守 > ウォーターフォール
- ライフサイクルを考慮すると、ウォーターフォールでも800時間削減できる
- 再利用視点で見るとテスト実施が当てはまる
- まとめ
- システムのライフサイクルを考慮するとテスト自動化したほうがコスト削減できる
- To-Be（あるべき姿）よりAs-Is（現状）を踏まえて自動化を考えていった方がいい
アジャイルテストの4象限で考える、プロダクト開発の品質への向き合い方
・登壇資料
・企業ホームページ
- 自己紹介
- ユビー社のQAエンジニア
- コンバウンドスタートアップの医療系企業
- 目的
- アジャイルテスト4象限を踏まえたテスト計画
- 前段整理
- 様々なプロダクトが登場し様々なテストが複雑に組み合わさっている
- アジャイルテスト4象限
- 第一象限：コードに着目したテスト
- 基本的にシンプル
- 第二象限：機能に着目したテスト
- 第一象限より複雑になる
- 第三象限：探索的なテスト
- ユーザ受入テストのようなイメージ
- 第四象限：非機能要件に着目したテスト
- ストレステストなど
- 第一象限：コードに着目したテスト
- アジャイルテスト4象限を実現するために
- プロダクトが複数あるためシナジーが生まれる良い点がある
- データ正規化・なめらかな連携などの課題がある
- プロダクトが複数あるためシナジーが生まれる良い点がある
- 複雑性に向き合うためのコンセプト
- 目線合わせを行ってみる
- 間違いは起こる前提で開発していく
- 複雑性へのアクション
- リスクストーミングを実施してみた
- 関係者が思っているリスクを言語化・可視化してみた
- リスクストーミングを実施してみた
- 品質特性への取り組み
- 現状について有識者へ相談して要件に落とし込んでいく
- ポイント
- 目線合わせを行う 言葉を合わせる
- 再整理
- 第一象限はプロダクト開発エンジニアが実施
- モック・デモを用いて言語化してみた
- サンプルケースを通じて標準化していく
- 第二象限はQAエンジニアが実施
- 本番環境でテストできるように考慮した
- 第三象限は既存機能置き換えなのでスキップ
- 第四象限はQAエンジニアが実施
- 第一象限はプロダクト開発エンジニアが実施
- 取り組みを通じたうま味
- 新規参画者のキャッチアップ速度が向上した
- 開発エンジニアもQAに対して興味関心を持ってもらうようになった
- ステークホルダーとのコミュニケーションが円滑になった
- 反省点
- 複雑な仕様へのシフトレフトが出来ていなかった（=QAまかせ）
- テスト基盤が貧弱になってしまった（コンポーネントレベルのテストを整備できなかった）
- テスト網羅性の担保についてQAエンジニアの力量によってしまった
- 生成AIを活用すれば、いい感じの結果になると考えている
- まとめ
- 課題が発生してもあせらずに分類わけする
- 目線そろえを行うことで、経験によるズレを見つけやすくなる
- テスト自動化にこだわらない
- 人が介在することでより良いプロダクトになる場合もある
- 質問
- テストケース名を自然言語で書いているの意味は？
- テストケース名を日本語で示している
- アサーション目的についても日本語で定義している
- 明確なテストを書くことでAIでレバレッジが効くの意味は？
- 類似した機能に対して、いい感じのテストケースを生成できる
- 開発者の力量によらず、一定品質のテストケースを生成してくれる
- 類似した機能に対して、いい感じのテストケースを生成できる
- テストケース名を自然言語で書いているの意味は？
テストコード文化を0から作り、変化し続けた組織
・企業紹介
・登壇資料
https://speakerdeck.com/kazatohiei/tesutokodowen-hua-wo0karazuo-ri-bian-hua-sisok-ketazu-zhi
- 自己紹介
- ウエディングパークのエグゼクティブエンジニア
- 文化醸成前
- 開発者がテストコードを書く文化がない
- テストコードを書く方法を知らないといった課題
- 環境整備
- ローカルでテストコードを書く環境を整備した
- レビュー時のテストカバレッジなどをダッシュボードで見れるようにした
- カバレッジ率は2%...
- テスト目標を設定したが..
- 当たった壁
- どんなに頑張っても1%しか上がらない
- 既存コードがテストを呼び出しにくい構成
- メソッド単位でテストコードを書いてもパーセントが変わらない
- 結果として目標に追われ、テストコードの量産になってしまう
- 変化点
- テストコードへの確度が高いメンバーが参画してきた
- テストコードを含んだPRが出てきた
- アプリケーション刷新というイベントがうまれた
- テストコードを全部書くという意識が生まれた
- 結果としてカバレッジ率92%を達成
- CI環境に関しても、より効率的な形に変わってきた
- テストコードへの確度が高いメンバーが参画してきた
- リリース後の変化
- Composerを通じたパッケージの自動管理
- 人に頼らない開発環境になっていった（脱属人化）
- 今では、テストコードを自主的に書いていく文化が育っていった
- Composerを通じたパッケージの自動管理
- 全社推進に向けた動き方
- 全社へ提案した際に効果説明を求められた
- テスト仕様書をテストコードでどれだけカバーしていくかを分析
- （リプレイスアプリケーションの機能活用）
- リプレース案件ではテスト項目が約7000件あった
- 約70%テストコードでカバーできている状態
- テスト仕様書・テスト実行の工数削減に寄与することができた
- 保守運用面でも効果があるのではないか
- NECプレゼンとリンクする
- 全社へ提案した際に効果説明を求められた
- その後の世界
- 効果証明だけでは足りない
- エンジニアのテスト作成工数・スキルが分からない
- 事業メンバーへ説明が出来ない
- 今までQAテストを行わなくてもプロダクト開発は行えていた
- テストコードを書かないことが悪ではない
- エンジニアのテスト作成工数・スキルが分からない
- 考え方の変更
- 事業・プロダクトの状況を鑑み、適切な判断をできる人材を育成
- テストコードを書くためのサポートが必要
- テストコードの研修＋コンサルティングを実行
- 実行フェーズ
- 研修カリキュラムを構築し教育を実施
- 効果証明だけでは足りない
- まとめ
- テストコードを組み込むチームが増加した
- スキルアップを目的とした方も増加してきた
- 定着率などの課題点に関してはまだある状況
- 活動にに対する芽が出始めた段階
- 個人ではなく組織で動いていくことが重要
所感
テスト自動化に関しては元々興味があったですが、キャッチアップする機会がなかったため、本カンファレンスを通じてテスト自動化に対する解像度を上げることが出来たかなぁと思いました！
そのうえで、今回キャッチアップした内容について、自身の知識として定着⇒他者へ反映させていくことを行っていきます。
その他登壇資料リンク
Jupyter Notebook を活用したシナリオテストの管理と自動化
振る舞い駆動開発(BDD)における、テスト自動化の前に大切にしていること
Kubernetes対応マイクロサービスのテスト自動化：実践的アプローチと課題解決法
まだチケットを手動で書いてるの？！GitHub Actionsと生成AIでチケットの作成を自動化してみた話
最後まで、本記事を読んでいただきありがとうございます。
本記事を通じて、カンファレンスの様子を感じ取れたら幸いです。