テスト対象の内容を 忘れるための テスト対象分析 ブロッコリー @nihonbuson

自己紹介 ● 風間裕也（ブロッコリー） ● 所属 ○ 株式会社10X ○ 株式会社iCARE フェロー（QAE技術顧問） ○ B-Testing（個人事業主） ● 社外活動 ○ JaSST Review実行委員長 ○ WACATE実行委員長 ● 執筆活動 ○ 『Agile Testing Condensed』（翻訳） ○ 『Testing in DevOps』（翻訳） ○ 『The BDD Books Discovery』（翻訳） ○ 『テストコードの注入から始める レガシーコードのリファクタリング』（技術同人誌） SNS上の アイコン

引用元：10X プロダクト本部・エンジニアリング本部 紹介資料

Copyright ©iCARE Co.,Ltd All Rights Reserved.
 健康課題を可視化するCarely 業務のデジタル化 
 4 4 ストレスチェック 健康診断管 理 過重労働管理 面談管理 労基署提出データ 統計データ 職場巡視 衛生委員会 事業について - Carely健康管理クラウド カンパニーケアを実現するための機能がオールインワン 調査方法：インターネット調査 / 調査期間：2022年10月12日～13日 / 調査対象：産業保健業務従事者1004名 対象選定方法：アンケートを基に所定の条件に合致する対象者を抽出 / アンケートモニター提供元：ゼネラルリサーチ 健康診断管理 面談管理 業務を効率化し、情報を一元化し、課題を可視化。 カンパニーケアの基盤となる健康管理システムです。 Carely導入企業では健康管理に かかる作業時間を約4分の1に 効率化。人事労務・産業看護職が抱え る健康診断やストレスチェック、過重 労働対策などのアナログ業務をクラ ウドシステムで効率化します。 Carelyでは、健康診断やストレス チェック、産業医面談や過重労働管 理といった様々な健康にまつわる データを一元管理することができま す。3ヵ年、5ヵ年とデータを蓄積し ていくことで、組織の健康状態を可 視化します。 業務効率化 データの一元管理

個人事業主としても動いてます 引用元：B-Testing.net

本発表でお伝えしたいこと ● テストプロセスに従ってテストを考えることで、 どの段階で何を考えるべきなのか明確にできる ● テスト対象分析とテスト要求分析で 行う内容が何か理解できる ● テスト対象分析とテスト要求分析を 分けて行う理由を理解できる ● 「テスト対象を忘れるためにテスト対象分析を行う」 の意図を理解できる

プロセスとは何か

プロセスとは何か プロセス（process）は、 英語で「過程」「工程」を意味する外来語である。 プロセッシング (processing) と言った場合は、 「処理」を意味する。 手続き(procedure)に着目し、対象を所定の手続きに よって別のものに変換する活動を表す場合もある。 プロセス (曖昧さ回避) - Wikipedia

プチワーク 以下の計算問題を解いてください 8×7ー32÷4

プチワーク 以下の計算問題を解いてください 8×7ー32÷4 答え…48 どうやって計算しましたか？

解答を導き出すまでの過程＝プロセス 8×7ー32÷4 を計算 答えは 48

解答を導き出すまでの過程＝プロセス 掛け算 を計算 答えは 48 引き算 を計算 割り算 を計算 8×7＝56 32÷4＝8 56ー8＝48

解答を導き出すまでの過程＝プロセス 計算順序を 確認 答えは 48 引き算 を計算 割り算 を計算 掛け算 を計算 掛け算と割り算を 計算してから 引き算すれば良いな

解答を導き出すまでの過程＝プロセス 計算 順序を 確認 答えは 48 繰り下がりの 引き算を 計算 割り 算を 計算 掛け 算を 計算 10の位との 合計を計算 16ー8 ＝10ー2 ＝8 40＋8 ＝48

解答を導き出すまでの過程＝プロセス 8×7ー32÷4 を計算 答えは 48 計算 順序を 確認 答えは 48 繰り下がりの 引き算を 計算 割り 算を 計算 掛け 算を 計算 10の位との 合計を計算

解答を導き出すまでの過程＝プロセス 8×7ー32÷4 を計算 答えは 48 計算 順序を 確認 答えは 48 繰り下がりの 引き算を 計算 割り 算を 計算 掛け 算を 計算 10の位との 合計を計算 人によってプロセスは違う プロセスを細かく分けることができる

テストプロセス

昔のテストプロセス テスト実行より前に行う内容 （「テスト設計」「テスト準備」などの呼び方あり） テスト 実行 参考：http://aster.or.jp/business/contest/doc/2020_U-30_V1.0.0.pdf#page=65

JSTQBで示しているテストプロセス テスト 分析 テスト 設計 テスト 実装 テスト 実行 何をテスト するか それをどう テストするか テストの実行に 必要なものすべて を準備したか テストスイート を実行する ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03を参考に作成

JSTQBで示しているテストプロセス（全体） テスト 計画 テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 完了 テストのモニタリングとコントロール テストの目的と、 制約内でテストの目的を 達成するための アプローチを定義する 計画した進捗と 実際の進捗を 継続的に比較する 何をテスト するか を決定する どのように テストするか を決定する テストの実行に 必要なもの すべてを準備する テストスイートを実 行する 完了したテストの データをまとめる ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03を参考に作成

テストプロセスについて詳しくは… https://speakerdeck.com/nihonbuson/test-process

今回定義したテストプロセス テスト 分析 テスト 設計 テスト 実装 テスト 実行 テスト 設計 テスト 対象 分析 テスト 要求 分析 テスト 設計方針 の決定 テスト 実装 テスト 実行 JSTQBで示しているテストプロセス 今回定義したテストプロセス

