Tweet
Tweet

Slide 1

Slide 1 text

はじめてのSDET あれ？私の職種レアすぎ・・・？ Jasst Nano vol.47 1

Slide 2

Slide 2 text

自己紹介 bun （ぶん）さん Jasst Nano Vol.29 ~ Vol.40 に登壇 • 2024 年7 月 に開発（っぽい）エンジニアからSDET （後 述）として転職しました • 開発・AWS ・テストちょっとずつできます • ISTQB TTA/TA/TM 取得済み • 2024/2023 Japan AWS Top Engineers / All Certifications Engineers • 2

Slide 3

Slide 3 text

なぜ登壇を控えていたのか？ 3

Slide 4

Slide 4 text

物理的に時間がなくって・・・英 語を学習してました 4

Slide 5

Slide 5 text

成果 (2024.7 ~ 2025.3) TOEIC LR: 675 → 845 • PROGOS: A1 → B1High ( 最高: B2) • 英会話: ＼(^o^) ／ → 自分の興味のあるト ピックならわりと話せるように • 5

Slide 6

Slide 6 text

これが言いたかった 6

Slide 7

Slide 7 text

冗談はさておき、ここからが本題 7

Slide 8

Slide 8 text

今していること ずっと何年も一人QA でプロダクトを支えてきた偉大なQAE と2 人のQA チームに います • SDET (Software Development Engineer in Test) という職種です • 2024.7 に開発者っぽい仕事からジョブチェンジしました • 8

Slide 9

Slide 9 text

SDET として 理想: 開発の知見もQA エンジニアのスキルもある人が、よりテストやQA にフォ ーカスして開発に自信を早く多く与える • シフトレフトの推進 ◦ 自動テストの効果的な導入・促進 ◦ 9

Slide 10

Slide 10 text

レア目な職種なので、ちょっと自分語 りをしてみます 10

Slide 11

Slide 11 text

チームに役立てたと思うこと・まだ まだなところ 11

Slide 12

Slide 12 text

チームに還元できたと思うこと ソフトウェア開発経験の知見と技術 • AWS エンジニアとしての経験 • CI/CD を実装する上での課題に対する解決案の提案 • 12

Slide 13

Slide 13 text

たとえば Playwright を使ったAPI テストの自動化 • TypeScript のエコシステムを使って極力AI に書いてもらいやすく ◦ テスト自動化に際するインフラ的な制限への対応 • よくあるのは特定のIP アドレスしか許容していないアプリへの対応など ◦ 静的解析を改良・CI への組み込み • 13

Slide 14

Slide 14 text

最近だとMCP サーバーを自作したり Zenn にて公開 • Model Context Protocol の略称 • 14

Slide 15

Slide 15 text

非常にわかりやすかった資料 15

Slide 16

Slide 16 text

クラスメソッドさん ブログ • プロトコルの仕様 • 開発方法 • などわかりやすく書いてある • 16

Slide 17

Slide 17 text

本当は「TestRail のテストケースを 自然言語で実装してみた」したかっ た 17

Slide 18

Slide 18 text

間に合いませんでした（多分ブログ書 きます） 18

Slide 19

Slide 19 text

つまずいたことならブログにしました 張り切って機能を提供しすぎるとMCP クライアントが認識できなかった • AI モデルが保有できるコンテキストはシビアなので、多くの情報をかえしすぎ ない • 19

Slide 20

Slide 20 text

不足している能力 20

Slide 21

Slide 21 text

足りていないと感じる能力 QAE としてのスキル • 特にテスト分析と探索的テストのスキル • 英語（ボソッ・・・） • 21

Slide 22

Slide 22 text

SDET は自動化しとけばいいわけ じゃない（と私は思います） ≠ 22

Slide 23

Slide 23 text

手動テストのメリットを理解し て、テストケースを自動化したい → 23

Slide 24

Slide 24 text

そうなると足りないもの 24

Slide 25

Slide 25 text

テスト分析スキル テスト観点の不足による「何をテストするべき」の整理が弱い • あぁぁ・・・ここにもエラー出力がされていた ◦ あぁぁ・・・エラーハンドリングをする際にユーザーセッションなどの目に見えない状態 を考慮忘れたぁ ◦ 25

Slide 26

Slide 26 text

それに対して最近同僚が、ゆもつよメ ソッドを持ってきてくれたり 26

Slide 27

Slide 27 text

詳細は省略します（良質な資料が検索だけでも たくさん） 27

Slide 28

Slide 28 text

すぐに感じたメリット 段階的にテスト条件を考えることができる • 「出力」の観点「反映」の観点などが嫌でも目に入る • エラーが反映されるべき場所 ◦ 状態が反映されるのは詳細ページだけ？ ◦ 人に依存するのではなくテスト分析の型がチームでできそう • テスト分析レビューもしやすい • 28

Slide 29

Slide 29 text

探索的テストについて 29

Slide 30

Slide 30 text

私「いや。実行者の経験とスキルに左 右されすぎるのでは？」 30

Slide 31

Slide 31 text

確かにそう。 31

Slide 32

Slide 32 text

だけど、それを言うにも手を尽くして から言わないとだよね 32

Slide 33

Slide 33 text

せや！英語の勉強と合わせて探索的テ ストについて学んだろ！ 33

Slide 34

Slide 34 text

ということでブログ書きました Explore It! • ページも200 もないので読みやすい。構文もそこまで難しくない。 • 34

Slide 35

Slide 35 text

心がけ始めたこと 開発者も多分知らない、そんな未知を探すのはワクワクする • いい感じのチャーターで想像力を働かせる • 「What if? 」を再現するためにツールや開発周りの知見のキャッチアップを続 ける • 35

Slide 36

Slide 36 text

自分がいることの利点・足りない能力 を感じていました 36

Slide 37

Slide 37 text

まとめ SDET として働き始めて、10 ヶ月くらい経ちました • 貢献できているところ • 開発やAWS エンジニアとして手をうごかせる、簡単な設計ができるという存在がQA チー ムにいる ◦ まだまだ頑張る • テスト分析・探索的テスト力の向上 ◦ 37

Slide 38

Slide 38 text

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