「Encraft #13 QA Enablement - Insight by QA activity」に参加してきました

• 2024/4/23
• https://knowledgework.connpass.com/event/314168/
• QAがいる環境にいたことがないけどどんな雰囲気か気になって参加してみた
• QAエンジニアが何を大事にしていてどんなことをしているか何となく知れました
• 開発チームとの関わり方の話がイメージしやすくてよかった

「品質保証活動からの情報提供」について考えよう

• 小山 竜治（koyaman）さん / 株式会社 ナレッジワーク

QA からの情報提供

• テストの目的の 1 つとして情報を提供するというのがある
• QA における情報
  • ステークホルダーに根拠のある判断をしてもらうための情報
  • 他にもさまざま
• テストは知る技術
  • 今どうなってるかを知るためにテストする
  • 知ったことを誰かに伝える
• QA の活動
  • プロセスがうまくやれてるか
  • プロダクトがいい状態か

事例

• 情報提供していること
  • テストの準備進捗
  • テストの実行進捗
  • TestDesignDoc
    • テストの意図や工夫
    • https://note.com/knowledgework/n/n0203ecdc3da0
  • バグだし会
    • 自分たちで使ってテストして不具合みつけて起票する
  • バグ傾向ダッシュボード
    • 各グラフからどんなインサイトを得られるかをイメージ
    • LookerStudio が便利

パネルディスカッション

• パネリスト：湯本 剛さん/風間 裕也さん/小山 竜治さん
• モデレータ：河野 哲也さん

ケーススタディ

In Dev(開発チームの中にいる入ってスクラムにも参加してる場合)

• バグちゃんと記録することから始めるといい
  • 何が起きてどう対処したかの記録
  • ユーザにとってどう価値を損なったか
  • 自分がやるかチームにやってもらうかはチーム次第
• テストを予告する
  • テストするとわかってると意識して開発できる
• ここから作ってもらうとテストの観点でいいとか言える
  • リファインメントでチケットの完了条件を問う

Out of Dev(開発チームの外の部門にいる場合)

• プロダクトが出来た段階でQAでテスト
• QAが外にいるのはリリースに重きをおいてるケース
• テストの順序
  • 正常系が通ってるかどうか
  • ダメならそこで伝えないとその先のテストできない
• 企画書をもらってプロダクトの存在意義を探る
  • どこを抑えるべきか把握してテストしていく
  • 安心してプロパティを出すため

Bridge(テストは第三者で開発とのブリッジをする場合)

• 発注元として
  • 委託先の言うことを鵜呑みにしない
    • 100ケースでいいのに5000ケースやろうとしてるとか
  • バグの見落としがあっても委託先のせいにしないと握っておく
• 委託先として
  • 何をやらないか発注元と握る
  • やってと言われたらやる

Assistance(QA に関する情報提供)

• QA部門が外から開発部門を支援する
• 開発部門が何をやってるか知る
  • 具体的に度のチケットのどういうところで悩んでるか聞いてアドバイスする
  • 一般論言うだけじゃフィットするか分からない