これから システムテスト自動化を始める 組織のための勉強会 2019/7 ぱいん 1

最初に質問です 1. みなさん、テストってしてます？動作確認はしてます？ 2. 毎週、同じテストやれって言われたらできますか？ 仕事だし頑張る? 3. 緊急リリースっていわれてテストやってと言われたやる？ 仕事だし頑張る？3日続いたら辞めたくなりませんか？ 2

自己紹介 • ぱいん • 本業：テストアーキテクト • 社外活動など – SeleniumConf Tokyo実行委員 – ソフトウェアテスト Advent calendar 作者 – ソフトウェアテスト系の勉強会に参加したり、 企画したり、発表したり • 趣味 – Twitter – カラオケ 3

今日のゴール 1.テスト自動化の大原則を理解する 2.QAチームとの付き合い方を理解する 4

このスライドでの言葉の定義 5 • 自動化エンジニア：自動テストやその実行環境を中心にエンジニアリングによって品質課題を解決 していく人 • リグレッションテスト：回帰テスト。ここでは、バグ発見というより「修正で他が壊れていないか」を見る テストに近い • 単体テスト：小さいプログラムレベルのテスト • 機能テスト・結合テスト：バックエンド（マイクロサービスやAPI群）の連携テスト。ここではシンプル に区別しない。 • E2Eテスト、UIテスト：Webやアプリだと画面を通したテスト。 • テスト自動化：（今日の話では）テスト実行の自動化のみ

おことわり • こちらの資料は、ぱいん個人の考えです。会社や所属組織の考え ではありません 6

目次 1. テスト自動化の絶対に覚えてほしいこと３つ 2. マイプラクティス 7

ミニワーク (3分) • ある日、ぱいんがQAとして1人日(8時間)だけ御社で 働くので、テスト自動化サポートしますといったら、 1. 何をお願いしますか？ 2. 理由は何ですか？ • 注意 – 粒度、書き方はお任せします – ぱいんは残業はしないもの とします★ 例) 管理機能の 組み合わせテスト パターンが多いから 例) マッチング機能の 開始～完了 良く壊れるから 8

ミニワーク (3分) • ぱいんが1人日(8時間)だけ御社で働くので、 テスト自動化サポートしますといったら、 こちらのネタバラシは、のちほど 9 例) 管理機能の 組み合わせテスト パターンが多いから 例) マッチング機能の 開始～完了 良く壊れるから

今日：絶対に覚えてほしいこと３つ 1. 自動テストの目的と手動テストの目的が違う 2. テスト自動化の８原則と解釈 3. 自動テストは開発とQAが協力して作るもの （by テスト自動化のピラミッド） 10

今日：絶対に覚えてほしいこと３つ 1. 自動テストの目的と手動テストの目的が違う 2. テスト自動化の８原則と解釈 3. 自動テストは開発とQAが協力して作るもの （by テスト自動化のピラミッド） 11

自動テストの目的と手動テストの目的が違う •自動テストの目的と手動テストの目的が違う –自動テストの目的 –手動テストの目的 ⇒に入る前に、特徴を整理してみましょう 12

自動テストと手動テストの特徴 手動テスト 自動テスト テストケースに書いていなくても 気づきがある ・なんとなく遅い ・色がおかしい ・一瞬何か映らなかった？ 繰り返し、正確な作業が得意 ・安定化試験、再現試験 ・MAX試験、設定初期値確認試験 テストする人のスキルに依存する ・ドメイン知識 ・バグが光る(?) 人が間違えやすい操作手順の難しいテス トが得意 ・割り込み試験、シミュレータ試験 臨機応変に対応できる ・既知不具合を回避する ・途中からやり直す 書いてあることしかテストできない 休みなしにテストできる 13

自動テストの目的と手動テストの目的の違い • 自動テスト – 前回から壊れていないか確認する – 確認する頻度を上げる ⇒結果として、Agility（機能追加や 変更をリリースするスピード）を高めら れる • 手動テスト – 新しい不具合を検出すること ⇒結果として、ユーザの満足度を 上げるための作業と言える 14

