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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. 質問

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  26. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide