Encraft #9 パネルディスカッション（公開用）

#9

パネルディスカッションの全体像 ● パネルディスカッションのゴール ○ 多くのQAエンジニアを悩ませているテーマの1つがテスト分析・テスト設計 ○ テスト分析・テスト設計に関わる悩みや課題を議論することで 課題解決のきっかけを得たり、悩みを共有したり、共感したりする （自分（たち）だけじゃない！） → その結果、明日の元気を持ち帰る ● パネルディスカッションの流れ ○ 登壇者の自己紹介 ○ イントロダクション：テスト分析・テスト設計概説 ○ ディスカッションタイム ■ 事前アンケートをベースに議論 ■ 上記、議論中に投稿された質問・コメントをベースに議論 © Knowledge Work Inc. 2

立ち位置 ● 秋山 浩一 氏 長年培った経験をベースにしたベテラン的な立場 ● 井芹 洋輝 氏 現場の一QAリーダー／テストテックリードとしての立場 ● 朱峰 錦司 氏 GIHOZ導入など各社課題を把握しているツールベンダとしての立場 ● 河野 哲也 司会進行としての交通整理をする立場 © Knowledge Work Inc. 3

モデレータ：河野 哲也 (𝕏:@TetsuayaKouno) ● 現職：株式会社 ナレッジワーク QA Engineer ● 経歴 ● ○ 高校卒業後日本無線でハードウェアQA（約10年） →電気通信大学で社会人マスタ/ドクタ(博士(工学)) ＋ フリーのコンサルタント →日立製作所でストレージ管理ソフトウェアのQA(約6年) →DeNAでWeb・モバイルのQA(3年半) →メルカリのグローバル環境でQA(2年) →2023年5月ナレッジワークにジョイン ○ テスト分析・テスト設計 （テスト設計コンテスト２連覇） 著書 ○ QA・テストがモヤモヤしたら読むITスタートアップ のためのQAの考え方（内製化失敗編／内製化成功編） © Knowledge Work Inc. 4

パネルディスカッションの全体像 ● パネルディスカッションのゴール ○ 多くのQAエンジニアを悩ませているテーマの1つがテスト分析・テスト設計 ○ テスト分析・テスト設計に関わる悩みや課題を議論することで 課題解決のきっかけを得たり、悩みを共有したり、 共感（自分だけじゃない！）したりする → その結果、明日の元気を持ち帰る ● パネルディスカッションの流れ ○ 登壇者の自己紹介 ○ イントロダクション：テスト分析・テスト設計概説 ○ ディスカッションタイム ■ 事前アンケートをベースに議論 ■ 上記、議論中に投稿された質問・コメントをベースに議論 © Knowledge Work Inc. 5

イントロダクション：テスト分析・テスト設計概説 ● テスティングの全体像を概観し、 テスト分析・テスト設計を概説する ○ 本パネルディスカッションのスコープを明確にする ○ パネリスト・参加者の共通認識と目線合わせを行う © Knowledge Work Inc. 6

テスティングの全体像 ● テスティングの全体像：PFD(Process Flow Diagram)表記 テスト実装を 省略している 組織もある 開発 成果物 テスト 分析 テスト 設計 テスト分析 成果物 © Knowledge Work Inc. テスト 実装 テスト計画の一部 マインドマップ 大項目一覧 などなど ハイレベルテ スト ケース群 テスト(設計)技法で 表現される レベル テスト 実行 ローレベルテ スト ケース群 第三者が テスト実行 可能なレベル 7

テスティングの全体像 ● そもそも、なぜテスト分析・テスト設計が必要なのか？ © Knowledge Work Inc. 8

テスティングの全体像 ● そもそも、なぜテスト分析・テスト設計が必要なのか？ ・ヌケモレのないテストをしたい ・場当たり的なテストをしたくない そのためにはレビューが必要 レビューするには段階的に成果物を 作る必要がある （いきなりコーディングしないのと同じ） 開発 成果物 テスト 分析 テスト 設計 テスト分析 成果物 © Knowledge Work Inc. テスト 実装 ハイレベルテ スト ケース群 テスト 実行 ローレベルテ スト ケース群 9

パネルディスカッションのスコープ ● テスティングの全体像 テスト実装を 省略している 組織もある 開発 成果物 テスト 分析 テスト 設計 テスト分析 成果物 © Knowledge Work Inc. テスト 実装 テスト計画の一部 マインドマップ 大項目一覧 などなど ハイレベルテ スト ケース群 テスト(設計)技法で 表現される レベル テスト 実行 ローレベルテ スト ケース群 第三者が テスト実行 可能なレベル 10

