Nagoya.Testing

1. The Outline of
Test Process
in Nagoya.Testing 2 in Tokyo
2012.04.06

2. Self Introduction
名前：きょん(kyon_mm)
Blog : うさぎ組
Target : 開発環境改善
Groovy、テスト、自動化、アジャイル、品質保証
24歳うさみみ系男子
SCMBootCamp、Nagoya.Testing, StartupGroovy

3. Agenda
テストとは？
テストプロセスについて
まとめ

4. テストとは？

5. JSTQB (Testing)
成果物が定義した要件を満足するかを判定し、目的に合致す
ることを実証し、欠陥を見つけるため、ソフトウェア製品や
関連成果物に対し、計画、準備、評価をすること。
全てのライフサイクルを通じて実施する静的、動的なプロセ
ス。
静的解析ツール、レビュー、ユーザビリティーテスト も含む

6. kyon_mm
対象のプロダクトを一意的に判断する行為。
（レビューやユーザビリティテストは必須な要素だが、テス
トではない）

7. #なごやこわい
コンパイルはテスト
ロジックを型に落とし込みやすい言語で、静的型付けだと、
コンパイル時に多くのエラーがとれる
つまり、静的型付け関（ry

8. Agenda
テストとは？
テストプロセスについて
まとめ

9. テストプロセスについて

10. テストプロセスについて
テスト戦略策定(テスト計画)
テスト分析/テスト設計
テスト実装
テスト実施/報告

11. テスト戦略策定
Purpose
テストの指針となるものに関して計画する。テストに要求されているもの、実施時のリス
クやリソースなど鑑みる。
Input
要求仕様書、アーキテクチャ、プロジェクト体制
Output
テスト計画書。例として次のような項目をリストにできるようにする。テストカテゴリ
(テスト目的、テスト対象)、テスト設計方針(適用する手法)、時期、人、手段、テストロ
グ、インシデントレポートの提供方法

12. テスト戦略手順
テスト要求(テスト目的、品質目標、リスク、リソース)の分析
テスト対象アーキテクチャの分析、分解する
「テスト対象」と「テスト要求」の分析結果を組み合わせて「テスト観点」を構
築する
テスト全体のバランスをとる。テストの抜けもれ、重複をなくす
テスト技法などの組合せの方針を決定する
テストのマイルストーンを決めて、テスト計画書に書き出す

13. テスト戦略
テスト要求
テストに求められているもののこと。「○○であることを保証
したい」「○○チームでテストをまわしてほしい」「○○までに
リリースしてほしい」などなど
アジャイルサムライ的に言うと「時間, 予算, 品質, スコープ」
などの要求があり、それらはリスクでもある。

14. テスト戦略
テスト対象
対象プロダクトでテストする機能、特徴のこと。
JSTQB的には「テストするコンポーネントやシステムのこ
と」

15. テスト戦略
テスト目的
対象プロダクトを評価する視点、どんなバグがあるか(ない
か)を確認する視点のこと。

16. テスト戦略手順
テスト要求(テスト目的、品質目標、リスク、リソース)の分析
テスト対象アーキテクチャの分析、分解する
「テスト対象」と「テスト要求」の分析結果を組み合わせて「テスト観点」を構
築する
テスト全体のバランスをとる。テストの抜けもれ、重複をなくす
テスト戦略全体を見ながら、テスト観点毎にテスト技法や網羅基準、組合せなど
の「テスト設計の方針」を決定する
テストのマイルストーンを決めて、テスト計画書に書き出す

17. テスト戦略：キーワード
ソフトウェアの品質特性
テストタイプ、テストカテゴリ
テストフレーム、テストアーキテクチャ
テスト技法、レビュー

18. テスト分析
Purpose
対象プロダクトを「テスト設計可能なレベル」まで分析する。プロダクトをテストし
やすいように再度整理する。
Input
外部仕様書、開発で採用しているツール、設計思想
Output
テストを設計するための調査結果。例として次のようなものがあげられる。機能をま
とめたマトリクス、状態遷移図、ER図、ユースケース図、デシジョンテーブル

19. テスト分析手順
対象プロダクトの「 振る舞い、モデル、ツール、原則など」を整理する。
整理した結果をもとにテスト対象をブレークダウンする。
必要であればプロダクトの仕様書とは別にテスト用に再整理したドキュメントを
作成する。
テスト分析結果をまとめる。

20. テスト設計
Purpose
テスト戦略で決定した「テスト観点」を「テスト設計方針」に従ってテストケース作成の
ために設計を実施する。
Input
前フェーズまでのインプット、アウトプット
Output
テスト設計書。例として次のような項目をリストにできるようにする。テストカテゴリ、
テスト目的、テスト対象、テスト条件とすべきパラメータ(仕様項目)、テスト実装方針(適
用するテスト技法、網羅基準)、テストケースにした際の優先順位基準

21. テスト設計手順
テスト観点毎にテスト分析結果およびテスト設計方針にしたがっ
てテスト条件を特定する。
テストケース数を見積もる
テスト設計が妥当かを考える。テストが多すぎないか、テスト目
的から外れていないか、テスト減らすことは出来るか。
テスト設計書にまとめる。

22. テスト設計
テスト技法(テスト設計技法)
テストケースを導出するための手法。主に網羅基準や論理関
係の決定からパターンを作成しやすくする目的で使用する。

23. テスト設計：キーワード
テスト技法
同値分割、境界値分析、制御パスフロー、All-Pair法、状態遷
移テスト、デシジョンテーブル、原因結果グラフ、リスク
ベースドテスト
静的解析
網羅基準

24. テスト実装
Purpose
テスト設計をもとにテストケースを実装する。テストケースはテスト実施者に最適化され
たフォーマットが望ましい。
Input
前フェーズまでのインプット、アウトプット
Output
テスト仕様書。例として次のような項目をリストにできるようにする。テストカテゴリ、
テスト目的、テスト対象、テスト設計方針、テスト条件の基準となった仕様、優先順位、
事前条件、テスト手順、期待結果(不変な項目、変化する項目)

25. テスト実装手順
テスト設計結果から、テスト条件パラメータを見直す
具体的な期待結果（不変項目、変化項目など）を考える
事前条件、テスト手順を考える
設計にしたがって（「事前条件、テスト条件パラメータ、期待結果の組合せ」
「テストケースの優先度」、などを考えて）、テストケースを作成する
テスト仕様書にまとめる。テスト環境やテスト実施者が実施しやすい、確認しや
すいようなテストケースの並び順や記述を考慮する。

26. テスト実施/報告
Purpose
テストを実施し、プロダクトを評価する。テストケースの結果だけではなく、プ
ロダクトの品質に関わるものは報告する。ただし、品質が定義されている事が重
要。
Input
前フェーズまでのインプット、アウトプット
Output
バグレポート、テスト成績、テスト結果報告

27. テスト実施/報告手順
テストログのフォーマットを決定する
テスト仕様書に従ってテストを実施する
テストログをとる
テストログからバグについて分析する
バグについてインシデントレポートをまとめる
品質見解報告をまとめる

28. Agenda
テストとは？
テストプロセスについて
まとめ

29. まとめ
テストプロセスって長いと思われがちだけど、実際はよく
やっていることを明確に定義づけたものです。
テスト自体がまだまだ未成熟な領域が広いので、違和感があ
るかもしれません。
一元的に正しいものは存在しません。