データをテストマネージメント、レポートに活用した事例

1. Marketplace QA Introduction
Jun 30, 2020
Toshinori Serata
EC Technology Supervisory Dept.
Rakuten, Inc.

2. 2
自己紹介

3. 3
Personal Profile
Name :Toshinori Serata (世良田敏義)
Join Rakuten : 2020 Apr
Career
2000 - 2004：SW developer for Car DVD player Backend
2004 - 2011 : SW developer for Multimedia and Messaging Mobile
2011 - 2013 : SW Project leader for Android Mobile
2013 - 2020 :Testing and Quality Management for Android Mobile andTV
2020 - : Market Place QA
Hobby
Road bike is my life. Keep physical and mental.
組み込み20年。QAとしてのキャパ拡張の為Webへ

4. 4
入社３日目からテレワーク
そんな組織の雰囲気は？

5. 5
Quality Assurance Atmosphere
テレワークへの移行も3月から行われていた為、スムーズに業務ができてしまいました
25
FTE
25
PS

6. 6
Quality Assuranceは色々あるけど…
立ち位置は？

7. 7
Quality Assurance Position
多くの機能開発における、品質確認をする横断的組織
Quality
Assurance
(QA)
Rakuten Service
Dev
Dev
Dev
Dev
Dev
Many Rakuten Service development

8. 8
Quality Assurance Position
ただテストするだけではなく、仕様確認から１件１件開発と二人三脚ですすめる
Spec Design SW Design
Development
Test
Bug fix リリース
Test Scope
estimation
Test
Design
Test
Execution
QA
Request
Quality
Result
confirm confirm confirm
QA work from SW development flow

9. 9
ここからは、私が担当する
楽天市場QAの話

10. 10
Marketplace QA Scope
Merchant
StorefrontからBack officeに至る様々な機能。店舗設定、商品設定による組み合わせ多数。
店舗申請 店舗設定 商品作成 拡張設定 商品購入 注文処理 会計処理 情報分析
出店申請 決済方法
配送方法
etc…
商品登録
クーポン
海外販売
あす楽
etc…
受注管理
etc…
検索
勘定
商品閲覧
購入履歴
etc…
受け取り 支払い
明細管理 閲覧情報
注文情報
会員情報
買い物情報
Shopper
Storefront Mall Back office

11. 11
実際どれぐらいの案件があるの？
Quiz
年間でどれぐらいあるでしょう？
（チャットにいれてみてください）

12. 12
Marketplace QA Volume
Numbers of Project from 2019 Apr to 2020 Jun
 Accumulated Total 194 Projects
Average per week
 Ave. 3.7 request/week as of now
(74 / 20 weeks)
Ave. 3 request/week until 2020 Mar
(120 / 40 weeks)
MarketplaceQA需要は、どんどん高まっている。今までのやり方だけでは処理しきれない。
2020 Mar

13. 13
大規模ソフトウェア開発における
テストマネージメントとデータに関して
２つの話をします
1. Reporting
2. Product line

14. 14
1. Reporting

15. 15
Marketplace QA Test management - Reporting
こんなことありませんか？
複数軸のデータ ただ出しても伝わらない
Total Case Passed Failed In Progress Blocked Not
Developed
ScopeOut Cannot test Retest Pending
100 94 1 0 1 0 1 2 0 1
評価進捗だしているけど、「評価どこまでできたの？」と聞かれる。
品質見解だしているけど、「結局品質どうなってるの？」と聞かれる。
スコア
バク曲線
残不具合数…
で？
５
４
３
２
１
Total Bug Critical Block Major Minor
10 1 0 1 8
Total Bug Fixed Open Invalid Workas
design
10 1 0 5 4
Score

16. 16
Marketplace QA Test management - Reporting
原因：数字の理由説明を伝えられていない。
 各々のWordingに対する使い方が、QA内部でもあいまいであった。
言語が違うので、定量的＋定性的説明が必要 説明の一環性が不足していた
Total Case Passed Failed In Progress Blocked Not
Developed
ScopeOut Cannot test Retest Pending
100 94 1 0 1 0 1 2 0 1
５
４
３
２
１
関係は？
違いは？
Total Bug Critical Block Major Minor
10 1 0 1 8
Total Bug Fixed Open Invalid Workas
design
10 1 0 5 4
基準は？
違いは？