テスティングの全体像 ● テスティングの全体像 テスト実装を 省略している 組織もある 開発 成果物 テスト 分析 テスト 設計 テスト分析 成果物 © Knowledge Work Inc. テスト 実装 テスト計画の一部 マインドマップ 大項目一覧 などなど ハイレベルテ スト ケース群 テスト(設計)技法で 表現される レベル テスト 実行 ローレベルテ スト ケース群 第三者が テスト実行 可能なレベル 11

テスト分析：少しだけ深掘り キーワード・仕様・ 環境などを抜き出す 開発 成果物 過去のテスト 成果物 ドメイン 知識 調査・ 抽出 整理 第三者の 知見 製品/ドメイン知識・ 本当のユースケース テスト分析 成果物 レビュー © Knowledge Work Inc. 開発成果物から抽出した 事柄をきっかけに何を テストするのかを定義していく 12

テスティングの全体像 ● テスティングの全体像 テスト実装を 省略している 組織もある 開発 成果物 テスト 分析 テスト 設計 テスト分析 成果物 © Knowledge Work Inc. テスト 実装 テスト計画の一部 マインドマップ 大項目一覧 などなど ハイレベルテ スト ケース群 テスト(設計)技法で 表現される レベル テスト 実行 ローレベルテ スト ケース群 第三者が テスト実行 可能なレベル 13

テスト設計：少しだけ深掘り 開発 成果物 過去のテスト 成果物 テスト設計の単位とテ スト設計技法の めぼしを決める （大中小項目の構造 を決める） レビュー テスト 概要 設計 © Knowledge Work Inc. テスト 詳細 設計 ハイレベルテ スト ケース群 テスト設計 の方針 テスト分析 成果物 第三者の 知見 第三者の 知見 レビュー テスト技法で設計 中小項目の実装 ＋設計しながら方針 を見直したり 14

パネルディスカッションの全体像 ● パネルディスカッションのゴール ○ 多くのQAエンジニアを悩ませているテーマの1つがテスト分析・テスト設計 ○ テスト分析・テスト設計に関わる悩みや課題を議論することで 課題解決のきっかけを得たり、悩みを共有したり、 共感（自分だけじゃない！）したりする → その結果、明日の元気を持ち帰る ● パネルディスカッションの流れ ○ 登壇者の自己紹介 ○ イントロダクション：テスト分析・テスト設計概説 ○ ディスカッションタイム ■ 事前アンケートをベースに議論 ■ 上記、議論中に投稿された質問・コメントをベースに議論 © Knowledge Work Inc. 15

事前アンケートの結果 ● こちらで勝手に質問・コメントをグルーピングしてます ● トピック別にディスカッションを進めます ○ 大きなトピック５つ ● お断り： スコープ外の質問・コメントは対象外とさせて頂きました トピックに入り切らない質問は拾えてないかもしれません あまりにも一般的すぎる悩みはスルーするかもしれません © Knowledge Work Inc. 16

テスト分析・テスト設計が重すぎる問題 ● 分析や設計のフレームワークはVSTePやHAYST法などいくつか存在しますが、 そこそこ重いフレームワークで、短いイテレーションの中に組み込むのが難しいと 感じています。1〜2時間程度のワークショップを繰り返して徐々に浸透させた、と いうような、段階的な取り組みの事例があれば聞いてみたいです。 ● アジャイルなQAにおいて、開発サイクルのスピードに対するテスト分析・設計の 粒度で悩んでいます。開発サイクルが早かったり絶対に後ろに倒せないスケ ジュールが引かれている場合など、テスト分析や設計にかかる時間がボトルネッ クになってしまうことがあります。この場合、なかなか網羅性を高めることができな いのですが、テスト分析・設計に対してどのようにアプローチを取るべきか、どの ぐらいまでテスト分析・設計を細かく行うかなどの考え方を伺ってみたいです。 © Knowledge Work Inc. 17

テスト分析・テスト設計が重すぎる問題 ● 今よりもっとスピード早く、的確で、再利用可能なテストケースを 作るにはどうしたらよいか ● 時間やリソース限られる中でのちょうど良いテスト分析がわからない ● 複雑すぎるシステムを効率よくテスト設計し、テスト数も抑えたい。 ● 効率的な設計、分析のために事前に用意しておく情報など ● 分析、設計の工数が不足してテスト実装時に抜け漏れが発生する ● 限られたリソースで、どのようにテスト設計をしていいか。 レガシーなシステムにどう新しい風を入れていくか悩んでいます。 © Knowledge Work Inc. 18

