Recommended
More Related Content
What's hot
What's hot (20)
テストの組み立て方
- 1. 2019/6/15 WACATE 2019 Summer 1 テストの組み立て方 WACATE2019 夏
- 2. 自己紹介 • 氏名：なかむら こうじ • あなたとテストの関わり： – テストを考えながら基本設計をしています。 • テストに関する資格： – JSTQB AL TM/TA, JCSQE 中級 • 派閥 – 猫派 2019/6/15 WACATE 2019 Summer 2
- 3. 身に着けてほしいこと • テストの目的を定めて、 目的に対応したテストを行うということ • プロジェクト/プロダクトに合った「品質」 のためのテスト • テストを全部出来ない中で「やりきる」 ためのテスト 2019/6/15 WACATE 2019 Summer 3
- 4. テストに対する制約と向き合う 2019/6/15 WACATE 2019 Summer 4 制約 要求される品質レベル テストに投入できる人数・スキル テストを行う期間 テストに必要な機器・施設 人を殺さない・環境を壊さない 経済的な損失を与えない 不快感を与えない 両者のバランスをとってテストを組み立てることが重要
- 5. テストに対する制約と向き合う 好きなだけいつまでもテストできるわけではない – 時間がない – 予算がない 2019/6/15 WACATE 2019 Summer 5 これくらいまで テスト できるよ ムリぽ！ (/ω＼) 与えられたリソース テスト対象の範囲 ＜
- 6. テストに対する制約と向き合う • そんな時どうする？ – 前から順番にできるとこまでテストする – とりあえず気になったところはテストする • こんなやり方だと・・・ – やっぱり全部はテストできていない さらに – 結局どんな品質が担保されたのか説明できない 2019/6/15 WACATE 2019 Summer 6
- 7. テストに対する制約と向き合う • バランスをとるということは・・・ – 全部できないの仕方ない – その中で何をテストすると価値が高いのか – その中でどうテストすると効率的なのか 2019/6/15 WACATE 2019 Summer 7 その１：全部できないなら「やること」「やらないこと」をはっきり決める その２：「やること」の優先を決めて、「やり方」に濃淡をつける
- 8. テストに対する制約と向き合う テスト対象の優先度をきめたり、 やること／やらないことを明確にするためには、 なんらかの判断基準となる“軸” が必要です。 本セッションではその“軸”となるいくつかの 考え方を紹介していきます。 2019/6/15 WACATE 2019 Summer 8
- 9. テストの目的 2019/6/15 WACATE 2019 Summer 9
- 10. テストの目的 • WACATEの申し込みサイトをテストしてください 2019/6/15 WACATE 2019 Summer 10 ・・・
- 11. テストの目的 • 何を目的とするかでテストすべきことが変わる – 設計書どおりにできているか（設計書ないけど） – 誤字脱字、不適切な表現がないか – 申し込みに必要な情報が網羅されているか – 個人情報が漏洩しないか 2019/6/15 WACATE 2019 Summer 11 目的を“軸”として優先度をつけてテストする範囲を決める
- 12. テストの目的（JSTQB-FL） • 検証（正しく作られているか） – 要件、ユーザーストーリー、設計、およびコードなどを評価する。 – 明確にしたすべての要件を満たしていることを検証する。 – 欠陥の作りこみを防ぐ。 – 故障や欠陥を発見する。 – テスト対象がそのような要件や標準に準拠していることを検証する。 • 妥当性確認（正しいものがつくられているか） – テスト対象が期待通りの動作内容であることの妥当性確認をする。 – テスト対象の品質が所定のレベルにあることを確証する。 – ステークホルダーが意志決定できる、特にテスト対象の品質レベル についての十分な情報を提供する。 – 不適切なソフトウェア品質のリスクレベルを低減する。 2019/6/15 WACATE 2019 Summer 12
- 13. テストの目的もさまざま • 難しく考えずにざっくりとした目的でも有効 例） – 正しく操作したら正しく動くこと – 間違った操作をしたらブロックすること 2019/6/15 WACATE 2019 Summer 13 やらない やる 表裏一体で同じように見えるけど、両方やるかは状況次第
- 14. テストの目的を定める • では、どうやってテスト目的を定めるのか • JSTQBではテストレベルとテストタイプという 観点でテストを構造化して目的を定める • ちなみにISO29119はリスクベースドの考え方なので、 リスクアセスメントに基づいて目的を定める ・・・と思われるけど今回は扱いません 2019/6/15 WACATE 2019 Summer 14
- 15. テストレベル 2019/6/15 WACATE 2019 Summer 15
- 16. テストレベル（JSTQB-FL） • テストレベルは系統的にまとめ、マネジメント していくテストの活動のグループである。 • テストレベルは、以下の属性で特徴付けられる。 – 特定の目的 – テストベース（テストケースの導出時に参照） – テスト対象（すなわち、テストするものは何か） – 典型的な欠陥と故障 – （そのテストレベルでの）アプローチと責務 2019/6/15 WACATE 2019 Summer 16
- 17. テストレベル • なんやよう分からん感じやけど 目的、テストベース、テスト対象、欠陥、 アプローチとかのまとまりを“軸”とする • 目的・・・はさっきやったやつね 2019/6/15 WACATE 2019 Summer 17
- 18. テストレベル • レベル（水準）なんで深さを表すものです • 開発プロセスと関連させて考えます 2019/6/15 WACATE 2019 Summer 18 要件定義 基本設計 詳細設計 実装 コンポーネント テスト 統合テスト システムテスト 要求分析 受け入れテスト レ ベ ル ○○な問題を解決したい システムで△△できる こんな仕組み こんな構造で
- 19. テストレベルを考える • JSTQBで紹介されている４段階が絶対ではない – 開発は何段階に分かれていますか？ • テスト設計のインプットとなる資料は何があるか – テスト対象としてどの単位のテストをしますか？ • クラス／メソッドなどのプログラム／部品単位 • 画面単位／複数画面の連携も含めた機能単位 – どの段階でどのような欠陥を取り除きますか？ • 必須チェックが正しいことはどこで担保するか – 誰がどの環境でテストしますか？ • 開発者はテストするの？どこまで責任持ってもらうの？ 2019/6/15 WACATE 2019 Summer 19
- 20. ワーク • うちではこんなテストレベルがありますよ。 – テストレベル間の違いは何ですか？ • 目的 • テストベース • テスト対象 • 狙っている欠陥 • 誰がどの環境でテストするかとか 2019/6/15 WACATE 2019 Summer 20
- 21. テストタイプ 2019/6/15 WACATE 2019 Summer 21
- 22. テストタイプ（JSTQB-FL） • 特定のテストの目的から見たソフトウェアシステム （あるいはシステムの一部分）の特性をテストする ための活動を束ねたものである。 – 機能の品質特性、例えば完全、正確および適切であること などを評価する。 – 非機能の品質特性、例えば信頼性、性能効率性、セキュリ ティ、互換性、使用性などを評価する。 – コンポーネントまたはシステムの、構造またはアーキテク チャーが正しく完全で仕様通りであることを評価する。 – 欠陥が修正されていることを確認するなどの変更による影 響を評価し（確認テスト）、ソフトウェアや環境の変更に よって意図しない振る舞いの変化が発生していないかを探 す（リグレッションテスト）。 2019/6/15 WACATE 2019 Summer 22
- 24. おっきなところからいくと • 機能／非機能 • 正常系／異常系 • 変更差分／回帰 – 組み合わせてもいいよ 2019/6/15 WACATE 2019 Summer 24 変更差分 回帰 正常系 異常系 正常系 機能 非機能 機能 非機能 機能 非機能
- 25. 例えばISO/IEC 25000シリーズから 2019/6/15 WACATE 2019 Summer 25 システム／ソフトウェア製品品質 機能適合性 機能完全性 機能正確性 機能適切性 性能効率性 時間効率性 資源効率性 容量満足性 互換性 共存性 相互運用性 使用性 適切度認識 性 習得性 運用操作性 ユーザーエラー 防止性 ユーザーインタ フェース快美性 アクセシビリティ 信頼性 成熟性 可用性 障害許容性 回復性 セキュリティ 機密性 インテグリティ 否認防止性 責任追跡性 真正性 保守性 モジュール性 再利用性 解析性 修正性 試験性 移植性 適応性 設置性 置換性
- 26. 他には？ • 非機能要求グレード（IPA） – https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html • プロダクトリスク – 主要なリスクに的を絞ったテストなど • 特定の欠陥を狙ったテスト – 社内の欠陥分析の結果から特定の欠陥を狙うとか 2019/6/15 WACATE 2019 Summer 26 特定の目的に基づいて 複数のテスト対象やテストレベルにまたがったテストが必要
- 27. 所感 • テストタイプって目的の設定次第ですよね？ • 自由度が高い分センスが問われそうですね – 目的の妥当性 – テストタイプとして他と分けて管理する意味があるか – そのテストタイプでテストすべき網羅性が検証可能か 2019/6/15 WACATE 2019 Summer 27
- 28. ワーク • うちではこんなテストタイプありますよ。 • テストタイプの自慢は何ですか？ – 何を狙ったテスト？ – 他のテストとはどういう違いがある？ テストレベルより難しいから要フォロー 2019/6/15 WACATE 2019 Summer 28
- 29. テストレベルとテストタイプ 2019/6/15 WACATE 2019 Summer 29
- 30. 例えばクレジットに対する機能適合性 テストレベルとテストタイプを組み合わせた目的 2019/6/15 WACATE 2019 Summer 30 テストレベル 目的 コンポーネントテスト 金額計算や請求月が設計通りか コンポーネント統合テスト UI上の入力に対して出力が正しいか システムテスト 限度額など他の入力と整合性があるか システム統合テスト 外部APIなどと正しく連携できるか 受け入れテスト 不正な取引をブロックできるか
- 31. テストレベルとテストタイプ テスト対象をテストレベルとテストタイプで分解 2019/6/15 WACATE 2019 Summer 31 テスト対象
- 32. テストレベルとテストタイプ テストレベルは段階的にテストを分割 2019/6/15 WACATE 2019 Summer 32 テスト対象 コンポーネントテスト 統合テスト システムテスト 受け入れテスト
- 33. テストレベルとテストタイプ テストタイプは目的の特性でテストを分割 2019/6/15 WACATE 2019 Summer 33 テスト対象 機能適合性 性能効率性 セキュリティ
- 34. テストレベルとテストタイプ メッシュ状にすることで細かなコントロールができる 2019/6/15 WACATE 2019 Summer 34 テスト対象 コンポーネントテスト 統合テスト システムテスト 受け入れテスト 機能適合性 性能効率性 セキュリティ Must MustMust Want Must Want Want Must Must Want
- 35. ちょっと抽象的すぎるので • 機能適合性テストとか言われてもピンとこない • もっと目的を絞った方がブレない – 入出力の整合性 • A画面の入力とB画面に出力は整合しているか – 基準日の一貫性 • 消費税増税の前後、過去日入力などで税計算は正しい？ – 状態遷移 • 登録→訂正→承認→承認取消…ちゃんと元に戻ってる？ 2019/6/15 WACATE 2019 Summer 35
- 36. まとめ 2019/6/15 WACATE 2019 Summer 36
- 37. テストを組み立てるということ • 目に見えないテストの領域を、 目に見える形で料理できる大きさに切り分ける • 制約によって限られたリソースの中で、 最も価値の高い部分を特定する • やる部分とやらない部分を合意して、 やると決めた部分は網羅的にきっちりやる 2019/6/15 WACATE 2019 Summer 37
- 38. やり方はいろいろあるけど 2019/6/15 WACATE 2019 Summer 38 やること やらないこと 優 先 高 低 がっつりやる！ 死なない程度にやる 不安があってもやらない 範囲と頑張り度合いを説明できて共有できることが大事
Editor's Notes
- マニュアルどおりに常に通り一辺倒のテストをしてたら無駄や過剰が発生する。 毎回、同じ環境で同じ物を作り続けているわけでないなら、バランスを考えて調整を図る必要がある。