「開発チーム」とQA /"Development Team" and QA

77fa3ebbf229a884c74c905034b1f4c2?s=47 akihisa1210
February 21, 2018
5.7k

「開発チーム」とQA /"Development Team" and QA

Cybozu Meetup #11 アジャイルQA で発表しました。
https://cybozu.connpass.com/event/79018/

77fa3ebbf229a884c74c905034b1f4c2?s=128

akihisa1210

February 21, 2018
Tweet

Transcript

  1. 「開発チーム」とQA Cybozu Meetup #11 サイボウズ株式会社 東京品質保証部 小山 晃久 1

  2. About me • 小山 晃久 • 2016年4月 新卒入社(人文系院卒) • QAとしてGaroonのお問い合わせ対応

    → 2017年7月からス クラムチームに参加 • 趣味は読書 ◦ 最近読んだ: フロイト『精神分析入門』、ゴールドラット『ザ・ゴール』 ◦ 今読んでる: ギャロウェイ『プロトコル』 2
  3. What is Scrum? 「スクラムガイド――スクラム公式ガイド: ゲームのルール」 著: Ken Schwaber and Jeff

    Sutherland 訳: 角征典 http://www.scrumguides.org/docs/scrumguide/v2017/20 17-Scrum-Guide-Japanese.pdf 3
  4. Garoon開発 • 中堅・大規模組織向けのグループウェア • 日本・ベトナム・中国で多拠点開発 • ウォーターフォール → スクラム 4

  5. 5

  6. スクラムチームの構成 6

  7. 3拠点 / 8チーム • 日本3チーム・ベトナム4チーム・上海1チーム • 日本の3チームのうち1チームは “Nexus” ◦ チーム間を取り持つ

    7
  8. Our team 8 PG PG SM PG QA QA

  9. 開発プロセス 9

  10. スクラム以前 • ウォーターフォール • リリースは6か月に1度 • 開発期間 → 試験期間(機能試験 →

    回帰試験) 10
  11. スクラム以後 • リリースは3か月に1度 • 1リリース = 約6, 7スプリント • 1スプリント

    = 3週間 • 1スプリント内で開発も試験もやる • 各リリースの最終スプリントは(原則)新規開発しない 11
  12. QAがやっていること 12

  13. • スクラムイベントへの参加 • 仕様書レビュー • 試験設計・試験仕様書作成 • 試験実施 • 不具合管理

    • リリース関連作業 • (場合によっては)仕様書作成 13
  14. • スクラムイベントへの参加 • 仕様書レビュー • 試験設計・試験仕様書作成 • 試験実施 • 不具合管理

    • リリース関連作業 • (場合によっては)仕様書作成 14
  15. スクラムイベントへの参加 15

  16. スプリントプランニング • 試験という観点からタスクの分割方法を提案 ◦ 「この機能を一度に実装するとテストケース数が膨大にな るので、分けて実装してほしい」 ◦ 「試験を簡単にするために、試験用の API を作るタスクを

    追加したい」 16
  17. リファインメント • 現段階で決めておくべき仕様に漏れがないか調査 ◦ 「このケースではバリデーションエラーを返す?それとも不 正な値が無視されるだけ?」 ◦ 「もしユーザーが◦◦の操作をしたらどうなる?」 • 過去の不具合情報を掘り出す

    17
  18. レトロスペクティブ (ふりかえり) • チーム内でふりかえり → KAIZEN ◦ 開発中のブランチで動作確認したい • →

    開発環境の作り方をレクチャーしてもらう ◦ ◦◦の試験に時間がかかった • → 次スプリントでは試験する単位を変えてみる ◦ もっと情報共有したい • → Slack、分報の導入 18
  19. 試験設計・試験仕様書作成 19

  20. • 実装と同時に開始 • できるだけ早く動くものを触ってみる ◦ 試験対象を学ぶ • よくわからないことがあれば都度聞く • 仕様の漏れが見つかったらフィードバック・提案

    • 実装者にテストケースについて相談(ただしうのみにはしない) ◦ Aを試験すればBは試験しなくてもよい? ◦ これはすべての動作環境で確認すべき? 20
  21. Good 21

  22. • スケジュール(以前は試験期間にしわ寄せが) • チーム内での連携 ◦ 相談しやすい ◦ 品質への関心の向上 • QAのスキルを活かせている(気がする)

    ◦ 不具合が出そうな点を事前に指摘 ◦ ユーザーが機能をどう使うか考える ◦ あとで読んでも意味の分かる仕様書 22
  23. 課題 23

  24. • 試験設計の成果物はスクラム以前のまま ◦ テスト対象・テスト目的・テストケースを含むスプレッドシ ート ◦ 自動テストと探索的テストで何ができるのか知る必要あり (銀の弾丸ではない) • チーム間での情報共有

    • 明確な成果はまだこれから ◦ 適応に時間がかかる(一時的に生産性が下がる) ◦ 技術的負債との闘い ◦ ふりかえりで地道に KAIZEN を重ねる 24
  25. 最後に: 「開発チーム」とQA 25

  26. スクラムガイドにおける「開 発チーム」 26

  27. • ある人にしかできない作業があったとし ても、スクラムにおける開発チームのメ ンバーに肩書きはない。 • テスティング、アーキテクチャ、運用、ビジ ネス分析のような専門領域であっても、 スクラムは開発チームのサブチームを認 めていない。 27

    (Ken Schwaber and Jeff Sutherland著、角征典訳「スクラムガイド」p.6 http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf)
  28. Our team 28 PG PG SM PG QA QA

  29. Our team 29 開発チームの メンバー 開発チームのメンバー SM 開発チームのメンバー 開発チームのメンバー 開発チームのメンバー

  30. 30 Question • 開発チーム「の」QA は(役職・職能の意味では)存在 しない? • 開発チーム「と」QA(品質保証担当者あるいは品質 保証という活動)はどのように付き合っていけばよい のか?