出社っていいものなの。開発者のテストに対する疑問や思いが聞けたの
by
bun
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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
本当にご清聴ありがとうございました