818 Views
December 06, 23
スライド概要
「Encraft #9 QA Enablement - Practical Test Design -」のパネルディスカッションで使用した資料になります。
https://knowledgework.connpass.com/event/301142/
#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月ナレッジワークにジョイン ○ テスト分析・テスト設計 (テスト設計コンテスト2連覇) 著書 ○ 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
事前アンケートの結果 ● こちらで勝手に質問・コメントをグルーピングしてます ● トピック別にディスカッションを進めます ○ 大きなトピック5つ ● お断り: スコープ外の質問・コメントは対象外とさせて頂きました トピックに入り切らない質問は拾えてないかもしれません あまりにも一般的すぎる悩みはスルーするかもしれません © 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
ディスカッションにご参加頂き ありがとうございました!