2023年01月25日(水): 2022年度版に更新しました
発表場所: SQiP研究会 基礎コース 講演時間: 180分(休憩と質疑応答込み) 対象者: ソフトウェアテストの初学者
ゴール: ソフトウェアテストの全体像を俯瞰して整理できる軸を持つことで、様々なテストの用語がどういった特性の言葉であるか判断きるようになる テストの要素技術に関してのエントリーポイントを把握して、効率よくテストについて学べる下地を持つ
ソフトウェアテストの概観を識るVer. 5.00(2022年度版)2022年12月9日(金)於 日本科学技術連盟ソフトウェア品質管理研究会(SQiP研究会)基礎コース ソフトウェア品質保証基礎 第7回 テスト技術Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 1
View Slide
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 2株式会社ベリサーブ品質保証部プロジェクト推進課 課長 兼 ソフトウェア品質コンサルティング部山﨑 崇 (YAMASAKI Takashi)2001年からセキュリティ対策ベンダーにおいて、さまざまなプロジェクトのソフトウェアテスト活動にQAエンジニアとして従事。その傍ら、さまざまなテストコミュニティに参画し、活動の場を広げる。2015年にベリサーブに入社。現場への技術支援、教育、コンサルテーションなどを担い、少しでも現場が幸せになるように日々奮闘中。主な活動• JaSST東京実行委員会 (’11~)• テスト設計コンテストU-30審査委員 (’16~)• ASTER テストプロセス改善研究会 (’16~)• JSTQB Foundation Level 認定講師 (’12~)など主な著書・訳書• システム開発ジャーナル Vol.10 (共著)• 実践ソフトウェアエンジニアリング 第9版 (共訳)• 開発現場で役立つテスト「超」実践講座 第9回 (著)• テスト技術者資格制度Foundation Level Extensionシラバス アジャイルテスト担当者 (共訳)など主な講演• JaSST’21北陸 基調講演「テストを学び成長する」 🔗• JaSST’17東北 基調講演「テストの極みを目指して」 🔗• JaSST‘15東京 チュートリアル「初心者からの脱出」 🔗• テスト設計コンテストチュートリアルU-30クラス(’17~’19)ちびこん編(’21 🔗)• SQiP研究会 品質保証の基礎コース 第7回「ソフトウェアテストの概観を識る」(’17, ’20~) 🔗• 第14回SPIトワイライトフォーラム「テストプロセス改善モデルの最新動向」 🔗などその他 https://www.linkedin.com/in/yamasaki696/ を参照
Copyright © 2017-2022 Takashi YAMASAKI All right reserved.ありがたいことに日本語で得られるテストの情報は2001年以降爆発的に増加しました「図:テストを主題とした書籍の年別出版数」※著者当人の厳格ではない調査に基づいて作成したもの3
一 方 で は 様 々 な 情 報 の 中 か ら自 分 の 求 め て い る 情 報 を 的 確 に見つけるのが難しいとも言えますCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 4
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 5
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 6
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 7
理解への第一歩は言葉を知ることからCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 8
ユニットテスト統合テストシステムテスト結合テストアルファテストベータテスト機能テスト非機能テスト性能テスト 負荷テスト受け入れテストスモークテストモンキーテスト探索的テストペネトレーションテストセキュリティテストコンパチビリティテストパステストステートメントテストデシジョンテーブルテストテスト設計テスト計画テスト分析テスト実装テスト実行テスト管理テスト報告テストケーステストウェアテストベーステストデータテスト環境テストツールテスト条件テスト戦略テストアプローチテスト技法ブラックボックステストホワイトボックステストグレーボックステストテスト手順ロードテストテスト駆動開発テストフレームワークでもこの業界「●●テスト」や「テスト●●」だらけ…Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 9
「分かることは分けられること」Copyright © 2017-2022 Takashi YAMASAKI All right reserved.「思考・論理・分析 ―「正しく考え、正しく分かること」の論理と実践―」 波頭 亮(著)10
分けるためにも概観できるテストの軸が重要Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストレベルテストプロセステストタイプテストの空間のどこに対しての要素であるかを意識した上でテスト技術などの要素を考える※図はイメージです11
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 12
共通言語としてJSTQB FL 取得のススメCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 13
本日使う道具はこの三点ですCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 14
テスト分析テストタイプテストプロセスシステムテストの自動化非機能テストブラックボックステストこんな感じで、随時気になったキーワードを独断と偏見によって貼り付けていってくださいCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 15
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 16
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 17
Copyright © 2017-2022 Takashi YAMASAKI All right reserved.出典: テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.2.3 エラー、欠陥および故障」より(一部要約)誘因① 納期のプレッシャー誘因② 人間の誤りを犯しやすい性質誘因③ プロジェクト参加者の経験不足または技術不足誘因④ プロジェクト参加者間の誤ったコミュニケーション(要件や設計の誤ったコミュニケーションを含む)誘因⑤ さまざまな複雑さ※ コード、設計、アーキテクチャ、解決すべき根本的な問題, そして/または使用する技術の複雑さ誘因⑥ システム内またはシステム間のインターフェースに対する誤解※ 特に、関連するシステム数が多い場合誘因⑦ 新しく不慣れな技術 など18
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 19
Industry References:3 B. Boehm and V. Basili, "Software Defect Reduction Top 10 List" IEEE Computer Society, Vol. 34, No. 1, Jan 2001リリース後に見つかった欠陥の修正コストは高いCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 20
適合コスト欠陥を回避するためにプロジェクト期間中に支出する金額不適合コスト障害によりプロジェクト期間中および期間後に支出する金額予防コスト品質上の欠陥の発生を早い段階で防止するために支出される欠陥コスト検出コスト製品ないし部品の品質を評価することによって品質レベルを維持するために支出される評価コスト内的障害コスト製品の出荷以前に欠陥や品質不良が発見された場合の処理に付随して発生する内部障害コスト外的障害コスト製品出荷後に市場で欠陥や品質不良が発見された場合の処理に付随して発生する外部障害コスト図:品質コスト / 出典:Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの品質コストCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 21
製品をリリースするまでにかかる品質コスト適合コスト欠陥を回避するためにプロジェクト期間中に支出する金額不適合コスト障害によりプロジェクト期間中および期間後に支出する金額予防コスト品質上の欠陥の発生を早い段階で防止するために支出される欠陥コスト検出コスト製品ないし部品の品質を評価することによって品質レベルを維持するために支出される評価コスト内的障害コスト製品の出荷以前に欠陥や品質不良が発見された場合の処理に付随して発生する内部障害コスト外的障害コスト製品出荷後に市場で欠陥や品質不良が発見された場合の処理に付随して発生する外部障害コストCopyright © 2017-2022 Takashi YAMASAKI All right reserved.図:品質コスト / 出典:Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの22
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 23
”全てのライフサイクルを通じて静的および動的に実施するプロセス。成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、コンポーネントやシステムおよび関連作業成果物に対し、計画、準備、評価をすること。”ISTQB Glossary https://glossary.istqb.org よりCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 24
人によっても違うし成熟度によっても違うし千差万別テストは行動ではない。大げさなテストをすることなく品質の高いソフトウェアを作るための精神的な訓練である。フェーズ4テストの目的は、何かを証明することではなく、プログラムが動かないことによって発生する危険性をある許容範囲までに減らすことである。フェーズ3テストの目的は、ソフトウェアテストが動かないということを示すことにある。フェーズ2テストの目的は、ソフトウェアテストが動くことを示すことである。フェーズ1テストとデバッグには何の差もない。デバッグ以外にはテストには特別な目的はない。フェーズ0ボーリス・バイザー著 「ソフトウェアテスト技法」よりテスト担当者の精神面による区分を引用Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 25
テストの目的も一義的ではないCopyright © 2017-2022 Takashi YAMASAKI All right reserved.要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ明確にしたすべての要件を満たしていることを検証するテスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をするテスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減するステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証するテスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.1.1 テストに共通する目的」より引用26
「品質に関わる新たな情報を得るための諸活動」※以下のテストの目的をすべて満たします欠陥を摘出する対象ソフトウェアの品質レベルが十分であることを確認する意志決定のための情報を示す欠陥の作りこみを防ぐ上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用「テストとは?」を整理するとCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 27
テストの7原則Copyright © 2017-2022 Takashi YAMASAKI All right reserved.欠陥がないことは示せない原則 1全数テストは不可能原則 2早期テストで時間とコストを節約原則 3欠陥の偏在原則 4殺虫剤のパラドックスにご用心原則 5テストは状況次第原則 6「バグゼロ」の落とし穴原則 7テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.3 テストの7原則」より引用テストは欠陥があるこ と は 示 せ る が 、28
早いテストから得られる情報の取得タイミングが早いほど価値が高い安いテストから得られる情報の取得コストが安いほど価値が高い旨いテストから得られる情報がニーズに合致していて正確で分かり易いほど価値が高い本質的にテストの価値は情報取得Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 29
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 30テストを通じて得られた情報によって製品やサービスの品 質 に 対 す る 確 信 度 合 い を 積 み 上 げ て い く逆説的には、テストをしなくて済むのであれば、誰もがそれをしたくないけれども、ソフトウェアの特性や人の特性やソフトウェア開発の背景などから、テストという手段を用いてその結果を見ないことには、リリースしても大丈夫であるかどうかを判断する術がない
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 31テストはテストのみでは存在しえない活動(テストのことだけ考えても意味がない)情報はそれを使うことで意味を持つ
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 32テ ス ト と は 、 テ ス ト と そ れ に 関 係 す るテスト以外のことについても考えに考え抜 い て そ れ ら の 本 質 を 知 る こ と
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 33
分けるためにも概観できるテストの軸が重要Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストレベルテストプロセステストタイプテストの空間のどこに対しての要素であるかを意識した上でテスト技術などの要素を考える※図はイメージです34
テストレベルとは?テストレベルは、系統的にまとめ、マネジメントしていくテストの活動のグループである。Copyright © 2017-2022 Takashi YAMASAKI All right reserved.“具体的にインスタンス化したテストプロセス。“ISTQB Glossary https://glossary.istqb.org よりテスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.2テストレベル」より35
受け入れテスト開発したシステムがユーザの求めているものに合致しているか確認する(受け入れ可能かどうか判断する)テストシステムテスト最終的に統合されたシステム全体を、実環境(またはそれに準ずる環境)で実施するテスト統合テストテスト済みのコンポーネントやシステムを統合して行うテストコンポーネントテスト分離してテストが可能なソフトウェアコンポーネント(部品)ごとに単体で行うテストテスト対象として着目する詳細度小大様々なテストレベルが存在するCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 36
要件定義外部設計内部設計実装テスト実装終わったらテストって乱暴すぎよねCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 37
外部設計内部設計実装要件定義コンポーネントテスト統合テストシステムテスト受け入れテスト対応関係上流工程の開発と下流工程のテストにおける責務との対応関係Copyright © 2017-2022 Takashi YAMASAKI All right reserved.段階的な詳細化段階的な統合38
システム要件基本設計詳細設計実装コンポーネントテストの計画要求定義テスト活動の開始システムテストの計画統合テストの計画コンポーネントテストの実施デバッグと修正統合テストの実施デバッグと修正システムテストの実施デバッグと修正受け入れテストの実施デバッグと修正Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自対応関係 サイクル:テスト、デバッグ、修正、再テストWモデル: テスト活動をフロントローディングすると効果的Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 39
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 40ただ、Wモデルの実践は簡単ではありません湯本さんの記事を読むと少しイメージが湧くかもhttps://note.mu/yumotsuyo/n/n83fee4567b5d
システム要件基本設計詳細設計実装コンポーネントテストの計画要求定義テスト活動の開始システムテストの計画統合テストの計画コンポーネントテストの実施デバッグと修正統合テストの実施デバッグと修正システムテストの実施デバッグと修正受け入れテストの実施デバッグと修正Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自対応関係 サイクル:テスト、デバッグ、修正、再テストWモデル: テスト活動をフロントローディングすると効果的Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 41マスターテスト計画master test planレベルテスト計画level test planレベルテスト計画level test planレベルテスト計画level test planレベルテスト計画level test plan各テストレベルだけではなくテスト全体の絵を描こう
テスト実行の自動化は低いテストレベルから出典:「実践アジャイルテスト」の「テスト自動化のピラミッド」を元に改変・追記GUIテストAPIレベルのテストユニットテスト/コンポーネントテスト手動テスト高低費用対効果保守性難易実行速度遅速Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 42
コンポーネントテストレベルでの自動化テスト駆動開発入門ケント・ベック著/オーム社刊コンポーネントテスト(ユニットテスト)レベルでの自動化は、xUnitなどのテストフレームワークを使うことが多いので、開発言語など自分の状況に合ったものを選択しましょうコンポーネントレベルでは実装とテストを同じ人が担うことも多く、特定のアプローチとしては テ ス ト 開 発 駆 動 (TDD: Test DrivenDevelopment)が有名です各地域のコミュニティーが中心となって全国各地でTDD Boot Camp開催しているので、そこで体験してみるのもお勧めですTDDの提唱者ケント・ベックの書籍。ピアソンショックにより絶版となっていたが、2017年にオーム社からt_wadaさんの新訳で復刊され、入手可能Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 43
統合テストレベルでの自動化継続的インテグレーション入門著者多数/日経BP刊統合テスト(インテグレーションテスト)レベルでの自動化に関しては、CI環境を用いることが一般化してきました継 続 的 イ ン テ グ レ ー シ ョ ン (CI:Continuous Integration)は、日毎、時毎、コミット毎といった短いサイクルでテストを走らすことで、統合に関係する問題を素早く見つけることが目的ですオープンソースではJenkinsが有名ですが商用のCIアプリやサービスなども存在するので自分達にあったものを選択しましょう特定のCI環境に特化したものではなく、概念レベルからしっかりと解説している書籍。特定のCI環境に特化した書籍と合わせて読むと効果的かと。Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 44
システムテストレベルでの自動化シスエムテスト自動化標準ガイドマーク&ドロシー著/翔泳社刊コンポーネントテストや統合テストレベルでのテスト自動化は一般化してきたものの、システムテストレベルはまだまだこれからといった感じですそのシステムテストレベルにおける自動化を扱った書籍が左記のものですまた、この書籍を翻訳したシステムテスト自動化研究会が毎年開催してるシステムテスト自動化カンファレンス(STAC)の資料も公開も参考になりますテスト自動化研究会が翻訳した「Software Test Automation 」。著者はマーク&ドロシー。邦題はシステムテスト全般を指しているように見えるが機能テストの自動化かメイン。Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 45
受け入れテストレベルでの自動化Copyright © 2017-2022 Takashi YAMASAKI All right reserved.継続的デリバリーJez Humble & David Farley 著ASCII DOWANGO刊受け入れテストのテストレベルは、DevOpsやCD ( 継 続 的 デ リ バ リ ー ContinuousDelivery, 継 続 的 デ プ ロ イ メ ン トContinuous Delivery)の領域を考慮します。左の書籍は、継続的デリバリーを主題に扱っています。ソースコードに変更を加えてからデプロイまでの一連の流れを「デプロイメントパイプライン」としてパイプライン化(つまり自動化)することで、アジリティのある開発とリリースを可能にします。46
DevOpsでの継続的テストのループCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 47出典:Dan AshbyのContinuous Testing in DevOpsを引用した書籍「A Practical Guide to Testing in Dev Ops」に翻訳本 P.xiiiDevPLANBRANCHCODEMERGEBUILDOpsRELEASEDEPLOYOPERATEMONITORここでテストここでテストここでテストそしてここでもさらにここでもテスト ここでテストしないの?もちろんできます!ここでもテストさらにここでもテストそしてここももちろん…
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 48テ ス ト レ ベ ル の 本 質 を 考 え て い く とソフトウェア開発ライフサイクルに留まらずソフトウェアライフサイクル全般におけるテストの全体像を考えていくことに繋がる
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 49
分けるためにも概観できるテストの軸が重要Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストレベルテストプロセステストタイプテストの空間のどこに対しての要素であるかを意識した上でテスト技術などの要素を考える※図はイメージです50
テストタイプとは?コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。Copyright © 2017-2022 Takashi YAMASAKI All right reserved.“ISTQB Glossary https://glossary.istqb.org より引用テストタイプは、以下に列挙する特定のテストの目的から見たソフトウェアシステム(あるいはシステムの一部分)の特性をテストするための活動を束ねたものである。テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より引用“51
JSTQBによるテストタイプの分類Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストタイプ機能テスト機能の品質特性、例えば完全、正 確 お よ び 適 切 であ る こ となどを評価する。非機能テスト非機能の品質特性、例えば信頼性、性能効率性、セキュリティ、互換性、使用性などを評価する。ホワイトボックステストコンポーネントまたはシステムの 、 構 造 ま た は ア ー キ テ クチャーが正しく完全で仕様通りであることを評価する。変更関連のテスト欠陥が修正されていることを確認するなどの変更による影響を評価し(確認テスト)、ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す(リグレッションテスト)。52テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。
JIS X 25010:2013 図4「製品品質モデル」より引用システム/ソフトウェア製品品質機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性• 機能完全性• 機能正確性• 機能適切性• 時間効率性• 資源効率性• 容量満足性• 共存性• 相互運用性• 適切度認識性• 習得性• 運用操作性• ユーザエラー防止性• ユーザインターフェース快美性• アクセシビリティ• 成熟性• 可用性• 障害許容性(対故障性)• 回復性• 機密性• インテグリティ• 否認防止性• 責任追跡性• 真正性• モジュール性• 再利用性• 解析性• 修正性• 試験性• 適用性• 設置性• 置換性ISO/IEC 25010の製品品質モデルCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 53
29119-4における品質特性とテストタイプの紐付けテストのタイプ 品質特性 副特性アクセシビリティテスト 使用性 アクセシビリティ互換性テスト 互換性 共存性コンバージョンテスト 機能適合性機能完全性機能正確性機能適切性ディザスタリカバリテスト(復旧災害テスト)信頼性成熟性障害許容性(対故障性)回復性機能テスト 機能適合性機能完全性機能正確性機能適切性設置性テスト 移植性 設置性相互運用性テスト 互換性 相互運用性ローカライゼーションテスト(L10Nテスト)機能適合性機能完全性機能正確性機能適切性使用性適切度認識性習得性運用操作性ユーザエラー防止性ユーザインターフェース快美性アクセシビリティ移植性 適用性保守性テスト 保守性モジュール性再利用性解析性ISO/IEC/IEEE 29119-4:2021 Table A.1 - 「ISO/IEC 25010 製品品質特性とテストタイプの紐付け」より引用 ※翻訳独自Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 54テストのタイプ 品質特性 副特性保守性テスト 保守性モジュール性再利用性解析性修正性試験性性能関連テスト 性能効率性時間効率性資源効率性容量満足性移植性テスト 移植性適用性設置性置換性手順テスト なし なし信頼性テスト 信頼性成熟性可用性障害許容性(対故障性)回復性セキュリティテスト セキュリティ機密性インテグリティ否認防止性責任追跡性真正性使用性テスト 使用性適切度認識性習得性運用操作性ユーザエラー防止性ユーザインターフェース快美性アクセシビリティ
• さまざまなテストを考慮するにあたり、品質モデルの各特性をガイドワードとして利用するのは良いですが、テストの中にすべて押し込むのは乱暴で、テストでは測りがたい特性もあります(たとえば、保守性とか移植性とか)• 前提として品質モデルはテストのためのモデルではないですし、各品質の特性は相関関係があります。そして、すべての品質特性をフル天にすれば良いわけでもありません• 各特性が「どうあるべきか」は、本来的には品質要求として定める必要があり、テストではその要求を満たしているのかを確認することになります• 例えば、時間効率性(パフォーマンス)として、何msの応答であれば妥当であるかは品質要求次第Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 55
品質特性間の相関関係の例Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 56図:品質属性間のプラスとマイナスの相関関係 Karl E.著「ソフトウェア要求 第3版」 P.333より。※なお、デザインに手を入れている可用性効率性導入可能性完全性相互接続性修正可能性性能移植性信頼性再利用性堅牢性安全性拡張性セキュリティユーザビリティ検証可能性可用性 + +効率性 + - - + - - + -導入可能性 + + +完全性 - - - - + + - -相互接続性 + - - - + + + - -修正可能性 + + - - + + + +性能 - - - - - - -移植性 - + - - + - - +信頼性 + - + + - + + + + +再利用性 - - + + - + - +堅牢性 + - + + + - + + + + +安全性 - + + - + + - -拡張性 + + + + + + +セキュリティ + + + - - + + + - -ユーザビリティ - + - - + + + -検証可能性 + + + + + + + + + +
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 57Product QualityFunctionalsuitabilityPerformanceefficiencyCompatibilityInteractioncapabilityReliability Security Maintainability Flexibility SafetyFunctionalcompletenessFunctionalcorrectnessFunctionalappropriatenessAppropriatenessrecognizabilityLearnabilityOperabilityUser errorprotectionUserengagementUserassistanceSelf-descriptivenessTime behaviorResourceutilizationCapacityCo-existenceInteroperabilityConfidentialityNon-repudiationIntegrityAccountabilityAuthenticityResistanceOperationalconstraintRiskidentificationFailsafeHazardwarningSafeintegrationFaultlessnessAvailabilityFaulttoleranceRecoverabilityModularityReusabilityAnalyzabilityModifiabilityTestabilityAdaptabilityScalabilityInstallabilityReplaceability変更新規追加既存凡例図は、現在策定中(まだリリースされていない、ISO/IEC 25010の新しい製品品質モデルの主特性と副特性の案が出典。策定中の情報についてはオフィシャルに表にでていませんが、この規格を策定するワーキンググループのコンビーナ(議長)である込山さんの資料を参照してください。https://speakerdeck.com/washizaki/squareguan-lian-falsebiao-zhun-hua-falsequan-ti-dong-xiang-25010-25019gai-yao-ip-shan-jun-bo製品品質のモデルも、時代と共に改訂を重ねてきており、先ISO/IEC25010:2013も現在絶賛改訂作業中です。また、製品品質以外にも、SQuaREには利用時の品質、データ品質、サービス品質なども規定されていています。
品質はソフトウェアライフサイクル全体を通じて考えましょうCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 58出典: SEC journal Vol.10 No.5 Jan. 2015 「システム・ソフトウェア品質標準SQuaREシリーズの歴史と概要」東基衞 をベースに一部改変
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 59テストタイプを突き詰めていくと開発している製品やサービスに求められていること、それらの存在意義といった根源的なことに繋がる
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 60
分けるためにも概観できるテストの軸が重要Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストレベルテストプロセステストタイプテストの空間のどこに対しての要素であるかを意識した上でテスト技術などの要素を考える※図はイメージです61
テストプロセスとは?Copyright © 2017-2022 Takashi YAMASAKI All right reserved.相互に関連する活動のセット。テスト計画作業、テストモニタリングとコントロール、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了といった活動から構成される。ISTQB Glossary https://glossary.istqb.org より引用“62
テストプロセスの例(JSTQB)テストプロジェクトのタイムラインCopyright © 2017-2022 Takashi YAMASAKI All right reserved.テスト分析テスト設計テスト実装テスト実行テストのモニタリングとコントロールテスト計画テスト完了t63
ISO/IEC/IEEE 29119-2のテストプロセス群ISO/IEC/IEEE 29119-2:2021 P-12 「Figure 2. The multi-layer model showing all test processes」を元に一部表現を変更。翻訳は独自Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストマネジメントプロセス群動的テストプロセス組織的テストプロセス群組織的テストプロセステスト設計と実装プロセステスト環境とデータマネジメントプロセステスト実行プロセステストインシデントレポートプロセステスト戦略と計画プロセステストのモニタリングとコントロールプロセステスト完了プロセス64
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 65出典: ISO/IEC/IEEE 29119-3:2021 P. ix 「Figure 1 Overview of test documentation」。一部要約・改変。翻訳は独自。テストポリシープロジェクトテスト計画書(例:マスターテスト計画など)テストモデル仕様書組織的テストプラクティステストインシデントレポートタイプテスト計画書(例: セキュリティテスト計画など)テストステータスレポートテスト完了レポートテストケース仕様書テスト手順仕様書実際の結果とテスト結果 テスト実行ログテストデータ要件 テストデータ準備レポートテスト環境要件 テスト環境準備レポートレベルテスト計画書(例: システムテスト計画など)
テストツールまるわかりガイドASTERテストツールWG著一連のテストプロセスでは様々な活動があ り 、 効 率 や 効 果 の 観 点 か ら ツ ー ル の活用を検討しましょう左のものは様々なツールの情報をまとめたガイドでありPDF版も公開されています特に、現在のプロセスの習熟度に沿った導入をアドバイスしてくれる診断ツールは面白いので是非試してみてください※テストプロセスの成熟度が低い場合はツールを使っても効果が得られにくいのでまだ利用する段階ではないと言われますテストプロセスを通じてツールの活用も検討Copyright © 2017-2022 Takashi YAMASAKI All right reserved.2020年にVersion 2.0.0が公開されました。「プロプライエタリのテストツールの追加情報やオープンソースのテストツールの情報については、今後は随時、記事投稿を募集し、継続的に改訂していく予定です」(ASTERのWebサイトより) ※左の画像はVersion 1.0.1です66
その他にも様々なテストプロセスモデルが存在しているのでうまく活用しましょう!但し、本質的にはコンテキストに沿ったテストのプロセス設計やテーラリングが必要ですCritical Testing Process(CTP)Systematic Test andEvaluation Process(STEP)Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 67
テストプロセスのためのプロセス改善モデルも色々ありますTPI NEXT2009年(日本語版が2015年9月に発売)ISO/IEC 330632015年8月TMMi Release 1.22018年(version. 1.0は2008年)Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 68
項目 TMMi TPI NEXT ISO/IEC 33063所感CMMIと同等の枠組み。CMMIのテストプロセス部分を補完する。CMMIについて既に経験や知識を持っている組織であれば展開は比較的容易であろう改善提案やコツなどまで含めたガイドとして利用可能。内容が具体的かつ実践的で、現場でのセルフアセスメントなどにも使いやすいものになっていると感じる縦 軸 に ISO/IEC 33020 、 横 軸 にISO/IEC/IEEE 29119-2を持つ新しいテストアセスメントモデル。GP、GR、GWPなどの評価指標が示されているリリース年 2018年(Ver. 1.0は2008年) 2015年8月(原書は2009年) 2015年9月リリース元 TMMi Foundation (非営利団体) Sogeti社 (オランダの企業) ISO/IEC (国際規格)モデルの種別 段階モデル 混合モデル(連続モデルより)※1 連続モデル評価軸 成熟度レベル 成熟度レベル 能力レベル評価の水準数 5段階 4段階 6段階測定対象 プロセス領域 キーエリア プロセス対象数 15 16 8 (+5+α)※2指標 固有/共通のプラクティス チェックポイント評価指標(共通プラクティス/リソース/作業生産物 など)言語 英語のみ 英語/独語/日本語 英語のみ※5(主観的な)特徴 (CMMI)と相似的・補完的 実践的・具体的(これだけで完結) (関連規格と)依存的・汎用的(主観的な)手軽さ 重め 軽め 重めスコープ すべてのテストレベルを対象 主に高位テストレベルを対象 すべてのテストプロセスを対象動的/静的動的テストだけではなく静的テストも対象TPIのキーエリアにあった静的テスト技法と評価が削除された(謎)(オプショナルとして)静的テストを含む※1: TPI NEXTの書籍P-222によれば「混合だが、どちらかと言えば連続表現」との記述あり※2: プ ロ セ ス リ フ ァ レ ン ス モ デ ル で あ る ISO/IEC/IEEE29119-2で定義されているプロセスは8プロセスのみであるが、実践のために5プロセスが追加で示されている。これらはAnnexなどにnormativeとして記述されている※3: ISO/IEC 33063のみでのページ数。関連規格を含めると200ページを超える(Annexを含む)※4: ISO/IEC 33063をJSA Web Storeで購入した場合の金額。関連規格を含めると総額は10万円程となる※5: (2016年3月時点では)JIS化されていない各テストプロセス改善モデルの簡易比較Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 69
テストプロセスの中でも特に重要なのがテストケースを作るまでのイメージを持てること!テスト設計※またはテスト準備、テスト計画など表現は様々テスト実行テスト要求分析テストアーキテクチャ設計テスト詳細設計テスト実装テスト実行テスト分析 テスト設計 テスト実装テスト実行未成熟なテスト開発プロセスJSTQBのテスト開発プロセスTest.SSFのテスト開発プロセスこの部分がテスト開発プロセスCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 70
テ ス ト 技 法 を 勉 強 し て演 習 で は 上 手 く 使 え た の に実 務 で は ど う や っ て 技 法 を適 用 す れ ば 良 い の か 分 か ら ず上手く使えていません(T_T)https://www.pakutaso.com/20141152308post-4790.htmlCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 71
Test DesignTechnicTestBasisTestCasesTestBasisTestCasesTestCasesテ ス ト ベ ー ス※に 対 し て い き な りテ ス ト 技 法 を 適 用 し て い る ?※テストベースとはテストを考える上で入力となる情報全般のこと。例えば要件定義書、仕様書、外部設計書など様々Test Design TechnicsCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 72
Test DesignTechnicTestBasisTestCasesTestBasisTestCasesTestCasesTest Design Technicsそれは失敗フラグですCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 73
JSTQBのテスト開発プロセスのイメージ例テスト手順テストケーステスト条件テストベース文書 A 文書 B 文書 Dテスト設計仕様テスト設計仕様テスト設計仕様テストケース仕様テストケース仕様テストケース仕様テスト手順仕様テスト手順仕様テスト手順仕様テスト手順仕様テストケース仕様テスト手順仕様テスト分析テスト設計テスト実装文書 C「テスト技術者資格制度Foundation Levelシラバス日本語版」を元に図にしたものCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 74
ISO/IEC/IEEE 29119でのテスト開発プロセスイメージISO/IEC/IEEE 29119-2:2021 P.32 Figure 10 Test design and implementation process より引用。翻訳は筆者によるCopyright © 2017-2022 Takashi YAMASAKI All right reserved.テストモデルの作成(TD1)テストカバレッジアイテムの識別(TD2)テストケースの導出(TD3)テスト手順の作成(TD4)テストモデルテストカバレッジアイテムテストケーステスト手順75
テスト設計コンテストのすゝめ特にこの分野は日本がリードしており現在進行形で切磋琢磨している状態。成果物も一部公開されており、具体的に見たい、知りたい人にも最適!OpenクラスとU-30クラスがあるので、若い人の腕試しもできます。また、チュートリアル資料と動画も公開されていますので勉強になります。Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 76画像はNPO法人ASTERのテスト設計コンテストのWebサイトより引用
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 77テストモデルを特定する4つのテストモデルモデルに紐づいたテスト観点テスト観点を詳細化する詳細化されたテスト観点(テストパラメータ)網羅基準を設定する網羅基準テストケース(テスト値)基準に基づいてケースを導出する網羅基準に紐づいたテストパラメータテスト技法テスト観点間の関係性を見出すテストフレーム同じような意味を持つテスト観点やテストフレームをまとめるテストコンテナテストコンテナ間の関連性を整理するテストアーキテクチャテストすべきことを洗い出すテストベース様々なテスト観点テスト観点を構造化する構造化されたテスト観点(中間状態)ドメイン知識/ガイドなどリファインする最終的に構造化されたテスト観点実際に自分たちがテスト開発できるだけの詳 細 度 で プ ロ セ ス を 設 計 し ま し ょ う
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 78ソフトウェアライフサイクルの中で継続的に行っていく各 テ ス ト の 特 徴 を 見 据 え た プ ロ セ ス を 設 計 す る
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 79ライフサイクルの中にパイプラインも構築していくDeployStageTestBuildCommit継続的デリバリー(CD)継続的インテグレーション(CI)継続的デプロイメント(CD)
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 80テ ス ト プ ロ セ ス を 突 き 詰 め て 考 え て い く とテストを実現するためのプロセスだけではなくソフトウェア開発ライフサイクルやソフトウェアライフサイクルとの融合やパイプライン化に繋がる
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 81
テスト技法とは?テスト条件の定義、テストケースの設計、およびテストデータの明確化をするための手続き。Copyright © 2017-2022 Takashi YAMASAKI All right reserved.“ISTQB Glossary https://glossary.istqb.org より引用82
Input Outputブラックボックステストテスト対象の(内部)構造には着目せずにテストケースを導出するテスト技法の総称ホワイトボックステストテスト対象の(内部)構造に着目して、テストケースを導出するテスト技法の総称Input Output昔ながらのテスト技法の分類Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 83
JSTQBによるテスト技法の分類Copyright © 2017-2022 Takashi YAMASAKI All right reserved.ブラックボックステスト技法同値分割法境界値分析デシジョンテーブルテスト状態遷移テストユースケーステストその他ホワイトボックステスト技法ステートメントテストデシジョンテストその他経験ベースのテスト技法その他チェックリストベースドテスト探索的テストエラー推測組み合わせられる 組み合わせられる84
ISO/IEC/IEEE 29119-4:2021 Figure 2. The set of test design techniques presented in this document より引用。翻訳は独自ISO/IEC/IEEE 29119によるテスト技法の分類Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 85ISO/IEC/IEEE 29119で紹介するテスト技法同値分割法クラシフィケーションツリー法境界値分析構文テスト全組み合わせテストペアワイズテストBase choiceテストEach choiceテストデシジョンテーブルテスト原因結果グラフ状態遷移テストメタモルフィックテストステートメントテストブランチテストデシジョンテストブランチコンデション組み合わせテストブランチコンディションテスト改良条件判定カバレッジテストAll-definitions testingAll-p-uses testingAll-c-uses testingAll-du-paths testingAll-uses testingエラー推測仕様に基づいた技法 構造に基づいた技法 経験に基づいた技法組み合せテスト技法シナリオテストデータフローテスト技法の分類は、名称こそ異なるものの、基本的にJSTQB FLと29119-4とでは同じ分類となっている。要件ベースドテスト
探索的テストはテスト技法なの?Copyright © 2017-2022 Takashi YAMASAKI All right reserved.断片的なテストケース チャーター 役割フリースタイルの探索純然たるスクリプト漠然としたスクリプト上図はCem Kaner & James Bach著「The Nature of Exploratory Testing」P.14 より引用。翻訳は筆者によるスクリプトテストテストを実施するにあたってテストケース(スクリプト)を事前に作成し、テストケースに記載されている手順通りに実行するテストの方法で、探索的テストの対義語的に使われることも多いですど こ ま で 詳 細 に ス ク リ プ ト 化 す る か に 幅 があります探索的テスト対象を触ってその反応を観察し、知識・経験・直感を駆使して次のアクションを決めるテストの方法で、テストの設計・実行・学習を同時に行い、フィードバックサイクルを繰り返すのが特徴ですどこまで探索をテスト実行者にゆだねるかに幅がありますVS86
なぜちゃんとテスト設計しなければならないのか?Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 87
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 88
同値分割法同じ結果が得られるグループ(同値パーティション)に分割し、そ の 中 か ら 代 表 値 を テ ス ト ケ ー ス と し て 選 定 し ま すCopyright © 2017-2022 Takashi YAMASAKI All right reserved.代表値ai代表値ck代表値bj89
着目する点 • 等価とみなせる値のグループ(同値パーティション)ポイント• 同 値 パ ー テ ィ シ ョ ン か ら 代 表 値 一 つ を 選 ぶ こ と で 、そのグループの値すべてをテストしたことと等価とみなす• 同値パーティションを考えるときは、有効な値だけでなく、無効な値の同値パーティションも考慮する• 分割する範囲を誤るとテスト漏れが起きる点に注意メリット • より少ないテストケース数で対象範囲を網羅できるキーワード• 同値パーティション(同値クラスとも呼ぶ)• 有効同値パーティション• 無効同値パーティション同値分割法の特徴Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 90
同値分割法のカバレッジCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 9129119-4ではこの技法のカバレッジを以下のように示している。𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 =NT× 𝟏𝟎𝟎 %𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 同値パーティションカバレッジN: 実行したテストケースによってカバーされるパーティション数T: 識別されたパーティションの総数
同値分割の対象に順序性がある場合(数値/時間/順番など)、代表値を任意に選ぶのではなく、同値パーティション間の境界の値をテストケースとして選定します境界値分析Copyright © 2017-2022 Takashi YAMASAKI All right reserved.7 8 24 25パスワードとして適切な長さの有効同値パーティションパスワードとしては短い無効同値パーティションパスワードとしては長すぎる無効同値パーティション0※25文字目は存在しないが、入力を無 効 化 す る 機 能を テス ト す る ため の論理的な値として25文字を上限とする。※文字数が負の数はありえないので0を下限とする有効な境界値 無効な境界値92
着目する点 • 同値パーティションに順序性がある場合の境界近傍ポイント• 欠 陥 が 境 界 付 近 に 埋 め 込 ま れ る こ と が 多 い と い う経験則に基づいている(例:>を≧と誤ってしまう)• 上限や下限が定まっていないなど、範囲が開いている場合はテストとして別途上限と下限を決める必要ありメリット• 少ないテストケースで、よりバグが潜んでいそうな箇所を狙い打てる(同値分割法では見つからない欠陥を見つけられる可能性が高まる)キーワード• 境界値(2値の境界値、3値の境界値)• 下限• 上限境界値分析の特徴Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 93
境界値分析のカバレッジCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 9429119-4ではこの技法のカバレッジを以下のように示している。𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 =NT× 𝟏𝟎𝟎 %𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 境界値分析カバレッジN: 実行したテストケースによってカバーされる明確な境界値の数T: 境界値の総数
1 2 3 4タイムサービス時間内である Y Y Y N対象商品である Y N N -会員である - Y N -15%割引する X - - -5%割引する - X - -割引無し - - X X• デジジョンテーブルテストは、デシジョンテーブルをもとにテストを導出するテスト技法• デシジョンテーブルとは、論理条件(ロジック)の組み合わせとそれに基づく動作を包括的にテーブルとて記述したものデシジョンテーブルテストCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 95
着目する点 • 論理関係(条件の組み合わせによって動作が確定するようなロジックを持つもの。有則や禁則)ポイント • IF文のような判定文をはじめ、論理関係があるものはおしなべてデシジョンテーブルとして表現できるメリット • 複数の条件によって動作が異なるようなロジックを漏れなく整理することができるキーワード• 決定表• テーブルの簡単化(圧縮)デシジョンテーブルテストの特徴Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 96
デシジョンテーブルテストのカバレッジCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 9729119-4ではこの技法のカバレッジを以下のように示している。𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 =NT× 𝟏𝟎𝟎 %𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: デシジョンテーブルテストカバレッジN: 実行したテストケースによってカバーされる、実行可能な判定規則の数T: 実行可能な判定規則の総数
• 状態遷移モデルをもとにテストを導出するテスト技法• 状態遷移モデルは、ソフトウェアの状態と、その遷移に着目したモデルで、UMLのステートマシン図も状態遷移モデルのひとつ• 組込みソフトウェアではよく使われるが、それ以外にもビジネスシナリオのモデル化や、画面遷移なども状態遷移モデルとして整理することもある状態遷移テストCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 98
状態遷移図の例Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 99凡例遷移イベント[ガード条件]/アクション状態終了状態疑似開始状態注1: ガード条件がない場合は、[]とともに省略する。注2: アクションしないか示す必要がない場合は/とともに省略する未登録試用中契約中期限切れ新規登録/有効日数=30日ライセンス確認[有効日数>=0]/有効日数-=1ライセンス購入/有効日数+=365日ライセンス確認[有効日数<0]ライセンス確認[有効日数<0]ライセンス購入/有効日数+=365日ライセンス確認[有効日数>=0]/有効日数-=1ライセンス購入/有効日数+=365日※ ミリーチャート、ムーアチャート、ハレルチャート、UMLのステートマシン図など、状態遷移図の表現はさまざま存在している。本資料ではミリーチャートをベースに独自にカスタマイズした記法を用いている。
状態遷移表の例Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 100イベント遷移前状態新規作成 ライセンス購入ライセンス確認[有効日数<0] [有効日数>=0]未登録有効期間 = 30日試用中 N/A N/A N/A試用中有効日数 += 365 ― 有効日数 -= 1N/A 契約期間中 期限切れ 試用中契約期間中有効日数 += 365 ― 有効日数 -= 1N/A 契約期間中 期限切れ 契約期間中期限切れ有効日数 = 365N/A 契約期間中 N/A N/A※ アクションを省略しているものや、状態×状態で表したものなど、状態遷移表の表現も様々存在している。
着目する点 • テスト対象の状態、状態を遷移するイベントやガード条件、遷移や状態におけるアクションなどポイント• 故障が発生するのは遷移したタイミングとは限らない(例:ある遷移で内部変数を壊しても、故障として現れるのは、壊した内部変数を参照した時になる)• 特定の経路や状態をテストするのか、すべての状態を網羅するのか、遷移を網羅するのか、nスイッチカバレッジを網羅するのかを決定するメリット• 状態遷移モデルにすることで、取り得る経路を整理でき、nスイッチカバレッジなども網羅基準をもとに、テストケースを導出できるキーワード• 状態、遷移、イベント、ガード条件、アクション• 状態遷移表、状態遷移図、ステートマシン図• nスイッチカバレッジ、形式手法/モデル検査状態遷移テストの特徴Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 101
状態遷移テストのカバレッジCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 10229119-4ではこの技法のカバレッジとして次の4つを示している。1. 状態カバレッジ (all states coverage)2. 0スイッチカバレッジ (0-switch coverage)3. 全遷移カバレッジ (all transitions coverage)4. Nスイッチカバレッジ (N-switch coverage)
OS アーキテクチャ ブラウザ1 Windows 10 32bit IE112 Windows 8.1 32bit Chrome3 Windows 7 32bit Firefox4 Windows 10 64bit Edge5 Windows 8.1 64bit IE116 Windows 10 64bit Chrome7 Windows 7 64bit IE108 Windows 8 32bit Chrome9 Windows 8.1 32bit IE1010 Windows 8 64bit Firefox11 Windows 7 64bit Chrome12 Windows 7 32bit IE1113 Windows 8.1 32bit Firefox14 Windows 8 32bit IE1015 Windows 8 64bit IE1116 Windows 10 32bit Firefox17 Windows 10 32bit Edge任意の2因子間に含まれる水準の組み合わせが最低でも1回以上出現するように作られた組み合わせ表の各行をテストケースとして選定します因子OS アーキテクチャ ブラウザ水準Windows 7Windows 8Windows 8.1Windows 1032bit64 bitIE11EdgeChromeFirefox2因子網羅100%とは以下の因子のペアにおいて、因子に含まれる全ての水準の組み合わせが少なくとも1つ以上存在します• OSとアーキテクチャ• OSとブラウザ• アーキテクチャとブラウザ全網羅の場合38通りの組み合わせになりますが、2因子網羅100%で良い場合は17になります※制約: 取り得ない組み合わせは省いていますペアワイズテストCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 103
着目する点 • 意図しない影響を及ぼす組み合わせ(無則)ポイント• 禁則(組み合わせることができないペア)を考慮しないと、実施不可能なテストケースの組み合わせが作られる• 2因子網羅で充分かどうか、3因子網羅でなくともよいかどうかは、別途検討する必要があるメリット• 2因子間網羅100%を可能な限り少ないテストケースで実施できる(組み合わせを現実的な数のテストケース数に圧縮できる)キーワード• 因子(Factors)/水準(Levels)• 制約(とりえない組み合わせ)• n-wiseカバレッジ(n因子網羅)ペアワイズテストの特徴Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 104
ペアワイズテストのカバレッジCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 10529119-4ではこの技法のカバレッジを以下のように示している。𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 =NT× 𝟏𝟎𝟎 %𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: ペアワイズテストカバレッジN: 実行したテストケースによってカバーされる、P-Vペアの数T: ユニークなP-Vペアの総数※P-Vペア(Parameter-Value pair)は組み合わせテストにおけるカバレッジアイテム。ペアワイズテストにおけるPVペアは、2因子間の水準のペア。例えば「Windows7とChrome」という2因子間の水準のペアが1つのP-Vペア
テスト技法を最初に学ぶにはこちらをオススメソフトウェアテスト技法ドリル 第2版秋山浩一著/日科技連出版刊代表的なブラックボックステストの技法を取り扱った書籍。非常に分かり易い文章でお勧め。特に様々な技法を次元という観点でまとめているところが秀逸。はじめて学ぶソフトウェアのテスト技法リー・コープランド著/日経BP刊ブラックボックステストとホワイトボックステストの様々なテスト技法を掲載。いろいろなテスト技法を知るとっかかりとしてお勧め。Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 106
将来的にはこれらの書籍もあたってみましょうソフトウェアテスト技法ボーリス・バイザー著/日経BP刊バイザーによるテスト技法を詳細に説明した書籍。ホワイトボックステストのテスト技法をしっかり学びたいならこれしかない!ブラックボックステストについても書かれている。実践的プログラムテスト入門ボーリス・バイザー著/日経BP刊バイザーのブラックボックステスト本。右の書籍からブラックボックステストのみに特化した書籍。いかんせん、ちょっと右の書籍は読むのがハードな部分もあるので…Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 107
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 108
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 109
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 110
その際にはSQuBOKガイドなどもオススメします全体の軸を持った上でSQuBOKガイドなどを効率よく知識を吸収していけます品質やテストに関する用語で分からないものがあればまずはこれにあたり詳細についてはガイドが示す参考資料をあたるのをオススメします※ ついこの間、第3版にアップグレードされて出版されたので、いまが買い時ですCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 111
Copyright © 2017-2022 Takashi YAMASAKI All right reserved.2. ソフトウェア品質マネジメント 3. ソフトウェア品質技術組織レベルのソフトウェア品質マネジメントプロジェクトレベル(共有)のソフトウェア品質マネジメントプロジェクトレベル(個別)のソフトウェア品質マネジメントGuide to the Software Quality Body of Knowledge (V3)2.1 ソフトウェア品質マネジメントシステムの構築と運用2.1.1 品質マネジメントシステム2.1.2 セキュリティのマネジメント2.2 ライフサイクルプロセスのマネジメント2.2.1 ライフサイクルモデル2.2.2 プロセスモデル2.3 ソフトウェアプロセス評価と改善2.3.1 ソフトウェアプロセス評価モデル2.3.2 ソフトウェアプロセス改善技術2.4 検査のマネジメント2.5 監査のマネジメント2.6 教育および育成のマネジメント2.6.1 スキル標準2.6.2 開発現場における教育および育成のマネジメント2.7 法的権利および法的責任のマネジメント2.8 意思決定のマネジメント2.9 調達のマネジメント2.9.1請負契約による外部委託2.10 リスクマネジメント2.10.1 リスクマネジメントプロセス2.10.2 リスク識別及び特定2.10.3 リスク分析および算定2.10.4 リスク評価および対応2.11 構成管理2.11.1 変更管理2.11.2 バージョン管理2.11.3 不具合管理2.10.4 トレーサビリティ管理2.12 プロジェクトマネジメント2.12.1 PMBOK(プロジェクトマネジメント知識体系)2.12.2 プロジェクトマネジメントに関する規格2.13 品質計画のマネジメント2.14 要求分析のマネジメント2.15 設計のマネジメント2.16 実装のマネジメント2.17 レビューのマネジメント2.18 テストのマネジメント2.18.1 テストプロセス2.18.2 テストの構造2.18.3 テストの計画と遂行2.18.4 テストに関する標準2.19 品質分析および評価のマネジメント2.19.1 プロダクト品質とプロセス品質の分析および評価2.20 リリース判定基準2.21 運用および保守のマネジメント2.21.1 ITIL2.21.2 SLA(サービスレベルアグリーメント)とSLM(サービスレベルマネジメント)2.21.3 サービスマネジメントに関する規格(ISO/IEC 2000シリーズ)2.21.4 保守に関する規格(ISO/IEC 14764)1. ソフトウェア品質の基本概念1.1 品質の概念1.1.1 品質の定義(品質の考え方の変遷)1.1.2 ソフトウェア品質モデル1.2 品質マネジメントの概念1.2.1 品質保証の考え方1.2.2 改善の考え方1.3 ソフトウェアの品質マネジメントの特徴1.3.1 プロダクト品質とプロセス品質1.3.2 品質の作り込み技術の考え方1.3.3 システムおよびソフトウェアの測定と評価の考え方1.3.4 V&V(Verification & Validation)工程に共通なソフトウェア品質技術3.1 メトリクス3.1.1 測定理論3.1.2 プロダクトメトリクス3.1.3 プロセスメトリクス3.2 モデル化の技法3.2.1 制御系のモデル化技法3.2.2 連続的のモデル化技法3.3.3 ドメイン特化言語3.3 形式手法3.3.1 形式仕様記述の技法3.3.2 形式検証の技法工程に個別なソフトウェア品質技術3.4 要求分析の技法3.4.1 要求抽出3.4.2 要求分析3.4.3 要求仕様化3.4.4 要求の妥当性確認と評価3.5 設計の技法3.5.1 方式設計の技法3.5.2 詳細設計の技法3.6 実装の技法3.7 レビューの技法3.7.1 レビュー方法3.7.2 仕様やコードに基づいた技法3.7.3 フォールトに基づいた技法3.7.4 リーディング技法3.8 テストの技法3.8.1 テスト設計技法3.8.2 テスト自動化技法3.9 品質分析および評価の技法3.9.1 信頼性予測に関する技法3.9.2 品質進捗管理に関する技法3.9.3 障害分析に関する技法3.9.4 データ解析と表現に関する技法3.10 運用および保守の技法3.10.1 運用の技法3.10.2 保守の種類と技法4.1 ユーザビリティ4.1.1 ユーザビリティの品質の概念4.1.2 ユーザビリティの技法4.2 セーフティ4.2.1 セーフティの品質の概念4.2.2 セーフティの技法4.2.3 セーフティ・クリティカル・ライフサイクルモデル4.3 セキュリティ4.3.1 セキュリティの品質の概念4.3.2 セキュリティの技法4.4 プライバシー4.4.1 プライバシーの品質の概念4.4.2 プライバシーの技法4. 専門的なソフトウェア品質の概念と技術 5. ソフトウェア品質の応用領域5.1 人工知能システムにおける品質5.1.1 人工知能システムにおける品質の概念5.1.2 人工知能システムの品質マネジメント5.1.3 人工知能システムの品質技術5.2 IoTシスステムにおける品質5.2.1 IoTシスステムにおける品質の概念5.2.2 IoTシスステムの品質マネジメント5.2.3 IoTシスステムの品質技術5.3 アジャイル開発とDevOpsにおける品質5.3.1 アジャイル開発とDevOpsにおける品質の概念5.3.2 アジャイル開発とDevOpsの品質マネジメント5.3.3 アジャイル開発とDevOpsの品質技術5.4 クラウドサービスにおける品質5.4.1 クラウドサービスにおける品質の概念5.4.2 クラウドサービスの品質マネジメント5.4.3 クラウドサービスの品質技術5.5 オープンソフトウェア利用における品質5.5.1 オープンソフトウェア利用における品質の概念5.5.2 オープンソフトウェア利用の品質マネジメント5.5.3 オープンソフトウェア利用の品質技術ソフトウェア品質知識体系ガイド(第3版) ―SQuBOK Guide V3―図1 「樹形図概観(カテゴリ層から副知識領域層までの上位4層)」より112
「品質に関わる新たな情報を得るための諸活動」※以下のテストの目的をすべて満たします欠陥を摘出する対象ソフトウェアの品質レベルが十分であることを確認する意志決定のための情報を示す欠陥の作りこみを防ぐ上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用「テストとは?」を整理するとCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 113
分けるためにも概観できるテストの軸が重要Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストレベルテストプロセステストタイプテストの空間のどこに対しての要素であるかを意識した上でテスト技術などの要素を考える※図はイメージです114
テストプロセスの例(JSTQB)プロジェクトタイムラインCopyright © 2017-2022 Takashi YAMASAKI All right reserved.テスト分析テスト設計テスト実装テスト実行テストのモニタリングとコントロールテスト計画テスト完了115
受け入れテスト開発したシステムがユーザの求めているものに合致しているか確認する(受け入れ可能かどうか判断する)テストシステムテスト最終的に統合されたシステム全体を、実環境(またはそれに準ずる環境)で実施するテスト統合テストテスト済みのコンポーネントやシステムを統合して行うテストコンポーネントテスト分離してテストが可能なソフトウェアコンポーネント(部品)ごとに単体で行うテストテスト対象として着目する詳細度小大様々なテストレベルが存在するCopyright © 2017-2022 Takashi YAMASAKI All right reserved. 116
JSTQBによるテストタイプの分類Copyright © 2017-2022 Takashi YAMASAKI All right reserved.テストタイプ機能テスト機能の品質特性、例えば完全、正 確 お よ び 適 切 であ る こ となどを評価する。非機能テスト非機能の品質特性、例えば信頼性、性能効率性、セキュリティ、互換性、使用性などを評価する。ホワイトボックステストコンポーネントまたはシステムの 、 構 造 ま た は ア ー キ テ クチャーが正しく完全で仕様通りであることを評価する。変更関連のテスト欠陥が修正されていることを確認するなどの変更による影響を評価し(確認テスト)、ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを探す(リグレッションテスト)。117テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。
テストの空間の第1面(テストタイプ×テストレベル)Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 118受け入れテストシステムテスト統合テストコンポーネントテスト機能テストセキュリティテスト相互運用性テスト使用性テスト・・・ホワイトボックステスト変更関連のテスト非機能テスト
テストの空間の第2面(テストプロセス×テストレベル)Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 119受け入れテストシステムテスト統合テストコンポーネントテストテスト計画テスト分析テスト設計テスト実装テスト実行テスト完了テストのM&C
テストの空間の第3面(テストプロセス×テストタイプ)Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 120機能テスト非機能テストセキュリティテスト相互運用性テスト使用性テスト・・・ホワイトボックステスト変更関連のテストテスト計画テスト分析テスト設計テスト実装テスト実行テスト完了テストのM&C
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 121
Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 122
テスターのスキルスペースCopyright © 2017-2022 Takashi YAMASAKI All right reserved.TESTSKILLSDOMAINKNOWLEDGESOFTSKILLSITSKILLSFig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)123
テスト以外の知識も必要ですTESTSKILLSDOMAINKNOWLEDGESOFTSKILLSITSKILLSCopyright © 2017-2022 Takashi YAMASAKI All right reserved.Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)124
主な参考文献・参考資料JSTQB/ISTQB関連• ISTQB Glossary (用語集)• テスト技術者資格制度Advanced Levelシラバス日本語版テストマネージャ• テスト技術者資格制度Foundation Levelシラバス日本語版Version 2018V3.1.J03• JSTQB認定ソフトウェアテスト技術者Foundation Levelトレーニングコース 資料(山﨑崇)ISO/IEC/IEEE 29119• ISO/IEC/IEEE 29119-2:2021 Software testing – Part 2: Test processes• ISO/IEC/IEEE 29119-3:2021 Software testing – Part 3: Test documentation• ISO/IEC/IEEE 29119-4:2021 Software testing – Part 4: Test techniques• ISO/IEC/IEEE 29119 勉強会 第1回 規格の全体構成と各規格の概要 (山﨑崇)• ISO/IEC/IEEE 29119 勉強会 第2回 Part 2 Test Processes (山﨑崇)• ISO/IEC/IEEE 29119 勉強会 第3回 Part3 テストドキュメント (山﨑崇)テストプロセス改善• テストプロセス改善モデルの最新動向 (山﨑崇)その他• JaSST‘15 Tokyo 初心者チュートリアル (山﨑崇)• JaSST’10 Tokyo 初心者セッション (片山徹郎 長谷川聡)主な写真素材Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 125