Weitere ähnliche Inhalte Ähnlich wie 20190531 jasst19 tohoku (20) Mehr von Sadaaki Emura (14) 20190531 jasst19 tohoku3. 3
Who am I
Name : Sadaaki Emura (nickname M)
Join in Rakuten : 2007
Career : Embedded engineer (2000-2002)
Web engineer (2002-2015)
Product manager (2015-2016)
QA (2016~)
Role: Test Automation Engineer Lead
Birthplace : Kanazawa-city
Hobby: jog , climbing , horse racing
5. 5
Our team (QA)
Scope : 5 services
Members : 10 + off site
Skill : QA specialist (almost not programmer)
Mission : Quality Assurance
by manual & automation test
10. 10
Small team in 2016 ~
• Test Management
• Test Analysist
• Test Automator
• Test Designer
• Tester
11. 11
Big organization in 2018 ~
• Test Management
• Test Analysist
• Test Designer
• Tester
• Test Automation Lead
• Automation Designer
• scripter
Manual Test team / each service Automation Test team
ロールベースで作業分離
19. 19
Improvement point 1st
テスト自動化設計書のテンプレート before
大分類 機能 フロー 概要 条件・パラメータ
投票 通常投票 ログイン → 投票ページ
→ 馬選択 → 確認 →
完了
買い目、買い方、馬をえらん
で投票する機能
式別(単勝、~三連単)
方式(通常、~フォー
メーション)
:
オッズ投票 オッズをソートして、そこか
ら欲しい馬券を選んで投票す
る機能
:
例 楽天競馬
20. 20
Improvement point 1st
機能 テスト観点
テスト目的
テスト前提 条件・パラ
メータ
CI条件 自動化の処理概要 自動化しない
こと
通常投票 • 正常購入処理
• 購入方法の網羅
• 馬券を正しく購入
できること
• 競馬会員ユーザ
• 十分な残高
式別(単勝、~
三連単)
方式(通常、~
フォーメーショ
ン):
購入回数上限 1. ログイン
2. お金の入金
3. 買目、馬を選ぶ
4. 購入する
5. 照会で確認
買った馬券の妥当
性は確認しない
一定条件で購入不可 • 競馬会員以外
• 残高不足
• 発売締切り
オッズ投票 1. ログイン
2. お金の入金
3. オッズから馬券を選ぶ
4. 購入する
5. 照会で確認
: • 会員登録
• 正常に登録
• 一日一回 1. 楽天ID作成
2. 会員申し込み
テスト自動化設計書のテンプレート after
21. 21
Improvement point 1st
機能 テスト観点
テスト目的
テスト前提 条件・パラ
メータ
CI条件 自動化の処理概要 自動化しない
こと
通常投票 • 正常購入処理
• 購入方法の網羅
• 馬券を正しく購入
できること
• 競馬会員ユーザ
• 十分な残高
式別(単勝、~
三連単)
方式(通常、~
フォーメーショ
ン):
購入回数上限 1. ログイン
2. お金の入金
3. 買目、馬を選ぶ
4. 購入する
5. 照会で確認
買った馬券の妥当
性は確認しない
一定条件で購入不可 • 競馬会員以外
• 残高不足
• 発売締切り
オッズ投票 1. ログイン
2. お金の入金
3. オッズから馬券を選ぶ
4. 購入する
5. 照会で確認
: • 会員登録
• 正常に登録
• 一日一回 1. 楽天ID作成
2. 会員申し込み
テスト自動化設計書のテンプレート after
• 自動化処理内容の可視化
• テスト観点を明示
22. 22
Improvement point 1st
機能 テスト観点
テスト目的
テスト前提 条件・パラ
メータ
CI条件 自動化の処理概要 自動化しない
こと
通常投票 • 正常購入処理
• 購入方法の網羅
• 馬券を正しく購入
できること
• 競馬会員ユーザ
• 十分な残高
式別(単勝、~
三連単)
方式(通常、~
フォーメーショ
ン):
購入回数上限 1. ログイン
2. お金の入金
3. 買目、馬を選ぶ
4. 購入する
5. 照会で確認
買った馬券の妥当
性は確認しない
一定条件で購入不可 • 競馬会員以外
• 残高不足
• 発売締切り
オッズ投票 1. ログイン
2. お金の入金
3. オッズから馬券を選ぶ
4. 購入する
5. 照会で確認
: • 会員登録
• 正常に登録
• 一日一回 1. 楽天ID作成
2. 会員申し込み
テスト自動化設計書のテンプレート after
• 実施条件の明示
• 網羅性の可視化
23. 23
Improvement point 1st
機能 テスト観点
テスト目的
テスト前提 条件・パラ
メータ
CI条件 自動化の処理概要 自動化しない
こと
通常投票 • 正常購入処理
• 購入方法の網羅
• 馬券を正しく購入
できること
• 競馬会員ユーザ
• 十分な残高
式別(単勝、~
三連単)
方式(通常、~
フォーメーショ
ン):
購入回数上限 1. ログイン
2. お金の入金
3. 買目、馬を選ぶ
4. 購入する
5. 照会で確認
買った馬券の妥当
性は確認しない
一定条件で購入不可 • 競馬会員以外
• 残高不足
• 発売締切り
オッズ投票 1. ログイン
2. お金の入金
3. オッズから馬券を選ぶ
4. 購入する
5. 照会で確認
: • 会員登録
• 正常に登録
• 一日一回 1. 楽天ID作成
2. 会員申し込み
テスト自動化設計書のテンプレート after
• 手動テストの必要性明確化
24. 24
Improvement point 1st
機能 テスト観点
テスト目的
テスト前提 条件・パラ
メータ
CI条件 自動化の処理概要 自動化しない
こと
通常投票 • 正常購入処理
• 購入方法の網羅
• 馬券を正しく購入
できること
• 競馬会員ユーザ
• 十分な残高
式別(単勝、~
三連単)
方式(通常、~
フォーメーショ
ン):
購入回数上限 1. ログイン
2. お金の入金
3. 買目、馬を選ぶ
4. 購入する
5. 照会で確認
買った馬券の妥当
性は確認しない
一定条件で購入不可 • 競馬会員以外
• 残高不足
• 発売締切り
オッズ投票 1. ログイン
2. お金の入金
3. オッズから馬券を選ぶ
4. 購入する
5. 照会で確認
: • 会員登録
• 正常に登録
• 一日一回 1. 楽天ID作成
2. 会員申し込み
テスト自動化設計書のテンプレート after
• CI運用に考慮する点記述
Hinweis der Redaktion
これまでのキャリア
最初、組み込み系のソフトウェアエンジニア 2年間
その後、WEBエンジニア 13年間
次にプロダクトマネージャの経験を経る
2016年、いまのSQA部署の構築から携わり、テスト自動化を合わせて構築しました(3年目)
次に、組織の話をさせてください
・5つのサービスを持っている
・ロールでチームが分かれている
QAの組織は
・ 10名 + offsite (増減します)
・ QAのスペシャリスト集団 ただ、ほとんどはエンジニア経験なし
・マニュアル、自動化で品質を担保する
3つのステップでおはなし
1. 2016年QA組織立ち上げ、自動化の取り組みを行う
徐々にメンバーが増え、それによって直面した課題
2. それに対して取り組んできた改善活動 2016年、QA構築当初の体制です
ひとりが、ISTQBでいうTMとTA、およびテスト自動化を担当
・テスト設計書のレビュー
・テスト自動化の設計
・テスト自動化の構築、運用
マニュアルと自動化のチームにわかれました
・マニュアル側は、自動化に関してのスキルがない
・自動化側は、プログラマーが主になり、かつドメインナレッジが少ない 自動化チームが拡大化したことで
・テストエンジニア経験の低いプログラマが増えてきた
・自動化のテストの質が低下し、品質担保が困難になってきた
マニュアルと自動化がチーム分けされたことにより
マニュアル側から都度、自動化のメンバーにどこを自動化している?
今回のプロジェクトで自動化どこカバーしている?
って質問、応答のやりとりが多々発生
重要な機能でUIの変更がよく発生する。 → 自動化に向かないとはいえ対応が求められる
1-2週間のテストサイクル案件が多く、それに自動化が追従困難
これまで自動化の設計書を各担当者にまかせていた
主に、処理フローと自動化でよく使われるデータドリブンに必要な情報、条件、パラメータを記述
テストする観点が含まれてませんでした
マニュアルチームから見ても、品質担保が不明 これをこのように自動化のテスト設計書のテンプレートを作成しました 具体的なテスト手順とそれにおいてのテスト観点
自動化でどういったことをvalidateするか
マニュアルチームへなにをやってるかを可視化
自動化担当には具体的なSTEPを記載することでテスト観点を実装にもれないようにさせた テストにあたっての前提条件
自動化で効果のある、DDのための要素、条件・パラメータ 自動化は銀の弾丸ではない
マニュアルチームから見て、注意しないといけないことを記載 自動化は、
・毎日実行させることが求めらる
・失敗した時、再実行可能が求められる
これを満たすための制約をクリアにする
⇒実装時にこれを考慮しないと意外と作り直しが発生する 1 script
増えた時間
テスト設計には時間が増える
レビュー
2人でレビューしている前提
before
やり直しのレビューも含んでいる(自動化の設計自体を)
after
1回のレビューでおわるケースがおおい
既存機能
これまでに存在している機能
テスト自動化でリグレッションテストで基本カバーしている
プロジェクトによって、リグレッションテストに影響あり
新規機能
これまでに存在しない機能
テスト自動化を新規に作る必要あり
UIは十分なテストしないと安定しない場合あり
新規機能に関して、マニュアルテストで品質を守る
既存機能に関して、自動化テストで品質を守る