Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Marketplace QA Introduction

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 29 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Marketplace QA Introduction (20)

Anzeige

Weitere von Rakuten Group, Inc. (20)

Aktuellste (20)

Anzeige

Marketplace QA Introduction

  1. 1. Marketplace QA Introduction Jun 30, 2020 Toshinori Serata EC Technology Supervisory Dept. Rakuten, Inc.
  2. 2. 2 自己紹介
  3. 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. 4 入社3日目からテレワーク そんな組織の雰囲気は?
  5. 5. 5 Quality Assurance Atmosphere テレワークへの移行も3月から行われていた為、スムーズに業務ができてしまいました 25 FTE 25 PS
  6. 6. 6 Quality Assuranceは色々あるけど… 立ち位置は?
  7. 7. 7 Quality Assurance Position 多くの機能開発における、品質確認をする横断的組織 Quality Assurance (QA) Rakuten Service Dev Dev Dev Dev Dev Many Rakuten Service development
  8. 8. 8 Quality Assurance Position ただテストするだけではなく、仕様確認から1件1件開発と二人三脚ですすめる 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. 9 ここからは、私が担当する 楽天市場QAの話
  10. 10. 10 Marketplace QA Scope Merchant StorefrontからBack officeに至る様々な機能。店舗設定、商品設定による組み合わせ多数。 店舗申請 店舗設定 商品作成 拡張設定 商品購入 注文処理 会計処理 情報分析 出店申請 決済方法 配送方法 etc… 商品登録 クーポン 海外販売 あす楽 etc… 受注管理 etc… 検索 勘定 商品閲覧 購入履歴 etc… 受け取り 支払い 明細管理 閲覧情報 注文情報 会員情報 買い物情報 Shopper Storefront Mall Back office
  11. 11. 11 実際どれぐらいの案件があるの? Quiz 年間でどれぐらいあるでしょう? (チャットにいれてみてください)
  12. 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. 13 大規模ソフトウェア開発における テストマネージメントとデータに関して 2つの話をします 1. Reporting 2. Product line
  14. 14. 14 1. Reporting
  15. 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 評価進捗だしているけど、「評価どこまでできたの?」と聞かれる。 品質見解だしているけど、「結局品質どうなってるの?」と聞かれる。 スコア バク曲線 残不具合数… で? 5 4 3 2 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. 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 5 4 3 2 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. 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. 18 Final Report標準化 推進者の声@Quanさん <Video> 苦労しているところ 今感じている効果と今後への意気込み Etc..
  19. 19. 19 評価進捗、不具合状況の組み合わせは多数 過程における状態との組み合わせも考慮 これらを整理し、真の品質見解へ
  20. 20. 20 2. Product line
  21. 21. 21 Marketplace QA Test management – Product line こんなモヤモヤありませんか? 関連仕様考慮が経験にのみ依存。「この人いなくなったらアウト…」 評価開始ともに環境制限多発。「ケースはレビューしたのに…」 評価開始ともに不具合多発。「開発で品質もっと確保してくれないかなぁ」 検出した不具合が、実は既知問題。「先に言ってくれよ…」 不具合対応などで突然案件がくる。「もっとはやく言ってくれよ…」 見えないがゆえの非効率、手戻り
  22. 22. 22 Marketplace QA Test management – Product line どうしてこうなった?:案件毎であるが故に俗人化。 機能全体の品質管理における見える化ができてない。  機能全体としての仕様がない(誰かの頭の中)  機能全体としての開発側での品質確保、QA側での品質確保への期待があいまい(担当依存)  機能全体としてのテストケースが整理されていない  機能全体としての不具合管理状況が共有されていない 継ぎ足しによる秘伝のたれ。そのレシピを紐解く必要あり。
  23. 23. 23 Marketplace QA Test management – Product line やろうとしていること:プロダクトラインとしての知識とデータの蓄積ができるスキームの構築 開発とのさらなる連携強化 まずは、評価における現状把握から進めてます プロダクトマネージャー 開発リーダー 品質保証リーダー 継続的にProjectのあるProductを選出 Product毎に品質専任者をつけた体制の構築 テスト計画から品質見解に至るまでの あるべき状態の設定 仕様管理 開発計画とQAの可否判断 テストスケジュール、リソース確保 テスト観点管理、ケース管理、環境管理 テスト実行進捗管理、レポート作成、リリース判定 テスト戦略、自動化戦略
  24. 24. 24 開発との連携強化をはじめてみて 現場の声@大野さん <Video> 始めるにあたって特に気にしたところ みえたこと、今後への意気込み Etc..
  25. 25. 25 成功体験をもとに複数のプロダクトへの拡張 データを蓄積し テスト計画、実行、品質判断の効率化 品質コントロール全体の効率化につなげる
  26. 26. 26 まとめ
  27. 27. 27 Summary テストマネージメントにおける効率化で大事なこと  データ説明に対して、共通言語をもつことで、品質に対する共通認識を開発と持ちやすくする  プロダクトラインとして、テスト管理の考え方を可視化して、開発と最適なテスト戦略 答えはちがっても、テストマネージメントにおける課題は似ているので面白い テスト計画 の考え方 テストベース の考え方 環境管理 の考え方 ケース管理 の考え方 品質判定 の考え方 テスト分担 の考え方
  28. 28. 28 さいごに

×