Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テストの目的を考えよう

imtnd
December 12, 2020

 テストの目的を考えよう

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

imtnd

December 12, 2020
Tweet

More Decks by imtnd

Other Decks in Programming

Transcript

  1. テストの⽬的を考えよう
    WACATE 2020 WINTER

    View full-size slide

  2. ⾃⼰紹介
    • ⾓⽥ 俊
    • Twitter
    • @imtnd
    • コミュニティ活動
    • WACATE実⾏委員
    • NaITE運営スタッフ

    View full-size slide

  3. セッションのゴール
    • テスト実施者
    • ⾃分が⾏っているテストの⽬的を意識しながら、テストができるよう
    になること
    • テストマネージャー
    • テストレベルでやることを明確化し、テストの計画が⽴てられるよう
    になること

    View full-size slide

  4. ⽬次
    1. ソフトウェア開発プロセス
    2. テストレベル
    1. コンポーネントテスト
    2. 統合テスト
    3. システムテスト
    4. 受け⼊れテスト
    3. テスト計画
    4. テスト⽬的のヒントアイテム
    5. 演習
    6. まとめ

    View full-size slide

  5. 移動を便利にするものを作って欲しい
    と⾔われたらどうしますか?

    View full-size slide

  6. ⾃動⾞を作成してほしいと
    ⾔われたらどうですか?

    View full-size slide

  7. ネジが欲しいと⾔われたら
    どうですか?

    View full-size slide

  8. V字モデル
    要求
    要件
    基本設計
    詳細設計
    コード作成
    コンポーネント
    テスト
    統合テスト
    システム
    テスト
    受け⼊れ
    テスト
    設計⼯程 検証⼯程
    詳細化

    View full-size slide

  9. アジャイル開発
    イテレーション1 イテレーション2 イテレーション3 イテレーション4

    View full-size slide

  10. テストレベル
    テストレベルは、系統的にまとめ、マネジメントしていくテスト
    の活動のグループである
    Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
    テストでやること(テスト活動)をグループ化して定義したもの
    • ⽬的
    • テスト対象 など

    View full-size slide

  11. 要求
    要件
    基本設計
    詳細設計
    コード作成
    コンポーネント
    テスト
    統合テスト
    システム
    テスト
    受け⼊れ
    テスト
    設計⼯程 検証⼯程

    View full-size slide

  12. コンポーネントテスト
    コンポーネントテスト(ユニットテストまたはモジュールテスト
    とも呼ばれる)は、個別にテスト可能なコンポーネントに焦点を
    あてる。コンポーネントテストの⽬的は以下の通りである。
    • コンポーネントの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証
    • コンポーネントに存在する⽋陥の検出
    • ⽋陥がより⾼いテストレベルまで⾒逃されることの防⽌
    Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

    View full-size slide

  13. • コンポーネント(部品)に対して、⼊⼒を与えて動作、出⼒
    (振る舞い)が想定通りになっているのかを確認する
    • 開発者が⾃分の作成したものが⾃分の作成意図通りになってい
    るのかを確認するのが⼀般的
    コンポーネント
    コンポーネントテスト

    View full-size slide

  14. 要求
    要件
    基本設計
    詳細設計
    コード作成
    コンポーネント
    テスト
    統合テスト
    システム
    テスト
    受け⼊れ
    テスト
    設計⼯程 検証⼯程

    View full-size slide

  15. 統合テスト
    統合テストは、コンポーネントまたはシステム間の相互処理に焦
    点をあてる。統合テストの⽬的は以下の通りである。
    • インターフェイスの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証
    • ⽋陥の検出(インターフェース⾃体、コンポーネントに内在、またはシステムに内在)
    • ⽋陥がより⾼いテストレベルまで⾒逃されることの防⽌
    Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

    View full-size slide

  16. • 複数のコンポーネント(部品)が統合でき(インターフェイス
    が仕様通りになっている)、動作することを確認する
    • 複数のコンポーネントを⼀度に統合しようとすると効率が悪い
    ことがある
    統合テスト(コンポーネント統合テスト)

    View full-size slide

  17. 要求
    要件
    基本設計
    詳細設計
    コード作成
    コンポーネント
    テスト
    統合テスト
    システム
    テスト
    受け⼊れ
    テスト
    設計⼯程 検証⼯程

    View full-size slide

  18. システムテスト
    システムテストは、システムが実⾏するエンドツーエンドのタス
    クと、タスクの実⾏時にシステムが⽰す⾮機能的振る舞いといっ
    たシステムやプロダクト全体の振る舞いや能⼒に焦点をあてる。
    システムテストの⽬的は以下の通りである。
    • システムの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証
    • システムが完成し、期待通りに動作することの妥当性確認
    • ⽋陥の検出
    • ⽋陥がより⾼いテストレベルまたは運⽤環境まで⾒逃されることの防⽌
    Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

    View full-size slide

  19. • システムの終端の振る舞いが仕様通りになっていることを確認
    する
    (システム全体としての評価)
    システムテスト
    システム

    View full-size slide

  20. • システム間や、複数のサービス、APIなどを統合して仕様通り
    に動作することを確認する
    システム統合テスト
    ※ JSTQBでは統合テストに分類されている

    View full-size slide

  21. 要求
    要件
    基本設計
    詳細設計
    コード作成
    コンポーネント
    テスト
    統合テスト
    システム
    テスト
    受け⼊れ
    テスト
    設計⼯程 検証⼯程

    View full-size slide

  22. 受け⼊れテスト
    システムテストと同様、⼀般的に受け⼊れテストはシステムやプ
    ロダクト全体の振る舞いや能⼒に焦点をあてる。受け⼊れテスト
    の⽬的は以下の通りである。
    • システムが完成し、期待通りに動作することの妥当性確認
    • システムの機能的/⾮機能的振る舞いが仕様通りであることの検証
    Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02
    http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
    受け⼊れテストで⽋陥が⾒つかることはあるが、⽋陥を⾒つける
    ことは⽬的ではない

    View full-size slide

  23. • 作成したシステムが使⽤できるか、効果があるかなどを評価する
    • テスト実施者は受け⼊れの相⼿による
    • 発注者
    • ユーザ
    • 運⽤管理者
    受け⼊れテスト

    View full-size slide

  24. 要求
    要件
    基本設計
    詳細設計
    コード作成
    コンポーネン
    トテスト
    統合テスト
    システム
    テスト
    受け⼊れ
    テスト

    View full-size slide

  25. テストレベルとテストフェーズ
    • テストレベル
    • テスト活動の段階をグループ化したもの
    • テストフェーズ
    • テストの時間を分けたもの
    • 以下のような場⾯も存在する
    • 統合テストフェーズであっても不具合があった場合はコンポーネントテストを
    ⾏う
    • 性能を早く⾒たいから統合テストでもシステムテストのテストを早く着⼿する
    ※ JSTQBでも区別していないので厳密に区別する必要はないが区別した⽅が良い場⾯もある

    View full-size slide

  26. テストレベルのカスタマイズ
    • テストレベルという概念はすごく抽象的
    • テスト対象は明確︖
    • コンポーネントとは︖
    • アプリ︖クラス︖メソッド、関数︖
    • システムとは︖
    • 統合テストでは、何と何を統合する︖
    • アプリの結合︖
    • クラスの結合︖
    • 作成者間で作成したものの結合︖
    • テストレベルの段階は4段階で良い︖

    View full-size slide

  27. テスト計画
    • どういった⼿段やスケジュールでテストを進めていくのかを
    定義したもの
    • テスト計画では、総合的、または、個別の各テストレベルでど
    ういったことを⾏うのか検討する
    • マスターテスト計画
    プロジェクト全体で各テストレベルで何を⾏うのかなどを総合的に決
    めたもの
    • 各テストレベルのテスト計画
    各テストレベルで達成するべき⽬的などを定義したもの

    View full-size slide

  28. テストレベルの役割を
    定義できていないと。。。
    • 各テストレベルで実施するテストの⽬的を定義できていないと、
    以下のようなことが起こる
    • 下位テストレベルで⾏われるべき内容が上位のテストレベルで⾏われ

    • システムテストで関数、メソッドへのパタメータの同値、境界値を確認する
    • 同じテストを複数のテストレベルで⾏っている
    • 同じテストを複数回⾏っても時間の無駄になる
    • 不具合が発覚したときの不具合原因を時間がかかる
    • テストの積み重ねがないと、不具合が発⽣したときの原因特定の範囲が広くなり、
    原因調査に時間がかかる

    View full-size slide

  29. テスト⽬的のヒントアイテム
    • ヒントになるアイテム
    • テストベース
    • テスト環境、テストツール
    • テスト対象、テストスコープ
    • テストデータ
    • テスト技法、カバレッジ基準
    • テスト実施者
    • テスト観点(テストタイプ)

    View full-size slide

  30. テストベース
    • テストベースが異なるということは、テスト⽬的の視点が異なる
    • テストのインプットとなるもの
    • 要求仕様書
    • 要件定義書
    • ユーザストーリー
    • バックログ
    • 基本設計書
    • 詳細設計書
    • ソースコード
    • 形のあるドキュメントとは限らない
    • PFDでテストレベルを定義するとインプットが明確になる

    View full-size slide

  31. テスト環境とテストツール
    • そのテストレベルはどういう環境でテストを実施するのか
    • シュミレータ or 実機
    • 開発環境 or 本番環境
    • 実機や本番環境でテストする場合には実環境相当の負荷をかけて置く場合も
    ある
    本番運⽤のときと、テスト環境が異なる場合は環境により不具合が出
    る可能性がある
    • 使⽤するテストツール
    テストツールを使⽤している理由を確認する
    • xUnit Framework
    • Cucumber
    • ⾃作ツール

    View full-size slide

  32. テスト対象とテストスコープ
    • そのテストのテストスコープはどこまでなのか
    • 対向のテストアイテムは 実物 or モック(スタブ)
    • 実物の場合はテストスコープ範囲内、モックはテスト範囲外となる
    • 実物を対向テストアイテムとする場合は、バージョンなども定義する
    • モックを使⽤してテストを実施する場合は、それよりも上位の
    テストレベルで実物を使⽤してテストを⾏うタイミングを決め
    る必要がある。

    View full-size slide

  33. テストデータ
    • どういったデータでテストを実施するのか
    • 試験⽤のデータ
    (機能が検証できる最⼩限のデータ)
    • 本番運⽤の実際に使⽤する想定のデータ
    • 実際の運⽤に使⽤していたデータ

    View full-size slide

  34. テスト技法とカバレッジ基準
    • 各テストレベルで使⽤するテスト技法と、満たすカバレッジを
    定義しよう
    • コードカバレッジC0,C1,MC/DC
    • 境界値分析で2値の境界値
    • 状態遷移テストで、0スイッチカバレッジを網羅
    • ペアワイズテストで、2ワイズカバレッジ網羅
    • ユースケーステストを網羅

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide