テストの目的を考えよう

by imtnd

Embed

Start on current slide

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 • 境界値分析で２値の境界値 • 状態遷移テストで、0スイッチカバレッジを網羅 • ペアワイズテストで、2ワイズカバレッジ網羅 • ユースケーステストを網羅

Slide 37

Slide 37 text

テスト実施者 • 誰がテストを⾏うのか • 開発者 • 違う機能を作成していた開発者 • テストのみを⾏うテスト担当者 • 他社のチーム • 海外のチーム • QA • テスト実施する⼈によってテスト⽬的が異なる • 作成したものが開発者の想定通りになっているのかを確認 • システム全体として問題ないことの検証 • 第3者にテストしてもらうことで不具合はより⾒つけやすくなる

Slide 38

Slide 38 text

テスト観点（テストタイプ） • どのテストレベルでどういったテストを⾏うのか • 使⽤性テスト • 負荷テスト • 移⾏テスト • 性能テスト • 運⽤テスト • 信頼性テスト • セキュリティテスト • どの段階でどういうテストを⾏うのかを決める • アジャイル開発では⼀つのイテレーション内だけではなく、いつのイテレーションのどのテストレベルでテストを⾏うのかを決めておく

Slide 39

Slide 39 text

テストレベルの名前 • テストレベルで実施している内容を踏まえて、メンバ全員で分かりやすい名前をつける • 〇〇テスト • 〇〇統合テスト • 分かりやすい名前を付けておくと、認識ズレも起こりづらい

Slide 40

Slide 40 text

演習 • 関わっているテストレベルを識別アイテムを使って⽬的を認識してみよう時間︓２０分間 • 他の上位、下位のテストレベルと何が違うのかを考えよう • ⾃分で⾏っているテストはどんな検証を⾏うことを期待されているのか • ⾏っていないテストとは何が違うのか → 他のテストレベルとの違いからテストの⽬的を考えてみよう • プロジェクト全体としてテストレベルがどう区別されているのか整理してみよう • 段階はもっと細分化すべきではないのか • 名前を変える

Slide 41

Slide 41 text

まとめ • テストレベルからテストの⽬的を考えよう • テストレベルをカスタマイズして具体的に定義してみよう • 参考アイテム • テストベース • テスト環境、テストツール • テスト対象、テストスコープ • テストデータ • テスト技法、カバレッジ基準 • テスト実施者 • テスト観点（テストタイプ）

Slide 42

Slide 42 text

参考情報 • テスト計画をもっと勉強したい⼈ • IEEE 829-1998 • IEEE 829-2008 • ISO/IEC/IEEE 29119-3