Upgrade to Pro — share decks privately, control downloads, hide ads and more …

QAって何?(MOSH株式会社様 社内勉強会20250519)

QAって何?(MOSH株式会社様 社内勉強会20250519)

MOSH株式会社様で2025年05月19日に開催された社内勉強会へ招待された際に使用した資料です。
当時のMOSH株式会社様が、QAエンジニアが居ない・QAエンジニアと一緒に仕事をした経験を持つメンバーも少ない、という状況であったため、そもそもQAとはどういうロール/行為なのか?という問いに対して、この時点でのすずきの解釈をまとめています。

Avatar for うきぐも ひろ

うきぐも ひろ

May 20, 2025
Tweet

More Decks by うきぐも ひろ

Other Decks in Technology

Transcript

  1. • ごはんの「品質」 ▪ おいしい ▪ ねずみ 異物混⼊騒ぎが起こらない ▪ 値段が安い ▪

    提供がはやい • ソフトウェアの「品質」 ▪ 役に⽴つ ▪ インシデントが起こらない ▪ 安い ▪ アプデ周期が⾼速 9 「品質」って幅が広い
  2. • ごはん屋さんの 「品質」を考える対象 ▪ ごはん⾃体 ▪ 店員の接客態度‧お店の雰囲気 ▪ オペレーション ▪

    味の安定度‧お店の防犯性 ▪ クーポン‧広告‧CM‧メルマガ • ソフトウェア開発組織の 「品質」を考える対象 ▪ ソフトウェア⾃体 ▪ チームの雰囲気/エンゲージメント ▪ 開発プロセス ▪ サイト信頼性‧セキュリティ ▪ 営業やCSの業務 10 「品質」を考える対象も幅が広い
  3. 先⼈たちの定義を⾒てみよう • 顧客を満⾜させる能⼒ 並びに密接に関連する利害関係者に対する意図した影響及び意図しない影響 ▪ by ISO9000:2015 ▪ • 製品の質、仕事の質、サービスの質、情報の質、⼯程の質、部⾨の質、

    作業者‧技術者‧管理者‧経営者の質 つまり⼈の質、 システムの質、会社の質、⽅針の質、等々というように、 これらすべての質を管理していこうというのが、我々の基本姿勢である ▪ by ⽇本的品質管理の⽗ 東京⼤学名誉教授 故 ⽯川馨 • あらゆるモノ/コトの良し悪しの度合い ▪ すずきがよく使う定義 11
  4. • 遠⽅への海外旅⾏ e.g. ヨーロッパ • 近場への海外旅⾏ e.g. 韓国 • 近場への海外旅⾏

    with付添い • 重⼤バグも直さずリリース • 重⼤バグだけ直してリリース • CSとインシデント時の対応を 予め決めてリリース 14 「保証」とはリスクベースな⾊分け リスク リスク
  5. 「保証」には情報が必要 • は医学的な情報に基づいて保証したり改善策を提⽰したりする ▪ ▪ 医学的な情報 例えば • ⾎液検査などを通じて得た 定量的な情報

    • 問診などを通じて得た 定性的な情報 ▪ 改善策 例えば • 薬の処⽅で取り敢えず症状を抑えつつ ⽣活習慣を整えて根本解決 ▪ • QAは品質に関する情報に基づいて保証したり改善策を提⽰したりする ▪ 品質に関する情報 例えば • テストなどを通じて得た 定量的なプロダクト品質の情報 • 社内コミュニケーションなどを通じて得た 定性的な組織/プロセス品質の情報 ▪ 改善策 例えば • テストケースの追加で取り敢えずインシデントを抑えつつ 開発プロセスを整えて根本解決 15
  6. QA(品質保証)って • こういうロール/⾏為では(本来)ない ▪ テストだけをやるロール/⾏為ではない ▪ 重箱の隅をつついて開発ベロシティを低下させるようなロール/⾏為ではない ▪ 開発チームに「これどうにかしろや〜」と丸投げするようなロール/⾏為ではない •

    こういうロール/⾏為である ▪ あらゆるモノ/コトをもっと良くしていくロール/⾏為である ▪ リスクベースな⾊分けによって 現実的かつみんながハッピーになる選択肢を⾒つけて 意思決定を加速するロール/⾏為である ▪ もっと良いモノをもっと楽しく作れるようになる⽅法を みんなと⼀緒に探るロール/⾏為である 17
  7. 1. ⾃分たちの「品質」を定義しよう • 「品質」の定義は 以下の2つを使い分けるのがベター 1. 「あらゆるモノ/コトの良し悪しの度合い」などとふんわりさせておく • スコープの矮⼩化を防ぐための 戦略的ふんわり

    2. ブレイクダウンさせてから定義する • ⾃プロダクトの「品質」とは具体的に何なのか ⽊構造などで整理しておく • ISO/IEC25010の品質モデル(i.e. 品質特性)を 参考にしてもよいが 依存にならないよう注意する • すべてを無理に定量化させなくてもよい • ⼀度理想形を挙げてから ロードマップなどで改善着⼿順を 決めるとよい 20
  8. 2. テストの「なぜ?」を⼤事にしよう • テストの説明可能性を上げるために「なぜ?」を問い続ける ▪ テストの「なぜ?」をテスト観点と呼ぶ ▪ 例えば下記のような(地道な)取り組みは⾮常に有効 • メンバ間で話し合ってテスト観点を明確にする

    - e.g. 「なぜこのテストをするの?」「なぜこのテストデータでテストするの?」 - e.g. 「なぜこの組み合わせ条件ではテストしなくても問題ないの?」 • テスト観点が明確なテストケース名/テストコードになるよう⼼がける • インシデントが起こった時「テストケースが不⾜していた」ではなく 「テスト観点が不⾜していた」「考慮してなかったテスト観点の組合わせがあった」と考える • テスト観点を考えるのはAIよりも⼈間の⽅が(まだ)得意 ▪ 壁打ち相⼿にはなる ▪ 「どうやって?」の抽象度まで進めばAIの優位性が勝ってくる ▪ • 関連資料 (ご興味あれば⾒てみてください) ▪ テストの設計意図を届けよう ▪ 説明できるテストをつくるためにできることを考える ▪ QAアーキテクチャの設計による説明責任の⾼いテスト‧品質保証 21
  9. 3. テスト技法をちょっと⾒てみよう • 基本的なテスト技法を知っておくと プロダクト開発の場⾯でも役に⽴つことがある ▪ テスト技法は 仕様を整理(モデリング)する⼿法でもある ▪ テスト技法は

    バグの偏在箇所に関するナレッジの集合体でもある ▪ • 「テスト技法練習帳」おすすめ ▪ https://amzn.asia/d/2WIzXH7 ▪ 社内の必修テキストにしている マッチョな組織もある ▪ • テスト技法の使い分け等は 最近AIも得意になってきた 22
  10. 4. テストはなるべく先に書こう • プロダクトの実装が終わってから時間が経てば経つほど テストを書くのは⾯倒くさくなる ▪ • この⼈間の仕様をコントロールするための仕組みが「テストファースト」 ▪ 「ならばテストを先に書けばいいのでは」という逆転の発想だが

    本質的にはシフトレフトと同じ ▪ テストのスコープクリープにハマりがちなので注意する • この⼈間の仕様をコントロールするための仕組みがTDD • 関連資料 ▪ 保守しやすく変化に強いソフトウェアを⽀える柱 ⾃動テストとテスト駆動開発 、その全体像 23
  11. おしまい • もう⼀度考えてみてくださいな ▪ Q1. 「QAエンジニア」に対して、どのような職責をイメージしますか? ▪ Q2. 「QAエンジニア」に対して、どのようなキャラクターをイメージしますか? •

    具体的にどうすればいいのか? ▪ ⾃分たちのプロダクト/組織の「品質」を具体化しよう ▪ 「なぜ?」と訊き合って テスト観点を⼤事にしよう ▪ 「テスト技法練習帳」おすすめ ▪ テストファーストはいいぞ 26