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

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

自己紹介 組み込み系システム（複合機 /医療機器）からクライアント /サーバーシ ステム、B2Bセキュリティソリューションの TestLead/Managerを歴任し た後、SaaSのQA TechLead, IoT通信キャリアの QA職を経て2024年 ナレッジワーク入社。プロダクトのテストをする傍ら可視化などの取り組 みに従事。現場でソフトウェアテストを行うことにこだわりながら開発プ ロセス改善・教育や品質文化の醸成など、幅広く活動をする傍ら、社外 活動においてエンジニアの地位向上、自身の技術力向上を行う。 社外：ASTER正会員、STAR(テスト自動化研究会 )コミッター、 SeleniumConf 2019 Tokyo Organizerなど。元WACATE実行委員(副 小山 竜治@koyaman/コヤマン QA Engineer © Knowledge Work Inc. 実行委員長）、元 JaSST Tokyo実行委員（テスト設計コンテスト審査 員） など。あと同人誌 Software Testing ManiaX作ってました 2

お話の流れ • テーマ・課題感の話 • 情報提供についてのおさらい • ナレッジワークでのケーススタディ © Knowledge Work Inc. 3

テーマ「QAからの”情報提供”について考えよう」 4

皆さんはどんな”情報提供”(フィードバックの提供)をして いますか？ 5

例えば テストの結果？ テストの進捗？ バグの傾向や残存情報？ うまくやれているか定性的な感想？ 仕様/設計/リスク/実装についてのコメント？ © Knowledge Work Inc. 6

それって 誰が嬉しいんでしたっけ？ © Knowledge Work Inc. 7

テーマ選定の課題感 • テストの目的の一つとして「十分な情報を提供する」というのが あるが、フォーカスされることが少ない • 情報提供には「誰にとって有用な情報なのか」といったコンテ キストを意識する必要があるはず • 情報提供の一環として色々テクニックがあるがあまり語られな い © Knowledge Work Inc. 8

きっかけはバグのDashboard作成(後述) © Knowledge Work Inc. 9

おさらい：QA活動における情報って？ 10

JSTQB FL syllabus V4.0 p.16 典型的なテストの目的 • 「要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する」 • 「故障を引き起こし、欠陥を発見する」 • 「求められるテスト対象のカバレッジを確保する」 • 「ソフトウェア品質が不十分な場合のリスクレベルを下げる」 • 「仕様化した要件が満たされているかどうかを検証する」 • 「ステークホルダーに根拠ある判断をしてもらうための情報を提供する」 • 「テスト対象の品質に対する信頼を積み上げる」 • 「テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をす る」 © Knowledge Work Inc. 11

ダケジャナイ！ 12

JSTQB FL syllabus V4.0 p.16 典型的なテストの目的 評価結果 • 「要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する」 • 「故障を引き起こし、欠陥を発見する」 • 「求められるテスト対象のカバレッジを確保する」 • 「ソフトウェア品質が不十分な場合のリスクレベルを下げる」 • 「仕様化した要件が満たされているかどうかを検証する」 • 「ステークホルダーに根拠ある判断をしてもらうための情報を提供する」 • 「テスト対象の品質に対する信頼を積み上げる」 • 「テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をす る」 欠陥情報 カバレッジ リスク レベル 満たされている かどうか 継続的な 品質の情報 品質の情報 妥当性の状態 © Knowledge Work Inc. 13

テストは「知る」ための手段 テストは「知る」技術であり、 知ったことを理解して”誰か”に伝えるのが大事 どんな状態なのかを知るために実証をする ＝テストを実行する なので実証して「知ったこと」を”誰か”に伝える →”誰か”が動けるようになる © Knowledge Work Inc. 14

QA活動の範囲 プロセス プロダクト © Knowledge Work Inc. うまくやれてる かどうか 対象が良いか どうか 15

情報提供する際に考えるフレームワーク 何を(What) テスト進捗・結果 (実行割合 ステータスなど ) 誰に(Who) どのように(How) 有用さ(Why) チームメンバー 予実とともに 安心してもらう 助けてもらう 例えばこんな形に整理するとわかりやすい (5W1Hが良いけど今回はシンプルにしてます) © Knowledge Work Inc. 16

ナレッジワークにおけるケーススタディ 17

弊社のコンテキスト • • ステークホルダー • 社外のユーザー：利用者数 500名以上のエンプラのお客様が多い • 社内のユーザー：全員がドッグフーディングしている (実際に使っている ) 社内で開発に関わる人々 • • • • PMM, PdM, EM, Frontend/Backend エンジニア, UXデザイナー, QA ビジネスドメイン：どんなテスト対象でどんな市場ニーズがあるか • テスト対象：ユーザビリティにこだわったナレッジ管理 SaaS（現在は営業職向け） • 市場ニーズ：受注率、顧客単価上昇に繋がる営業資料、営業ノウハウ共有を促進 プロジェクト制約：どんなスコープ、期間、リソースか • スコープ：担当領域ごとにチーム分け、 Epic>UserStory単位で開発を進める。 • 期間：1週間〜1ヶ月程度 SDLCの要素：どんな開発手法か • 1週間1Sprint, スクラム © Knowledge Work Inc. 18

やっている情報提供例1 • チケット管理によるタスクの見える化 / ポイントによる見積もりの容易化 • 共通テストケースによるテスト実施結果の見える化 何を(What) 誰に(Who) どのように(How) 有用さ(Why) テストの準備進捗 チームメンバー QAメンバー JIRAのチケット JIRAのカンバン 状況を理解 してもらう 助けてもらう チームメンバー 共通テストケース による テスト実施割合 結果や状況を 理解してもらう 助けてもらう プロセス テストの実行進捗 プロセス © Knowledge Work Inc. 19

やっている情報提供例2 • TestDeisgnDocによるテストの意図 (狙い), テストをする上での工夫 何を(What) 誰に(Who) どのように(How) 有用さ(Why) 作業成果物の評価 チーム 確認したいこと欄 伸びしろの理解 欠陥の発見 チーム 確認したいこと欄 欠陥の早期修正 テスト対象の カバレッジ確保 チーム テスト方針欄 安心してもらう 妥当性の理解 リスクレベル を下げる チーム テスト方針欄+ 要注意観点欄 安心してもらう 妥当性の理解 要件が満たされている かどうか チーム テスト観点欄 安心してもらう 妥当性の理解 TestDesignDocはプロセスの中で作るので、普通にプロジェクトをこなしていれば 上記が実現できるようになっている © Knowledge Work Inc. 20

やっている情報提供例3 • バグ出し会 何を(What) 誰に(Who) どのように(How) 有用さ(Why) 妥当性確認 チーム モブテスト 妥当性の理解 欠陥の発見 チーム モブテスト 欠陥の早期修正 • E2E Testとリグレッションテスト 何を(What) 誰に(Who) どのように(How) 有用さ(Why) 期待通りに 動作するか チーム e2e test slack通知 安心してもらう 妥当性の理解 テスト対象の品質に対 する信頼積み上げ チーム e2e test slack通知 リグレッション テスト報告 安心してもらう デプロイ判断する © Knowledge Work Inc. 21

やっている情報提供例4 • バグ傾向Dashboardとバグふりかえり会 何を(What) 誰に(Who) どのように(How) 有用さ(Why) 作業成果物の評価 組織と チーム Dashboardの all bug statusで 伸びしろの理解 リスクレベルと チケットの対応状態 組織と チーム Dashboardの reaction timeで 健全なプロセスの 維持状態の理解 組織と チーム Dashboardの Open/Closeで プロダクトの 健康状態の理解 プロセス テスト対象の品質に対 する信頼積み上げ バグの情報入力を普通にしていれば自然に見れるようになっている © Knowledge Work Inc. 22

テーマ選定の課題感(再掲) • テストの目的の一つとして「十分な情報を提供する」というのが あるが、フォーカスされることが少ない • 情報提供には、コンテキストを意識「誰にとって有用な情報な のか」を意識する必要があるはず • 情報提供の一環として色々テクニックがあるがあまり語られな い © Knowledge Work Inc. 23

Dashboardの話 デモ © Knowledge Work Inc. 24

koyamanが感じるLooker Studioを使うメリット • Web上にあるので皆が(セキュアに)気軽に見て触れる • BIツールのようにQueryを書かなくていいので手軽 • Data Sourceを自動更新にできればデータが増えた際にグラフが 自動追従するのでメンテコストが比較的低い • 計算フィールドが数式の代わりをしてくれる • Sheetsで数式運用すると増えたデータに数式を手で入れたりする生 あたたかい時間が辛い • Reportは複数のDataSourceを持てるので、例えばSheetsのデー タとgithubのデータを統合して１つのReportで見れる © Knowledge Work Inc. 25

Dashboardのポイント 昨日zennに投稿しました 各グラフは 「この情報からどう改善するインサイトを得られるか」 をイメージして(=Whyを意識して) ● プロダクト改善をするために必要な情報 ● プロセス改善をするために必要な情報 (=QAがアプローチすべき両面を意識して) © Knowledge Work Inc. 26