アジャイルネイティブなQA by 三牧 麻美
自己紹介
- 新卒2年目
- kintoneとkintoneモバイルの品質保証責任者
- Scrum開発のみ経験済
kintone
- 顧客管理などのアプリをクラウド上で作成
- 多拠点開発
kintoneモバイル
- US向け
- 既存のモバイルアプリとは仕様を一新
- 新しいチームでの開発
- スクラムイベントなどが何も決まってない状態から始めた
- PG4, PM1,QA2
開発がはじまるまで
- 必要なことの洗い出し
- 不安に思っていることなど
- スプリント開始までにやることを整理
品質について
- 開発が始まる前にPMとQAで意識合わせ
スクラムイベント
READY/DONEの定義決め
- QAが関わっているのは以下の2つ
- バックログに必要な受入試験手順が記載されている
- 開発チーム全員が飼養管理アプリに書かれた仕様で疑問がない
READY
- PGが仕様書を作成
- PM/QAレビュー
- リファインメントで全員で共有・疑問をなくす
- QAが受入試験を作成する
- PGレビューへ
開発プロセス
- 設計・試験のタイミングは統一しない
- バックログに合わせて決める
- スプリントをまたぐこともあり
試験プロセス
- 試験バックログで監理
- QA工数の見積もり
- 試験するPBLを監理
- 関係ある試験は一緒に試験
- 試験仕様書・試験結果の監理
問題となった点
- 今後の見通しが明確でなかった
- いつ機能試験を実施するか最初に計画してもあまり意味がなかった
- 大まかに計画することに
- →チーム全体でのコミュニケーションが大事
今後の課題
- 2週間毎のリリースが目標
- 1スプリントで試験まで完了するには？
- 回帰試験をどうするか？
質問
1スプリントで開発とテストが別々だが、開発が進みすぎて、テストが積まれる状況にならないか？
- プランニング以上のものは基本的には実装しない
- 余った時間はリファクタリングなどをしている
スクラムで開発している一方でロールを分割しているが、分割のメリットは何か？
- 一緒にやった場合を経験したことが無いので想像できない
- 分けることで、スクラムはスプリント内で終わらせないといけないという意識があるが、試験は試験として終わらせることを強制してないので、柔軟な対応をするには逆に分けているのは良いことかなと。
天野さんの補足
- 歴史的な経緯で開発とQAが分かれている。
- 元々サイボウズは開発とQAが別組織だった。
- スクラムをやることで垣根を小さくしようとしている
- 今後はもっと一体となってやっていようとしている
- 現在は自動化をエンジニアがやっているが、QAでもやれるようにと考えている
スクラムイベントでQAが参加しているが、仕様のレビューは参加していると思うが、QAからのフィードバックの内容はどのようなものか？
- 例えば、kintone本体の機能を元にした指摘などをしている。
「開発チーム」とQA by 小山 晃久
自己紹介
- 新卒2年目
- QAとしてガルーンのお問い合わせ対応をしていた
- 2017年7月からスクラムチームに参加
Scrumとは何か？
ガルーン
チーム構成
- ブーメランデスク
- QA2,PG3,SM1
開発プロセス
スクラム以前
- ウォーターフォール
- リリースは6ヶ月に1度
スクラム以降
- リリースは3ヶ月に1度
- 1リリース=6,7スプリント
- 1スプリント=3weeks
- 各リリースの最終スプリントは原則新規開発しない
- 回帰試験、改善系中心
QAがやっていること
- スクラムイベントへの参加
- 仕様書レビュー
- （場合によっては）ユーザーに提供する仕様書作成
スプリントプランニング
- タスクの分割をする
- QAは試験という観点からタスクの分割方法を提案する
リファインメント
- 現段階で決めておくべき仕様に漏れがないか調査
- 過去の不具合情報を掘り出す
- 新しい機能を追加するとき、類似機能の不具合共有とか
レトロスペクティブ（振り返り）
- チーム内でふりかえり→KAIZENへ
- 開発中のブランチで動作確認したい
- 開発環境の作り方をレクチャーしてもらう
- ○○の試験に時間がかかった
- 次スプリントでは試験する単位を変えてみる
- 開発中のブランチで動作確認したい
試験設計・試験仕様書作成
- 実装と同時に開始
- できるだけ早く動くものを触ってみる
- 試験対象を学ぶ
- 分からなかったらすぐに聞く
- 仕様の漏れが見つかったらFB・提案
- 実装者にテストケースについて相談
- ただし鵜呑みにしない
良かったこと
- スケジュール感が良くなった
- 以前は試験期間にしわ寄せがあった
- チーム内の連携が良くなった
- 品質の関心も向上した
- QAのスキルを活かせる
- 不具合の出そうなものを伝える
課題
最後に
問いかけ
- 開発チームのQAは存在しない？
- 開発チームとQAはどのように付き合っていけば良いのか？
質問
QAがスクラムチームに入ってみて、開発チームからのFBは何かあったか？ウォーターフォールからスクラムで変わったことによっての話とか
- ネガティブなものは無い。
- Agile testingなどを勉強して、一体になって行うことの重要性に気付いた
開発メンバーからの補足
- 1スプリントでテストまで終わらせる取り組みをしていて、QAとのやり取りを初めてやることに。
- 初めての頃は試験仕様書が読めず、「もう少し分かりやすく」とFBした。
リリース判定はPOがすると思うが、QAは情報やメトリクスを示したりするのか？
- リリース判定会議をしている。
- 不具合の重要度を示したり、予定したテストが終わっているか、性能が改善しているかなどを伝えている
「まだまだ品質向上せい！」と言ったりしないのか
- 一緒にやっているので、QAが上からモノを言う形にはならない。
振り返りってどうやって進めているのか？また、その際にQAの立場として面白かったことは？
- 基本的にはスクラムチームの中で行っているが、KPTを使っている。
- 振り返りに優先順位を付けて、誰が何をするかまでTODOにして落とし込んでいる
- QA側からは初期の頃、QAとPGが知りきれていなかった頃、お互い知るために、開発環境について教えてもらったり、試験にかかったことに対しての改善策を考えたりした。
- 振り返りの場ではQAとしてでなく、メンバーの一員として参加している
補足
- 1スプリント3weekでやっていると、長いので、改善のタイミングが遅くなる。
- プチレトロという中間の振り返りを3weekの中日にやったりする
- 毎回KPTだと飽きるので、たまに変えたりする
QAにおけるスクラム導入 Before/After by 匠 史朗
自己紹介
- 松山品質保証部部長
- 39歳
- 2008年中途入社
- 今日は苦労話を中心に
チーム概要
- 社内向けシステムを担当
- 主なユーザーは社内の人
チームメンバー
- PO（東京1名）
- PG5名（うち、東京2名）
- QA6名
スクラム概要
- スプリントは2weeks
- 他にPG/QA定例（修1回）やQA定例（週2回）を実施
Before / After
Before
- 試験中やリリース後に見つかった問題は3ヶ月後〜6ヶ月後に対応だった
- QAプロセスは全実装Fix後に実施
- 機能説明会後に試験設計開始
- 別々の製品をウォーターフォールでやっていたが、リリース日は同時にしていた（慣例）
After
- リリースサイクルは1ヶ月。
- 1スプリント2weeks
- スプリント計画からQAも全員参加
- 実装が完了したものからテスト設計を始めてる
- 別々の製品は別々のリリース日に
問題点
今後の課題
- 回帰試験の自動化
- 自動化できれば前半から回帰試験ができる
- PGによる試験設計レビュー
- QAプロセス自体もアジャイル化したい
質問
品質保証部に所属しているようだが、サイボウズとして開発部とは別だと思うが、スクラムチームは部門を超えているということか？マトリクス組織ならば、縦と横がどちらが強い感じか？
- 職能別の部門になっている
- PMだけが集まっていたり、デザイナーのみの部署がある
- 動き自体はプロダクトチームで動いている
- マネージャはリソース調整や全体の成長を促すようにしている
- ローテーションをさせたり
ウォーターフォールの場合のQAは非機能要件テストをやっていると思うが、スクラムになってから減ったのか？
- ウォーターフォールの頃は通っていないとリリースNGになっていたが、スクラムになってからは少なくなったが、回数が増えているのでセキュリティテストは手厚くなっている
- 性能検証は減っているかも
- プロダクトチームとは別チームで性能試験やセキュリティ試験をやっている
ウォーターフォールのQAはブラックボックステストが中心的だったと思うが、今後の課題を見るとホワイトボックステストに寄っていきたいのか？
- ウォーターフォールの頃からあまりブラックボックステストをやっていた訳ではない。
- 細かめに書いてもらったものを試験していたので、そこの間引き方が今後の課題
製品の試験期間とリリース日の間に空白の期間があるのは何か？
- 運用試験やリハーサルなどがあるため。