テスト分析の中の細かいプロセス ● テスト対象分析（仕様理解） ○ テスト対象がどのようなものなのか理解する ■ テスト対象の業務理解 ■ テスト対象の画面構成などの仕様理解 ● テスト要求分析 ○ 何をテストしてPassすれば、 今回の内容（機能）がOKだと判断できるのか決める ● テスト設計方針の決定 ○ テスト設計を行う際に適用すべき テスト設計技法は何か明らかにする

テスト分析の中の細かいプロセス ● テスト対象分析（仕様理解） ○ テスト対象がどのようなものなのか理解する ■ テスト対象の業務理解 ■ テスト対象の画面構成などの仕様理解 ● テスト要求分析 ○ 何をテストしてPassすれば、 今回の内容（機能）がOKだと判断できるのか決める ● テスト設計方針の決定 ○ テスト設計を行う際に適用すべき テスト設計技法は何か明らかにする

今回定義したテストプロセスについて 詳しくは先月書いた記事をご覧ください。 入社1ヶ月目でやったこと 〜ソフトウェアテストプロセスに基づいた テストケース作成を行ってみた〜

今回の題材

勉強会参加登録のシステム ※システムの 　完成イメージ

テスト対象分析

テスト対象分析 ● テスト対象がどのようなものなのか理解する ○ テスト対象の業務理解 ○ テスト対象の画面構成などの仕様理解

テスト対象分析の進め方 1. テスト対象となるインプット情報を理解する ○ 仕様書 ○ Figmaなどの画面イメージ ○ 実際のアプリ ○ チケット情報 2. 登場する要素を書き出す 3. グルーピングを行なって階層構造にする

今回の題材に対するテスト対象分析 勉強会名 日程 参加 形態 申し込み ボタン 募集 日程 グループ 情報

テスト対象分析の例（マインドマップ）

テスト要求分析

テスト要求分析 ● 何をテストしてPassすれば、 今回の内容（機能）がOKだと判断できるのか決める ● 達成したいことを考える ● 画面構成がどうなっているかは関係ない ○ どんな画面構成であれ、目的が達成できればOK

テスト要求分析の進め方 1. テストすべき内容を書き出していく ○ どんな部分をテストすべきなのか ○ 何を確認できればOKなのか ○ 起こりそうな不具合は何か 2. グルーピングを行なって階層構造にする テスト要求分析を行う際は、 仕様書、画面イメージなどの 情報を見ないで進める

テスト要求分析の例（マインドマップ）

テスト要求分析の例（マインドマップ）

なぜ仕様書や画面イメージを見ないのか ● 記載内容や画面イメージに考えが引っ張られる ○ 「○○ボタンが押せること」←これは「要求」か？ ● CPM法（コピー＆ペースト＆モディファイ）を招く ○ 仕様書の「募集日程を記載する」という部分を コピペして、テスト内容として 「募集日程を記載できること」と書いてしまう ● 仕様書や画面イメージを見なくても書き出せる内容は その機能において本当に必要な部分なはず

なぜテスト対象分析が必要なのか ● テスト要求分析だけ行おうとすると、 「○○ボタンという情報はテスト対象の話だから…」 と頭の中で留めながら成果物を作成することになる 後の作業時に テスト対象のことを頭の中から取り出す ＝忘れる ためにテスト対象分析を行う

テスト要求分析時に役立つこと ● テスト対象分析として成果物にすることで、 テスト要求分析時に、 ○ 後から見返すことができる ○ テスト対象分析で書いたことを そのままテスト要求分析に書こうとする時に、 「本当に要求なのか…？」と考え直せる

おわりに

本発表でお伝えしたいこと（再掲） ● テストプロセスに従ってテストを考えることで、 どの段階で何を考えるべきなのか明確にできる ● テスト対象分析とテスト要求分析で 行う内容が何か理解できる ● テスト対象分析とテスト要求分析を 分けて行う理由を理解できる ● 「テスト対象を忘れるためにテスト対象分析を行う」 の意図を理解できる

引用元：10X プロダクト本部・エンジニアリング本部 紹介資料

©iCARE Co.,Ltd
 Confidential iCAREのQAEチームではメンバーを募集しています！ チームの特徴 ● 開発側と伴走しながら一緒に作り上げていきます ○ 早期バグ発見を目指し、プロジェクトの上流から 開発チームやビジネスサイドとコミュニケーションをとって テスト活動に取り組んでいます ● QAEチーム自体の取り組みが活発です！ ○ QAE技術顧問 ブロッコリーさん の相談会 ■ 進行しているPJのテスト分析やテスト設計のレビュー ■ リリース済みのPJの振り返り ■ 開発プロセスの中でのQAEチームの動き方の相談 ○ QAEチーム単体での勉強会 ■ 輪読会（Agile Testing Condensed） ■ テスト技法の勉強会（ソフトウェアテスト技法の練習帳） ● 絶賛QAE募集中です！(シニアQAEも大歓迎！) 詳しくはQRか、下記で検索をお願いします! 🙏 iCARE　求人　QAE　

今回の内容をもっと話したい方へ… ● この後の懇談会で話しかけてください！ ○ 今日の発表以外のテストプロセスも話せます！ ○ オフライン参加の方限定 ● Youtrustにてカジュアル面談の募集をしています ○ テストプロセスやテスト設計について 語り合ってみませんか？ ○ 希望しない限りは、弊社の紹介はしません ■ 純粋にテスト技術について話したい人もOK！