こちらはベリサーブAdvent Calendar 2019の7日目の記事になります。
6日目は、M-Mshimaさんの基本情報技術者試験に合格した話でした。
概要説明
- 本投稿は、ベリサーブ主催イベント「VeriServe Academic Initiative 2019」の技術講演:1の内容を一部抜粋、編集したものです
背景
- テスト自動化という一見すると魔法のような言葉のせいか、手段や方法が先に議論されがち
- テストの自動化って言うと、勝手にロボットがやってくれるようなイメージすらある
目的
- テスト自動化にも計画が必要であることを理解する
- 計画を立てるうえで必要な情報、考慮すべきことを把握する
対象
- テスト自動化の検討をしたい/おこなっている人
- テスト自動化で過去に失敗したことのある人
言葉の説明
- テスト自動化: 特に断りのない限りは、このページでは、システムテストのテスト実行の自動化を指します
5W2Hとは
（私が）テスト自動化を「効率的」かつ「現実的」に実現するために、多角的に分解するための一つの切り口と、定義した
1. Why: 目的、導入後の効果
2. What/Where: テスト対象、テスト範囲
3. Who: 作成担当者、運営担当者
4. When: 時期、実施タイミング、システムの寿命
5. How: 導入手法、アーキテクチャ、開発プロセス、ツール
6. How much: コストの話
1. Why
- テストを自動化する目的は何か？自動化した結果何ができるのか？を考える前に自動化の得意なこと・苦手なことを整理しましょう
テスト自動化の特徴 1 & 2
テスト自動化を行う目的の例 (機能テストに限らない場合)
- 高頻度で確認したいこと
- (毎デプロイごとに)アプリ起動・終了を保証したい
- ユーザが使用するフローのTOP５をユーザの操作レベルで疎通確認しておきたい
- マネーパス（お金周り）に関するテスト
- 自動化したほうが楽になること
- システムの安定性を見るためのテスト（連続稼働テスト、同時アクセステスト、負荷テスト）
- 組合せが爆発的に多いテスト（金融、自動車）
- 人間がやると単純作業すぎて精神的に病んでしまうもの (10000回アプリを開いて閉じる、15分ボタンを連打するなど)
テスト自動化した結果、何ができるのか
- テスト自動化自体によるメリット
- 大きな実装変更を入れた際のデグレ検出、予防
- アプリ起動確認による手動システムテスト実施開始判断
- 間接的なメリット
- これまでの手動テスターに探索的テスト、UXテストをしてもらう
- 手動テストの人員をなくす?
(とは限らない、人間じゃないと気づけない不具合もあるし、そもそも自動テストだけでリリースできるシステムかどうかと言う議論も別途あったりする）
2. Where/What
- Where/What は、テスト自動化を行う対象や範囲の説明
- システムテストを全部自動化しようは、典型的な失敗パターン
- システムテスト自動化は一定のところから急激にコストが利便を上回る
- ケーブルを抜く、挿す (挿抜)
- 再起動する (電源操作)
- 指紋認証する （生体認証）
- CAPTCHAを突破する (自動化防止)
- システムテスト自動化は一定のところから急激にコストが利便を上回る
- 必ずやりたいこと、できればやりたいこと、やらないことを定義しましょう（途中で入れ替えても構いません）
3. Who
(1) 誰が構築するのか:自社でやるか、外部に任せるか
(2) 誰が運用・保守するのか
(3) 誰と協力する必要があるのか
(1) 誰が構築するのか:自社でやるか、外部に任せるか
- 自社のエンジニアがノウハウを蓄積しつつ、アンチパターンにハマらないように専門家/アドバイザ/ベンダーに頼るのが得策
- 外部に丸投げしてはいけない
- 自動テストの効果の高いポイント、難しいポイントを自社でノウハウ蓄積しないと、継続して運用することが難しくなる
- テスト対象のシステム・サービスごとに自動化の極大点は異なる、自動化のプロであっても、そのシステムについて詳しい訳ではない
(2) 誰が運用・保守するのか
- 運用・保守とは
- テストケースの追加への対応
- アプリ更新時の自動テストの追従
- テスト結果分析
- 自動テストがFAILEDを出してきた場合、何が起きたのかを改めて人間が確認する作業 ⇒自動テストはPass/Fail/Errorしか判定できない
- 構築３：保守７ともいわれている 3
- テスト結果分析
(3) 誰と協力する必要があるのか
- テスト自動化を実現するのに必要な関係者
- インフラチーム：CI/CD環境への組込みを依頼
- メンテナンスタイムを共有してもらう
- 定期的に実行するトリガーを自動化する仕組みを作る 例)真夜中に自動実行させる
-
クライアントサイド開発チーム
- 自動コードを書きやすい本体の実装（IDを埋めてもらうなど)
-
サーバサイド開発チーム
- テストしやすいAPIを作ってもらう
4. When
- どのタイミングでテストが可能になるのか
- 手動でテストできないものは、自動化できない
- いつ自動テストが必要になるか
- 一気に全部作り上げるのは特に初期は難しい
- 段階をいくつか設けると良い
- どのくらいの期間テストが実行されるのか
- 実行頻度 × 想定される期間 （１回/日 ＊ 365日 = 365回)
- 想定される期間： 自動テストが稼働することを期待する期間
5. How
- どこまで自動化が現実的に出来るのか
- テストケースを実際に手動で動かしてみる
- テストツールだけでできない場合連携するシステムはないのか
- 画像判定ツール
- ツールの選定
- キャプチャ＆リプレイツール(マウスやキーボードの操作が自動的に記録されるツール) vs. スクリプト実装(テスト用のコードを実際に書く)
- 有償 vs. 無償
- やりたいことが実現できるかをトライアルすることをおススメ
- スクリーンショットが取れるか
- モバイルで実機と連携できるか、テストケース管理ツールと連携できるか
- JavaScriptなどコード挿入による拡張性があるか
- 自動テストを作る人のスキルセット (実はこれが一番大事かもしれない、ツールありきで始めると失敗するよ！）
6. How much
- テストのコストダウン
- 条件付きでコストダウンの成果のレポートはでている 4
- 開発タームとして、2回目以降でコスト削減を実現
-
本来求められているのは、テストのコストダウンではなくて本当に必要なのは、開発全体のコストダウンではないか
- 問題の本質はテストだけではなく、プロセスやにあるのかもしれない
- 仕様の把握、品質基準の策定、テスト計画、プロセス...
- 安心してリリースできていますか？
→1から自動テストを構築した経験からすると、少なくともテスト実装した部分が動いていることはテスターにとって安心感がある
- 問題の本質はテストだけではなく、プロセスやにあるのかもしれない
テスト自動化などはDXを推進するべく、長期的に投資をしていく分野なのではないか
→ 目先のコストダウンではなく、組織としての長期的な持続可能性を探るのも一つの手だと考えている
まとめ
-
テスト自動化をする目的を必ず明確にしましょう
- 目的が曖昧、トップダウンで失敗した例は、数知れず
-
費用対効果を高めるために、細かくPDCAを回す
- 最初は小さく作ってみる
- システムとの親和性、想定コストとの差異を観察し、範囲やスケジュールを変化させていく
-
組織、システム、開発状況によって最適解が異なる
- 前例、アンチパターンだけに振り回されない
- 自社の中でノウハウをためていくことが最も重要
Thank you for your reading
ご質問、ご意見等ありましたら、このページのコメント、もしくはTwitterアカウント @pinepplecandyへお願い致します。
弊社ビジネスへのお問い合わせは、弊社お問い合わせフォームで承ります。
以下、参考文献になります。良いテスト自動化ライフを。