余談）自動テストが実際に良く使われるところ • 業務フローに対する回帰テスト（リグレッションテスト） • マネーパス（お金周り）に関するテスト • システムの安定性を見るためのテスト（連続稼働テスト、同時アクセステスト） • 組合せが多いテスト（金融、自動車） 15 なぜこれらのテストに使われるか、 自動テストの特徴と比較して 考えてみましょう

今日：絶対に覚えてほしいこと３つ 1. 自動テストの目的と手動テストの目的が違う 2. テスト自動化の８原則と解釈 3. 自動テストは開発とQAが協力して作るもの （by テスト自動化のピラミッド） 16

テスト自動化の8原則 （テスト自動化研究会製） • 1. 手動テストはなくならない • 2. 手動でおこなって効果のないテストを自動化しても無駄である • 3. 自動テストは書いたことしかテストしない • 4. テスト自動化の効用はコスト削減だけではない • 5. 自動テストシステムの開発は継続的におこなうものである • 6. 自動化検討はプロジェクト初期から • 7. 自動テストで新種のバグが見つかることは稀である • 8. テスト結果分析という新たなタスクが生まれる 17

テスト自動化の8原則 • テスト自動化研究会のいうワーキンググループの提唱した原則になります • 本家サイトはこちら: https://sites.google.com/site/testautomationresearch/test_automation_principle • (解釈) ここでいう「テスト自動化」は「システムテスト」レベルを指していると考えて読んでみてく ださい • 次のスライドからは、各原則についての – 黒文字の部分は、原則についての説明です – 青文字は、ぱいんの解釈＋補足説明です 18

テスト自動化の8原則 1. 手動テストはなくならない – ユーザビリティテストなど、そもそも自動化できないテストタイプが存在する。システムに対してはじめて実行 されるテストはテストケース自体の成熟度の観点から、手動で実施したほうがテスト実行の品質が高いケー スが多い。また、自動化がうまく進行している機能テストの残り数％など、テストを自動化するコストとベネ フィットが釣り合わないケースもある。これらの事情によって、手動で実施されるテストが無くなることはない。 • そもそも自動化できないテスト：ユーザビリティテスト、ランダムテストなど • システムテスト自動化は一定のところから急激にコストが利便を上回る – コストが利便を上回る例 （ “課題となる例” ⇒ “想定される対処策”) • ケーブルを抜く、挿す (挿抜系) ⇒専用治具を購入/作成 • 再起動する (電源系) ⇒専用治具を購入/作成 • 指紋認証する （生体系）⇒ 人工指？ • CAPTCHAを突破する (自動化防止系) ⇒APIレベルで通してしまう or 画像解析??? • 車を運転する（自動化まだ出来ていない系） ⇒ ロボットを作る？ライントレースする何かを準備する？ 19

テスト自動化の8原則 2. 手動でおこなって効果のないテストを自動化しても無駄である – そもそも、テストプロセス（e.g.テスト分析、テスト設計、テスト実装、報告）、特にテスト分析、テス ト設計が適切に行われていないテストは、優秀なテスターが手動でテストを実施したところで、テスト に期待される動作の保証やバグの検出といった効果を発揮しない。いわんや、自動テストにおいてお や、である。 • ゴミ(効果の低い)のテストケースを自動化しても、ゴミが自動実行されるだけ • 手動のテストケースをそのまま自動化は、おススメしない – 自動化に最適化されていない • 重複した手順 • 人間の理解への配慮（テストケース名） • 確認内容の曖昧さ 20

テスト自動化の8原則 • 3. 自動テストは書いたことしかテストしない – 人間による手動テストは、テストケースの記述に対して驚くほど広範な要素を暗黙的にテストして いる。これに対し、操作、合否判定を厳密に記述する必要がある自動テストにおいては、おのずと視 野は「記述された様に」限定される。ユーザ名とパスワードを入力してログインする、といったテストが自 動化されていたとして、その自動テストは仮にログイン画面に表示されているロゴが競合他社のもので あったとしても、それに気づくことはない。 • 「自動テストと手動テストの特徴」にて説明した通り 21

