これからシステムテスト自動化を始める組織のための勉強会2019/7ぱいん1
View Slide
最初に質問です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$$$$QADevDev30
テスト対象のシステムの処理を上の四角い箱だと考えてください。ユニットテストは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 # ページ名 URL1 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=102 13 WACATE2018冬 テスト自動化セッションhttps://www.slideshare.net/mirer/automation-session-public3 13 自動化ツール導入のコツ（日本ノーベル）https://www.jnovel.co.jp/service/qc/automation/auto-point.html4 17-26 テスト自動化の8原則(テスト自動化研究会)https://sites.google.com/site/testautomationresearch/test_automation_principle5 31 Lean Testing or Why UnitTests are Worse than YouThink (blog)https://blog.usejournal.com/lean-testing-or-why-unit-tests-are-worse-than-you-think-b6500139a0096 29-30 The Practical Test Pyramid(martinFowler.com)https://martinfowler.com/articles/practical-test-pyramid.html7 Some いらすとや https://irasutoya.com 43
ご清聴ありがとうございました• ご質問・お問い合わせ• ぱいん @pineapplecandy on Twitter44
pineapplecandy
onlinesalon
yukimatsuyoshi
naohachi89
toshi0383
k1style
pkshadeck
route06
niftycorp
masasuzu
yoshiitaka
smt7174
dougneiner
chrislema
zakiwarfel
paigeccino
aleyda
malarkey
garrettdimon
brad_frost
akosma
geoffreycrofte
danielanewman
jnunemaker