$30 off During Our Annual Pro Sale. View Details »

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

akihisa1210
February 21, 2018
7.9k

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

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

akihisa1210

February 21, 2018
Tweet

More Decks by akihisa1210

Transcript

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

    View Slide

  2. About me
    ● 小山 晃久
    ● 2016年4月 新卒入社(人文系院卒)
    ● QAとしてGaroonのお問い合わせ対応 → 2017年7月からス
    クラムチームに参加
    ● 趣味は読書
    ○ 最近読んだ: フロイト『精神分析入門』、ゴールドラット『ザ・ゴール』
    ○ 今読んでる: ギャロウェイ『プロトコル』
    2

    View Slide

  3. What is Scrum?
    「スクラムガイド――スクラム公式ガイド: ゲームのルール」
    著: Ken Schwaber and Jeff Sutherland
    訳: 角征典
    http://www.scrumguides.org/docs/scrumguide/v2017/20
    17-Scrum-Guide-Japanese.pdf
    3

    View Slide

  4. Garoon開発
    ● 中堅・大規模組織向けのグループウェア
    ● 日本・ベトナム・中国で多拠点開発
    ● ウォーターフォール → スクラム
    4

    View Slide

  5. 5

    View Slide

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

    View Slide

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

    View Slide

  8. Our team
    8
    PG
    PG
    SM
    PG
    QA
    QA

    View Slide

  9. 開発プロセス
    9

    View Slide

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

    View Slide

  11. スクラム以後
    ● リリースは3か月に1度
    ● 1リリース = 約6, 7スプリント
    ● 1スプリント = 3週間
    ● 1スプリント内で開発も試験もやる
    ● 各リリースの最終スプリントは(原則)新規開発しない
    11

    View Slide

  12. QAがやっていること
    12

    View Slide

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

    View Slide

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

    View Slide

  15. スクラムイベントへの参加
    15

    View Slide

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

    View Slide

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

    View Slide

  18. レトロスペクティブ
    (ふりかえり)
    ● チーム内でふりかえり → KAIZEN
    ○ 開発中のブランチで動作確認したい
    ● → 開発環境の作り方をレクチャーしてもらう
    ○ ○○の試験に時間がかかった
    ● → 次スプリントでは試験する単位を変えてみる
    ○ もっと情報共有したい
    ● → Slack、分報の導入
    18

    View Slide

  19. 試験設計・試験仕様書作成
    19

    View Slide

  20. ● 実装と同時に開始
    ● できるだけ早く動くものを触ってみる
    ○ 試験対象を学ぶ
    ● よくわからないことがあれば都度聞く
    ● 仕様の漏れが見つかったらフィードバック・提案
    ● 実装者にテストケースについて相談(ただしうのみにはしない)
    ○ Aを試験すればBは試験しなくてもよい?
    ○ これはすべての動作環境で確認すべき?
    20

    View Slide

  21. Good
    21

    View Slide

  22. ● スケジュール(以前は試験期間にしわ寄せが)
    ● チーム内での連携
    ○ 相談しやすい
    ○ 品質への関心の向上
    ● QAのスキルを活かせている(気がする)
    ○ 不具合が出そうな点を事前に指摘
    ○ ユーザーが機能をどう使うか考える
    ○ あとで読んでも意味の分かる仕様書
    22

    View Slide

  23. 課題
    23

    View Slide

  24. ● 試験設計の成果物はスクラム以前のまま
    ○ テスト対象・テスト目的・テストケースを含むスプレッドシ
    ート
    ○ 自動テストと探索的テストで何ができるのか知る必要あり
    (銀の弾丸ではない)
    ● チーム間での情報共有
    ● 明確な成果はまだこれから
    ○ 適応に時間がかかる(一時的に生産性が下がる)
    ○ 技術的負債との闘い
    ○ ふりかえりで地道に KAIZEN を重ねる
    24

    View Slide

  25. 最後に:
    「開発チーム」とQA
    25

    View Slide

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

    View Slide

  27. ● ある人にしかできない作業があったとし
    ても、スクラムにおける開発チームのメ
    ンバーに肩書きはない。
    ● テスティング、アーキテクチャ、運用、ビジ
    ネス分析のような専門領域であっても、
    スクラムは開発チームのサブチームを認
    めていない。
    27
    (Ken Schwaber and Jeff Sutherland著、角征典訳「スクラムガイド」p.6
    http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf)

    View Slide

  28. Our team
    28
    PG
    PG
    SM
    PG
    QA
    QA

    View Slide

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

    View Slide

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

    View Slide