こんにちは、QAチームの生井(id:riririusei99)です。
今回は私、生井が登壇しました、『Agile QA Night!!』のイベントをレポートします！
Agile QA Night!!とは
株式会社ビズリーチ様が開催する、「D3（ディーキューブ）」というプロジェクトチームでは、たくさんのイベントや勉強会を開催しており、今回は「Agile QA」というテーマで勉強会が開催されました。
Agileな組織が多くなっている昨今、QAはどのようにAgileに入っていくべきなのでしょうか。 今回はAgile開発に上手に入り込んでいるQAの方々をお招きし、以下のような話をしていきたいと思います。 （Connpassより）
きっかけ
前回のブログで発表した内容が好評で、今回の勉強会の開催・参加が決まりました。
本当にありがとうございます。今日話してて思ったけど、今度どこかで Agile QA Night とかをやれば良いのでは？
— ブロッコリー (@nihonbuson) 2019年2月13日
登壇者は @hiroyuki3gou と @riririusei99 と自分とかで。
参加レポート
さっそく発表の内容のレポートをします。
発表1:チームスピリットにおける品質保証の仕組み:リターンズ
前回の発表の再演を依頼されていましたので内容はほぼ同じですが、AgileQAというテーマに則したように若干構成をいじっています。
また、前回の発表で話きれなかった部分などの補足などを追加しています。
発表した感想ですが、120人入る会場で登壇することは人生で初めてで非常に緊張しました。
といいつつも、社内のメンバーに向けてリハーサルを行った際盛大に失敗した発表をしていたおかげで幾分かリラックスして臨めました。
協力してくれたメンバーに感謝です。
※質疑応答の時間がとれなかったため、パネルディスカッションの質問については後述します。
発表2:伝統的な文化が根強い組織がAgileな感じにQA戦略を組み立てた
※資料は共有され次第、添付します
次は認定スクラムマスター、認定スクラムプロダクトオーナーを所持されているacchanさんの発表です。
私も認定スクラムマスター取りに行きたい。
発表では既存の開発がいわゆる「なんちゃってスクラム開発」になっていたところに対して、
- Heuristic Test Strategy Model
- A new model for test strategies
- MicroSoftによるScale Agile to Large Teams
- QA2AQ
といった考え方をベースにしてスクラムと品質保証に取り組んでいるという内容でした。
個人的には、「開発、QAという境はなくチームがスプリント内で開発、テスト全てやる」という考え方と弊社の「QAは開発チームの１メンバーなので、スプリント内で開発・テスト全てやる」という考え方はとても近いかなぁと思いました。
参考リンク
Heuristic Test Strategy Model
danashby.co.uk
docs.microsoft.com
www.wirfs-brock.com
発表3:Agile開発に入り込むQAの方法
３番目の発表については、開催・会場提供していただいているブロッコリーさんです。 Agile開発に入り込むQAというテーマで初めはQAの開発組織の関わり方について発表した後、モブプログラミングを開発者とテストエンジニアが行うというテーマで発表されました。
- 時間の経過を意識したテストケースの命名
- テストエンジニアは指摘事項を言い切るべきか
といったテーマについては、日々の業務に直結するような内容で非常に参考になりました。
参考リンク nihonbuson.hatenadiary.jp
発表4:Agileな開発におけるテスト観点のお話(仮)
発表の最後は「アジャイルな気持ち」と「テスト観点」について発表したなそさんの発表です。
アジャイルな現場→居酒屋という発想…!! #D3QA
— すみす@inTOKYO (@smith703) 2019年3月14日
アジャイルな現場とは居酒屋だというなそさん
- 「スプリント：入店から退店まで」
- 「プロダクトバックログ：伝票」
- 「完了の定義：料理を提供し、お金を払う」
たしかにこの居酒屋に置き換えると理解が進みそう…積極的に使っていこうと思います。
さすがテストラジオを運営しているなそさん、発表が上手く、数々の名言が飛び出して来ました。「テスト観点はみんなの心の中にある」
— No.9@なまい (@riririusei99) 2019年3月14日
それを集めるような仕事してるので、使っていこうと思います。
#D3QA
パネルディスカッション
さすがに、壇上で話していたのでここは若干、割愛。 詳しくはtwitterで「 #D3QA」で検索お願いします。 ここでは、パネルディスカッションで答えられなかった質問にいくつか答えていきます。
なまいさんのテスト計画書の具体例が見たいです。イメージを掴みたい！
すごーく簡素に書いてみました
| 項目 | 項目例 | 説明 |
|---|---|---|
| 品質 | デモ利用可能なプロトタイプのの出荷 | PM・ステークホルダーの要求を書く |
| リリース判定項目 | 優先度High以上のチケットが全て解決済み シナリオテストの実施が完了している |
|
| 実施体制 | QA２名で実施 | |
| 戦略 | プロダクト品質のリスクを洗い出し優先順位を決めて実施する | |
| QualityBacklog | 以下に必要なタスクを計画する | |
| （強化テスト） | シナリオテスト,ユーザビリティテスト | デモ利用のため性能テストは行わない |
| （手動テスト） | テスト設計改善 | 上がったバグチケットを分析し、多発する観点をチェック項目に組み込む |
| （自動テスト） | E2E基盤作成 | 本番機能開発に備えて基盤作成 |
| スケジュール |
以前書いた内容はこんな感じです。
teamspirit.hatenablog.com
Agileはいつも短いスプリントでの検証なので、たまに大きな検証漏れも発生する場合があり、それは解決するために何か素晴らい方法提案できるのでしょうか？
まずは大きな検証漏れがどんなものがあるか明らかにすること＆合意するのが大事だと考えています。
プロダクトにおけるNever(絶対にやってはいけないこと), Must（できること）,Want(できたら嬉しい)をPM・ステークホルダー・QAでそれぞれ出し合って合意しましょう。
そうすることで想定している大きな検証漏れが発生しづらくなります。
合意した内容は一度作ったら作りきりにせず、都度メンテナンスが必要です。
アジャイルでQAやっているのは楽しいですか？楽しいとしたらどのあたりが楽しいですか？
楽しいと思う瞬間はたくさんあります。個人的に思う３点を書きます。
- 仕様作成から参画できるので自分のアイディアが反映されることがある
- 機能実装の進め方もチームで決めるため、テストの量を（ある程度）コントロールしながら開発を進めることできる
- チームで作ったものという意識が感じられるため、リリースのときはやっぱり嬉しい
開発者がQAが行うテストを日常的に行う（手伝う）ことってありますか？
実装するメンバーもQAも等しく開発チームの一員なので手伝う・モブテストやることはよくあります！
おわりに
組織の状態によってスクラム開発におけるQAエンジニアの働き方は違うのだなぁと感じました。
その上で、組織が成長することで自分たちの組織の中でも品質保証のやり方を変化させていかないといけない未来が見えてきました。
特に開発メンバーのテスト支援という部分で挑戦できる部分がたくさんあることがわかったので今後は、そういった部分でも注力したいと考えています。
We're Hiring!!
チームスピリットではQAエンジニア/開発エンジニアを絶賛募集しています！！ 興味をもった方、詳しく話を聞いてみたい方は、以下のリンクからお問い合わせください！
以上、登壇レポートでした。
