アジャイルに触れて_変化したQAとしての心理__スモールから積み重ねることの大切さ_.pdf

Transcript

1. アジャイルに触れて 変化したQAとしての心理 〜スモールから積み重ねることの大切さ〜 JaSST nano vol.48 すなかわ / ミジンコおじさん
2. 自己紹介 • 名前　砂川　雅裕 　（すなかわ　まさひろ） • SNS　X : koppamijinko • 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン • 趣味 野球観戦、映画、旅行 　　→ 節約、資産形成、自己研鑽 • 好きなテスト技法 デシジョンテーブルテスト • プライベートでは二児の父（男女の双子）
3. 今日のきっかけ • Discord • X • 廊下での声がけ • 仲間からの声がけ すごく励みになりました！ ただ、もう少し話せれば 良かったかもと思ったので ...
4. 今日のきっかけ 心 技 体 あまり話さなかったなと 思ったので、この辺りを 振り返ろうと思いました！
5. ちなみになぜ５月にしたか？ 1年前、自分が主体的に 発表するきっかけになったの が、JaSST nano でした。 そのため、感謝？をこめて 最後に話をさせていただきま す。
6. アジェンダ • アジャイルに触れる前のわたしがしていた品質保証がどうだったか • アジャイルに触れて、気づいた価値観 • QAとして少し変えたところや取り組んだ事例の紹介 • まとめ
7. アジャイルに触れる前のわたしがしていた 品質保証がどうだったか
8. かつての話（テストエンジニアとしての業務） 要求定義 基本設計 詳細設計 実装 コンポーネント テスト 統合テスト システムテスト 受け入れテスト この辺りを 依頼されるこ とが多かった
9. テストエンジニアとして品質を守るためにやってたこと 様々な仕様書 テスト分析 / テスト設計 テストケース作成 テスト実行 結果報告
10. テストエンジニアとして品質を守るためにやってたこと 様々な仕様書 テスト分析 / テスト設計 テストケース作成 テスト実行 結果報告 • テスト結果 • テストを作っている中での気づき • 不具合票 などのテスト活動を通した情報提供で プロダクトの品質を守ってきた
11. この時の心理 ドキュメントなし でどう テスト作るん？ 無理よ 膨大な ドキュメントから テスト作るのも 技術 だしな 正直WFが出来ない でアジャイルなんて できないっしょ とはいえ、 仕様変更とか 起きまくって 辛いなぁ...。 アイデアから テストしたい
12. アジャイルに触れて、気づいた価値観
13. 最初にアジャイルに触れたとき (第三者検証終盤 ) 要求定義 基本設計 詳細設計 実装 コンポーネント テスト 統合テスト システムテスト 受け入れテスト 引き続き この辺りの 担当
14. 最初にアジャイルに触れたとき (第三者検証終盤 ) 要求定義 基本設計 詳細設計 実装 コンポーネント テスト 統合テスト システムテスト 受け入れテスト テストのインプットに 対して、QA(質問)をするこ とで、インプットの質を上げ るようにした
15. これを続けていた結果 • インプットに対するQAが減った ◦ インプットの質が向上 • 本番で顕在化する不具合が減った ◦ テストがゲートキーパーとして 機能していた • 自分が作るテストのレビューの 時間が減った ◦ というよりも一緒にテストのパ ターンを増える時間が増えた などなど、副次的な効果が多かった
16. この時の心理 ドキュメントがなく ても、 一緒に作る マインドが大事か も？ QCDの バランス踏まえ て、テストの厚 みを 考える必要あり そう アジャイルに おけるQAの役割 ってテスト作って やるだけなのか？ インプットとなる アイデアのところを QAでブラッシュアッ プさせるのは いい成果かも
17. 今の状況 • XPを行っている = アジャイル開発で進めている • XPのプラクティスの中に、TDDや受け入れテスト、CI / CDが入っている ◦ エンジニアもテストを書いている ◦ テスト＝継続的に行うものなので、自動で回っていることを前提にする
18. 入社前の私の状況 • アジャイル開発の現場にいて、そこでテストはしていた • 認定スクラムマスター研修は受けて、取得していたので、 アジャイル開発が何たるかというのはなんとなく理解していた • 自動テストは、趣味でTestCafeやPlaywright などを操作したことが あるくらいだった（もちろんCI / CDは不明）
19. 今の会社のチームの話 プロダクト マネージャー (PdM) プロダクト デザイナー (PD) QAエンジニア 開発エンジニア 要求分析 要件定義 体験設計 デザイン システム構築 設計・実装 テスト (動的・静的) 自分たちの職種のスペシャリティは発揮しつつも、 連携するところは連携しながら、チーム開発を続けている
20. チームが価値提供する上で目指している価値観 • チームが目指しているのは、顧客に対してできる限り早く「価値」を提供すること • 価値提供をしていくためには、チームが変化に対応ができるような状態になって いないといけない
21. 本当に届けたいもののうち、どこがクリティカルか 2 3 8 4 4
22. 本当に届けたいもののうち、どこがクリティカルか 2 3 2 4 赤線のところが 最も効率よく価値を 提供し続けられている 8
23. 本当に届けたいもののうち、どこがクリティカルか 2 3 2 4 8 私たちが、届けたい価値というのは何か ということを考えて、実現方法として 最もクリティカルな方法は何か？ そのためには、小さくリリースしていく ことがやっぱり重要であると感じてきた。
24. スモールに開発することに関して アジャイルソフトウェア開発宣言
25. スモールに開発することに関して MVP（Minimum Viable Product）
26. QAとして少し変えたところや 取り組んだ事例の紹介
27. スモールに開発することで QAが感じたメリット • リリースする範囲の仕様や実装内容を把握しやすくなった ◦ 実際にエンジニアとテストを作る時にも、何を実現したいのかを把握しやすく なった ◦ 実装内容が他の機能に影響を与えたり、不正なデータの生成を助長させな いか、すぐにフィードバックしやすくなってきた • リリースしたい内容に対する議論がしやすくなった ◦ 例えば、画面デザインができた時に、PdMやPDに対して、抜け漏れている 内容がないか、推敲する時間が取れるようになった（特に法律とかセキュリ ティホールを作らないか など） ◦ 議論した点がそのまま抜け落ちていないか、テストに書き起こしておくこと で、リリース後のバグの混在を防ぎやすくなった
28. スモールに開発することで QAが感じたデメリット • リリース単位がスモールであっても、プロダクトが成長していると思わぬところに 影響範囲があり、それを見逃す可能性が高い ◦ テストをしていないと、見逃したまま本番にリリースしてしまう可能性は上が る • 提供したい価値が既存のユースケースを変えてしまう可能性がある ◦ 例えば、画面の表示を一新したいとした場合、他のプロダクトとのデザイン や体験の一貫性がないと逆に認知負荷を上げてしまうことがある
29. このデメリットに対して取り組んでいること • リリース単位がスモールであっても、プロダクトが成長していると思わぬところに 影響範囲があり、それを見逃す可能性が高い ◦ テストをしていないと、見逃したまま本番にリリースしてしまう可能性は上が る • 提供したい価値が既存のユースケースを変えてしまう可能性がある ◦ 例えば、画面の表示を一新したいとした場合、他のプロダクトとのデザイン や体験の一貫性がないと逆に認知負荷を上げてしまうことがある 受け入れテスト 探索的テスト
30. 30 XPにおけるテストの性質の違い 　　　 受け入れ テスト 　　　 ストーリーを実装するために作るテスト 基本的には、エンジニア自身がストーリーを完遂するために、 Checkingとしてのテストが出来上がる PdMやPDが仕様として守りたいものを確認するテスト ビジネスサイドが仕様として守りたい機能をピックアップして、 システム全体の妥当性確認に観点を置いている ⚠ストーリーの受入基準がPASSするためのテスト ↓ 💡ビジネスサイドがシステムが求められている要求や絶対に起こしては いけない致命的バグが起きないかCheckするためのテスト 受け入れテスト TDD
31. 31 探索的テスト • 基本的には、チーム全員で参加 • 目的を定めて、実施することが多い • テストするというよりも、お互いに学習しながら実施する ◦ こうすることで、他のシステムにも触れたりする ◦ 画面や体験に一貫性がないところを感じることができる
32. 最近の心理 ドキュメントも 大事だけど、 価値提供は大事 だな QCDは、出す プロダクトで 体現すべきだ なぁ。テストだけ が考えること じゃないかも 動的テストでやって た部分は、どんどん 自動化＋シフトレフ トしていこ 早いフィードバックの 方が結果として価値 向上にも 繋がってきたのか な？
33. まとめ
34. 34 心理の変化 • 最初は、テストを作ってバグを出したり、テスト結果を伝えることに 価値を見出していた • アジャイルと出会い、最初は第三者検証の立場だったので、 大きく踏み込めない部分があったが、＋αの価値を出すだけで、 一緒に仕事をしている人からいいフィードバックをもらえた • 現職では、色んな知見をもとに、QAとして主にテスト活動を チームで包括に、もっと上流の段階で、やるようにしている。 そうする方が、包括的なテストを作るよりも小さい労力で品質保証が できているような感じがあるから
35. 35 これからしたいこと • 今は、自動テストでテストが回帰的に回り続ける環境で、 主に機能性担保を続けているが、もう少しアジャイルテスティングを 発展させて、価値を提供し続けることにフォーカスしていきたい ◦ 主にシフトレフト部分に関しては、もっとフォーカスしていくようにしたい • さらにアジャイルQA、アジャイルテスト担当者として成長していくために、何がで きるかということを模索していきたい
36. 36 最後に • 本日の話に興味を持ってくださった方は、ぜひ一緒にお話しましょう！