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