テスト自動化の8原則 4. テスト自動化の効用はコスト削減だけではない – もし、テスト自動化によってなんらかのコストが削減できるとしたら、十分に成熟しているテストケースが 既に存在しており、そのテストは今後何度も実行される予定があり、自動テストの開発を円滑に進め るための準備が完了している場合と、テストの手順が同じで、テストすべきデータが膨大に存在する 場合の「テスト実行」のコストである。テスト自動化には、繰り返し型開発におけるセーフティネットとし ての役割や、バグ修正日数の低減、影響範囲レビュープロセスの代替、といった、開発アクティビティ への効用も存在するため、冒頭にあげたひどく限定された局面を狙うより勝ち目があるかもしれない。 • テスト実行するコストは０になるが、テスト実行の前処理後処理は人の手が必要 • 経験上、テストだけで見るとコスト削減はできない。むしろ、メンテナンスなどのコストは増える • セーフティネットとして、機能拡張・変更へのシステムとして柔軟性を持つこと、 作りこみ不具合の早期検出などの副次的効果が大きい 22

テスト自動化の8原則 5. 自動テストシステムの開発は継続的におこなうものである • テスト自動化に関わる苦労を10とすると、自動テストシステムが完成するまでが3、残りの7は運用に関す るコストである。テスト対象の変化への追従、テストケース、テストタイプ自体の追加、変更に対する適応、 といった、今あるものが継続的に効果を発揮するための活動はもとより、自動テストのターンアラウンドタイム の向上、信頼性の向上、などなど、システムの価値を向上させていくための活動など、やるべきことは多岐に 亘る。テスト自動化システムの提供はプロジェクトというよりサービスとしてとらえるべきである。 • 自動テストの苦労 構築３：運用７ – システム仕様の変更に対する追従 – 画面仕様（画面遷移、部品）の変更 – システム挙動の変化 – テストケースの追加、変更 • システムがEOLするまで追従する覚悟、または、追従をあきらめる決断が必要 23

テスト自動化の8原則 6. 自動化検討はプロジェクト初期から – 自動化を考慮せず「出来上がってしまった」システムに対して自動テストを書いていくことは、よくあるテスト自動化エンジ ニアの苦行のひとつである。自動テストシステムがシステムをよりよく操作、判定できるように、ひいてはセーフティネットを 最適なコストで構築するためにはシステム側で最初から検討して設計に織り込んでおく必要がある。また、繰り返し実 行されるテストが予めわかっているなら、自動化を前提として、テスト計画を策定すれば効果的である。開発初期から、 テスト自動化を考慮した設計・実装をしておく • テスト自動化を考慮した設計・実装とは – テスト用APIの設計・実装 （ユーザ作成、画面コンポネントへの直リンク、テスト用リセット機能） – IDの埋め込み – 実装方針のルール化、統一(主にフロントエンド) ⇒設計・実装・インフラと協力して開発できるチームであることはテスト自動化成功のためのカギ 24

テスト自動化の8原則 7. 自動テストで新種のバグが見つかることは稀である – 運用に乗った自動テストは基本的に「枯れた」テストケースを対象とするため、ほとんどの種類のバグはテスト ケースを枯らす過程、あるいは自動テストを実装する過程で既に人間によって発見されているはずである。 多くの運用に乗った自動テストの意義は「一度動いたはずの機能がうっかり壊れる」ことを最速で発見する ことにある。ただし、手順が同じでデータの種類が膨大なテストを自動化する場合、ファジング、テストパター ンを有機的に生成できるAPIレイヤのテスト、ブラウザやRDBなどのバージョンアップの影響を受けていないこ とを確認するテストなど、いくつかの例外もある。 • テスト実装時: 自動化を実現させるために見つけるバグ（いわゆる、自動化ブロッキングバグ）が 大半 • 運用時：デグレードを検出する • (経験上)検出できる例外系 – タイミングに起因するバグ（高速操作で発生、人間の操作では起きないもの） – 連続稼働、繰り返し処理によるバグ 25

