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