なんちゃってスクラムのテストに悩んでいた時の自分へ伝えたいの

JaSST nano vol.31(https://jasst-nano.connpass.com/event/304605/) での発表資料です。

過去になんちゃってなスクラムプロジェクトに悩んだことがあります。
「あの時の自分にどうしても伝えたいことは？」というのを絞り出してみました。

Transcript

1. なんちゃってスクラムのテストに 悩んでいた時の自分へ伝えたいの
2. あのとき 「これだけは知っておきたかった」を話します
3. 自己紹介 ＞ クラスメソッド株式会社 開発3年、クラウドエンジニア2年 JSTQB AL TM勉強中 ＞ 経歴 ダイの大冒険 ＞ 好きなもの モダンアプリケーションコンサルティング部 ＞名前 bun913（今泉大樹）
4. 私の立場や発表の前提 ＞ 領域 スクラム開発を想定しています。過去になんちゃってスクラムで悩んだことがあります。 （私にとってのなんちゃってスクラムの定義は後ほど） ＞ 開発手法 Webアプリケーションが主領域（AWS、バックエンド開発、ちょっとフロントエンド） ＞立場 開発に近い立場として、テストやQAについて真剣に考えています
5. LTの対象者・ゴール 対象者 スクラム開発にあまり慣れていない開発者・テス ト担当者の方 ゴール 「どこまでテストすれば良いの？」 「開発者個々人のセンスで実装しちゃっている」 などの課題への一つのアプローチを提示
6. 免責事項 私はスクラムの専門家というわけではありません スクラムガイドや書籍を読んでいますが、正確では ない知識を記載・発言しているおそれがあります そもそもスクラム自体が軽量なフレームワークであ り、唯一の正解的方法はないという前提でお話させ ていただきます
7. なんちゃってスクラムのあるある言いたい
8. （私的）あるある 何をどこまでやったら完了かわからない
9. 私のなんちゃってスクラム体験 やるべきことってどう管理するの？ A. よくわからんけどカンバン使うらしい 開発の流れは？ A. スプリントとかいうのを2週間で区切ろう スクラムイベントってなに？ A. よくわからんけど、毎日朝会やろう →一見それっぽい流れ？
10. スプリントバックログを見てみると・・・
11. バックログアイテムを開いてみると・・・
13. ToDoリスト感
14. もっと情報が欲しい・・・！ 以下のような情報が書いてない・合意取ってない 具体的に何をやるのか？ 背景や意図は？ビジネス的な意味は？ 誰が使う機能なのか？なぜ優先するのか？ 何をやらないのか？ 具体的に何ができていれば受け入れとなるの？ これらが無いと有用なテストが書きにくい・・・ なんとなくカバレッジ網羅しているとか
15. 要するに私にとって「なんちゃって」とは ツールやタイムボックスなどはスクラムっぽい 一方で、スクラムの理論や価値基準は置いてけぼり 透明性・検査がない PO・スクラムマスター・チームの間でコミュニケー ション不足 開発もテストも仕様も、個々人の技量・スキルでな んとかしている もちろんコラボレーションもない（少ない）
16. じゃあ具体的に何をやれっていうのさ！
17. ユーザーストーリーベースのバックログなら スクラムをうまく回すために受け入れ基準をきちん と書く（SmartHR様 TechBlog）が参考になります ユーザーストーリーに対する受け入れ基準を書 くと何が嬉しいのか 具体的にどのように書いてみるのか？ ということが分かりやすく書かれており、とて もおすすめです
18. なお、個人的には・・・ 必ずしもユーザーストーリーの形式でなくても良い とは思う（機能ベースのタスク・チケットでも） スプリント計画などで受け入れ基準まで書けない場 合は、プロダクトバックログリファインメントでや るというケースも聞いたことがあります 大事なのはスクラムをうまく回すために、チケット を明確にしておく・合意しておくことだと思います
19. 更にすばらしいと思うアプローチとして 色々な人とコラボレーションで受け入れ基準を書く テストが得意・QA担当 デザインが得意など 色々な人との認識が合うので手戻り自体が少なくな る・手戻りのコストが少なくなるなどのメリット
20. こちらの資料が非常に参考になりました わからない？をわかる！に変えよう！- QAエンジニ アが実践している基本的な考え方と方法（rina様） 後半の「コラボレーションベースのテストアプ ローチ」 QAさんとコラボすることで、開発者がテスト技 法に習熟していなくとも、有用なテストケース を実装できそう もちろん開発者も基本的な技法を知ってお いたほうがよい
21. 開発者としても知っておきたい技法 Mustレベル（個人的に） 同値分割 境界値分析 なぜそう思うのか？ 効率的にバグが出そうなところをテストできる （体感としても）単体テストで頻出 あと結局のところ・・・色々な本で「基本」 「非常に重要」という紹介をされている
22. 概念は知っているけどどう勉強するの？ ソフトウェアテスト技法練習帳 ～知識を経験に変え る40問～ （技術評論社）
23. あの困っている時に知りたかったことでした！
24. まとめ
25. まとめ ユーザーストーリーと受け入れ基準はちゃんと書こう 機能ベースのタスク・チケットでも良いと思う 大事なのは「具体的には何を」「なぜ」やるのか などを明確にして、合意することだと思う 時間の関係で省いた実例マッピングも熱い 開発者でもテスト技法を知っておいた方が良いと思う おすすめの練習本があるよ！
26. 重厚なドキュメントがなくても コミュニケーションとコラボレーション は忘れないぞ！
27. ご清聴ありがとうございました