Slide 1

Slide 1 text

出社っていいものなの。 開発者のテストに対する 疑問や思いが聞けたの bun913

Slide 2

Slide 2 text

自己紹介 > 所属 開発3年、クラウドエンジニア2年 JSTQB Advanced Level TMに合格しました > 経歴 ダイの大冒険 > 好きなもの クラスメソッド株式会社 >名前 bun913(今泉大樹)

Slide 3

Slide 3 text

私の立場や発表の前提 > 領域 スクラム開発やスクラムライクな開発の経験がメインです > 開発手法 Webアプリケーションが主領域(AWS、バックエンド開発、ちょっとフロントエンド) >立場 開発に近い立場として、テストやQAについて真剣に考えています

Slide 4

Slide 4 text

最初に謝罪したい こと ・スライドのタイトルが若干違うかもしれないこと ・会話形式で進むため、テンポ悪いです

Slide 5

Slide 5 text

出社っていいものなの。 開発者のテストに対する 疑問や思いが聞けたの これが・・・

Slide 6

Slide 6 text

普段話さない同僚(開発 者)と会食で話す時に流れ で神記事たちを紹介してき たから褒めてほしいの こうかも!

Slide 7

Slide 7 text

同僚(開発者)との会食時の会話を再 現していきます

Slide 8

Slide 8 text

〜お互いの好きな技術を話したあと〜 同僚「じゃあ、最近テストとか好きなんですね」 私「そうですね。スクラム開発の中でテストの知識と か技法を活かせると楽しいですね。」 同僚「技法って境界値分析とかですか?」 私「ですです。」 同僚「でも、ぶっちゃけドメイン知識とか、プロダク トの背景とか知らないと技法だけだと苦しくならない ですか?」

Slide 9

Slide 9 text

私「あ〜、個人的にはほとんどの場合で、めっちゃ大 事だと思いますね」 同僚「ほとんど?」 私「例えばセキュリティとかに特化したテクニカルな テストのことは分からないですけど、スクラムチーム で一緒に入るような人とかは特にそうですよね。」 同僚「色々な職能の人をひっくるめて開発チームって いうやつ?」

Slide 10

Slide 10 text

私「ですね。スクラムの3つの役割みたいなイメージしてます」 PO(プロダクトオーナー) SM(スクラムマスター) 開発チーム フロントエンド開発 バックエンド開発 QA・テストリード

Slide 11

Slide 11 text

同僚「そうですよねぇ!開発側もQAも、機能の背景 とか知識が大事ですよね。」 私「以前rinaさんという方も背景とか目的を考えるこ とが大事だって言ってましたし、僕もそう思います」 「わからない?をわかる!に変えよう!- QAエンジニアが実践している基本的な考え方と方法」 より

Slide 12

Slide 12 text

同僚「いやぁそうですよね!絶対!」 私「ですね。それでQAの方の発案で受け入れ基準に テストケースみたいなのを入れ込むとか」 同僚「バグを未然に防いで、開発者側も単体テストで より有効なテストをかけちゃうみたいな!?」 私「です!rinaさんが同じ資料で紹介してました」 私「あまりテスト技法をしらない開発側にも勉強にな るし、非常に良いと思います」

Slide 13

Slide 13 text

同僚「えぇぇ・・・めっちゃいいね。rinaさん」 「わからない?をわかる!に変えよう!- QAエンジニアが実践している基本的な考え方と方法」 より

Slide 14

Slide 14 text

私「テストの資格試験(JSTQB)でも、プロセス準拠 のテスト戦略みたいな名前で、こんな感じのことが書 いてありますからね」 私「だからはっきりと、ユーザーストーリーと受け入 れ基準をしっかり書くのをテスト戦略って言い張りま しょう」 同僚「めっちゃいいですね。なるほどな〜。」

Slide 15

Slide 15 text

私「SmartHRさんの記事すごくいいんでSlackで送っ ときますね」 「スクラムをうまく回すために受け入れ基準をきちんと書く」 「早くしっかりユーザに価値を届けるためのチケットの書き方」

Slide 16

Slide 16 text