どこまででているのか不安な問題 ● テストカバレッジが十分か、バグのすり抜けは起きないか ● どこまで(範囲、時間)やったらいいか毎回迷っています ● できたかどうかの判断がつかない ● 要件定義に近いところかと思いますがどこまで情報収集して 良しとするか ● 網羅できているかどうかを確認するお勧めの方法は ありましたら伺いたいです © Knowledge Work Inc. 19

ナレッジ化どうやるの問題 ● テスト設計のナレッジ共有の仕組みや、組織としてのテスト設計ス キルの維持について意見を伺いたいです。テスト技法の適用から アーキテクチャ設計まで、教育・スキル研鑽にはかなりの時間がか かるうえに、型として教えるにもどこを抑えるのは難しいところがあ ると思います。その過程でメンティーの観察・言語化・整理、設計へ の執着心などベーススキルも関わります。真面目にやると負担の 大きなものなので、どのように向き合っているのか気になりました © Knowledge Work Inc. 20

ナレッジ化どうやるの問題 ● ドキュメントをどれぐらいの粒度で残すか、はいつも悩みます。メン バ間での揃え方も。特にハイレベルとローレベルのバランス、どれ ぐらいトレーサビリティを担保すべきか。 ● テスト観点のナレッジ化 ● 各社がテストを通してどこまで保証する体制を作っているのか、具 体のテストケース設計などはどういった組織体制でどう見直してい るかなど他の企業の方の考え方を聞きたい © Knowledge Work Inc. 21

組織的な運用がうまくいかない問題 ● テスト分析やテスト設計のアプローチがQAチーム内でバラツキがあり標 準化を考えているが比較的小さいチームの場合は標準化をしないメリット もあると考えているがどのくらいのチーム規模になったときに標準化を考 えるべきか ● テスト分析/設計それぞれの工程の境界が体型的に理解できておらず チームメンバーに説明するときに曖昧なイメージを与えてしまう ● QAがいないなんちゃってアジャイル組織でどのように、合意を取りながら テスト分析をしていけばよいのかわかりません ● レビューアがレビューしやすいフォーマットが知りたい。トレーサビリティが あると良いのか？など © Knowledge Work Inc. 22

組織的な運用がうまくいかない問題 ● 少人数のチームですが、テスト分析やテスト設計のやり方、主義がことな るため協力しづらい ● 要件定義（実装前のフェーズ）の段階でどのようにテストを設計すればよ いかわからず、メンバー間で粒度もバラついてしまいます ● 人によってレベルにバラつきがある ● 知識やスキルの共有。効果的なメンバの育成とフィードバック ● 第三者へ教えたり、教えられたりしづらい ● 教育が必要なところ。これをやれば大丈夫という正解があまりないこと。 ● 認識齟齬の解消方法 © Knowledge Work Inc. 23

スキルアップどうやるの問題 ● 知識としてはJSTQBで学んだのですが、実際にテスト分析を行う 場合に何から始めればいいか悩んでいます ● テスト分析や設計の育成 ● テスト設計に必須の構造化能力の磨き方、育て方 ● テストベースの欠陥を見つける、のスキル上げが難しい。 心がけていることや見つけるための考え方があれば知りたい ● 作成したものをジャッジできるメンバーが社内にいないこと © Knowledge Work Inc. 24

パネルディスカッションの全体像 ● パネルディスカッションのゴール ○ 多くのQAエンジニアを悩ませているテーマの1つがテスト分析・テスト設計 ○ テスト分析・テスト設計に関わる悩みや課題を議論することで 課題解決のきっかけを得たり、悩みを共有したり、 共感（自分だけじゃない！）したりする → その結果、明日の元気を持ち帰る ● パネルディスカッションの流れ ○ 登壇者の自己紹介 ○ イントロダクション：テスト分析・テスト設計概説 ○ ディスカッションタイム ■ 事前アンケートをベースに議論 ■ 上記、議論中に投稿された質問・コメントをベースに議論 © Knowledge Work Inc. 25

ディスカッション中の質問・コメント ● テストケースバラついちゃだめなん？分散の問題か。底上げどうしま しょって話じゃないの？ © Knowledge Work Inc. 26

ディスカッションにご参加頂き ありがとうございました！