17. 17
Marketplace QA Test management - Reporting
やったこと：Final Reportを表現する際に必要なことを共通言語化し、推進者による定期的確認
同じQA内でさえ、理解し統一するって結構難しい 定着化が大事
Blocked Not Developed ScopeOut Cannot test Retest Pending
cannot be executed
currently because of a
bug
Not use no longer need to be
tested
cannot be executed
currently because
of an Environmental li
mitation
Not Use Not Use
例1）テストケースのステータス定義の明文化、不要なものの削除
Status Resolution QA Situations FinalScore Effect? Real Bug?
Open NA Normal Bug (planned to be fixed at this sprint) 〇 〇
Reopen Unresolved DEV agreed the behavior is incorrect but will not fix it in this sprint. 〇 〇
Close Fixed Verified fixed Bugs. 〇
Working as intended
….
Spec/DEV document Issue. 〇
例2) Issueにおけるステータスの扱い方、スコアへの影響可否、Bugかそうでないかの定義

18. 18
Final Report標準化
推進者の声@Quanさん
<Video>
苦労しているところ
今感じている効果と今後への意気込み
Etc..

19. 19
評価進捗、不具合状況の組み合わせは多数
過程における状態との組み合わせも考慮
これらを整理し、真の品質見解へ

20. 20
2. Product line

21. 21
Marketplace QA Test management – Product line
こんなモヤモヤありませんか？
関連仕様考慮が経験にのみ依存。「この人いなくなったらアウト…」
評価開始ともに環境制限多発。「ケースはレビューしたのに…」
評価開始ともに不具合多発。「開発で品質もっと確保してくれないかなぁ」
検出した不具合が、実は既知問題。「先に言ってくれよ…」
不具合対応などで突然案件がくる。「もっとはやく言ってくれよ…」
見えないがゆえの非効率、手戻り

22. 22
Marketplace QA Test management – Product line
どうしてこうなった？：案件毎であるが故に俗人化。
機能全体の品質管理における見える化ができてない。
 機能全体としての仕様がない（誰かの頭の中）
 機能全体としての開発側での品質確保、QA側での品質確保への期待があいまい（担当依存）
 機能全体としてのテストケースが整理されていない
 機能全体としての不具合管理状況が共有されていない
継ぎ足しによる秘伝のたれ。そのレシピを紐解く必要あり。

23. 23
Marketplace QA Test management – Product line
やろうとしていること：プロダクトラインとしての知識とデータの蓄積ができるスキームの構築
開発とのさらなる連携強化 まずは、評価における現状把握から進めてます
プロダクトマネージャー
開発リーダー 品質保証リーダー
継続的にProjectのあるProductを選出
Product毎に品質専任者をつけた体制の構築
テスト計画から品質見解に至るまでの
あるべき状態の設定
仕様管理
開発計画とQAの可否判断
テストスケジュール、リソース確保
テスト観点管理、ケース管理、環境管理
テスト実行進捗管理、レポート作成、リリース判定
テスト戦略、自動化戦略

24. 24
開発との連携強化をはじめてみて
現場の声@大野さん
<Video>
始めるにあたって特に気にしたところ
みえたこと、今後への意気込み
Etc..

25. 25
成功体験をもとに複数のプロダクトへの拡張
データを蓄積し
テスト計画、実行、品質判断の効率化
品質コントロール全体の効率化につなげる

26. 26
まとめ

27. 27
Summary
テストマネージメントにおける効率化で大事なこと
 データ説明に対して、共通言語をもつことで、品質に対する共通認識を開発と持ちやすくする
 プロダクトラインとして、テスト管理の考え方を可視化して、開発と最適なテスト戦略
答えはちがっても、テストマネージメントにおける課題は似ているので面白い
テスト計画
の考え方
テストベース
の考え方
環境管理
の考え方
ケース管理
の考え方
品質判定
の考え方
テスト分担
の考え方

28. 28
さいごに