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

by bun

Slide 1

Slide 1 text

Slide 2

Slide 2 text

あのとき「これだけは知っておきたかった」を話します

Slide 3

Slide 3 text

自己紹介＞クラスメソッド株式会社開発3年、クラウドエンジニア2年 JSTQB AL TM勉強中＞経歴ダイの大冒険＞好きなものモダンアプリケーションコンサルティング部＞名前 bun913（今泉大樹）

Slide 4

Slide 4 text

私の立場や発表の前提＞領域スクラム開発を想定しています。過去になんちゃってスクラムで悩んだことがあります。（私にとってのなんちゃってスクラムの定義は後ほど）＞開発手法 Webアプリケーションが主領域（AWS、バックエンド開発、ちょっとフロントエンド）＞立場開発に近い立場として、テストやQAについて真剣に考えています

Slide 5

Slide 5 text

LTの対象者・ゴール対象者スクラム開発にあまり慣れていない開発者・テスト担当者の方ゴール「どこまでテストすれば良いの？」「開発者個々人のセンスで実装しちゃっている」などの課題への一つのアプローチを提示

Slide 6

Slide 6 text

免責事項私はスクラムの専門家というわけではありませんスクラムガイドや書籍を読んでいますが、正確ではない知識を記載・発言しているおそれがありますそもそもスクラム自体が軽量なフレームワークであり、唯一の正解的方法はないという前提でお話させていただきます

Slide 7

Slide 7 text

なんちゃってスクラムのあるある言いたい

Slide 8

Slide 8 text

（私的）あるある何をどこまでやったら完了かわからない

Slide 9

Slide 9 text

私のなんちゃってスクラム体験やるべきことってどう管理するの？ A. よくわからんけどカンバン使うらしい開発の流れは？ A. スプリントとかいうのを2週間で区切ろうスクラムイベントってなに？ A. よくわからんけど、毎日朝会やろう →一見それっぽい流れ？

Slide 10

Slide 10 text

スプリントバックログを見てみると・・・

Slide 11

Slide 11 text

バックログアイテムを開いてみると・・・

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

ToDoリスト感

Slide 14

Slide 14 text

もっと情報が欲しい・・・！以下のような情報が書いてない・合意取ってない具体的に何をやるのか？背景や意図は？ビジネス的な意味は？誰が使う機能なのか？なぜ優先するのか？何をやらないのか？具体的に何ができていれば受け入れとなるの？これらが無いと有用なテストが書きにくい・・・なんとなくカバレッジ網羅しているとか

Slide 15

Slide 15 text

要するに私にとって「なんちゃって」とはツールやタイムボックスなどはスクラムっぽい一方で、スクラムの理論や価値基準は置いてけぼり透明性・検査がない PO・スクラムマスター・チームの間でコミュニケーション不足開発もテストも仕様も、個々人の技量・スキルでなんとかしているもちろんコラボレーションもない（少ない）

Slide 16

Slide 16 text

じゃあ具体的に何をやれっていうのさ！

Slide 17

Slide 17 text

ユーザーストーリーベースのバックログならスクラムをうまく回すために受け入れ基準をきちんと書く（SmartHR様 TechBlog）が参考になりますユーザーストーリーに対する受け入れ基準を書くと何が嬉しいのか具体的にどのように書いてみるのか？ということが分かりやすく書かれており、とてもおすすめです

Slide 18

Slide 18 text

なお、個人的には・・・必ずしもユーザーストーリーの形式でなくても良いとは思う（機能ベースのタスク・チケットでも）スプリント計画などで受け入れ基準まで書けない場合は、プロダクトバックログリファインメントでやるというケースも聞いたことがあります大事なのはスクラムをうまく回すために、チケットを明確にしておく・合意しておくことだと思います

Slide 19

Slide 19 text

更にすばらしいと思うアプローチとして色々な人とコラボレーションで受け入れ基準を書くテストが得意・QA担当デザインが得意など色々な人との認識が合うので手戻り自体が少なくなる・手戻りのコストが少なくなるなどのメリット

Slide 20

Slide 20 text

こちらの資料が非常に参考になりましたわからない？をわかる！に変えよう！- QAエンジニアが実践している基本的な考え方と方法（rina様）後半の「コラボレーションベースのテストアプローチ」 QAさんとコラボすることで、開発者がテスト技法に習熟していなくとも、有用なテストケースを実装できそうもちろん開発者も基本的な技法を知っておいたほうがよい

Slide 21

Slide 21 text

開発者としても知っておきたい技法 Mustレベル（個人的に）同値分割境界値分析なぜそう思うのか？効率的にバグが出そうなところをテストできる（体感としても）単体テストで頻出あと結局のところ・・・色々な本で「基本」「非常に重要」という紹介をされている

Slide 22

Slide 22 text

概念は知っているけどどう勉強するの？ソフトウェアテスト技法練習帳～知識を経験に変える40問～（技術評論社）

Slide 23

Slide 23 text

あの困っている時に知りたかったことでした！

Slide 24

Slide 24 text

まとめ

Slide 25

Slide 25 text

まとめユーザーストーリーと受け入れ基準はちゃんと書こう機能ベースのタスク・チケットでも良いと思う大事なのは「具体的には何を」「なぜ」やるのかなどを明確にして、合意することだと思う時間の関係で省いた実例マッピングも熱い開発者でもテスト技法を知っておいた方が良いと思うおすすめの練習本があるよ！

Slide 26

Slide 26 text

重厚なドキュメントがなくてもコミュニケーションとコラボレーションは忘れないぞ！

Slide 27

Slide 27 text

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