テスト自動化の8原則 8. テスト結果分析という新たなタスクが生まれる – マニュアルテストでバグが発見された場合、その再現手順は明らかであるから人間はある程度の最適 化ののち、即座にバグ登録を行う。しかし、自動テストがFAILEDを出してきた場合、何が起きたのか を改めて人間が確認する必要がある。これが1日数件ならまだかわいいものであるが、自動テストが 無事？拡大した結果、数万件のテストケースに対して数千件のFAILEDが検出されたとしよう。それ を種類ごとに仕分ける作業だけでも憂鬱である。自動テストが拡大した結果、テスト結果分析のコス トがそれに伴ってリニアに伸びないような施策、例えばコールスタックやAPIコール履歴などから、ある程 度自動的にFAILEDを仕分ける機構などを検討する必要がある。 • テスト結果分析ですること – 何が起きたのか（ログ、エビデンスから追いかける) – どこの手順で不具合が起きたのか（ログから追いかける) – テストコードのミスか、システムのバグか（発生事象とテストコードから追いかける） ⇒実行結果はPASS/FAILのみ。これらが整理出来て、ようやく不具合起票できる 26

雑談）月曜から夜更かし(風) • 手段が目的化している問題 – お客様「テスト自動化を進めたい！」 – ぱいん「はい、よろこんでっ！何を自動化で目指したいんでしょうか？」 – 客「いや、だからっ、テストを自動化したい（イラッ）」 – ぱいん「」 – ありがちな問題。 – 考察： • テスト自動化に対しての、目的があいまい、どういう効果があるか理解されていないお客様も多い。 • そういう場合に限って、作業だけ切り出してきて仕舞には「テスト自動化の効果ながかった」と言われるのがつらい • なので、テスト分析段階から協力して考えていきたい 27

今日：絶対に覚えてほしいこと３つ 1. 自動テストの目的と手動テストの目的が違う 2. テスト自動化の８原則と解釈 3. 自動テストは開発とQAが協力して作るもの （by テスト自動化のピラミッド） 28

テストピラミッド ユニットテスト UIテスト 開発のためのもの 検証のためのもの フィードバックが 早い フィードバックが 遅い 局所的 エンドツーエンド 実行が早い 実行が遅い 頑健 壊れやすい 安い 高い UI (E2E) Service (API) Unit $$$ $ 29

誰がテストするのか • 開発者にとってのテスト – 最小限に済ませたい – 早くリリースしたい • QAエンジニアにとってのテスト – 出来るだけ全てをテストしたい – 慎重にリリースしたい • みんなでテストをしよう – 品質はみんなで上げるもの – Unitテストをしっかり書けば、結果として、リリースが早くできる – 組織の状況に応じてやっていくしかない – UIテストで「カバレッジをxx%にしよう」はアンチパターン UI (E2E) Service (API) Unit $$$ $ QA Dev Dev 30

テスト対象のシステムの処理を上の四角い箱だと考えてください。 ユニットテストは1個ずつの範囲は小さいがピンポイントで狙うことが出来る UIテストは、虫食いのようにパスをカバーできるが、隅っこ(例外)などは残りがち。 これらを組み合わせることが、テストを効率的にやるためには必要となります。 31

じゃあ、どうすればいいんですか？ • と思いますよね。私は思います。 • これはやってはいけない、みたいな話して、自動化どうするの？ • という皆さんの声にお応えして、 32

