ソフトウェアテスト自動化、一歩前へ Yoshiki Ito / TEST Study #2, June 30

おことわり ◼ 資料はあとでSpeaker Deckに公開予定 ◼ スライドのスクショ撮影、SNSシェア等OK 2

前回 TEST Study #1 「品質とスピード」 3 ◼ YouTubeで視聴可能。まだの方はぜひ https://www.youtube.com/watch?v=fX0DtxTTZXc

目次 1. はじめに 2. ソフトウェアテストの自動化 3. テストピラミッド＆類似のモデル 4. 一歩前に進める現実的なやりかた 5. まとめ 4

伊藤由貴（@yoshikiito） ◼ テスト自動化エヴァンジェリスト ◼ 仕事の経歴 ⚫ 2012年 株式会社ベリサーブに新卒入社し、 テスト・QAの世界へ ⚫ 2019年～ 自動テスト推進課を立ち上げ、 社内外でテスト自動化の普及・推進活動を行っている ◼ コミュニティ活動 ⚫ NPO法人日本ソフトウェアテスト技術振興協会 会員 ⚫ JSTQB AL シラバス テスト自動化エンジニア 日本語翻訳ワーキンググループ 5

普段の仕事について https://www.veriserve.co.jp/corp/ より 6

本講演の概要 7 Point1 “テスト自動化”のいろいろな側面を知る Point2 テスト自動化で「良い」とされている状態を知る Point3 理想と現実をどう近づけていくのか、を考える

目次 1. はじめに 2. ソフトウェアテストの自動化 3. テストピラミッド＆類似のモデル 4. 一歩前に進める現実的なやりかた 5. まとめ 8

Q：みなさんはどんな「テスト」をやっていますか？ あるいは、どんな「テスト」をイメージしますか？ 9

“ソフトウェアテストの自動化” は広い ◼ 人（役割）によって、“テスト”でイメージする範囲が違う ⚫ 人（役割） ⚫ 開発者、テスター、QAエンジニア、発注者 などなど ⚫ イメージする範囲≒テストレベル ⚫ 単体テスト、結合テスト、システムテスト、受け入れテスト などなど ◼ 特定の、特に自分が関わる部分だけでなく、 広い「テスト」「テスト自動化」を色々な側面から見ることが大事 10

アジャイルテストの4象限 11 『実践アジャイルテスト』P96より 単体テスト コンポーネントテスト 機能テスト 例 ストーリーテスト プロトタイプ シミュレーション 探索的テスト シナリオ ユーザビリティテスト UAT（受入テスト） アルファ／ベータ パフォーマンス／負荷テスト セキュリティテスト 「～性」テスト 自動 手動 自動と手動 ツール Q1 Q2 Q3 Q4 技術面 ビジネス面 チ ― ム を 支 援 す る 製 品 を 批 評 す る

アジャイルテストの4象限のうち自動化に向いている範囲 12 『実践アジャイルテスト』P96より 単体テスト コンポーネントテスト 機能テスト 例 ストーリーテスト プロトタイプ シミュレーション 探索的テスト シナリオ ユーザビリティテスト UAT（受入テスト） アルファ／ベータ パフォーマンス／負荷テスト セキュリティテスト 「～性」テスト 自動 手動 自動と手動 ツール Q1 Q2 Q3 Q4 技術面 ビジネス面 チ ― ム を 支 援 す る 製 品 を 批 評 す る

Testing vs Checking 13 ◼ Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process of confirmation, verification, and validation. When we already believe something to be true, we verify our belief by checking. ◼ チェックとは、既存の信念を確認する動機で行うものである。確認は、確認、検証、そして妥当性確認のプロ セスである。私たちがすでに何かを真実だと信じているとき、私たちはチェックすることによってその信念を 確認します。 Checking ◼ Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing. ◼ テストとは、新しい情報を見つけようという動機で行うものです。テストは、探索、発見、調査、学習のプロセス です。製品を評価するつもりで、あるいは想定していなかった問題を認識するつもりで、製品を構成し、操作 し、観察することがテストです。 Testing Blog: Testing vs. Checking より 日本語訳はDeepL

Testing vs Checkingのうち自動化に向いている範囲 14 ◼ Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process of confirmation, verification, and validation. When we already believe something to be true, we verify our belief by checking. ◼ チェックとは、既存の信念を確認する動機で行うものである。確認は、確認、検証、そして妥当性確認のプロ セスである。私たちがすでに何かを真実だと信じているとき、私たちはチェックすることによってその信念を 確認します。 Checking ◼ Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing. ◼ テストとは、新しい情報を見つけようという動機で行うものです。テストは、探索、発見、調査、学習のプロセス です。製品を評価するつもりで、あるいは想定していなかった問題を認識するつもりで、製品を構成し、操作 し、観察することがテストです。 Testing Blog: Testing vs. Checking より 日本語訳はDeepL

目次 1. はじめに 2. ソフトウェアテストの自動化 3. テストピラミッド＆類似のモデル 4. 一歩前に進める現実的なやりかた 5. まとめ 15

テストピラミッド 16 TestPyramid より • UI≒End to End • Service≒Integration

アイスクリームコーン 17 The Software Testing Ice Cream Coneより（※原典がドメイン切れ？のため別サイトより引用）

似たようなモデル 18 Fixing a Test Hourglass より https://twitter.com/kentcdodds/status/960723172591992832 より