同僚「あっ。ごめんこの記事知ってます。以前めっち ゃ良いなって思ったんですよ」 私「僕もダイの大冒険と同じくらい好きですね」 同僚「へぇ〜」(興味ない) ※ 私は「ダイの大冒険ガチ勢」を自称しています

Slide 17

Slide 17 text

しばらく関係ない話をしてから・・・

Slide 18

Slide 18 text

〜私がジムに通い出した話をした後〜 〜(略)〜 私「中山きんにくんさん、な。」 同僚「へぇ〜」(どうでも良い) 同僚「でもさっきQAの方の関わり方みたいな話した じゃないですか」(話を逸らす) 私「え、はい」 同僚「ぶっちゃけ最初からスクラムチームにQAの方 が入っているのみたことないんですよね」

Slide 19

Slide 19 text

同僚「ぶっちゃけ、バグが目立ち初めたりしてから呼 ばれたり。プロダクトがある程度育ってから呼ばれた りとか」 私「いや実は私もそっちの方を多く観測しますね」 同僚「ですよね。あと、同じスクラムチームと言いな がら実質MTGとかも別々にやっているケースとかもあ るじゃないですか?」 私「結構ありますよね」

Slide 20

Slide 20 text

私「実質リーダー同士しか話さないみたいな。チケットでの やりとりはあるけど」 開発サブチーム QAサブチーム コミュニケーション

Slide 21

Slide 21 text

私「これ自体にどうこう思わないですけどね。対立構 造とかになってさえいなければ」 私「個人的には、どういう形であれ同じ目的を持った 専門性が違う人って意識なんですけどね」 同僚「プロダクトをよくしたい。ビジネスを成功させ たい。みたいな思いは一緒ってこと?」

Slide 22

Slide 22 text

私「です!スクラムでよく言われるT字型の人材みたいな」 「スクラムチーム—I字型とT字型の人々|サイバーメディアン」 より

Slide 23

Slide 23 text

私「個人的に少なくとも可能なうちは近くで関わり合 いたいですけどね。」 私「双方に越境して知見を共有したり、課題を解決し たりとか。サイボウズさんでもそんな記事みました」 「DevからQAに越境してみた」 より

Slide 24

Slide 24 text

私「異動までしなくてもプチ越境があるとかも」 「20230207_DevLOVE_ぷち越境QAのすすめ」 より

Slide 25

Slide 25 text

同僚「いや〜。でもプロジェクトとかプロダクトの規 模が大きかったり、ドメインの境界多かったりとかで 最適解違うよね。絶対。」 私「ですよね〜」 私「他にもテストの独立性とかもあると思うので、単 純に私がお互いに尊敬し合いたいだけですね」 同僚「もうそれ役割っていうか組織文化の話になるん じゃないですか?」 私「確かに。そもそも役割関係なく、尊敬し合えた方 が絶対いいですしね」

Slide 26

Slide 26 text

私「SmartHRさんも横断のQAチーム作ったみたいな 話もみましたしね」 「SmartHR基本機能のQAチームが開発チーム横断で品質保証活動をがんばっている話」 より

Slide 27

Slide 27 text

同僚「部分最適にならないようにみたいなのあるんで すかね?」 私「そうなんですかね?」 私「いや、ていうかオタク早口で色々語っちゃってす みません」 同僚「いや楽しかったですよ」 (この後は逆にドメイン駆動設計とか、ソフトウェアアー キテクチャの考え方を聞いて終了)

Slide 28

Slide 28 text

他にも・・・ 以下のような話を開発の方に話すと喜ばれる率高い ブロッコリーさんの実例マッピングに関する話 テスト技法の話とか 境界値分析 あと、ドメイン分析テストが「あぁ〜す げ〜。めっちゃいいですね」って言われる テストツール・サービスの話とか GIHOZ ノーコードテストツールetc

Slide 29

Slide 29 text

なので・・・ もっと皆さんの小さな改善、小さな挑戦、小さな知 見・・・教えて下さると嬉しいです JaSST nano で5分登壇でもよいです ブログ書いてみた!でもよいです オリジナルな知見でなくてもよいので、おすすめのコ ンテンツなどありましたらぜひ教えて下さい

Slide 30

Slide 30 text

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