スクラムにおけるQA メンバー ( 非開発

者 ) の関わり方を模索してみ

た

2015/05/25 TestingCasualTalks #2

株式会社ガイアックス 境野高義

1

当日の発表資料に少しだけ追加修正しています。

2

本日の人口分布調査！

１）開発者 → ほとんど開発者でしたね！

２）マネジメント、企画、デザイン、その他 →10 人くらい

３） QA ・テスト →10 人くらい　 →そのうち「コードを書かない」人が数人

( それぞれ 1/3 ずつくらいかなと思ってました… )

3

自己紹介

所属：株式会社ガイアックス QA マネー

ジャー

最近：技術を勉強中

(SeleniumWebDriver,Rspec,Ansible,Serverspec とか )

Twitter ：@sakaimo

4

音楽が好きです

5

カメラ好きです

6

ももクロ 好きでした

http://www.momoclo.net/7

でんぱ組 .inc 好きです

http://dempagumi.dearstage.com/8

ラブライブ！ 好きです

http://www.lovelive-anime.jp/9

からの

10

ここ半年くらい： BABYMETAL

https://www.facebook.com/BABYMETAL.jp/photos/pb.249847745062499.-2207520000.1432393067./845540615493206/

11

( ﾟд ﾟ )って顔しないでｗ

12

本題入ります

13

伝統サポーターズ

14

伝統サポーターズ

サポーターが職人を支援するクラウドファンディング

↓職人・作り手と

ファンがつながる( 月額 500 円からサポート可 )

↓後継者不足と

需要低迷の課題解決

15

プロジェクトのフェーズ

•状態•リーンな進め方•MVP( 実用最小限の製品 ) の価値検証は完了

•次のステップ•サービス拡大・成長•課金•その管理機能

•期間•8 週間 ( 去年 12 月～今年 1 月 )

16

開発技術要素

•Ruby on Rails で書いてます•Capybara でテストコード•Wercker で CI•Bitbucket でコード管理•Hipchat にプルリクや Wercker の結果を通知•Ansible で環境構築•(Payment gateway は WebPay)

( 追加スライド )

< プロジェクトのチャレンジ >

スクラムのプラクティスを取り入れた開発プロセス

社内では 2 例目18

スクラムとは？ ( イメージ )

19

今回は… ( 精緻には ) 見積もらない

20

•社内で 2 例目•SM(ScrumMaster) 以外初めての体験•1 スプリント 1 週間•JIRA アジャイルで管理

21

今回は

体制

PO(Product Owner) １人

開発 3 人

QA １人

SM １人

22

<QA のチャレンジ >

このプロセスの中にQA( 非開発者 ) が入っていく

23

これまで チャレンジ

24

スプリントの進め方

25

狙い① : 要件定義を充実させる

26

狙い② : スプリントごとにテスト

27

狙い① ( 要件定義の充実 ) の成果

< 仕様の考慮もれ >

・職人ステータスは変更できる・「職人」のみプロジェクトを持てる仕様　 ↓プロジェクトを 1 つ以上持っていたら「職人」から変更をできないように

こんなことが指摘できました

28

< ストーリー間の整合性>

管理者はユーザーの旧 PW を知らない　 ↓管理画面でのパスワード変更機能は提供しない

狙い① ( 要件定義の充実 ) の成果

こんなことが指摘できました

29

狙い② ( スプリントごとにテスト )の成果

スプリント内にテストは収まらなかった…　・バグはプロダクトバックログに入れる　・機能の実装も、バグ修正も同じテーブルに乗っている　・都度優先順位を決めて高い順に対応していく

実際はこうなった

30

今回の振り返り

KPT法を使っていますKeep / Problem / Try

31

Keep

•要件ヒアリングの際に指摘できる•実装前に「仕様の定義もれ」「ストーリーの矛盾」の指摘ができる

•まとめてテスト、よりも、細かくテスト•( スプリントに収まらなかったけど ) スプリントごとのテストのほうが早く見つけられる

32

Problem

•スプリントにテストが収まらなかった•開発とテストのバランス•どこまでテストするのか

•テスト項目の想定•要件定義の充実＋開発者のテスト→正常系はほぼOK•異常系の想定不足

•機能単位でのテストになった•機能は複数ストーリーから成り立つことが多い•ストーリーの優先順位は、機能単位ではない•従来のやり方から抜けられなかった (QA のマインド的な ) 33

Try

•テストのやり方、内容を変える•正常系はさらっとでいい（開発者のテストコードが前提 )•異常系を厚く•ストーリー間 / 機能間の相互関係を重点的に

•ストーリーごとにテストする•機能 (複数ストーリの集合 ) の完成を待っていたのでは遅い•迅速なフィードバックはアジャイル開発において不可欠

34

まとめ

•スプリントごとにテスト→フィードバックができるのはメリット

•PO も交えて軌道修正していく ( スクラム開発の特性 )

•作れらたものをテストします、ではなく一緒にサービスを作ってる感じが楽しい！

35

ぜひサポーター登録を！

36

私がサポートしている　　　　　　　越前箪笥の職人さん

37

月々 500 円 (1 年 ) のサポートで、

写真立てがいただけます。

最後にお知らせ

38

ガイアックスの QAに

足りないもの

39

技術力( プログラミング的な )

40

新チーム発足させます

開発スピードを上げるために技術を使って QA ・テストするチーム　・ E2E テスト自動化　・ CI 環境の構築、運用　・コードでテストする　・ TDD をあたり前にする　・開発者と同じ土俵で話ができる　…とか

　そーゆー社内文化を作る！41

求人はじめました！QAエンジニアなんだから

コードくらい書けるでしょ？

近日 Wantedly公開42

ご清聴ありがとうございました

43筆ペン使ってたら楽しくなってきたので調子に乗って描いてみました (笑