ワーク２：テスト自動化アーキテクト体感ワーク • お題：貴方はQAのマネージャです。新システムのテスト自動化を任されたら、どういう自動テス ト(システムテスト）を作るか • 成果物（以下のセット）： – テストの名前（どういうテストをするかわかるもの） – テストの目的 – 実現するために必要な準備 • 流れ – 個人ワーク（5分） – グループワーク（10分くらい） – シェア（1グループ1分） 33

ワーク２：テスト自動化アーキテクト体感ワーク • ケース 34

ワーク２：テスト自動化アーキテクト体感ワーク • お題：貴方はQAのマネージャです。新システ ムのテスト自動化を任されたら、どういう自動テ スト(システムテスト）を作るか • 成果物（以下のセット）： – テストの名前（どういうテストをするかわかるも の） – テストの目的 – 実現するために必要な作業 • 流れ – 個人ワーク（5分） – グループワーク（10分くらい） 35

補足） • テストを検討する機能 （これ以外の機能はテスト対象としない） – ユーザ側機能 • 配車予約機能 • 配車キャンセル機能 • 予約車両位置確認機能 – ドライバ側機能 • 配車依頼受信機能 36

ワーク２：テスト自動化アーキテクト体感ワーク • 私なりの回答案 37

まとめに代えて マイプラクティス:経験から得たTipsの紹介 38

マイプラクティス (≠ベストプラクティス) • これまで見てきたプロジェクトでうまくいったりいかなかったりする要因 を自分なりにまとめた 1. 計画（目的、範囲、期限）を立ててから方法を考えること 2. 完全並行運用から始める。自動化に任せる範囲を徐々に増や していく 3. ためす→まなぶ→なおす→ためす、のループを早く回すこと。最初 から成功を狙わない 39

マイプラクティス (≠ベストプラクティス) 1. 計画（目的、範囲、期限）を立ててから方法を考えること –手動テストに比べて、自動テストは準備するまで、1回目実行して以 降（運用）のコストが重い –必ず、優先度は付ける • 細かく刻むのが良い（テストケースA ＞ テストケースC ＞テストケースB) • 時間で切るのもアリ –1カ月に1回振り返る、見直すのがおススメ • 起きたことを覚えていられる限界 • 調整（e.g. 増員、減員)も現実的に可能 40

マイプラクティス (≠ベストプラクティス) 2. 完全並行運用から始める。自動化に任せる範囲を徐々に増や していく –1回も手動実行していないテスト、かつシステムが開発中であれば通る までに一苦労するはず –人的リソース、コストが割けないのであれば、タイミングをずらす、見送 るのも一つの手 41

マイプラクティス (≠ベストプラクティス) 3. ためす→まなぶ→なおす→ためす、のループを早く回すこと。最初 から成功を狙わない –本体システムの特性によって難易度が大きく変わる • 簡単： 静的Webサイト • 難易度中：非同期Webアプリ • 難易度高：非同期Webアプリ＋デバイス連携 –ツールの特性、メンバ構成、習熟度にも大きく依存する –始められそうなところをまずやってみる、慣れてきたら本丸に挑戦するの もアリ 42

参考文献、サイト No. Slide # ページ名 URL 1 5, 14 輝く未来を抱きしめて。ア ジャイル・DevOps時代の品質 組織づくり (IT検証フォーラム 2019) https://speakerdeck.com/daipresents/hui-kuwei- lai-wobao-kisimete-aziyairudevopsshi-dai- falsepin-zhi-zu-zhi-dukuri-c31f59fe-d95e-4452- 8cba-34407ce94689?slide=10 2 13 WACATE2018冬 テスト自動 化セッション https://www.slideshare.net/mirer/automation- session-public 3 13 自動化ツール導入のコツ（日 本ノーベル） https://www.jnovel.co.jp/service/qc/automation/au to-point.html 4 17-26 テスト自動化の8原則(テスト 自動化研究会) https://sites.google.com/site/testautomationresearc h/test_automation_principle 5 31 Lean Testing or Why Unit Tests are Worse than You Think (blog) https://blog.usejournal.com/lean-testing-or-why- unit-tests-are-worse-than-you-think-b6500139a009 6 29-30 The Practical Test Pyramid (martinFowler.com) https://martinfowler.com/articles/practical-test- pyramid.html 7 Some いらすとや https://irasutoya.com 43

ご清聴ありがとうございました • ご質問・お問い合わせ • ぱいん @pineapplecandy on Twitter 44