テスト設計チュートリアル ちびこん編 ’25

テスト設計チュートリアル ちびこん編 ’25の資料です。
https://aster.connpass.com/event/354592/

Transcript

1. テスト設計コンテスト チュートリアル ちびこん編 2025 2025/05/24 井芹 久美子（テスト設計コンテスト審査委員会） 1
2. このチュートリアルについて テスト設計コンテスト（テスコン）運営組織にて開催している 2つのチュートリアルのうち、こちらは比較的経験の浅い方向けです。 ソフトウェアテストについて今一度振り返りたい方も、お気軽にどうぞ。 想定聴講者は、 • テストケースの作成またはレビューを実施したことがある方 • テストケースやテスト手順をつくる前のアクティビティについて話を 聞いてみたい方 テスト設計コンテスト参加の経験や予定の有無は 問いません 2
3. 講演者とテスト設計コンテストの紹介 • テスト設計コンテスト（テスコン）について • テスト設計の出来を競うコンテスト • 目的 • ソフトウェアテストを分析設計から行うことを周知し、ソフトウェア テストエンジニアに対する教育の機会を提供する • コンテストという形式をとることにより、ソフトウェアテストが創造的な 作業であり、楽しいということを経験してもらい、若年層及び初級テスト エンジニアからベテランテストエンジニアまでテストへの興味を高める • ソフトウェアテスト業界における技術開発を競技を通じ、促進する • 若手向けのU-30クラス、どなたでも参加できるOPENクラスがある • 講演者について • テスト設計コンテスト U-30クラス審査委員。 テスト設計コンテストの目的は https://www.aster.or.jp/testcontest/index.html より引用。ただし太字は本資料作成者による 3
4. 本資料におけるテスト開発プロセスと用語 本資料で採用しているプロセスとJSTQBのプロセスとの対応は以下の通り。 用語は、説明している場合を除き、基本的に本資料作成時点のJSTQB/ISTQBの用語 定義に従います。https://glossary.istqb.org/ja_JP/search 4 テスト 要求分析 テスト ｱｰｷﾃｸﾁｬ 設計 テスト 詳細設計 テスト 実装 テスト 実施 本講での テスト開発 プロセス テスト要求の 獲得と整理/ テスト要求 モデリング テスト アーキテクチャ モデリング テスト技法の 適用による テストケースの 列挙 手動/自動化 テストスクリプト (テスト手順)の 記述 図は テスト設計チュートリアル ちびこん編 '21 資料 67ページより引用。ただし青点線枠は本資料作成者による テスト分析 テスト設計 テスト実装 テスト 実行 JSTQBの テスト開発 プロセス
5. ゴール 次の2点を達成することを目指しています。 5 テスト活動では、テストの内容は 当然のこと、説明のしやすさや ドキュメントの保守性など、幅広い 面で注意が必要です。 その中で、特に気を付けたいことを ご紹介できればと思います。 テストケースやテスト手順を どのようにつくるのか、そのために どのような情報収集や準備が必要か、 見てみましょう。 実装までのテスト開発プロセス のイメージを掴んでいただく 実装までのテスト開発プロセス の中で特に気を付けたいこと を知っていただく
6. コンテンツ 2つあるゴールにあわせた2テーマについてお話しします。 6 [テーマ2] 審査コメントを参考に 気を付けたいポイント テスト要求分析を中心にお話し します。ただし、実際には反復的に なることがありますが、シーケンシ ャルに説明します。 各テスト技法の詳細や、成果物の 具体的な作成手順は説明しません。 テスコンU-30クラスの審査員が参加 チームの皆さんにフィードバック したコメントを分析し、見えてきた ポイントを解説します。 テストの活動の助けになると考えた情報をお話ししますが 絶対的な解ではありません、考えるヒントにしていただければと思います [テーマ1] テストケース・テスト 手順をつくるまでの活動例
7. [テーマ1] テストケース・テスト手順を つくるまでの活動例 7
8. このアプリをテストする場合、どのように考えますか？ 30秒、各自で考えてみてください(あてませんのでお気軽に) 8 「三角形判定アプリ」は，ソフトウェアテスト学習用の、 AndroidOSとiOS向けの スマホアプリである．ユーザーは，三角形の3 辺の長さの値を入力する．判定ボタ ンを押下すると，入力された値を3辺の長さとする三角形が 不等辺三角形，二等辺三角形，正三角形のいずれなのかが 表示される．設定画面で、ライトモード/ダークモード、 文字の大きさ（大/中/小）を選択し設定することができる。 補足 • 辺の長さとして有効な値は、1～999の整数。 • デフォルトはライトモード、文字の大きさは中。 • 利用状況調査のためアプリからサーバにログを 送信する。ログは別のツールで解析する予定。 ▲開発中の画面 仕様は、本「ソフトウェア・テストの技法 第2版」2ページを参考に作成 画像は、テスト設計チュートリアル ちびこん編 ‘24 資料 11ページから引用
9. 短い仕様でも気になることは沢山見つかる テストした方がよいことは沢山ありそう。 不等辺三角形になるような3つの値を入力してみる 二等辺三角形になるような3つの値を入力してみる 正三角形になるような3つの値を入力してみる 辺の長さに数値以外を入力してみる 2つの辺だけ入力して1辺は未入力のままとする 1つの辺だけ入力して2辺は未入力のままとする ダークモードで動作させてみる 最新バージョンのAndroidOSやiOSで動作させてみる 繰り返しインストール、アンインストールしてみる 判定にかかる時間を計測してみる … 9
10. すぐにテスト実行を開始できそう？ 思いついた内容をもとにテストすれば十分だろうか？ 10 No. アクション 期待結果（判定結果） 1 辺の長さ(3,3,3)を入力して判定ボタンを 押す 判定結果として「正三角形」と表示され る 2 辺の長さ(4,3,3)を入力して判定ボタンを 押す 判定結果として「二等辺三角形」と表示 される 3 辺の長さ(6,3,4)を入力して判定ボタンを 押す 判定結果として「不等辺三角形」と表示 される 4 辺の長さ(a,3,4)を入力して判定ボタンを 押す 文字種エラーになる 5 辺の長さのうち1辺のみ(3)を入力して判 定ボタンを押す 未入力エラーになる 6 辺の長さのうち2辺のみ(3,2)を入力して 判定ボタンを押す 未入力エラーになる … … …
11. 一方で、分からないこと、曖昧なこともある 辺の長さの入力値について、文字の種類はどのくらいテストする？ 古いOSもテストする？ インターネットに接続できない状態でもテストする？ ログについてもテストが必要？ どんなテストを重点的にする？ 全機能、同じくらいでいいのだろうか？ 使える工数はどのくらい？ テストがつくれそうな情報でも 納得できるテストがつくれるくらい十分な情報とは限らない 11
12. 以降の説明の背景にある考え方 本資料で大事にしている考え方は次の3つ。 この3つを実現するため、まずはテスト要求分析に取り組みましょう。 12 段階的に 進める 多面的に考える テスト全体を 俯瞰し バランスをとる 仕様などから一気に 具体的なテストケースや テスト手順を作成する のではなく段階的に 考えていく できるだけ多くの情報を 集めて状況にあった テストを考える テストケース1件ずつや 「判定機能のテスト」 といった細かい粒度で 考えるだけでなくテスト 全体の構造を意識する
13. テスト要求分析 13
14. 分からないこと、曖昧なことが沢山ある 辺の長さの入力値について、文字の種類はどのくらいテストする？ 古いOSもテストする？ インターネットに接続できない状態でもテストする？ ログについてもテストが必要？ どんなテストを重点的にする？ 全機能、同じくらいでいいのだろうか？ 使える工数はどのくらい？ 分からないこと、曖昧なことがあるので、まず情報を集める どんな情報を集めるとよさそうだろうか？ 14 テストの 目的や責務は？ テストの優先順 や厚みは？ 技術面や組織に 関する制約は？ テスト観点(テス トすべきこと)は 他にないか？
15. 集めたい情報 一般的に、以下の情報は必要そう。 15 仕様は？ 仕様書のほか、開発中のメモ等 利用シナリオは？ 強み、弱みは？ 過去バージョンの評判や故障はどうか？ どのようなプロダクトか？ ステークホルダーは誰で それぞれの関心事は？ プロダクトの周辺は？ 開発の状況や現在の品質は？ 関連する法令は？ 慣習は？ 連携システムは？ 同時に使うシステムは？ ユーザーは誰？ どんな関わり方か？ 開発メンバーが不安に思っているところは？ 営業やカスタマーサポートチームの関心は？ 組織や経営層の期待は？ 3H(初めて、変更、久しぶり)の部分は？ 前プロセスのレビュー結果やテスト結果は？ 3Hは https://note.com/akiyama924/n/n79b902f69ddf を参考にした
16. テストケースのもとにならない情報も集める テストへの要求は、 テストケースを導くもの（エンジニアリング的テスト要求）のほか、 技術的・組織的な制限に関する情報（マネジメント的テスト要求） があり、両方を集める。 16 想定する使い方 ユーザや開発者がミスをしそうなところ 自信があるところ、ないところ 複雑な機能 … エンジニアリング的テスト要求 工数 テストチームのスキル 利用できるツール 今後の開発やテストの再利用の予定 … マネジメント的テスト要求 テスト設計チュートリアル テスコン編 ‘22 資料 14ページ、 JaSST‘22 Hokuriku 目指せテスト設計リーダー!! テスト設計チュートリアル 資料 26ページを参考に作成
17. 集められない情報がある場合はどうするか？ 現実には、契約や組織の都合で集められないことがある。 集められない情報は推測して補うが、以下を注意する。 17 できるだけ関連情報 を集める ステークホルダーを 巻き込む 情報が増えたときに 備えて見直しやすい ようにしておく 前提を明らかにする、 確度を上げる 情報や思考の幅を広げる、 ステークホルダーの 納得感を醸成する 変わるかもしれない部分 だと分かるようにする
18. 集めた情報から多くを引き出す 集めた情報の中には、そのままではテストのインプットに しづらいものや、異なる情報同士を組み合わせることで新たな 情報に繋がるものもある。 集めた情報は、理解を深めるために分解や構造化をする。 図は テスト設計コンテスト'21 - テスト要求分析チュートリアル 資料 57ページより引用 18
19. 情報を分解・分類、構造化する例 その1 画面遷移について明らかにするために、分解・分類、構造化を試みる。 19 「三角形判定アプリ」にはTOP画面、入力画面、判定結果画面、設定画面がある。 TOP画面で開始ボタンを押すと入力画面に遷移する。入力画面では、辺の長さと して値を入力できる。また、判定ボタンを押すと、判定結果画面に遷移する。 判定結果画面では、判定結果を表示する。3辺の長さが入力済であり、すべて有 効な値の場合は、その値に応じて三角形の種類を表示する。判定結果画面には、 もう一度ボタンがあり、押すと入力画面に遷移する。それぞれの値は有効な値だ が三角形が成立しない場合、判定結果画面には、三角形不成立エラーのメッセー ジを表示する。入力された値のうち1つ以上が有効な値でない場合は無効値エラ ーのメッセージを、未入力がある場合は未入力エラーのメッセージを表示する。 TOP画面以外の画面には戻るボタンがあり、押すと一つ前の画面に戻る。ただし、 判定結果画面の戻るボタンを2秒以上押した場合は、一つ前の画面ではなく、 TOP画面に戻る。
20. 情報を分解・分類、構造化する例 その1 遷移元や遷移先の画面・遷移を引き起こすイベント・条件に分類する。 20 「三角形判定アプリ」にはTOP画面、入力画面、判定結果画面、設定画面がある。 TOP画面で開始ボタンを押すと入力画面に遷移する。入力画面では、辺の長さと して値を入力できる。また、判定ボタンを押すと、判定結果画面に遷移する。 判定結果画面では、判定結果を表示する。3辺の長さが入力済であり、すべて有 効な値の場合は、その値に応じて三角形の種類を表示する。判定結果画面には、 もう一度ボタンがあり、押すと入力画面に遷移する。それぞれの値は有効な値だ が三角形が成立しない場合、判定結果画面には、三角形不成立エラーのメッセー ジを表示する。入力された値のうち1つ以上が有効な値でない場合は無効値エラ ーのメッセージを、未入力がある場合は未入力エラーのメッセージを表示する。 TOP画面以外の画面には戻るボタンがあり、押すと一つ前の画面に戻る。ただし、 判定結果画面の戻るボタンを2秒以上押した場合は、一つ前の画面ではなく、 TOP画面に戻る。
21. 情報を分解・分類、構造化する例 その1 結果を図や表で表現し、全体を眺めてみる。 重複や抜けなど、気になるところはないだろうか？ 21 戻るボタン押下 [2秒以上] TOP画面 入力画面 判定結果 画面 設定画面 判定ボタン押下 戻るボタン押下 [2秒未満] 戻るボタン押下 戻るボタン押下 開始ボタン押下 もう一度ボタン 押下
22. 情報を分解・分類、構造化する例 その1 結果を図や表で表現すると、曖昧な点や疑問が見えやすくなる。 必要に応じて更に情報収集し、テストへの要求を理解する。 なお、この例では、更に状態遷移表のように表で表現しても効果的である 22 戻るボタン押下 [2秒以上] TOP画面 入力画面 判定結果 画面 設定画面 判定ボタン押下 戻るボタン押下 [2秒未満] 戻るボタン押下 戻るボタン押下 開始ボタン押下 判定結果画面から入力画面 に遷移する方法が2通り ある、意図的か？ もう一度ボタン 押下 設定画面への 遷移方法は？
23. 情報を分解・分類、構造化する例 その2 テスト対象である「三角形判定アプリ」を取り巻く環境の図示を試みる。 まず、どのような人やシステムが、どのように関係するかを洗い出す。 • 人 • ユーザー …公開されるアプリや仕様書をダウンロード (DL) する • iOS端末利用者 • Android端末利用者 • 開発チーム • 仕様作成者 …仕様書を作成し、公開する • iOSアプリ開発者 …アプリをリリースする • Androidアプリ開発者 …アプリをリリースする • システム …アプリをDL、インストールできるようにするために必要 • App Store • Google Play 23
24. 情報を分解・分類、構造化する例 その2 テスト設計チュートリアル ちびこん編 ‘24 資料 22ページより引用 24 App Store Google Play ・三角形判定をする ・スマホアプリの テスト体験をする ・仕様書を公開する（DLサイトを用意） ・アプリを リリースする ・アプリを リリースする アプリDL アプリDL 対象OSバージョンのほかに、 端末も複数機種・複数メーカー必要そう フィードバックの仕組みがあったほうが よいのでは？ アプリからDLサイトへの 動線はある？ 気になることを遠慮せず書き込む
25. 理解したテストへの要求をもとにするが、担当範囲外の品質に関する活動の情報も 集めておき開発全体から見て適切な目的や責務にすることが重要。 抽象的過ぎると解釈がぶれ、後続の活動がしづらい。 一方、具体化には情報収集等の手間がかかるので必要な程度を見極める。 例は、ASTER U-30テスト設計コンテストストプロジェクト要求補足書2024 Ver. 1.0 を参考に作成 プロダクトのどの部分が対象か？ どのテストレベル、どのテストタイプが対象か？ 例 ネイティブアプリケーション部分のみをテスト対象とする。 テストで得たい情報は何か？ テスト結果を受けて行われる活動のために何をすべきか？ 例 本番リリースできる品質であることを確認する。 テストの目的や責務を決定する 25 責務 目的
26. 集めた情報とそこからテストの目的や責務を検討した例 • 責務 • アプリの機能と非機能について、システムテストを行う • ただし対象は判定機能と設定機能とし、ログ出力機能は対象外とする • 目的 • 受入テスト開始可能な品質であることを確認する • アクセシビリティガイドラインへの適合を確認する • 仕様書に対するフィードバックを行い仕様書の改善に貢献する 26 統合テストの後、人事部による受入テストの前に行う 非機能テストはまだ実施していない ログ出力機能は直近のリリース対象外で、プログラム実装もしていない 社内にアクセシビリティガイドラインがあり適合が期待されている このアプリは、今後も継続的なバージョンアップを行う予定がある 仕様書の作成は開発ドキュメントの作成経験が浅いメンバーが担当している
27. 集めた情報やテストの目的・責務を踏まえて、テスト観点を検討する。 本講演の「テスト観点」は、テストすべきことを指す。 • 三角形判定アプリのテスト観点の例 • 正三角形など、三角形の形 • 負荷 • OSの種類やバージョン • 入力のしやすさ • テスト初心者など、ユーザーの種類 • … 抽象度は様々で、そのままテストケースに登場するものも、テストケース作成 時には具体化が必要なものも含む。 テスト設計チュートリアル ちびこん編 ‘21 資料 12ページを参考にした テスト観点を考える 27
28. 集めた情報をもとにテスト観点を洗い出す 例えば、テスト観点だと思うものを書き込んでみる。 28 App Store Google Play ・三角形判定をする ・スマホアプリの テスト体験をする ・仕様書を公開する（DLサイトを用意） ・アプリを リリースする ・アプリを リリースする アプリDL アプリDL 対象OSバージョンのほかに、 端末も複数機種・複数メーカー必要そう 端末の機 種 OSのバー ジョンア ップ アプリ更 新 iOSと Android の差分 アプリイ ンストー ル・アン インスト ール アプリ終 了のしか た いじわる な操作 インスト ール・更 新中断 アプリDL 中の通信 断 仕様書ＤＬ サイトへの 同時アクセ ス数 図は テスト設計チュートリアル ちびこん編 ‘24 資料 26ページ より引用
29. 様々な方法を使って考えるとよい。 生成AIを使える環境では、例えば、生成AIを利用して作成した叩き台をベースに 検討を進める、ブラッシュアップしていく、といった方法も考えられる テスト観点を考える 29 テスト対象 自体の情報 を基に 考える 起こりうる 欠陥や故障 から考える 抽象度を 変えてみる チームで 知恵を 出し合う 仕様書の情報を 図や表に変えて みる、別々に書 かれている情報 を組み合わせて 検討してみる モブ作業や、 経験がある人と 意見交換する等。 例えば、文字種 入力のエラーは エラーの一種、 他にエラーは あるだろうか？ 例えば、三角形 判定アプリで不 正な判定結果が 表示されると したら どんな場合？ ISO/IEC25010等 (SQuaREシリーズ) や6W2Hを参考に する。 とらわれすぎない ように注意 組織標準等 まとまった 情報を 参考にする
30. 文字の 種類 メッセー ジごとの 文字色 3辺の 数字の 組み合わ せ 端末機種 OSのバー ジョンア ップ iOSと Android の差分 仕様書ＤＬ サイトへの 同時アクセ ス数 未入力 表示しき れない桁 数 何もない ところを タップ ボタンの 押し方 値の リセット 手段は？ 入力手段 アプリ終 了のしか た いじわる な操作 入力の 有効値 アプリ 更新 アプリイ ンストー ル・アン インスト ール インスト ール・更 新中断 アプリDL 中の通信 断 UI操作 三角形 判定 入力値 バリデ ーショ ン UI表示 負荷 条件 端末 環境 インス トール 出した観点をグループ分けしてラベルをつけた例 ※ここから、さらに整理が必要 なんか粒度が ばらばら？ これだけ？ 他にもあるよね グルーピングを通してブラッシュアップする 過不足や不揃いが見えたら、より良くするチャンス。 30 例は テスト設計チュートリアル ちび こん編 ‘24 資料 28ページより引用
31. グルーピングを通してテスト観点をブラッシュアップする テストタイプでグルーピングした例。 曖昧なテスト観点が見つかったら、意図を再確認したりグループを見直す。 31 例は テスト設計チュートリアル ちびこん編 ‘24 資料 29ページより引用 互換性テスト 端末 環境 負荷 条件 機能テスト UI操作 三角形 判定 UI表示 インス トール 入力値 バリデ ーショ ン これは何を確認したいの だろう？ 負荷状態での性能？ 負荷により問題発生した ときのふるまい？ ユーザー運用操作性テスト UI操作 UI表示 ※一つ前で整理しきっていないものを載せ ている。実際はもっと前段階で整理する必 要があり、それとは別に、載せたあとも追 加や調整が必要
32. テストの優先順位や厚みを考える どのようなテスト観点を優先するか、手厚くするか、検討する。 より必要性が高いテストにリソースを割けるよう、複数の角度から考える。 • 多くのユーザーが頻繁に使う部分のテストを厚くする • メインターゲットとなるユーザーが気にしそうな部分 のテストを優先的に行う • 売り文句やプレスリリースに関するテストを優先する • 関係するシステムや人が多く問題が起こった場合に 対応が難しい部分のテストを厚くする • データ破損など重篤な問題が一定以上の確率で発生 する恐れがある機能のテストを厚くする • 詳細は次ページ以降へ 32 使われ方から 考える プロダクトの 特徴から考える リスクから 考える
33. テストの優先順位や厚みを考える • 通常、一つ一つのリスクについて、悪影響を及ぼす事象や状況の顕在化可能性と、 顕在化した場合の影響度を検討する • 例えば、「三角形判定アプリ」では判定ボタンの連打により故障の恐れが あるとする。その顕在化可能性は、どのくらいだろうか？ 10秒、各自で考えてみてください(あてませんのでお気軽に) 33 リスクから 考える
34. テストの優先順位や厚みを考える • うまく使えば有効な方法だが、難しい • 顕在化可能性と影響度を決めるのは、難しい • 例えば、判定ボタンの連打により故障の恐れがあるとして、その顕在化 可能性はどのくらいだろうか？ 小さいこどもの利用を想定するかといっ た前提の置き方や、経験が異なる人同士で、判断は分かれそうである • 判断が難しいから念のためテストする、という選択肢もある しかし、高額な環境や煩雑な準備が必要なテストならば、どうだろうか？ • 少なくとも、ステークホルダーが納得できるよう工夫する • 顕在化可能性と影響度の検討にステークホルダーにも参加してもらう、 検討の前提や判断基準をできるだけ明確にする等の工夫をして、 テストのステークホルダーが納得できるように決める 34 リスクから 考える
35. 制約への対応を考える 一般的に、テストには工数面や環境面等で制約がある。 テストの実現性を高めるために、前述したマネジメント的テスト要求 をもとにして制約を明らかにし対処方針を決める。 例えば、 35 あるテスト環境は 10日間しか使えない 利用可能日に合わせてテストの実行順を決定する 一部のテスト実行を自動化し夜間の実行をしやすくする 今後予定されている 仕様の改善や 追加開発に備えたい 仕様とテストのトレーサビリティを確保し、仕様変更に よりテストのどこに影響があるか分かりやすくする リグレッションテストを用意してプログラムの修正を 行いやすくする
36. テストアーキテクチャ設計 36
37. 全体像を設計する 本資料での「テストアーキテクチャ」は、テスト観点の全体像を、それらの関係性 等の特定の関心事に基づいてモデル化したもの。 テスト観点やその組み合わせ、テストタイプ等が含まれうる。 テストアーキテクチャ設計により、全体像を分かりやすく整理し、 バランスの検討やテストケース作成をやりやすくする。 そのため、例えば以下を行う。 • テストケースの構造を可視化する。まとめて扱いたいテスト観点を考える。 • テスト全体の構造を可視化する。 例えば、「システムテスト」にどのようなテストを含めるか、 「機能テスト」や「性能テスト」等に前後関係はあるか、等を考える。 テストアーキテクチャの定義は https://www.aster.or.jp/testcontest/u30.html#Submission3 を参考にした 37
38. テストケースの構造を可視化する あるテストケースで、複数のテスト観点をまとめて扱いたいことがある。 「三角形判定アプリ」の例 まとめて扱いたいテスト観点を明らかにしテストケースの構造を検討する。 様々なテストをする場合、通常、 テストケースの構造が複数できる。 図は テスト設計チュートリアル ちびこん編 ‘22 資料 49ページの図を参考に作成 38 辺の長さ OS バージョン 期待結果 (三角形の種類) (3,3,3) iOS18 正三角形 辺の長さ OSバージ ョン 期待結果 判定機能
39. テストケースの構造を可視化すると何が嬉しいか？ テストケースについて、扱うテスト観点をもとに構造を考えることは、 意図に沿ったテストケースをつくる助けとなる。 • テストケースに紐づくテスト観点の十分性について 早期から議論やレビューがしやすくなる • テストケースの構造自体はテストケースで使う値の検討前から 考え、議論やレビューをすることができる。 • まとめて扱いたいテスト観点は不足なく含まれているか？ 余分なテスト観点が含まれており必要以上に複雑なテストケースに なっていないか？ • テストケースの意図を分かりやすく示せる • 「大項目」「小項目」といった見出しを使えばテストケースを表現する ことはできるものの、各テストケースの意図が理解しづらくなる。 39
40. 行う予定のテストやテスト同士の関係性を可視化する。 例では、担当するテストより前のテストも明らかに しており、重複がないかや位置づけを確認しやすい。 例は テスト設計チュートリアル ちびこん編 ‘24 資料 31ページから引用 テスト全体の構造を可視化する 40 ユニットテスト 統合テスト システムテスト 性能テスト 互換性テスト 性能検証 機能テスト 機能テスト 機能テスト ユーザー運用 操作性テスト 入力値 バリデ ーショ ン 三角形 判定 UI操作 UI表示 インス トール 自分たちの担当スコープ 他のテストレベルで同じことをしないように調整する
41. テスト全体の順序を示した例 サイクルや前後関係を表現すると、意図の共有や作業分担のときに役立つ。 図は テスト設計チュートリアル ちびこん編 ‘21 資料 44ページから引用 41
42. テスト全体の構造を可視化すると何が嬉しいか？ コミュニケーションや学習の場面で良いことがある。 • テスト観点同士やテストタイプ同士等の関係性を俯瞰でき、 見通しが良くなり、バランスや後続の活動を検討しやすくなる • 大きな抜け漏れや重複、偏りに気づきやすくなる • 前後関係やサイクルの有無を示すと、テストの詳細設計、実装や実行の タイミングを考える上でのインプットにできる • 情報量がテストケースに比べて少なく、短時間で全体像を 掴む際に便利である • 自分たちの責務範囲やその周辺のテスト、相互の関係性を短時間で 共有するのに役立つ • レビュアーに説明する際や、前提知識が少ない新メンバーが学習する際等、 最初から細かなテストケース1件1件を見せるよりも、どのようなテストが 行われるか伝えやすくなる 42
43. テスト詳細設計 43
44. テストで使う具体的な値を考えテストケースをつくる テスト観点それぞれについて、とりうる値を特定しテストケースをつくる。 テスト技法を使うと体系的に考えやすく、網羅度もあわせて検討しやすい。 「三角形判定アプリ」では、 辺の長さの入力項目は有効な値は 1～999の整数、「境界値分析」を 適用してテストしたい。 →0,1,999,1000を使おう。 →更にピンポイントで確認したい値を 検討、使う値を特定する。 値を特定したら、テストアーキテクチャ設計で検討したテストケースの 構造を使ってテストケースを作成する。 44 0 1000 1 999 … 値 補足 入力値 -1 負の値、エラーになる 0 1 999 1000 数字以外 エラーになる
45. 値の決定方法 値は、テストやテストケースの目的と整合するように決定する。 45 値 入力値 -1 0 1 999 1000 A(半角英字) Ｂ(全角英字) ２(全角数字) ! (半角記号) … 値 入力値 10 (有効な値) 2000 (無効な値) (未入力) 過去に文字種が関係する重篤 な故障があり、再発しない ことを確認したいならば、 文字種を細分化してテスト する必要があるかもしれない テスト開始判定を行う ためのスモークテスト用 の値なら、割り切って 実施することを狙っても 良いかもしれない
46. テスト実装 46
47. テストが実行できるように手順をつくる テスト実行や、ドキュメントの保守の効率化を考えられるとよい。 手動でのテスト実装を想定した場合、次のようなことを考える。 • 準備に時間がかかる複数のテストケースについて、 準備や実行をまとめて行うことで手間を減らせるのでは • 1回の作業で複数のテストケースを確認できないか • 入力値に応じて正しく三角形が判定されるかテストする 前にアプリのインストールのテストをすれば、準備の 手間が省けそう • テスト対象のプロダクトの知識が浅いメンバーが実行 するならば、複雑な手順は具体的に書いた方がよさそう • テスト手順は記述量が比較的多い。複数のテスト手順に 共通する内容をまとめて書く等、今後の保守活動に 配慮する 47 準備やテスト実行を 同時にできないか？ 続けて実行した方が 効率的では？ 仕様変更時の更新の 手間を減らすには？ テスト実行者から 見て分かりやすい？
48. テストプロセスの流れ まとめ 48
49. ここまでの説明と背景にある3つの考え方の関係性 49 テスト 要求分析 テスト ｱｰｷﾃｸﾁｬ 設計 テスト 詳細設計 テスト 実装 テスト 実施 本講での テスト開発 プロセス テスト開発プロセスの図は テスト設計チュートリアル ちびこん編 '21 資料 67ページより引用 段階的に 進める 多面的に考える テスト全体を 俯瞰し バランスをとる 直接関係 するのは どこか？ 背景にある 考え方 テスト要求の 獲得と整理/ テスト要求 モデリング テスト アーキテクチャ モデリング テスト技法の 適用による テストケースの 列挙 手動/自動化 テストスクリプト (テスト手順)の 記述
50. 3つの考え方を大事にしたい理由 テスト開発プロセスの概観が分かったところで 次のページから気を付けたいポイントを見てみましょう 50 段階的に考える 多面的に考える テスト全体を俯瞰し バランスをとる 状況に適したテストを 検討するためには不可欠。 また、テストを通じ情報 を整理することで欠陥の 早期発見のチャンスが 増えるという利点もある。 大きな抜けや優先順の 間違いを防ぐため。 バランスをとるためには 全体やテスト間の関係性 の可視化が必要で、この 可視化により細部を理解 しやすくなる利点もある。 特に複雑なテストでは 大きな抜けを防ぐために 徐々に具体化や詳細化を 行いたい。 また、それぞれ活動内容 が異なるので、分けた方 が難易度が下がる。
51. [テーマ2] 審査コメントから見えてきた 気を付けたいポイントと対処方法 51
52. ご紹介するポイントの出所の説明 テスコンU-30クラスでは、審査員が参加チームの成果物 （テスト要求定義～テスト実装の成果物）を審査した後で、 フィードバックを行っている。 テスト設計コンテスト’24 U-30クラスの審査の流れ 52 参加チーム にて 成果物作成 予選審査 書類選考 決勝審査 書類選考 プレゼン審査 コメント送付、 フィードバック会で フィードバック 決勝戦での質疑応答、 コメント送付で フィードバック 決勝進出 チームにて 成果物更新
53. ご紹介するポイントの出所の説明 2024年度のテスコンU-30クラスの予選で審査員からお送りした 各チームへのフィードバックコメントの分析をもとに、 気を付けたいポイントをご紹介します。 テスト設計コンテスト’24 U-30クラスの審査の流れ 普段のテスト活動でレビューを受けたり行ったりする際、あるいは、 テストケースを作るときのヒントとしてお聞きいただければ嬉しいです。 53 参加チーム にて 成果物作成 予選審査 書類選考 決勝審査 書類選考 プレゼン審査 決勝進出 チームにて 成果物更新
54. 気を付けたいポイント 取り上げるのはこの4つ。 補足 • 審査コメントをそのまま引用せず、要約や改変をして載せている場合があります。 太字等、文字の装飾は本資料作成者によるものです。 • 特定のチームや審査員について取り上げる意図はありません。 コメントを受けたチームや書いた審査員が推測できても、胸の中にしまって おいていただけますようお願いいたします。 54 根拠や意図、結果や実現方法の分かりやすさ 多面性 ビジネス文書としての可読性 状況に合ったテスト活動 • 説明 • コメント例 • 対策
55. 気を付けたいポイント 55 根拠や意図、結果や実現方法の分かりやすさ 説明 成果物の背景にある根拠や意図が読み取れない。 または、ある成果物をもとに活動した結果や実現方法の詳細が分からない。 何が困るか？ • 根拠や意図が分からないと、テストアーキテクチャなどの成果物を読む 側は妥当性が判断できない。 • 結果や実現方法が分からないと、意図通りに活動が行われたか判断 できない。結果として、やはり妥当性が判断できない。 • 意図や根拠が不明だったり、結果や実現方法が曖昧ということは、 前提や目的と食い違った活動になっている恐れがある。 （次ページに続く） 根拠は？ 意図は？ 成果物 結果は？ どう実現した？
56. 気を付けたいポイント 56 根拠や意図、結果や実現方法の分かりやすさ コメ ント 例 1. 根拠や意図が読み取れない • 何を狙いとして(Why)、どのようにしてテストアーキテクチャの図を作 ったのか(How)が示されていません。そのため、テストアーキテクチャ の意図が分かりませんでした。 • 非機能テストで、特定の特性について責務範囲外としていますが、 責務範囲外とした理由が示せると、納得感が高まると思います。 • テスト要求分析でユーザーの行動などを分析されていますが、それらの アウトプットが唐突に提示されている印象を持ちました。 何を考えたのか、どんな点を意識して出力したのかを分かりやすくして いただけると、理解しやすくなると思います。 （次ページに続く）
57. 気を付けたいポイント 57 根拠や意図、結果や実現方法の分かりやすさ コメ ント 例 2. 結果や実現方法の詳細が分からない • 使用したテスト技法について、以下を例としてテスト技法を適用した 具体的な内容を成果物に掲載することを検討してください。 • 同値分割法であれば、対象とした要素に対して識別した有効と無効の 同値パーティションを示す • 境界値分析であれば、対象とした要素に対してモデル化した数直線と、 そこから得られた境界値を示す • デシジョンテーブルテストであれば、対象とした条件の組み合わせと 動作に対するデシジョンテーブルを示す • 状態遷移テストであれば、状態遷移図および/または状態遷移表と、 どのような基準でテストケースを網羅するのかを示す （次ページに続く）
58. 気を付けたいポイント 58 根拠や意図、結果や実現方法の分かりやすさ コメ ント 例 3. 成果物間の繋がりが分からない • PFD(Process Flow Diagram)で成果物の全体像を示されています。この PFDの情報と実態の成果物とに違いがあると、読み手が迷子になってし まい、自分達の伝えたいことが伝わりにくくなるためもったいないです。 対策 ✓ 段階的にテストを考え、インプットの情報や、メモやホワイトボードの コピーなど思考過程がわかる情報をとっておく。 ✓ 途中で全体を見直すタイミングを設け、成果物間の整合性をとる。 ✓ 経験や現状を成果物の読者とどの程度共有できているかに依って、 説明の細かさを調整する必要があることに注意。
59. 気を付けたいポイント 59 多面性 説明 インプットが仕様書のみ等、テストを考えるための情報収集が十分行われ たように見えない。 あるいは、様々な情報が収集されているが、情報を活用する余地が残って いる。 コメ ント 例 1. 情報の収集、分析 • テスト観点の内容としては、仕様書あるいは一般的な機能の範囲内の 記述にとどまっています。 • 起こりそうなバグやユースケースを想定し検討された点は良かったです。 • リグレッションテストについても検討しており、今後のリリースに 向けた対応が考慮できています。 （次ページに続く）
60. 気を付けたいポイント 60 多面性 コメ ント 例 2. 集めた情報の活用 • ユーザビリティテストは他のテストと変わらないように見えます。 ユーザビリティテストだからこそ検出できる不具合やテスト対象の 改善点があるかと思います。そのためのテスト内容と、テストのやり方 が考慮されると更に良くなると思います。 • ペルソナを設定するとしたら、テスト対象である割り勘支援アプリの 価値をより多く実感するペルソナがよいと思います。 対策 ✓ 多様な情報を集める。集めるだけではなく、抽象化や具体化をするなど して発想を広げる。 ✓ しっかり情報収集や検討をしたと思っても、目的と整合しない結果に なったら何かがずれているか目的の見直しが必要。目的を踏まえて十分 多面的に検討できているか、集めた情報を活かしきれているか、確認 しながら進める。
61. 気を付けたいポイント 61 状況に合ったテスト活動 説明 テスト活動の制約が考慮されていない、あるいは、費用対効果の面で再考 の余地がある。そのため、活動の実現性や効率が十分高くない恐れがある。 コメ ント 例 1. 体制、工数 • 記載されている内容だけで探索的テストを行うとしたら、エキスパート レベルのエンジニアが必要かもしれません。また、視認性や操作性に ついても、着目点を決めておかないと、個人任せになりすぎてしまい、 テスト設計時に狙った意図と異なるテストをしてしまうかもしれません。 • テスト実行工数が大きく、実行完了までの時間が掛かってしまうのでは ないかという懸念があります。 2. 今後の開発やテストを想定した保守性の考慮 • 文書全般において、保守性を考慮すると各文書には更新履歴があると 良いでしょう。 （次ページに続く）
62. 気を付けたいポイント 62 状況に合ったテスト活動 対策 ✓ マネジメント的テスト要求も意識的に収集する。 ✓ チームメンバーが持つスキルや利用可能なリソースを把握し、事前の 教育や機材の調達等、必要なスキルやリソースとの差分を埋める方法を 検討する ✓ 費用対効果を考える。例えば、1回だけ実施する予定の社内研修の教材 用アプリのテスト実行に数カ月かけるのは妥当だろうか？ ✓ テスト対象の過去や未来の情報にも着目する ✓ 状況が変化しやすい場合は、反復的に制約の確認と対処方法の検討を 行えるようにスケジューリングする
63. 気を付けたいポイント 63 ビジネス文書としての可読性 説明 読み方や文書の構造が分かりづらい、文字の大きさ等が極端で見辛い。 結果、誤解を生んだり、読者に時間をかけさせたりする恐れがある。 補足として、テスコンU-30クラスでは提出物のページ数に制限が設けられ ていることも影響している可能性はある。制限がなくても、様々な事情か ら読者に不親切な文書ができる場合が考えられるため、ここで取り上げる。 コメ ント 例 1. 読み方の明記 • IDの振り方のルールを明示している点はよいと思います。 • 凡例がなかったり、説明が少なかったりすることがあり、わかりにくさ や保守性の低下に繋がっています。 2. 文字の大きさや図表の大きさ、見せ方に関する配慮 • ひとつの図が複数ページに分割されている、読むためにかなり拡大する 必要がある、など、読者に負荷をかけてしまう状態になっています。 • 一部の図は、全体を俯瞰して確認しづらいです。 （次ページに続く）
64. 気を付けたいポイント 64 ビジネス文書としての可読性 コメ ント 例 3. 文書構造の複雑さ • テストアーキテクチャの図は理解できるのですが、共通要素が多く、 もっとシンプルに表現できるのではと思います。 • 文書量が多いこともあり、文書間の関連をより明確にするか、より単純 化して作成されると、文書を読む側の印象は更に良くなると思います。 対策 ✓ 書かないと伝わらないことは書く必要があるが、文章量が多すぎても 理解しづらい。理解しやすさや、可読性を高めるよう文書構成の工夫を 検討する。 ✓ 図表が大きすぎる場合は、抽象度が粗い図表と細かい図表を作成したり、 スコープを分けたりして、複数に分割する。保守性とのトレードオフに なることがあるので注意は必要。 ✓ 作成者が作成直後に見ても、分かりづらさに気づきにくい。他の人に レビューを依頼するか、自分で確認する場合は時間を置いて見直す。
65. 気を付けたいポイント テストケース作成やテスト成果物のレビューにて、ご参考になる 情報を何かしら掴んでいただけていたら、幸いです。 65 根拠や意図、結果や実現方法の分かりやすさ 多面性 状況に合ったテスト活動 ビジネス文書としての可読性
66. さいごに 皆さんが、以下のゴールを達成できていると嬉しいです。 66 本日の話は絶対的な解ではありません。 考えるヒントとしていただき、みなさんが置かれている状況に より合ったテストに繋げていただければ幸いです。 既にうまくできているという方、実践や試行の場を探している方は、 もしよければテスコンへのご応募を検討していただければ嬉しいです。 実装までのテスト開発プロセス のイメージを掴んでいただく 実装までのテスト開発プロセス の中で特に気を付けたいこと を知っていただく
67. おまけ もう少し学びたいなと思ってくださった方へ 2025/06/04にテスコン編も開催予定です。 • テスト設計チュートリアル テスコン編 ’25 https://aster.connpass.com/event/355108/ 過去のちびこん編の資料や動画は、公開されています。 チュートリアルは、担当の審査員ごとに伝え方に特色があります。 過去分も確認してみていただけると、また違った発見があるかもしれません。 • 2024年度 • https://www.aster.or.jp/testcontest/doc/2024_chibicon_v1.0.0.pdf • 2023年度 • https://speakerdeck.com/goyoki/test-design-tutorial • 2021年度 • https://www.aster.or.jp/business/contest/doc/2021_chibicon_V1.0.0.pdf • テスト設計コンテストチャンネル • https://www.youtube.com/@aster-test-design-competition 67
68. 参考文献と引用文献 68
69. 参考文献と引用文献 いずれも、本書作成時点の情報である • テスト設計チュートリアル ちびこん編 ‘24 資料 • https://www.aster.or.jp/testcontest/doc/2024_chibicon_v1.0.0.pdf • テスト設計チュートリアル ちびこん編 ‘23 資料 • https://speakerdeck.com/goyoki/test-design-tutorial • テスト設計チュートリアル ちびこん編 '21 資料 • http://www.aster.or.jp/business/contest/doc/2021_chibicon_V1.0.0.pdf • テスト設計チュートリアル テスコン編 ‘22 資料 • https://www.aster.or.jp/testcontest/doc/2022/2022_tescon_V1.0.0.pdf • JaSST‘22 Hokuriku 目指せテスト設計リーダー!! テスト設計チュートリアル 資料 • https://www.jasst.jp/symposium/jasst22hokuriku/pdf/B1.pdf • JaSST‘13 Kyushu ちょっと明日のテストの話をしよう 資料 • https://www.jasst.jp/symposium/jasst13kyushu/pdf/S5.pdf • テスト設計コンテスト'21 - テスト要求分析チュートリアル 資料 • https://www.aster.or.jp/business/contest/doc/2020_TRA_1-3_V1.0.0.pdf 69
70. 参考文献と引用文献 いずれも、本書作成時点の情報である • テスト設計コンテスト • https://www.aster.or.jp/testcontest/ • テスト設計コンテスト U-30クラス • https://www.aster.or.jp/testcontest/u30.html • ASTER U-30テスト設計コンテストストプロジェクト要求補足書2024 Ver. 1.0 • https://www.aster.or.jp/testcontest/doc/aster_u30_tdc_supplement_2024.pdf • テスト設計コンテスト’24 U-30クラス 予選 審査コメント • J.マイヤーズ/T.バジェット/M.トーマス/C.サンドラー(原著), 長尾真(監訳),松尾正信 (翻訳). ソフトウェア・テスト の技法 第2版. 近代科学社, 2006年. • ISTQB テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 • https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf • ISTQB テスト技術者資格制度 用語集 • https://glossary.istqb.org/ja_JP/search • 27号：欠陥の偏在 • https://note.com/akiyama924/n/n79b902f69ddf 70