バグフィルター 19 『A Practical Guide to Testing in DevOps Japanese Edition』 セクション6 DevOpsにおけるテスト戦略 より

ピラミッド＆類似のモデルからの学び 20 ◼ 特定のテストレベル（自分が関わっているテストレベル）に閉じず、 テスト全体、各レイヤーの総体としてどうテストするかを考える ⚫ 良いとされているモデルを参考にしつつも、自分たちにとって最適な形を模索すべし

目次 1. はじめに 2. ソフトウェアテストの自動化 3. テストピラミッド＆類似のモデル 4. 一歩前に進める現実的なやりかた 5. まとめ 21

「テストを自動化したいんです」というときのよくある実情 22 開発状況 既にプロダクトはリリース済で機能追加・改修フェーズ 単体・結合テスト ほぼない or どれだけあるのか把握されていない E2Eテスト 手動で行っているが追いつかない、不具合を見逃してしまう

負のサイクル 23 修正 コスト大 テストが 不十分 不具合 が多い ココを自動化で なんとかする

理想を掲げるだけでは前に進めない 24 ◼ 単体・結合テストがほぼ無く、E2Eテストでなんとかしている場合 ⚫ 理想：単体テストから整備する。テストピラミッドなどから、費用対効果も良いはずである。 ⚫ 現実：単体テストができない。 理想通りでないからやらない、では改善されない。

現実的な道 25 無

アンチパターンであることを理解したうえで、やる 26 ◼ アンチパターンである理由がいわゆる「コスパ」であれば、 受け入れるという選択肢もある ⚫ どのみち、どこかでお金と時間をかけなければ成功しない ◼ 単体テストから整備するべきである、という共通認識は持ちつつも、 E2Eテストから整備することで 「ユーザーにとって不利益になっていない」ことを担保できる状態を作る

現実的な道①：E2Eテストを整備する 27 無

E2Eテスト、どこからやるか 28 ◼ E2Eテストは100%自動化をめざすとうまくいかない（ことが多い） どんな順番でどこまでやるか、を考える必要がある ◼ 順序・範囲を決める方法はいくつかある ⚫ 大まかには、なんらかのスコアをつけて上から順にやる方法

『リーン開発の現場』のやり方 29 ◼ リスク、手動テストのコスト、自動化コスト、に大小をつけ リスクと手動テストのコストが大の部分からやる 質とスピード（2022春版、質疑応答用資料付き）P105~111 より

Angie Jonesのやり方 30 ◼ 直感（G）、リスク（R）、価値（V）、費用対効果（C）、過去の状況（H）で スコアを付け、自動化対象を選択する方法 オリジナル：Which Tests Should We Automate? by Angie Jones 講演者によるブログ記事：自動化するテストの選択方法（自動化スコアで判断する方法） いずれの方法も、 チームで優先順位・ 範囲を考え、 合意することが大事！

今ある（手動実行前提の）テストケースをそのまま自動化しない 31 ◼ 懸念点 ⚫ 手順や確認項目が曖昧な場合、不安定・低信頼な自動テストになる ⚫ テストケースに依存関係が含まれがちで、Fail時の原因調査や保守が大変 ◼ 例外 ⚫ E2Eテストの自動化をこれから始める、ツールの適合性を確認する、 というときには既存のテストケースを一部コンバートしてみるのはアリ ◼ 対策 ① 今あるテストケースの再構成や詳細化をして使う ② 「テストケース」になる前から考える

テスト設計プロセスに自動化検討を組み込む 32 ◼ テストケースから自動化対象を選ぶのではなく、 テスト設計（以前）からテスト自動化を考慮 テスト設計コンテスト’21 OPENクラス エムスリーQAチームプレゼン資料より

現実的な道②：E2Eテスト以前を整備する 33 無

E2Eテストをセーフティネットにして、より前段のテストを整備 34 ◼ 単体テストができない技術的な理由の例 ⚫ クラスや関数同士が密結合になっていて、そのままでは単体テストができない。 単体テスト可能な状態にしようとすると、壊してしまいそう ◼ E2Eテストを頼りにまずは「単体テストができる状態」を目指して 手を入れていく ⚫ 何か問題が起こったら、E2Eテストが一定検知してくれる

単体テスト、どこからやるか 35 ◼ 『ソフトウェア品質を高める開発者テスト』のやり方 ⚫ ほとんどのバグはソースコードファイルの10%~20%から出る、という考えに基づく ⚫ 複雑度（ファイル行数と相関）とHotspot値（バグの出やすさを数値化したもの） によってスコア付け ⚫ 複雑度が高いものはファイルを分割し、単体テストを書いていく

目次 1. はじめに 2. ソフトウェアテストの自動化 3. テストピラミッド＆類似のモデル 4. 一歩前に進める現実的なやりかた 5. まとめ 36

まとめ 37 ◼ いきなりベストプラクティスの通りでなくとも良いので、 理想を目指して多少の遠回りを許容しつつもテスト自動化をすすめよう ⚫ 知らずにアンチパターンを踏むのと、理解しつつ一部を許容するのとでは全く異なる

ありがとうございました この続きは後半のパネルトークで！ イベント後に質問・感想・ご意見などあれば以下までお願いします ☺ ◼ e-mail: yoshikiito.elあっとgmail.com ◼ Twitter: @yoshikiito