自動システムテストのための テスト再設計と人材育成

Transcript

1. 1 © PKSHA Technology Inc. 1 © PKSHA Technology Inc. ⾃動システムテストのための テスト再設計と⼈材育成 株式会社PKSHA Technology クオリティアシュアランスグループ リーダー ⾦⼦昌永 2025年12⽉6⽇ ソフトウェアテスト⾃動化カンファレンス2025
2. 2 © PKSHA Technology Inc. ⾃⼰紹介：⾦⼦昌永 (かねこ まさのり) PKSHA AI ヘルプデスク, PKSHA ChatAgent を中⼼に、 QA エンジニアとしてテストを主に開発プロセス全体を対象とした品質保証に従事。 リーダーとして他プロダクト担当者の技術的サポート、⼈材採⽤も担当。 ⾞載機器と医療機器という組込みソフトウェア⼀筋のキャリアから AI SaaS の世界に⾶び込み早3年。 [共訳] 実践ソフトウェアエンジニアリング第 9 版（2021） インナーソースチェックリスト（2023） [発表] JaSST’24 Tokyo, ソフトウェアエンジニアリングシンポジウム2020, XP祭り2019, ソフトウェア品質シンポジウム2015 休⽇は畑に勤しむ。
3. 3 © PKSHA Technology Inc. カンファレンスページより： https://testautomationresearch.connpass.com/event/361747/ ⾃動システムテストに本格的に取り組み始めた3年前、⼿動テストを そのまま⾃動化するのでは効果は⾒込めず、テストを再設計するこ とが必要と判断しました。 現在では、テストケースあたりバグ発⾒率は⼿動時の3倍に、テスト ケース数は1700件から1000件に減り、3営業⽇早くテストが完了する ようになりました。 本発表では、その過程であるテスト設計の⼯夫と⼈材育成について お話します。
4. 4 © PKSHA Technology Inc. 前提：テスト対象と開発プロセスの概要 • 機能概要 • チャットエージェントを作る機能 • 作ったエージェントとテキストチャットする機能 • チャットした結果を分析する機能 • 成⻑中 (新機能追加、仕様変更、バグ修正、リアーキテクティング) • 企業向けSaaS (⾦融、交通、通信、⼩売、製造など多数) • ⼀般的なWebブラウザーのほか、複数のチャットツールで動作 • 毎週⽕曜にステージング環境へリリース、次の⽕曜に本番環境へリリース • その間の⼟⽇に外部ベンダーによるシステムテストレベルのリグレッションテスト • 未変更機能への悪影響がないことを確かめる全機能テスト ⼤きな修正とテストを低頻度でするよりも、⼩さな修正とテストを⾼頻度でする ⽅が品質が安定し、スピードも早まると考え、本番リリースとリグレッションテ ストを毎週⾏っている。このリグレッションテストが本発表の焦点。
5. 5 © PKSHA Technology Inc. 前提：チーム構成 PdM(Product Manager), EM(Engineering Manager) SWE(Software Engineer), QAE(Quality Assurance Engineer) によるクロスファンクショナルチーム。 システムテストレベルの活動主体はQAE。 リグレッションテストのテスト設計を担当。 現在では⾃動テストの実装、運⽤も担当。 PdM, SWE もテスト設計をレビュー。 ⼿動リグレッションテストの実⾏は外部ベンダーが担当。 QAEが実⾏指⽰、検収。 発表者はQAE2名に含まれず、チームのQA活動をリードする⽴場。 Software Engineer Entrance Book より https://pksha.notion.site/Software-Engineer-Entrance-Book-242b8721424280378a8ffd13605c1491
6. 6 © PKSHA Technology Inc. 前提：⼿動テストケース • 1⾏1テストケース、⼿順と期待結果の表形式 • 2017年からの歴史がある • 発表者は多くの現場で同様の表に出会い、その度に改善してきた • そして今回も 2022年のものから抜粋
7. 7 © PKSHA Technology Inc. ⽬次 1. はじめに結果から 2. 当初の問題構造と改善⽅針 3. テストの再設計 4. ⼈材育成 5. おわりに
8. 8 © PKSHA Technology Inc. 8 © PKSHA Technology Inc. 1. はじめに結果から
9. 9 © PKSHA Technology Inc. ⼿動テストケース数の推移 機能追加と共に テストケース数が増加 (+350件/年) ⾃動テスト 導⼊検討 削減の始まり 本格導⼊開始 1700 970 (発表現在) 機能追加は続くが テストケース数が減少 (-350件/年) 削減の始まり以降グラフ の刻みが⽬⽴つのは詳細 なデータをとるように なったから
10. 10 © PKSHA Technology Inc. ⾃動システムテストによって⾒つかったバグ数の累積 • 本格導⼊から4か⽉後の2023年8⽉、初めて⾃動テストでバグを発⾒ 🎉 • 約 30件/年 80 60 40 0 20
11. 11 © PKSHA Technology Inc. ⼿動と (⾃動 & テスト再設計) の⽐較 手動 自動 & テスト再設計 備考 テストケース比率 60% 40% ほぼAutify 一部Playwright テストケース実行 1件あたりバグ発見率 0.04 % 0.13 % 3倍見つけやすい バグ1件あたり発見費用 32 万円 13 万円 60%低減 テスト環境にデプロイ後 テスト結果が出るまでの営業日数 4 1 3営業日短縮 余裕をもって修正可能 効果が⾼まり、安くなり、早く結果が出るようになった 👏 よって本取り組みを継続し、さらなる⾃動実⾏を⽬指す。 さて、再設計とは？当初は何が問題だったのか？ 発表者から⾒て、意外と語られていない問題に切り込む。
12. 12 © PKSHA Technology Inc. 12 © PKSHA Technology Inc. 2. 当初の問題構造と改善⽅針
13. 13 © PKSHA Technology Inc. ⾃動テスト導⼊検討初期の核⼼的な問い テストケースにIDがない ⼿順はわかるが⽬的がわからない 半数以上(900+)が commonというシートに 冗⻑な⼿順 テストベースとの対応不明 実際の⽤途と かけ離れている 全体の構造は？ 個々を理解できるか？ 上記による問題例は？ 今のテストを⾃動化してよいか？ 「毎週実⾏しているのだから⾃動化しよう！」はよいとして… 効率と保守性を⾼めるため、⾃動化の前に再設計の必要ありと判断した 重要な機能のテストケースの失敗時にリリース判断しづらいことあり。 チームで2時間かけても読み解けず、作者も⽬的を覚えてない。 翌⽇に意味のないテストケースだったと判明。 など複数
14. 14 © PKSHA Technology Inc. 実は、⼀度挑戦して廃れていた • 2021年のこと • ⽬的：⼿動⽤テストケースを Autify で⾃動化すること • 実現性確認の過程で200件のテストケースを実装 • 次第に動かなくなっていった • 仕様変更に追従しない • 不安定な実装 • 何のテストシナリオなのか実装した本⼈もわからなくなった • “⾃動化”以外の⽬標がなく、効果も測定しなかった • 効果不明のまま時間が過ぎ、廃れた
15. 15 © PKSHA Technology Inc. 改善⽅針：リグレッションテスト再設計&⾃動化プロジェクト • ⽬的 • 保守コストを下げる (例：NG時の結果判断、仕様変更時の編集) • テスト結果を早く得る (本番リリース前⽇に結果がわかるのでは遅い) • ⼿段 • 1000件以上の全体を⾒通せるように構造化する • 必要⼗分であることが説明できるように再設計する • 再設計したテストを⾃動化する • リソース：識者⽀援のもと既存QAEが業務の⼀部として取り組む • 期間：テスト全体に及ぶには3年以上と⾒込む • 育成：既存QAEが⽅針を理解し、⾃律的に取り組めるように育成する • 半期毎の計画と結果確認を組織‧個⼈の公式⽬標として
16. 16 © PKSHA Technology Inc. 16 © PKSHA Technology Inc. 3. テストの再設計
17. 17 © PKSHA Technology Inc. 1000件以上の全体を⾒通せるように構造化 • 抽象機能カテゴリ > 具体機能カテゴリ の2階層に分け命名 • 例：チャットエージェントを作る機能 > { ⽂の登録, 学習, チャットUI設定…} • ⾃動テストでもこれに沿って命名している • シート数：24 → 55 • 注意が必要な分類 • 例：A機能の設定をもとに、B機能を動かし、C機能への反映を確認する テストケースは A, B, C どれに位置づける？ → B • あるテストがどのシートにあるか、不慣れな⼈も探せるようになった 👏 • どこから再設計&⾃動化を進めるか管理できるようになった 👏 900 270 150 100 90 70 50 30 500 600 10 10 10 250 130 200 Common という名では 内容想像不可 分けられていて も名前から内容 を想像しづらい チャットエージェントを 作る機能 {A, B, C…} 作ったエージェントと チャットする機能 {A, B, C…}
18. 18 © PKSHA Technology Inc. 具体機能カテゴリ毎のテスト再設計で必要⼗分を⽬指す • テストベースを明らかにする • ユーザーズマニュアル、要求仕様書、現テストケース… • パラメーターを明らかにする • ISTQBにおけるテスト条件の識別に相当 • ハイレベルテストケースを書く • 開発チーム員ならわかる程度の抽象度で書く • レビュー • ローレベルテストケースを書く • デシジョンテーブル、状態遷移表など モデルを適⽤できる場合は描く • テストケースの名前を書く • 既存テストケースに対する追加、変更、削除を区別 • ⾃動実⾏可能性を⾒積もり • レビュー リグレッション テスト設計書 再設計シート テストケース実行 1件あたり バグ発見率 3倍 自動テスト 実装 追跡可能
19. 19 © PKSHA Technology Inc. 必要⼗分にする過程で削除する場合が最も多かった 機能追加は続くがテストケース数が減少(-350件/年) ※概算値 ‧下記パターンにおける削除：-190件/年 ‧⾃動化による削除：-250件/年 ‧追加：90件/年 無則 43% テスト対象機能に関係ないパラメーターを手順 に入れている 重複 28% 他のテストケースと重複している システムテスト未満でやるべき 16% 単体テスト、結合テストで可能 用途から乖離 8% 有則だが実際の用途と激しく乖離しておりテス トする価値がない 廃止された仕様 5% 廃止された仕様だが手順は可能
20. 20 © PKSHA Technology Inc. 無則のテストはリグレッションテストでは不要 ③「仕様にない領域のテスト(無則のテスト)」が本取り組みでの問題領域。 ソフトウェアの変更時、余計な実装⑥によってバグが⽣まれうる。 そうしたバグをシステムテストで⾒つけるなら③でしか発⾒できない。 無則のテストは無限に広がりうる。アーキテクチャから影響範囲を特定する、 組み合わせテスト技法を採⽤するなどして絞り込む⼯夫をしないといけない。 そうしたテストが有⽤なのは変更時のみであり、 変更内容に関わらず実⾏するリグレッションテストでは 無則のテストは不要 (S = T を⽬指す) と決めた。 松尾谷徹：ソフトウェアテストの最新動向：7.テスト／デバッグ技法の 効果と効率, 情報処理 Vol.49 No.2 pp.168-173, 2008
21. 21 © PKSHA Technology Inc. プロジェクトで得られた知⾒をドキュメントにして標準化 リグレッションテストの… • 定義 • ⽬的 • 実⾏頻度 • ⾃動と⼿動 • テスト設計ルール • テストケース全体構造 (抽象機能カテゴリ、具体機能カテゴリ) • テスト環境 (実⾏環境、テストデータ、サードパーティツール設定…) • ⾃動テスト実装ルール、テクニック
22. 22 © PKSHA Technology Inc. 22 © PKSHA Technology Inc. 4. ⼈材育成
23. 23 © PKSHA Technology Inc. QAE2名に対する⼈材育成 • 取り組み当初の状態 • ✅製品知識、テスト設計経験が豊富 • ✅JSTQB FL の知識がある • ⚠知識を業務に応⽤できておらず何年も我流でやっている • ✅今のプロセスは⼀般的に⾒て良いか？という疑問と学習意欲がある • 注⼒したこと • 暗黙的なテストプロセスをJSTQB FL知識と対応づけられるように • 機能のパラメーターを捉え、有則と無則を区別できるように
24. 24 © PKSHA Technology Inc. 暗黙的なテストプロセスをJSTQB FL知識と対応づけられるように • テストを作ろうというとき何を参照する？ • そこから何をどう読み取る？ • ⼊出⼒？状態？順番？タイミング？データのCRUD？ユースケース？ • 例えば左図のように考えている？ • 読み取ったことを何かに書いて整理している？ …(中略：深掘り継続)… • 今まで特に暗黙的だったプロセス、重要なプロセスは右図でいうと？ → 「テスト分析ですね」👏 ⼭﨑崇：テスト開発について改めて考えてみよう！(WACATE2023招待講演) https://speakerdeck.com/yamasaki696/tesutokai-fa-nituitegai-metekao-etemiyou-tesutofen-xi-yatesutoshe-ji-woye-wu-deshang-shou-kudekiruyouninarutamenosi-fang-shan-hua
25. 25 © PKSHA Technology Inc. 機能のパラメーターを捉え、有則と無則を区別できるように • 業務で⾝近な題材から考える • この機能のパラメーターは？ • 今のテストケースにはそれ以外も書かれているが関係ある？ • 関係の有無をどうやって推測する？ • 関係しないはずのパラメーターを考慮する意味は？ • 機能の捉え⽅の解説 (先述の⼭﨑⽒資料も参照) • UML, FRAM, ゆもつよメソッドにおける論理的機能構造 • 様々な⼊出⼒の種類があることを知り、テスト分析能⼒を鍛える • 複数の⾝近な題材による訓練が必要 • このケースでは画⾯に⾒えているものを⼿順に加える癖をやめる訓練が必要だった 機能 入力 入力 入力 入力 入力 出力 出力 出力 出力 関係するはずの 関係しないはずの 関係するはずの 関係しないはずの
26. 26 © PKSHA Technology Inc. 26 © PKSHA Technology Inc. 5. おわりに
27. 27 © PKSHA Technology Inc. おわりに • まとめ • 「毎週実⾏しているのだから⾃動化しよう！」から始まったが、 効率と保守性を⾼めるため、⾃動化の前に再設計の必要ありと判断した • 再設計とは、1000件以上の全体を⾒通せるように構造化することと、 必要⼗分であることが説明できるようにすること • 必要⼗分にする過程で削除する⽅が多く、特に無則のケースを削除した • 得られた知⾒をドキュメント化し継続活動できるようにした • テストケースあたりバグ発⾒率は⼿動時の3倍に、⼿動テストケース数は1700件から 970件に減り、⾃動実⾏分は3営業⽇早くテストが完了 • まだ⼿動テストは60%あり、本活動を継続する • さらなる議論の期待 • 本カンファレンス含め、⾃動実⾏させる議論は多いものの、 それに適したテスト設計の議論を発表者から⾒ることが少なく、 類似のカジュアルな議論、事例‧⽂献共有、新規発表を期待しています
28. 28 © PKSHA Technology Inc.