テストの目的を考えよう

In WACATE 2020 winter
テストの目的を考えよう　セッション資料
https://wacate.jp/workshops/2020winter/

Transcript

1. テストの⽬的を考えよう WACATE 2020 WINTER
2. ⾃⼰紹介 • ⾓⽥ 俊 • Twitter • @imtnd • コミュニティ活動 • WACATE実⾏委員 • NaITE運営スタッフ
3. セッションのゴール • テスト実施者 • ⾃分が⾏っているテストの⽬的を意識しながら、テストができるよう になること • テストマネージャー • テストレベルでやることを明確化し、テストの計画が⽴てられるよう になること
4. ⽬次 1. ソフトウェア開発プロセス 2. テストレベル 1. コンポーネントテスト 2. 統合テスト 3. システムテスト 4. 受け⼊れテスト 3. テスト計画 4. テスト⽬的のヒントアイテム 5. 演習 6. まとめ
5. 質問
6. 移動を便利にするものを作って欲しい と⾔われたらどうしますか？
7. ⾃動⾞を作成してほしいと ⾔われたらどうですか？
8. ネジが欲しいと⾔われたら どうですか？
9. V字モデル 要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト 受け⼊れ テスト 設計⼯程 検証⼯程 詳細化
10. アジャイル開発 イテレーション1 イテレーション2 イテレーション3 イテレーション4
11. テストレベル テストレベルは、系統的にまとめ、マネジメントしていくテスト の活動のグループである Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf テストでやること（テスト活動）をグループ化して定義したもの • ⽬的 • テスト対象 など
12. 要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト 受け⼊れ テスト 設計⼯程 検証⼯程
13. コンポーネントテスト コンポーネントテスト（ユニットテストまたはモジュールテスト とも呼ばれる）は、個別にテスト可能なコンポーネントに焦点を あてる。コンポーネントテストの⽬的は以下の通りである。 • コンポーネントの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証 • コンポーネントに存在する⽋陥の検出 • ⽋陥がより⾼いテストレベルまで⾒逃されることの防⽌ Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
14. • コンポーネント（部品）に対して、⼊⼒を与えて動作、出⼒ （振る舞い）が想定通りになっているのかを確認する • 開発者が⾃分の作成したものが⾃分の作成意図通りになってい るのかを確認するのが⼀般的 コンポーネント コンポーネントテスト
15. 要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト 受け⼊れ テスト 設計⼯程 検証⼯程
16. 統合テスト 統合テストは、コンポーネントまたはシステム間の相互処理に焦 点をあてる。統合テストの⽬的は以下の通りである。 • インターフェイスの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証 • ⽋陥の検出（インターフェース⾃体、コンポーネントに内在、またはシステムに内在） • ⽋陥がより⾼いテストレベルまで⾒逃されることの防⽌ Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
17. • 複数のコンポーネント（部品）が統合でき（インターフェイス が仕様通りになっている）、動作することを確認する • 複数のコンポーネントを⼀度に統合しようとすると効率が悪い ことがある 統合テスト（コンポーネント統合テスト）
18. 要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト 受け⼊れ テスト 設計⼯程 検証⼯程
19. システムテスト システムテストは、システムが実⾏するエンドツーエンドのタス クと、タスクの実⾏時にシステムが⽰す⾮機能的振る舞いといっ たシステムやプロダクト全体の振る舞いや能⼒に焦点をあてる。 システムテストの⽬的は以下の通りである。 • システムの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証 • システムが完成し、期待通りに動作することの妥当性確認 • ⽋陥の検出 • ⽋陥がより⾼いテストレベルまたは運⽤環境まで⾒逃されることの防⽌ Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
20. • システムの終端の振る舞いが仕様通りになっていることを確認 する （システム全体としての評価） システムテスト システム
21. • システム間や、複数のサービス、APIなどを統合して仕様通り に動作することを確認する システム統合テスト ※ JSTQBでは統合テストに分類されている
22. 要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト 受け⼊れ テスト 設計⼯程 検証⼯程
23. 受け⼊れテスト システムテストと同様、⼀般的に受け⼊れテストはシステムやプ ロダクト全体の振る舞いや能⼒に焦点をあてる。受け⼊れテスト の⽬的は以下の通りである。 • システムが完成し、期待通りに動作することの妥当性確認 • システムの機能的/⾮機能的振る舞いが仕様通りであることの検証 Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf 受け⼊れテストで⽋陥が⾒つかることはあるが、⽋陥を⾒つける ことは⽬的ではない
24. • 作成したシステムが使⽤できるか、効果があるかなどを評価する • テスト実施者は受け⼊れの相⼿による • 発注者 • ユーザ • 運⽤管理者 受け⼊れテスト
25. 要求 要件 基本設計 詳細設計 コード作成 コンポーネン トテスト 統合テスト システム テスト 受け⼊れ テスト
27. テストレベルとテストフェーズ • テストレベル • テスト活動の段階をグループ化したもの • テストフェーズ • テストの時間を分けたもの • 以下のような場⾯も存在する • 統合テストフェーズであっても不具合があった場合はコンポーネントテストを ⾏う • 性能を早く⾒たいから統合テストでもシステムテストのテストを早く着⼿する ※ JSTQBでも区別していないので厳密に区別する必要はないが区別した⽅が良い場⾯もある
28. テストレベルのカスタマイズ • テストレベルという概念はすごく抽象的 • テスト対象は明確︖ • コンポーネントとは︖ • アプリ︖クラス︖メソッド、関数︖ • システムとは︖ • 統合テストでは、何と何を統合する︖ • アプリの結合︖ • クラスの結合︖ • 作成者間で作成したものの結合︖ • テストレベルの段階は4段階で良い︖
29. テスト計画 • どういった⼿段やスケジュールでテストを進めていくのかを 定義したもの • テスト計画では、総合的、または、個別の各テストレベルでど ういったことを⾏うのか検討する • マスターテスト計画 プロジェクト全体で各テストレベルで何を⾏うのかなどを総合的に決 めたもの • 各テストレベルのテスト計画 各テストレベルで達成するべき⽬的などを定義したもの
30. テストレベルの役割を 定義できていないと。。。 • 各テストレベルで実施するテストの⽬的を定義できていないと、 以下のようなことが起こる • 下位テストレベルで⾏われるべき内容が上位のテストレベルで⾏われ る • システムテストで関数、メソッドへのパタメータの同値、境界値を確認する • 同じテストを複数のテストレベルで⾏っている • 同じテストを複数回⾏っても時間の無駄になる • 不具合が発覚したときの不具合原因を時間がかかる • テストの積み重ねがないと、不具合が発⽣したときの原因特定の範囲が広くなり、 原因調査に時間がかかる
31. テスト⽬的のヒントアイテム • ヒントになるアイテム • テストベース • テスト環境、テストツール • テスト対象、テストスコープ • テストデータ • テスト技法、カバレッジ基準 • テスト実施者 • テスト観点（テストタイプ）
32. テストベース • テストベースが異なるということは、テスト⽬的の視点が異なる • テストのインプットとなるもの • 要求仕様書 • 要件定義書 • ユーザストーリー • バックログ • 基本設計書 • 詳細設計書 • ソースコード • 形のあるドキュメントとは限らない • PFDでテストレベルを定義するとインプットが明確になる
33. テスト環境とテストツール • そのテストレベルはどういう環境でテストを実施するのか • シュミレータ or 実機 • 開発環境 or 本番環境 • 実機や本番環境でテストする場合には実環境相当の負荷をかけて置く場合も ある 本番運⽤のときと、テスト環境が異なる場合は環境により不具合が出 る可能性がある • 使⽤するテストツール テストツールを使⽤している理由を確認する • xUnit Framework • Cucumber • ⾃作ツール
34. テスト対象とテストスコープ • そのテストのテストスコープはどこまでなのか • 対向のテストアイテムは 実物 or モック（スタブ) • 実物の場合はテストスコープ範囲内、モックはテスト範囲外となる • 実物を対向テストアイテムとする場合は、バージョンなども定義する • モックを使⽤してテストを実施する場合は、それよりも上位の テストレベルで実物を使⽤してテストを⾏うタイミングを決め る必要がある。
35. テストデータ • どういったデータでテストを実施するのか • 試験⽤のデータ （機能が検証できる最⼩限のデータ） • 本番運⽤の実際に使⽤する想定のデータ • 実際の運⽤に使⽤していたデータ
36. テスト技法とカバレッジ基準 • 各テストレベルで使⽤するテスト技法と、満たすカバレッジを 定義しよう • コードカバレッジC0,C1,MC/DC • 境界値分析で２値の境界値 • 状態遷移テストで、0スイッチカバレッジを網羅 • ペアワイズテストで、2ワイズカバレッジ網羅 • ユースケーステストを網羅
37. テスト実施者 • 誰がテストを⾏うのか • 開発者 • 違う機能を作成していた開発者 • テストのみを⾏うテスト担当者 • 他社のチーム • 海外のチーム • QA • テスト実施する⼈によってテスト⽬的が異なる • 作成したものが開発者の想定通りになっているのかを確認 • システム全体として問題ないことの検証 • 第3者にテストしてもらうことで不具合はより⾒つけやすくなる
38. テスト観点（テストタイプ） • どのテストレベルでどういったテストを⾏うのか • 使⽤性テスト • 負荷テスト • 移⾏テスト • 性能テスト • 運⽤テスト • 信頼性テスト • セキュリティテスト • どの段階でどういうテストを⾏うのかを決める • アジャイル開発では⼀つのイテレーション内だけではなく、 いつのイテレーションのどのテストレベルでテストを⾏うのかを決めておく
39. テストレベルの名前 • テストレベルで実施している内容を踏まえて、 メンバ全員で分かりやすい名前をつける • 〇〇テスト • 〇〇統合テスト • 分かりやすい名前を付けておくと、認識ズレも起こりづらい
40. 演習 • 関わっているテストレベルを識別アイテムを使って⽬的を認識 してみよう 時間︓２０分間 • 他の上位、下位のテストレベルと何が違うのかを考えよう • ⾃分で⾏っているテストはどんな検証を⾏うことを期待されているのか • ⾏っていないテストとは何が違うのか → 他のテストレベルとの違いからテストの⽬的を考えてみよう • プロジェクト全体としてテストレベルがどう区別されているのか整理 してみよう • 段階はもっと細分化すべきではないのか • 名前を変える
41. まとめ • テストレベルからテストの⽬的を考えよう • テストレベルをカスタマイズして具体的に定義してみよう • 参考アイテム • テストベース • テスト環境、テストツール • テスト対象、テストスコープ • テストデータ • テスト技法、カバレッジ基準 • テスト実施者 • テスト観点（テストタイプ）
42. 参考情報 • テスト計画をもっと勉強したい⼈ • IEEE 829-1998 • IEEE 829-2008 • ISO/IEC/IEEE 29119-3