![Step4 ツールをキーワード駆動にしてチームに展開
GAS
実行
Scenario.json
シナリオ生成ツール作ったから
各々で作っといて！
[{test_no:0001,
order_day:2023-01-01,
span:12,
:
},{test_no:0002,
order_day:2023-01-01,
span:12,
:
}
]](https://image.slidesharecdn.com/random-240227041417-6b3c6b13/85/00001_test_automation_portfolio_20240227-21-320.jpg)
More Related Content
Similar to 00001_test_automation_portfolio_20240227 (20)
Recently uploaded (11)
00001_test_automation_portfolio_20240227
- 2. 自己紹介 名前：池田 経歴：開発 5年、SET 1年、QA 1年目 趣味：ロードバイク、キャンプ、サウナ 特技：コスプレ、3Dプリンタ造形、カメラ、小型船舶操縦 資格：基本情報、AWS SAA、JSTQB FL
- 3. 目次 ● 前提 ● 自動化の流れ ○ Step1 テスト実行を自動化 ○ Step2 確認対象データ出力を自動化 ○ Step3 データ突合を自動化 ○ Step4 ツールをキーワード駆動にしてチームに展開 ○ Step5 リグレッションテスト導入 ● 自動化して良かったこと ● 所感
- 7. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 8. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 10. アプリ Step1 操作自動化(af) RDB 契約 請求 API CLI (スクリプト) APIエンドポイントを叩く ?Pythonのrequests ?PostMan Webブラウザの操作自動化 ?Selenium(バックグラウンド実行 ) ?Selenium IDE(画面ポチポチでコード生成 ) ?Autify 注文パ ターン 100
- 11. アプリ Step1 操作自動化(af) RDB 契約 請求 API CLI (スクリプト) APIエンドポイントを叩く ?Pythonのrequests ?PostMan Webブラウザの操作自動化 ?Selenium(バックグラウンド実行 ) ?Selenium IDE(画面ポチポチでコード生成 ) ?Autify 注文パ ターン 100
- 12. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 14. アプリ Step2 確認対象データ出力を自動化(af) RDB 契約 請求 API CLI (スクリプト) 請求パ ターン 100 ●APIエンドポイントを叩く ?Pythonのrequests(GET系) ●SQLコマンドで取ってくる ●ブラウザに表示される値を取得 ?Selenium(バックグラウンド実行 ) mysql db_name -ss -e “SELECT * FROM invoice” id 利用開始日 利用終了日 請求日 1 1/1 1/31 2/1 2 2/1 2/28 3/1 3 :
- 15. アプリ Step2 確認対象データ出力を自動化(af) RDB 契約 請求 API CLI (スクリプト) 請求パ ターン 100 ●APIエンドポイントを叩く ?Pythonのrequests(GET系) ●SQLコマンドで取ってくる ●ブラウザに表示される値を取得 ?Selenium(バックグラウンド実行 ) mysql db_name -ss -e “SELECT * FROM invoice” id 利用開始日 利用終了日 請求日 1 1/1 1/31 2/1 2 2/1 2/28 3/1 3 :
- 16. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 17. アプリ Step3 確認する値を突合(bf) RDB CLI (スクリプト) 請求パ ターン 100 mysql db_name -ss -e “SELECT * FROM table_name” id 利用開始日 利用終了日 請求日 1 1/1 1/31 2/1 2 2/1 2/28 3/1 3 : 確認してOK/NGを入力 コピペ 確認してOK/NGを入力 確認してOK/NGを入力 確認してOK/NGを入力 確認めんどいな......
- 18. var1.0 ver1.1 Ver1.0 Step3 確認する値を突合(af) CLI (スクリプト) Ver1.1 請求パ ターン 100 請求パ ターン 100 id 利用開始日 利用終了日 請求日 1 1/1 1/31 2/1 2 2/1 2/28 3/1 3 : diff ver1.0_0001_start_day.txt ver1.1_0001_start_day.txt 開始日 1/1 2/1 3/1 開始日 1/1 2/1 3/1 var1.0 ver1.1 終了日 1/31 2/28 3/31 diff ver1.0_0001_end_day.txt ver1.1_0001_end_day.txt id 利用開始日 利用終了日 請求日 1 1/1 1/31 2/1 2 2/1 2/28 3/1 3 : result 0001_start_day OK 0001_end_day NG 0001_invoice_day OK : 終了日 1/31 2/28 3/28 データを整形してtxt出力、diffコマンド 用にデータを整形してtxt出力、diff結 果を一覧表示
- 19. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 20. Ver1.0 Step4 ツールをキーワード駆動にしてチームに展開(bf) CLI (スクリプト ) Ver1.1 請求パ ターン 100 請求パ ターン 100 result_v1.0_vs_v1.1 0001_start_day OK 0001_end_day OK 0001_invoice_day OK : 開発メンバー 開発メンバー 開発メンバー ver1.0->1.1 分割系確認してほし い ver1.1->ver1.1.1 日割り系確認してほ しい。 (仕様は口頭) ver1.0->1.2 月跨ぎ確認してほし い 仕様書 仕様書 仕様書 仕様書 Ver1.1 CLI (スクリプト ) Ver1.1. 1 請求パ ターン 100 請求パ ターン 100 result_v1.1_vs_v1.1.1 0001_start_day OK 0001_end_day OK 0001_invoice_day OK : Ver1.0 CLI (スクリプト ) Ver1.2 請求パ ターン 100 請求パ ターン 100 result_v1.1_vs_v1.2 0001_start_day OK 0001_end_day OK 0001_invoice_day OK : 各々でシナリオ作ってテスト 回してくれないかな......
- 22. Ver1.0 Step4 ツールをキーワード駆動にしてチームに展開(af) CLI (スクリプト ) Ver1.1 請求パ ターン 100 請求パ ターン 100 result_v1.0_vs_v1.1 0001_start_day OK 0001_end_day OK 0001_invoice_day OK : 開発メンバー 開発メンバー 開発メンバー Ver1.1 CLI (スクリプト ) Ver1.1. 1 請求パ ターン 100 請求パ ターン 100 result_v1.1_vs_v1.1.1 0001_start_day OK 0001_end_day OK 0001_invoice_day OK : Ver1.1 CLI (スクリプト ) Ver1.2 請求パ ターン 100 請求パ ターン 100 result_v1.1_vs_v1.2 0001_start_day OK 0001_end_day OK 0001_invoice_day OK : 問い合わせ ツールメンテナンスは任せろ～ シナリオ シナリオ シナリオ
- 23. 自動化の流れ Step1 テスト実行を自動化 Step2 確認対象データ出力を自動化 Step3 データ突合を自動化 Step4 ツールをキーワード駆動にしてチームに展開 Step5 リグレッションテスト導入
- 25. 自動化して良かったこと ● テスト工数削減(step1,2,3) ● バグの早期検出(step4) 開発メンバーが製造段階で影響範囲のテストを実施するので、統合テストでのバグが減った ● レビューの負担軽減(step5) システムの仕様上、ユースケースの入力パターンが多く、条件が複雑だった為、開発メンバーが仕様を把握して切れず、考慮漏れに よるバグが多発していた。※設計レビューはアドホック形式 →レビュー段階で「ユースケース一覧のこの範囲をテストする」というテスト項目(テスト実行シナリオ)レビューも一緒に行うことで、開 発担当とレビュアーの影響範囲の認識齟齬や場当たり的な指摘が減った。