Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テストの目的を考えよう
Search
imtnd
December 12, 2020
Programming
0
740
テストの目的を考えよう
In WACATE 2020 winter
テストの目的を考えよう セッション資料
https://wacate.jp/workshops/2020winter/
imtnd
December 12, 2020
Tweet
Share
More Decks by imtnd
See All by imtnd
WACATE 2022 夏 ワークショップの目的
imtnd
0
910
テスト設計技法をなぜ&どのように使うのか体験しよう!
imtnd
0
1.4k
analyze the behavior with decision table
imtnd
0
3.8k
WACATE流テスト分析のワークショップを体感してみよう
imtnd
0
190
テスト技法作成のアプローチを考える
imtnd
0
680
アジャイルとテスト / Agile and Testing
imtnd
1
1.9k
やってみよう状態遷移テスト #xpjug
imtnd
0
1k
Agile Japan 2019 Report
imtnd
0
1k
Let's consider about Test Levels
imtnd
1
750
Other Decks in Programming
See All in Programming
Mergeable Libraryで 高速なアプリ起動を実現しよう!
giginet
PRO
1
2k
私のEbitengineの第一歩
qt_luigi
0
430
いつか使える ObjectSpace / Maybe useful ObjectSpace
euglena1215
2
120
メモリ最適化を究める!iOSアプリ開発における5つの重要なポイント
yhirakawa333
0
380
The Future of Frontend i18n : Intl.MessageFormat
sajikix
1
2.4k
Ebitengineの1vs1ゲーム WebRTCの活用
ponyo877
0
350
What we keep in mind when migrating from Serverless Framework to AWS CDK and AWS SAM
kasacchiful
1
130
BasicBasic認証
sadnessojisan
5
3.1k
ESLint Rule により事業, 技術ドメインに沿った制約と誓約を敷衍させるアプローチのすゝめ
shinyaigeek
1
2.8k
フロントエンドカンファレンス北海道2024 『小規模サイトでも使えるVite 〜HTMLコーディングをよりスマートに〜』長谷川広武(ハム)
h2ham
1
2.5k
iOSの隠されたAPIを解明し、開発効率を向上させる方法/iOSDC24
noppefoxwolf
2
120
『ドメイン駆動設計をはじめよう』中核の業務領域
masuda220
PRO
5
890
Featured
See All Featured
Statistics for Hackers
jakevdp
793
220k
The Illustrated Children's Guide to Kubernetes
chrisshort
46
48k
Code Reviewing Like a Champion
maltzj
518
39k
Building Adaptive Systems
keathley
36
2.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
25
5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
230
17k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
109
6.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
45
4.8k
Art, The Web, and Tiny UX
lynnandtonic
294
20k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
Intergalactic Javascript Robots from Outer Space
tanoku
268
26k
GraphQLとの向き合い方2022年版
quramy
43
13k
Transcript
テストの⽬的を考えよう WACATE 2020 WINTER
⾃⼰紹介 • ⾓⽥ 俊 • Twitter • @imtnd • コミュニティ活動
• WACATE実⾏委員 • NaITE運営スタッフ
セッションのゴール • テスト実施者 • ⾃分が⾏っているテストの⽬的を意識しながら、テストができるよう になること • テストマネージャー • テストレベルでやることを明確化し、テストの計画が⽴てられるよう
になること
⽬次 1. ソフトウェア開発プロセス 2. テストレベル 1. コンポーネントテスト 2. 統合テスト 3.
システムテスト 4. 受け⼊れテスト 3. テスト計画 4. テスト⽬的のヒントアイテム 5. 演習 6. まとめ
質問
移動を便利にするものを作って欲しい と⾔われたらどうしますか?
⾃動⾞を作成してほしいと ⾔われたらどうですか?
ネジが欲しいと⾔われたら どうですか?
V字モデル 要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム
テスト 受け⼊れ テスト 設計⼯程 検証⼯程 詳細化
アジャイル開発 イテレーション1 イテレーション2 イテレーション3 イテレーション4
テストレベル テストレベルは、系統的にまとめ、マネジメントしていくテスト の活動のグループである Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
テストでやること(テスト活動)をグループ化して定義したもの • ⽬的 • テスト対象 など
要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト
受け⼊れ テスト 設計⼯程 検証⼯程
コンポーネントテスト コンポーネントテスト(ユニットテストまたはモジュールテスト とも呼ばれる)は、個別にテスト可能なコンポーネントに焦点を あてる。コンポーネントテストの⽬的は以下の通りである。 • コンポーネントの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証 • コンポーネントに存在する⽋陥の検出 • ⽋陥がより⾼いテストレベルまで⾒逃されることの防⽌
Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
• コンポーネント(部品)に対して、⼊⼒を与えて動作、出⼒ (振る舞い)が想定通りになっているのかを確認する • 開発者が⾃分の作成したものが⾃分の作成意図通りになってい るのかを確認するのが⼀般的 コンポーネント コンポーネントテスト
要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト
受け⼊れ テスト 設計⼯程 検証⼯程
統合テスト 統合テストは、コンポーネントまたはシステム間の相互処理に焦 点をあてる。統合テストの⽬的は以下の通りである。 • インターフェイスの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証 • ⽋陥の検出(インターフェース⾃体、コンポーネントに内在、またはシステムに内在) • ⽋陥がより⾼いテストレベルまで⾒逃されることの防⽌ Foundation
Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
• 複数のコンポーネント(部品)が統合でき(インターフェイス が仕様通りになっている)、動作することを確認する • 複数のコンポーネントを⼀度に統合しようとすると効率が悪い ことがある 統合テスト(コンポーネント統合テスト)
要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト
受け⼊れ テスト 設計⼯程 検証⼯程
システムテスト システムテストは、システムが実⾏するエンドツーエンドのタス クと、タスクの実⾏時にシステムが⽰す⾮機能的振る舞いといっ たシステムやプロダクト全体の振る舞いや能⼒に焦点をあてる。 システムテストの⽬的は以下の通りである。 • システムの機能的/⾮機能的振る舞いが設計及び仕様通りであることの検証 • システムが完成し、期待通りに動作することの妥当性確認 •
⽋陥の検出 • ⽋陥がより⾼いテストレベルまたは運⽤環境まで⾒逃されることの防⽌ Foundation Level シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf
• システムの終端の振る舞いが仕様通りになっていることを確認 する (システム全体としての評価) システムテスト システム
• システム間や、複数のサービス、APIなどを統合して仕様通り に動作することを確認する システム統合テスト ※ JSTQBでは統合テストに分類されている
要求 要件 基本設計 詳細設計 コード作成 コンポーネント テスト 統合テスト システム テスト
受け⼊れ テスト 設計⼯程 検証⼯程
受け⼊れテスト システムテストと同様、⼀般的に受け⼊れテストはシステムやプ ロダクト全体の振る舞いや能⼒に焦点をあてる。受け⼊れテスト の⽬的は以下の通りである。 • システムが完成し、期待通りに動作することの妥当性確認 • システムの機能的/⾮機能的振る舞いが仕様通りであることの検証 Foundation Level
シラバス ⽇本語版 Version 2018V3.1.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf 受け⼊れテストで⽋陥が⾒つかることはあるが、⽋陥を⾒つける ことは⽬的ではない
• 作成したシステムが使⽤できるか、効果があるかなどを評価する • テスト実施者は受け⼊れの相⼿による • 発注者 • ユーザ • 運⽤管理者
受け⼊れテスト
要求 要件 基本設計 詳細設計 コード作成 コンポーネン トテスト 統合テスト システム テスト
受け⼊れ テスト
None
テストレベルとテストフェーズ • テストレベル • テスト活動の段階をグループ化したもの • テストフェーズ • テストの時間を分けたもの •
以下のような場⾯も存在する • 統合テストフェーズであっても不具合があった場合はコンポーネントテストを ⾏う • 性能を早く⾒たいから統合テストでもシステムテストのテストを早く着⼿する ※ JSTQBでも区別していないので厳密に区別する必要はないが区別した⽅が良い場⾯もある
テストレベルのカスタマイズ • テストレベルという概念はすごく抽象的 • テスト対象は明確︖ • コンポーネントとは︖ • アプリ︖クラス︖メソッド、関数︖ •
システムとは︖ • 統合テストでは、何と何を統合する︖ • アプリの結合︖ • クラスの結合︖ • 作成者間で作成したものの結合︖ • テストレベルの段階は4段階で良い︖
テスト計画 • どういった⼿段やスケジュールでテストを進めていくのかを 定義したもの • テスト計画では、総合的、または、個別の各テストレベルでど ういったことを⾏うのか検討する • マスターテスト計画 プロジェクト全体で各テストレベルで何を⾏うのかなどを総合的に決
めたもの • 各テストレベルのテスト計画 各テストレベルで達成するべき⽬的などを定義したもの
テストレベルの役割を 定義できていないと。。。 • 各テストレベルで実施するテストの⽬的を定義できていないと、 以下のようなことが起こる • 下位テストレベルで⾏われるべき内容が上位のテストレベルで⾏われ る • システムテストで関数、メソッドへのパタメータの同値、境界値を確認する
• 同じテストを複数のテストレベルで⾏っている • 同じテストを複数回⾏っても時間の無駄になる • 不具合が発覚したときの不具合原因を時間がかかる • テストの積み重ねがないと、不具合が発⽣したときの原因特定の範囲が広くなり、 原因調査に時間がかかる
テスト⽬的のヒントアイテム • ヒントになるアイテム • テストベース • テスト環境、テストツール • テスト対象、テストスコープ •
テストデータ • テスト技法、カバレッジ基準 • テスト実施者 • テスト観点(テストタイプ)
テストベース • テストベースが異なるということは、テスト⽬的の視点が異なる • テストのインプットとなるもの • 要求仕様書 • 要件定義書 •
ユーザストーリー • バックログ • 基本設計書 • 詳細設計書 • ソースコード • 形のあるドキュメントとは限らない • PFDでテストレベルを定義するとインプットが明確になる
テスト環境とテストツール • そのテストレベルはどういう環境でテストを実施するのか • シュミレータ or 実機 • 開発環境 or
本番環境 • 実機や本番環境でテストする場合には実環境相当の負荷をかけて置く場合も ある 本番運⽤のときと、テスト環境が異なる場合は環境により不具合が出 る可能性がある • 使⽤するテストツール テストツールを使⽤している理由を確認する • xUnit Framework • Cucumber • ⾃作ツール
テスト対象とテストスコープ • そのテストのテストスコープはどこまでなのか • 対向のテストアイテムは 実物 or モック(スタブ) • 実物の場合はテストスコープ範囲内、モックはテスト範囲外となる
• 実物を対向テストアイテムとする場合は、バージョンなども定義する • モックを使⽤してテストを実施する場合は、それよりも上位の テストレベルで実物を使⽤してテストを⾏うタイミングを決め る必要がある。
テストデータ • どういったデータでテストを実施するのか • 試験⽤のデータ (機能が検証できる最⼩限のデータ) • 本番運⽤の実際に使⽤する想定のデータ • 実際の運⽤に使⽤していたデータ
テスト技法とカバレッジ基準 • 各テストレベルで使⽤するテスト技法と、満たすカバレッジを 定義しよう • コードカバレッジC0,C1,MC/DC • 境界値分析で2値の境界値 • 状態遷移テストで、0スイッチカバレッジを網羅
• ペアワイズテストで、2ワイズカバレッジ網羅 • ユースケーステストを網羅
テスト実施者 • 誰がテストを⾏うのか • 開発者 • 違う機能を作成していた開発者 • テストのみを⾏うテスト担当者 •
他社のチーム • 海外のチーム • QA • テスト実施する⼈によってテスト⽬的が異なる • 作成したものが開発者の想定通りになっているのかを確認 • システム全体として問題ないことの検証 • 第3者にテストしてもらうことで不具合はより⾒つけやすくなる
テスト観点(テストタイプ) • どのテストレベルでどういったテストを⾏うのか • 使⽤性テスト • 負荷テスト • 移⾏テスト •
性能テスト • 運⽤テスト • 信頼性テスト • セキュリティテスト • どの段階でどういうテストを⾏うのかを決める • アジャイル開発では⼀つのイテレーション内だけではなく、 いつのイテレーションのどのテストレベルでテストを⾏うのかを決めておく
テストレベルの名前 • テストレベルで実施している内容を踏まえて、 メンバ全員で分かりやすい名前をつける • 〇〇テスト • 〇〇統合テスト • 分かりやすい名前を付けておくと、認識ズレも起こりづらい
演習 • 関わっているテストレベルを識別アイテムを使って⽬的を認識 してみよう 時間︓20分間 • 他の上位、下位のテストレベルと何が違うのかを考えよう • ⾃分で⾏っているテストはどんな検証を⾏うことを期待されているのか •
⾏っていないテストとは何が違うのか → 他のテストレベルとの違いからテストの⽬的を考えてみよう • プロジェクト全体としてテストレベルがどう区別されているのか整理 してみよう • 段階はもっと細分化すべきではないのか • 名前を変える
まとめ • テストレベルからテストの⽬的を考えよう • テストレベルをカスタマイズして具体的に定義してみよう • 参考アイテム • テストベース •
テスト環境、テストツール • テスト対象、テストスコープ • テストデータ • テスト技法、カバレッジ基準 • テスト実施者 • テスト観点(テストタイプ)
参考情報 • テスト計画をもっと勉強したい⼈ • IEEE 829-1998 • IEEE 829-2008 •
ISO/IEC/IEEE 29119-3