ソフトウェアテストの概観を識る/Understanding_overview_of_software_testing

2023年01月25日(水): 2022年度版に更新しました

発表場所: SQiP研究会 基礎コース
講演時間: 180分（休憩と質疑応答込み）
対象者: ソフトウェアテストの初学者

ゴール:
ソフトウェアテストの全体像を俯瞰して整理できる軸を持つことで、様々なテストの用語がどういった特性の言葉であるか判断きるようになる
テストの要素技術に関してのエントリーポイントを把握して、効率よくテストについて学べる下地を持つ

Transcript

1. ソフトウェアテストの概観を識る Ver. 5.00（2022年度版） 2022年12月9日(金) 於 日本科学技術連盟 ソフトウェア品質管理研究会（SQiP研究会） 基礎コース ソフトウェア品質保証基礎 第7回 テスト技術 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 1
2. 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/ を参照
3. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. ありがたいことに日本語で得られるテストの 情報は2001年以降爆発的に増加しました 「図：テストを主題とした書籍の年別出版数」※著者当人の厳格ではない調査に基づいて作成したもの 3
4. 一 方 で は 様 々 な 情 報 の 中 か ら 自 分 の 求 め て い る 情 報 を 的 確 に 見つけるのが難しいとも言えます Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 4
5. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 5
6. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 6
7. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 7
8. 理解への第一歩は 言葉を知ることから Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 8
9. ユニットテスト 統合テスト システムテスト 結合テスト アルファテスト ベータテスト 機能テスト 非機能テスト 性能テスト 負荷テスト 受け入れテスト スモークテスト モンキーテスト 探索的テスト ペネトレーションテスト セキュリティテスト コンパチビリティテスト パステスト ステートメントテスト デシジョンテーブルテスト テスト設計 テスト計画 テスト分析 テスト実装 テスト実行 テスト管理 テスト報告 テストケース テストウェア テストベース テストデータ テスト環境 テストツール テスト条件 テスト戦略 テストアプローチ テスト技法 ブラックボックステスト ホワイトボックステスト グレーボックステスト テスト手順 ロードテスト テスト駆動開発 テストフレームワーク でもこの業界「••テスト」や「テスト••」だらけ… Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 9
10. 「分かることは分けられること」 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 「思考・論理・分析 ―「正しく考え、正しく分かること」の論理と実践―」 波頭 亮(著) 10
11. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに対しての 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです 11
12. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 12
13. 共通言語としてJSTQB FL 取得のススメ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 13
14. 本日使う道具はこの三点です Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 14
15. テスト分析 テストタイプ テストプロセス システムテストの 自動化 非機能テスト ブラックボックス テスト こんな感じで、随時 気になったキーワードを 独断と偏見によって貼り付けて いってください Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 15
16. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 16
17. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 17
18. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 出典： テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.2．3 エラー、欠陥および故障」より（一部要約） 誘因① 納期のプレッシャー 誘因② 人間の誤りを犯しやすい性質 誘因③ プロジェクト参加者の経験不足または技術不足 誘因④ プロジェクト参加者間の誤ったコミュニケーション （要件や設計の誤ったコミュニケーションを含む） 誘因⑤ さまざまな複雑さ ※ コード、設計、アーキテクチャ、解決すべき根本的な問題, そして/または使用する技術の複雑さ 誘因⑥ システム内またはシステム間のインターフェースに対する誤解 ※ 特に、関連するシステム数が多い場合 誘因⑦ 新しく不慣れな技術 など 18
19. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 19
20. 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
21. 適合コスト 欠陥を回避するためにプロジェクト 期間中に支出する金額 不適合コスト 障害によりプロジェクト期間中 および期間後に支出する金額 予防コスト 品質上の欠陥の発生を早い段階で 防止するために支出される欠陥コスト 検出コスト 製品ないし部品の品質を評価する ことによって品質レベルを維持する ために支出される評価コスト 内的障害コスト 製品の出荷以前に欠陥や品質不良が 発見された場合の処理に付随して 発生する内部障害コスト 外的障害コスト 製品出荷後に市場で欠陥や品質不良が 発見された場合の処理に付随して 発生する外部障害コスト 図：品質コスト / 出典：Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの 品質コスト Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 21
22. 製品をリリースするまでにかかる品質コスト 適合コスト 欠陥を回避するためにプロジェクト 期間中に支出する金額 不適合コスト 障害によりプロジェクト期間中 および期間後に支出する金額 予防コスト 品質上の欠陥の発生を早い段階で 防止するために支出される欠陥コスト 検出コスト 製品ないし部品の品質を評価する ことによって品質レベルを維持する ために支出される評価コスト 内的障害コスト 製品の出荷以前に欠陥や品質不良が 発見された場合の処理に付随して 発生する内部障害コスト 外的障害コスト 製品出荷後に市場で欠陥や品質不良が 発見された場合の処理に付随して 発生する外部障害コスト Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 図：品質コスト / 出典：Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの 22
23. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 23
24. ”全てのライフサイクルを通じて静的および動的に実施 するプロセス。成果物が特定の要件を満足するかを判 定し、目的に合致することを実証し、欠陥を見つけるた め、コンポーネントやシステムおよび関連作業成果物に 対し、計画、準備、評価をすること。” ISTQB Glossary https://glossary.istqb.org より Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 24
25. 人によっても違うし成熟度によっても違うし千差万別 テストは行動ではない。大げさなテストをすることなく品質の 高いソフトウェアを作るための精神的な訓練である。 フェーズ4 テストの目的は、何かを証明することではなく、プログラムが 動かないことによって発生する危険性をある許容範囲までに 減らすことである。 フェーズ3 テストの目的は、ソフトウェアテストが 動かないということを示すことにある。 フェーズ2 テストの目的は、ソフトウェアテストが 動くことを示すことである。 フェーズ1 テストとデバッグには何の差もない。 デバッグ以外にはテストには特別な目的はない。 フェーズ0 ボーリス・バイザー著 「ソフトウェアテスト技法」よりテスト担当者の精神面による区分を引用 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 25
26. テストの目的も一義的ではない Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することに よって欠陥を防ぐ 明確にしたすべての要件を満たしていることを検証する テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通 りの動作内容であることの妥当性確認をする テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分 な情報を提供する 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象 がそのような要件や標準に準拠していることを検証する テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.1.1 テストに共通する目的」より引用 26
27. 「品質に関わる新たな 情報を得るための諸活動」 ※以下のテストの目的をすべて満たします 欠陥を摘出する 対象ソフトウェアの 品質レベルが十分で あることを確認する 意志決定のための 情報を示す 欠陥の作り こみを防ぐ 上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 「テストとは？」を整理すると Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 27
28. テストの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
29. 早 い テストから得られる情報の 取得タイミングが早いほど価値が高い 安 い テストから得られる情報の 取得コストが安いほど価値が高い 旨 い テストから得られる情報がニーズに合致 していて正確で分かり易いほど価値が高い 本質的にテストの価値は情報取得 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 29
30. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 30 テストを通じて得られた情報によって製品やサービスの 品 質 に 対 す る 確 信 度 合 い を 積 み 上 げ て い く 逆説的には、テストをしなくて済むのであれば、誰もがそれをしたくないけれども、ソフトウェアの特性や人の特性やソフト ウェア開発の背景などから、テストという手段を用いてその結果を見ないことには、リリースしても大丈夫であるかどうかを 判断する術がない
31. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 31 テストはテストのみでは存在しえない活動 （テストのことだけ考えても意味がない） 情報はそれを使うことで意味を持つ
32. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 32 テ ス ト と は 、 テ ス ト と そ れ に 関 係 す る テスト以外のことについても考えに考え 抜 い て そ れ ら の 本 質 を 知 る こ と
33. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 33
34. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに対しての 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです 34
35. テストレベルとは？ テストレベルは、系統的にまとめ、マネジメント していくテストの活動のグループである。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. “ 具体的にインスタンス化したテストプロセス。 “ ISTQB Glossary https://glossary.istqb.org より テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.2テストレベル」より 35
36. 受け入れテスト 開発したシステムがユーザの求めているものに合致して いるか確認する（受け入れ可能かどうか判断する）テスト システムテスト 最終的に統合されたシステム全体を、実環境 （またはそれに準ずる環境）で実施するテスト 統合テスト テスト済みのコンポーネントや システムを統合して行うテスト コンポーネントテスト 分離してテストが可能なソフトウェアコンポーネント （部品）ごとに単体で行うテスト テ ス ト 対 象 と し て 着 目 す る 詳 細 度 小 大 様々なテストレベルが存在する Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 36
37. 要件定義 外部設計 内部設計 実装 テスト 実装終わったらテストって乱暴すぎよね Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 37
38. 外部設計 内部設計 実装 要件定義 コンポーネント テスト 統合テスト システムテスト 受け入れテスト 対応関係 上流工程の開発と下流工程のテストにおける責務との対応関係 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 段 階 的 な 詳 細 化 段 階 的 な 統 合 38
39. システム 要件 基本設計 詳細設計 実装 コンポーネント テストの計画 要求定義 テスト活動の 開始 システムテスト の計画 統合テストの 計画 コンポーネント テストの実施 デバッグと修正 統合テストの 実施 デバッグと修正 システムテスト の実施 デバッグと修正 受け入れテスト の実施 デバッグと修正 Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自 対応関係 サイクル:テスト、デバッグ、修正、再テスト Wモデル: テスト活動をフロントローディングすると効果的 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 39
40. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 40 ただ、Wモデルの実践は簡単ではありません 湯本さんの記事を読むと少しイメージが湧くかも https://note.mu/yumotsuyo/n/n83fee4567b5d
41. システム 要件 基本設計 詳細設計 実装 コンポーネント テストの計画 要求定義 テスト活動の 開始 システムテスト の計画 統合テストの 計画 コンポーネント テストの実施 デバッグと修正 統合テストの 実施 デバッグと修正 システムテスト の実施 デバッグと修正 受け入れテスト の実施 デバッグと修正 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 各テストレベルだけではなくテスト全体の絵を描こう
42. テスト実行の自動化は低いテストレベルから 出典：「実践アジャイルテスト」の「テスト自動化のピラミッド」を元に改変・追記 GUI テスト APIレベルの テスト ユニットテスト/ コンポーネントテスト 手動テスト 高 低 費 用 対 効 果 保 守 性 難 易 実 行 速 度 遅 速 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 42
43. コンポーネントテストレベルでの自動化 テスト駆動開発入門 ケント・ベック著/オーム社刊 コンポーネントテスト(ユニットテスト)レベルで の自動化は、xUnitなどのテストフレームワー クを使うことが多いので、開発言語など自分の 状況に合ったものを選択しましょう コンポーネントレベルでは実装とテストを同じ 人が担うことも多く、特定のアプローチとして は テ ス ト 開 発 駆 動 (TDD: Test Driven Development)が有名です 各地域のコミュニティーが中心となって全国各 地でTDD Boot Camp開催しているので、そ こで体験してみるのもお勧めです TDDの提唱者ケント・ベックの書籍。ピアソンショックにより絶版となってい たが、2017年にオーム社からt_wadaさんの新訳で復刊され、入手可能 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 43
44. 統合テストレベルでの自動化 継続的インテグレーション入門 著者多数/日経BP刊 統合テスト(インテグレーションテスト)レベル での自動化に関しては、CI環境を用いるこ とが一般化してきました 継 続 的 イ ン テ グ レ ー シ ョ ン (CI: Continuous Integration)は、日毎、時 毎、コミット毎といった短いサイクルでテスト を走らすことで、統合に関係する問題を 素早く見つけることが目的です オープンソースではJenkinsが有名ですが 商用のCIアプリやサービスなども存在する ので自分達にあったものを選択しましょう 特定のCI環境に特化したものではなく、概念レベルからしっかりと解説して いる書籍。特定のCI環境に特化した書籍と合わせて読むと効果的かと。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 44
45. システムテストレベルでの自動化 シスエムテスト自動化標準ガイド マーク&ドロシー著/翔泳社刊 コンポーネントテストや統合テストレベルでの テスト自動化は一般化してきたものの、システ ムテストレベルはまだまだこれからといった感 じです そのシステムテストレベルにおける自動化を 扱った書籍が左記のものです また、この書籍を翻訳したシステムテスト自動 化研究会が毎年開催してるシステムテスト自動 化カンファレンス（STAC）の資料も公開も参考 になります テスト自動化研究会が翻訳した「Software Test Automation 」。著者は マーク&ドロシー。邦題はシステムテスト全般を指しているように見えるが機 能テストの自動化かメイン。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 45
46. 受け入れテストレベルでの自動化 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 継続的デリバリー Jez Humble & David Farley 著 ASCII DOWANGO刊 受け入れテストのテストレベルは、DevOpsや CD （ 継 続 的 デ リ バ リ ー Continuous Delivery, 継 続 的 デ プ ロ イ メ ン ト Continuous Delivery）の領域を考慮しま す。 左の書籍は、継続的デリバリーを主題に扱って います。 ソースコードに変更を加えてからデプロイまで の一連の流れを「デプロイメントパイプライン」 としてパイプライン化（つまり自動化）すること で、アジリティのある開発とリリースを可能に します。 46
47. 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.xiii Dev PLAN BRANCH CODE MERGE BUILD Ops RELEASE DEPLOY OPERATE MONITOR ここで テスト ここで テスト ここで テスト そして ここでも さらに ここでもテスト ここでテストしないの？ もちろんできます！ ここでも テスト さらに ここでも テスト そして ここも もちろん…
48. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 48 テ ス ト レ ベ ル の 本 質 を 考 え て い く と ソフトウェア開発ライフサイクルに留まらず ソフトウェアライフサイクル全般における テストの全体像を考えていくことに繋がる
49. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 49
50. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに対しての 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです 50
51. テストタイプとは？ コンポーネントやシステムのある特性に対応したテスト の目的を基にテスト活動をまとめたもの。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. “ ISTQB Glossary https://glossary.istqb.org より引用 テストタイプは、以下に列挙する特定のテストの目的か ら見たソフトウェアシステム（あるいはシステムの一部 分）の特性をテストするための活動を束ねたものである。 テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より引用 “ 51
52. JSTQBによるテストタイプの分類 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストタイプ 機能テスト 機能の品質特性、例えば完全、 正 確 お よ び 適 切 であ る こ と などを評価する。 非機能テスト 非機能の品質特性、例えば信頼 性、性能効率性、セキュリティ、 互換性、使用性などを評価する。 ホワイトボックス テスト コンポーネントまたはシステム の 、 構 造 ま た は ア ー キ テ ク チャーが正しく完全で仕様通り であることを評価する。 変更関連のテスト 欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、 ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを 探す（リグレッションテスト）。 52 テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。
53. JIS X 25010:2013 図4「製品品質モデル」より引用 システム/ソフトウェア製品品質 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 • 機能完全性 • 機能正確性 • 機能適切性 • 時間効率性 • 資源効率性 • 容量満足性 • 共存性 • 相互運用性 • 適切度認識性 • 習得性 • 運用操作性 • ユーザエラー 防止性 • ユーザイン ターフェース 快美性 • アクセシビリ ティ • 成熟性 • 可用性 • 障害許容性 (対故障性) • 回復性 • 機密性 • インテグリ ティ • 否認防止性 • 責任追跡性 • 真正性 • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性 • 適用性 • 設置性 • 置換性 ISO/IEC 25010の製品品質モデル Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 53
54. 29119-4における品質特性とテストタイプの紐付け テストのタイプ 品質特性 副特性 アクセシビリティテスト 使用性 アクセシビリティ 互換性テスト 互換性 共存性 コンバージョンテスト 機能適合性 機能完全性 機能正確性 機能適切性 ディザスタリカバリテスト （復旧災害テスト） 信頼性 成熟性 障害許容性(対故障性) 回復性 機能テスト 機能適合性 機能完全性 機能正確性 機能適切性 設置性テスト 移植性 設置性 相互運用性テスト 互換性 相互運用性 ローカライゼーションテスト （L10Nテスト） 機能適合性 機能完全性 機能正確性 機能適切性 使用性 適切度認識性 習得性 運用操作性 ユーザエラー防止性 ユーザインターフェー ス快美性 アクセシビリティ 移植性 適用性 保守性テスト 保守性 モジュール性 再利用性 解析性 ISO/IEC/IEEE 29119-4：2021 Table A.1 - 「ISO/IEC 25010 製品品質特性とテストタイプの紐付け」より引用 ※翻訳独自 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 54 テストのタイプ 品質特性 副特性 保守性テスト 保守性 モジュール性 再利用性 解析性 修正性 試験性 性能関連テスト 性能効率性 時間効率性 資源効率性 容量満足性 移植性テスト 移植性 適用性 設置性 置換性 手順テスト なし なし 信頼性テスト 信頼性 成熟性 可用性 障害許容性(対故障性) 回復性 セキュリティテスト セキュリティ 機密性 インテグリティ 否認防止性 責任追跡性 真正性 使用性テスト 使用性 適切度認識性 習得性 運用操作性 ユーザエラー防止性 ユーザインターフェー ス快美性 アクセシビリティ
55. • さまざまなテストを考慮するにあたり、品質モデルの各特性をガイ ドワードとして利用するのは良いですが、テストの中にすべて押し 込むのは乱暴で、テストでは測りがたい特性もあります（たとえば、 保守性とか移植性とか） • 前提として品質モデルはテストのためのモデルではないですし、各 品質の特性は相関関係があります。そして、すべての品質特性をフ ル天にすれば良いわけでもありません • 各特性が「どうあるべきか」は、本来的には品質要求として定める 必要があり、テストではその要求を満たしているのかを確認するこ とになります • 例えば、時間効率性（パフォーマンス）として、何msの応答であれば妥当である かは品質要求次第 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 55
56. 品質特性間の相関関係の例 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 56 図：品質属性間のプラスとマイナスの相関関係 Karl E.著「ソフトウェア要求 第3版」 P.333より。※なお、デザインに手を入れている 可 用 性 効 率 性 導 入 可 能 性 完 全 性 相 互 接 続 性 修 正 可 能 性 性 能 移 植 性 信 頼 性 再 利 用 性 堅 牢 性 安 全 性 拡 張 性 セ キ ュ リ テ ィ ユ ー ザ ビ リ テ ィ 検 証 可 能 性 可用性 ＋ ＋ 効率性 ＋ － － ＋ － － ＋ － 導入可能性 ＋ ＋ ＋ 完全性 － － － － ＋ ＋ － － 相互接続性 ＋ － － － ＋ ＋ ＋ － － 修正可能性 ＋ ＋ － － ＋ ＋ ＋ ＋ 性能 － － － － － － － 移植性 － ＋ － － ＋ － － ＋ 信頼性 ＋ － ＋ ＋ － ＋ ＋ ＋ ＋ ＋ 再利用性 － － ＋ ＋ － ＋ － ＋ 堅牢性 ＋ － ＋ ＋ ＋ － ＋ ＋ ＋ ＋ ＋ 安全性 － ＋ ＋ － ＋ ＋ － － 拡張性 ＋ ＋ ＋ ＋ ＋ ＋ ＋ セキュリティ ＋ ＋ ＋ － － ＋ ＋ ＋ － － ユーザビリティ － ＋ － － ＋ ＋ ＋ － 検証可能性 ＋ ＋ ＋ ＋ ＋ ＋ ＋ ＋ ＋ ＋
57. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 57 Product Quality Functional suitability Performance efficiency Compatibility Interaction capability Reliability Security Maintainability Flexibility Safety Functional completeness Functional correctness Functional appropriateness Appropriateness recognizability Learnability Operability User error protection User engagement User assistance Self- descriptiveness Time behavior Resource utilization Capacity Co-existence Interoperability Confidentiality Non- repudiation Integrity Accountability Authenticity Resistance Operational constraint Risk identification Failsafe Hazard warning Safe integration Faultlessness Availability Fault tolerance Recoverability Modularity Reusability Analyzability Modifiability Testability Adaptability Scalability Installability Replaceability 変更 新規追加 既存 凡例 図は、現在策定中（まだリリースされていない、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には利用時の品質、 データ品質、サービス品質なども規定されていています。
58. 品質はソフトウェアライフサイクル全体を通じて考えましょう Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 58 出典： SEC journal Vol.10 No.5 Jan. 2015 「システム・ソフトウェア品質標準SQuaREシリーズの歴史と概要」東基衞 をベースに一部改変
59. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 59 テストタイプを突き詰めていくと開発している 製品やサービスに求められていること、それら の存在意義といった根源的なことに繋がる
60. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 60
61. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに対しての 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです 61
62. テストプロセスとは？ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 相互に関連する活動のセット。テスト計画作業、 テストモニタリングとコントロール、テスト分析、 テスト設計、テスト実装、テスト実行、テスト完了 といった活動から構成される。 ISTQB Glossary https://glossary.istqb.org より引用 “ 62
63. テストプロセスの例（JSTQB） テストプロジェクトのタイムライン Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 t 63
64. 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
65. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 65 出典： ISO/IEC/IEEE 29119-3:2021 P. ix 「Figure 1 Overview of test documentation」。一部要約・改変。翻訳は独自。 テストポリシー プロジェクトテスト計画書 （例：マスターテスト計画など） テストモデル仕様書 組織的テストプラクティス テストインシデントレポート タイプテスト計画書 （例： セキュリティテスト計画など） テストステータスレポート テスト完了レポート テストケース仕様書 テスト手順仕様書 実際の結果とテスト結果 テスト実行ログ テストデータ要件 テストデータ準備レポート テスト環境要件 テスト環境準備レポート レベルテスト計画書 （例： システムテスト計画など）
66. テストツールまるわかりガイド ASTERテストツールWG著 一連のテストプロセスでは様々な活動が あ り 、 効 率 や 効 果 の 観 点 か ら ツ ー ル の 活用を検討しましょう 左のものは様々なツールの情報をまとめた ガイドでありPDF版も公開されています 特に、現在のプロセスの習熟度に沿った 導入をアドバイスしてくれる診断ツールは 面白いので是非試してみてください ※テストプロセスの成熟度が低い場合は ツールを使っても効果が得られにくいので まだ利用する段階ではないと言われます テストプロセスを通じてツールの活用も検討 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 2020年にVersion 2.0.0が公開されました。「プロプライエタリのテス トツールの追加情報やオープンソースのテストツールの情報については、 今後は随時、記事投稿を募集し、継続的に改訂していく予定です」 （ASTERのWebサイトより） ※左の画像はVersion 1.0.1です 66
67. その他にも様々なテストプロセスモデルが 存在しているのでうまく活用しましょう！ 但し、本質的にはコンテキストに沿ったテストのプロセス設計やテーラリングが必要です Critical Testing Process (CTP) Systematic Test and Evaluation Process(STEP) Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 67
68. テストプロセスのためのプロセス改善モデルも色々あります TPI NEXT 2009年 (日本語版が2015年9月に発売) ISO/IEC 33063 2015年8月 TMMi Release 1.2 2018年 (version. 1.0は2008年) Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 68
69. 項目 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/IEEE 29119-2で定義されているプロセスは８プロセスのみであ るが、実践のために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
70. テストプロセスの中でも特に重要なのが テストケースを作るまでのイメージを持てること！ テスト設計※またはテスト準備、テスト計画など表現は様々 テスト 実行 テスト 要求分析 テスト ｱｰｷﾃｸﾁｬ 設計 テスト 詳細設計 テスト 実装 テスト 実行 テスト分析 テスト設計 テスト実装 テスト 実行 未成熟な テスト開発 プロセス JSTQBの テスト開発 プロセス Test.SSFの テスト開発 プロセス この部分がテスト開発プロセス Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 70
71. テ ス ト 技 法 を 勉 強 し て 演 習 で は 上 手 く 使 え た の に 実 務 で は ど う や っ て 技 法 を 適 用 す れ ば 良 い の か 分 か ら ず 上手く使えていません(T_T) https://www.pakutaso.com/20141152308post-4790.html Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 71
72. Test Design Technic Test Basis Test Cases Test Basis Test Cases Test Cases テ ス ト ベ ー ス ※ に 対 し て い き な り テ ス ト 技 法 を 適 用 し て い る ？ ※テストベースとはテストを考える上で入力となる情報全般のこと。例えば要件定義書、仕様書、外部設計書など様々 Test Design Technics Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 72
73. Test Design Technic Test Basis Test Cases Test Basis Test Cases Test Cases Test Design Technics それは失敗フラグです Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 73
74. JSTQBのテスト開発プロセスのイメージ例 テスト手順 テストケース テスト条件 テストベース 文書 A 文書 B 文書 D テスト設計 仕様 テスト設計 仕様 テスト設計 仕様 テストケース 仕様 テストケース 仕様 テストケース 仕様 テスト 手順仕様 テスト 手順仕様 テスト 手順仕様 テスト 手順仕様 テストケース 仕様 テスト 手順仕様 テスト 分析 テスト 設計 テスト 実装 文書 C 「テスト技術者資格制度Foundation Levelシラバス日本語版」を元に図にしたもの Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 74
75. 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
76. テスト設計コンテストのすゝめ 特にこの分野は日本がリードしており現在進行形で切磋琢磨している状態。 成果物も一部公開されており、具体的に見たい、知りたい人にも最適！ OpenクラスとU-30クラスがあるので、若い人の腕試しもできます。 また、チュートリアル資料と動画も公開されていますので勉強になります。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 76 画像はNPO法人ASTERのテスト設計コンテストのWebサイトより引用
77. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 77 テスト モデルを 特定する 4つの テスト モデル モデルに 紐づいた テスト観点 テスト 観点を 詳細化 する 詳細化された テスト観点 (テストパラメータ) 網羅 基準を 設定する 網羅基準 テストケース (テスト値) 基準に 基づいて ケースを 導出する 網羅基準に 紐づいた テスト パラメータ テスト技法 テスト 観点間の 関係性を 見出す テスト フレーム 同じような 意味を持つ テスト観点や テストフレーム をまとめる テスト コンテナ テスト コンテナ間の 関連性を 整理する テスト アーキテクチャ テスト すべきことを 洗い出す テストベース 様々な テスト観点 テスト観点を 構造化する 構造化された テスト観点 (中間状態) ドメイン知識/ ガイドなど リファイン する 最終的に 構造化された テスト観点 実際に自分たちがテスト開発できるだけの 詳 細 度 で プ ロ セ ス を 設 計 し ま し ょ う
78. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 78 ソフトウェアライフサイクルの中で継続的に行っていく 各 テ ス ト の 特 徴 を 見 据 え た プ ロ セ ス を 設 計 す る
79. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 79 ライフサイクルの中にパイプラインも構築していく Deploy Stage Test Build Commit 継続的デリバリー（CD） 継続的インテグレーション（CI） 継続的デプロイメント（CD）
80. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 80 テ ス ト プ ロ セ ス を 突 き 詰 め て 考 え て い く と テストを実現するためのプロセスだけではなく ソフトウェア開発ライフサイクルやソフトウェアライ フサイクルとの融合やパイプライン化に繋がる
81. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 81
82. テスト技法とは？ テスト条件の定義、テストケース の設計、およびテストデータの明 確化をするための手続き。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. “ ISTQB Glossary https://glossary.istqb.org より引用 82
83. Input Output ブラックボックステスト テスト対象の(内部)構造には着目せ ずにテストケースを導出するテスト 技法の総称 ホワイトボックステスト テスト対象の(内部)構造に着目して、 テストケースを導出するテスト技法 の総称 Input Output 昔ながらのテスト技法の分類 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 83
84. JSTQBによるテスト技法の分類 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. ブラックボックステスト技法 同値分割法 境界値分析 ﾃﾞｼｼﾞｮﾝﾃｰﾌﾞﾙﾃｽﾄ 状態遷移テスト ユースケーステスト その他 ホワイトボックステスト技法 ステートメントテスト デシジョンテスト その他 経験ベースのテスト技法 その他 ﾁｪｯｸﾘｽﾄﾍﾞｰｽﾄﾞﾃｽﾄ 探索的テスト エラー推測 組み合わせられる 組み合わせられる 84
85. 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. 85 ISO/IEC/IEEE 29119で 紹介するテスト技法 同値分割法 クラシフィケーションツリー法 境界値分析 構文テスト 全組み合わせテスト ペアワイズテスト Base choiceテスト Each choiceテスト デシジョンテーブルテスト 原因結果グラフ 状態遷移テスト メタモルフィックテスト ステートメントテスト ブランチテスト デシジョンテスト ブランチコンデション 組み合わせテスト ブランチコンディションテスト 改良条件判定カバレッジテスト All-definitions testing All-p-uses testing All-c-uses testing All-du-paths testing All-uses testing エラー推測 仕様に基づいた技法 構造に基づいた技法 経験に基づいた技法 組み合せテスト技法 シナリオテスト データフローテスト 技法の分類は、名称こそ異なるものの、基本的に JSTQB FLと29119-4とでは同じ分類となっている。 要件ベースドテスト
86. 探索的テストはテスト技法なの？ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 断片的な テストケース チャーター 役割 フリースタイルの探索 純然たる スクリプト 漠然とした スクリプト 上図はCem Kaner & James Bach著「The Nature of Exploratory Testing」P.14 より引用。翻訳は筆者による スクリプトテスト テストを実施するにあたってテストケース（スクリ プト）を事前に作成し、テストケースに記載されて いる手順通りに実行するテストの方法で、探索的テ ストの対義語的に使われることも多いです ど こ ま で 詳 細 に ス ク リ プ ト 化 す る か に 幅 が あります 探索的テスト 対象を触ってその反応を観察し、知識・経験・直感 を駆使して次のアクションを決めるテストの方法で、 テストの設計・実行・学習を同時に行い、フィード バックサイクルを繰り返すのが特徴です どこまで探索をテスト実行者にゆだねるかに幅が あります VS 86
87. なぜちゃんとテスト設計 しなければならないのか？ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 87
88. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 88
89. 同値分割法 同じ結果が得られるグループ（同値パーティション）に分割し、 そ の 中 か ら 代 表 値 を テ ス ト ケ ー ス と し て 選 定 し ま す Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 代表値a i 代表値c k 代表値b j 89
90. 着目する点 • 等価とみなせる値のグループ(同値パーティション) ポイント • 同 値 パ ー テ ィ シ ョ ン か ら 代 表 値 一 つ を 選 ぶ こ と で 、 そのグループの値すべてをテストしたことと等価とみなす • 同値パーティションを考えるときは、有効な値だけでなく、 無効な値の同値パーティションも考慮する • 分割する範囲を誤るとテスト漏れが起きる点に注意 メリット • より少ないテストケース数で対象範囲を網羅できる キーワード • 同値パーティション（同値クラスとも呼ぶ） • 有効同値パーティション • 無効同値パーティション 同値分割法の特徴 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 90
91. 同値分割法のカバレッジ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 91 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 同値パーティションカバレッジ N: 実行したテストケースによってカバーされるパーティション数 T: 識別されたパーティションの総数
92. 同値分割の対象に順序性がある場合(数値/時間/順番など)、代表値を 任意に選ぶのではなく、同値パーティション間の境界の値をテストケー スとして選定します 境界値分析 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 7 8 24 25 パスワードとして適切な 長さの有効同値 パーティション パスワードとしては 短い無効同値 パーティション パスワードとしては 長すぎる無効同値 パーティション 0 ※25文字目は存在しないが、入力を 無 効 化 す る 機 能を テス ト す る ため の 論理的な値として25文字を上限とする。 ※文字数が負の数はあり えないので０を下限とする 有効な境界値 無効な境界値 92
93. 着目する点 • 同値パーティションに順序性がある場合の境界近傍 ポイント • 欠 陥 が 境 界 付 近 に 埋 め 込 ま れ る こ と が 多 い と い う 経験則に基づいている（例：＞を≧と誤ってしまう） • 上限や下限が定まっていないなど、範囲が開いている 場合はテストとして別途上限と下限を決める必要あり メリット • 少ないテストケースで、よりバグが潜んでいそうな箇所を 狙い打てる（同値分割法では見つからない欠陥を見つけ られる可能性が高まる） キーワード • 境界値（2値の境界値、3値の境界値） • 下限 • 上限 境界値分析の特徴 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 93
94. 境界値分析のカバレッジ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 94 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 境界値分析カバレッジ N: 実行したテストケースによってカバーされる明確な境界値の数 T: 境界値の総数
95. 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
96. 着目する点 • 論理関係(条件の組み合わせによって動作が確定するような ロジックを持つもの。有則や禁則) ポイント • IF文のような判定文をはじめ、論理関係があるものは おしなべてデシジョンテーブルとして表現できる メリット • 複数の条件によって動作が異なるようなロジックを 漏れなく整理することができる キーワード • 決定表 • テーブルの簡単化（圧縮） デシジョンテーブルテストの特徴 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 96
97. デシジョンテーブルテストのカバレッジ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 97 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: デシジョンテーブルテストカバレッジ N: 実行したテストケースによってカバーされる、実行可能な判定規則の数 T: 実行可能な判定規則の総数
98. • 状態遷移モデルをもとにテストを導出するテスト技法 • 状態遷移モデルは、ソフトウェアの状態と、その遷移に 着目したモデルで、UMLのステートマシン図も状態遷移 モデルのひとつ • 組込みソフトウェアではよく使われるが、それ以外にも ビジネスシナリオのモデル化や、画面遷移なども状態 遷移モデルとして整理することもある 状態遷移テスト Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 98
99. 状態遷移図の例 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 99 凡 例 遷移 イベント[ガード条件]/アクション 状態 終了 状態 疑似 開始 状態 注1: ガード条件がない場合は、[]とともに省略する。 注2: アクションしないか示す必要がない場合は/とともに省略する 未登録 試用中 契約中 期限切れ 新規登録 /有効日数=30日 ライセンス確認 [有効日数>=0] /有効日数-=1 ライセンス購入 /有効日数＋=365日 ライセンス確認 [有効日数<0] ライセンス確認 [有効日数<0] ライセンス購入 /有効日数+=365日 ライセンス確認 [有効日数>=0] /有効日数-=1 ライセンス購入 /有効日数+=365日 ※ ミリーチャート、ムーアチャート、ハレルチャート、UMLのステートマシン図など、状態遷移図の表現は さまざま存在している。本資料ではミリーチャートをベースに独自にカスタマイズした記法を用いている。
100. 状態遷移表の例 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 100 イベント 遷移前状態 新規作成 ライセンス購入 ライセンス確認 [有効日数<0] [有効日数>=0] 未登録 有効期間 ＝ 30日 試用中 N/A N/A N/A 試用中 有効日数 ＋＝ 365 ― 有効日数 －＝ 1 N/A 契約期間中 期限切れ 試用中 契約期間中 有効日数 ＋＝ 365 ― 有効日数 －＝ 1 N/A 契約期間中 期限切れ 契約期間中 期限切れ 有効日数 ＝ 365 N/A 契約期間中 N/A N/A ※ アクションを省略しているものや、状態×状態で表したものなど、状態遷移表の表現も様々存在している。
101. 着目する点 • テスト対象の状態、状態を遷移するイベントやガード条件、 遷移や状態におけるアクションなど ポイント • 故障が発生するのは遷移したタイミングとは限らない （例：ある遷移で内部変数を壊しても、故障として 現れるのは、壊した内部変数を参照した時になる） • 特定の経路や状態をテストするのか、すべての状態を網羅 するのか、遷移を網羅するのか、nスイッチカバレッジを 網羅するのかを決定する メリット • 状態遷移モデルにすることで、取り得る経路を整理でき、 nスイッチカバレッジなども網羅基準をもとに、テスト ケースを導出できる キーワード • 状態、遷移、イベント、ガード条件、アクション • 状態遷移表、状態遷移図、ステートマシン図 • nスイッチカバレッジ、形式手法/モデル検査 状態遷移テストの特徴 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 101
102. 状態遷移テストのカバレッジ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 102 29119-4ではこの技法のカバレッジとして次の4つを示している。 1. 状態カバレッジ (all states coverage) 2. 0スイッチカバレッジ (0-switch coverage) 3. 全遷移カバレッジ (all transitions coverage) 4. Nスイッチカバレッジ (N-switch coverage)
103. OS アーキテクチャ ブラウザ 1 Windows 10 32bit IE11 2 Windows 8.1 32bit Chrome 3 Windows 7 32bit Firefox 4 Windows 10 64bit Edge 5 Windows 8.1 64bit IE11 6 Windows 10 64bit Chrome 7 Windows 7 64bit IE10 8 Windows 8 32bit Chrome 9 Windows 8.1 32bit IE10 10 Windows 8 64bit Firefox 11 Windows 7 64bit Chrome 12 Windows 7 32bit IE11 13 Windows 8.1 32bit Firefox 14 Windows 8 32bit IE10 15 Windows 8 64bit IE11 16 Windows 10 32bit Firefox 17 Windows 10 32bit Edge 任意の2因子間に含まれる水準の組み合わせが最低でも1回以上出現する ように作られた組み合わせ表の各行をテストケースとして選定します 因 子 OS ｱｰｷﾃｸﾁｬ ブラウザ 水 準 Windows 7 Windows 8 Windows 8.1 Windows 10 32bit 64 bit IE11 Edge Chrome Firefox 2因子網羅100％とは以下の因子のペアにおいて、因 子に含まれる全ての水準の組み合わせが少なくとも1 つ以上存在します • OSとアーキテクチャ • OSとブラウザ • アーキテクチャとブラウザ 全網羅の場合38通りの組み合わせになりますが、 2因子網羅100％で良い場合は17になります ※制約: 取り得ない組み合わせは省いています ペアワイズテスト Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 103
104. 着目する点 • 意図しない影響を及ぼす組み合わせ（無則） ポイント • 禁則(組み合わせることができないペア）を考慮しないと、実 施不可能なテストケースの組み合わせが作られる • 2因子網羅で充分かどうか、3因子網羅でなくとも よいかどうかは、別途検討する必要がある メリット • 2因子間網羅100％を可能な限り少ないテストケースで実施 できる（組み合わせを現実的な数のテストケース数に圧縮で きる） キーワード • 因子（Factors)/水準（Levels） • 制約（とりえない組み合わせ) • n-wiseカバレッジ（n因子網羅） ペアワイズテストの特徴 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 104
105. ペアワイズテストのカバレッジ Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 105 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: ペアワイズテストカバレッジ N: 実行したテストケースによってカバーされる、P-Vペアの数 T: ユニークなP-Vペアの総数 ※P-Vペア（Parameter-Value pair）は組み合わせテストにおけるカバレッジアイテム。ペアワイズテストにおけるPVペアは、 2因子間の水準のペア。例えば「Windows7とChrome」という2因子間の水準のペアが1つのP-Vペア
106. テスト技法を最初に学ぶにはこちらをオススメ ソフトウェアテスト技法ドリル 第2版 秋山浩一著/日科技連出版刊 代表的なブラックボックステストの技法を 取り扱った書籍。非常に分かり易い文章 でお勧め。特に様々な技法を次元という 観点でまとめているところが秀逸。 はじめて学ぶソフトウェアのテスト技法 リー・コープランド著/日経BP刊 ブラックボックステストとホワイトボック ステストの様々なテスト技法を掲載。い ろいろなテスト技法を知るとっかかりと してお勧め。 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 106
107. 将来的にはこれらの書籍もあたってみましょう ソフトウェアテスト技法 ボーリス・バイザー著/日経BP刊 バイザーによるテスト技法を詳細に説明した 書籍。ホワイトボックステストのテスト技法を しっかり学びたいならこれしかない！ブラッ クボックステストについても書かれている。 実践的プログラムテスト入門 ボーリス・バイザー著/日経BP刊 バイザーのブラックボックステスト本。右の書籍か らブラックボックステストのみに特化した書籍。い かんせん、ちょっと右の書籍は読むのがハードな部 分もあるので… Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 107
108. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 108
109. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 109
110. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 110
111. その際にはSQuBOKガイドなどもオススメします 全体の軸を持った上でSQuBOKガイドな どを効率よく知識を吸収していけます 品質やテストに関する用語で分からない ものがあればまずはこれにあたり詳細に ついてはガイドが示す参考資料をあたる のをオススメします ※ ついこの間、第3版にアップグレードさ れて出版されたので、いまが買い時です Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 111
112. 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 ITIL 2.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
113. 「品質に関わる新たな 情報を得るための諸活動」 ※以下のテストの目的をすべて満たします 欠陥を摘出する 対象ソフトウェアの 品質レベルが十分で あることを確認する 意志決定のための 情報を示す 欠陥の作り こみを防ぐ 上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 「テストとは？」を整理すると Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 113
114. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに対しての 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです 114
115. テストプロセスの例（JSTQB） プロジェクトタイムライン Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 115
116. 受け入れテスト 開発したシステムがユーザの求めているものに合致して いるか確認する（受け入れ可能かどうか判断する）テスト システムテスト 最終的に統合されたシステム全体を、実環境 （またはそれに準ずる環境）で実施するテスト 統合テスト テスト済みのコンポーネントや システムを統合して行うテスト コンポーネントテスト 分離してテストが可能なソフトウェアコンポーネント （部品）ごとに単体で行うテスト テ ス ト 対 象 と し て 着 目 す る 詳 細 度 小 大 様々なテストレベルが存在する Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 116
117. JSTQBによるテストタイプの分類 Copyright © 2017-2022 Takashi YAMASAKI All right reserved. テストタイプ 機能テスト 機能の品質特性、例えば完全、 正 確 お よ び 適 切 であ る こ と などを評価する。 非機能テスト 非機能の品質特性、例えば信頼 性、性能効率性、セキュリティ、 互換性、使用性などを評価する。 ホワイトボックス テスト コンポーネントまたはシステム の 、 構 造 ま た は ア ー キ テ ク チャーが正しく完全で仕様通り であることを評価する。 変更関連のテスト 欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、 ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを 探す（リグレッションテスト）。 117 テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。
118. テストの空間の第1面（テストタイプ×テストレベル） Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 118 受け入れテスト システムテスト 統合テスト コンポーネントテスト 機 能 テ ス ト セ キ ュ リ テ ィ テ ス ト 相 互 運 用 性 テ ス ト 使 用 性 テ ス ト ・・・ ホ ワ イ ト ボ ッ ク ス テ ス ト 変 更 関 連 の テ ス ト 非機能テスト
119. テストの空間の第2面（テストプロセス×テストレベル） Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 119 受け入れテスト システムテスト 統合テスト コンポーネントテスト テ ス ト 計 画 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テ ス ト 完 了 テ ス ト の Ｍ ＆ Ｃ
120. テストの空間の第３面（テストプロセス×テストタイプ） Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 120 機能テスト 非 機 能 テ ス ト セキュリティテスト 相互運用性テスト 使用性テスト ･･･ ホワイトボックステスト 変更関連のテスト テ ス ト 計 画 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テ ス ト 完 了 テ ス ト の Ｍ ＆ Ｃ
121. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 121
122. Copyright © 2017-2022 Takashi YAMASAKI All right reserved. 122
123. テスターのスキルスペース Copyright © 2017-2022 Takashi YAMASAKI All right reserved. TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf) 123
124. テスト以外の知識も必要です TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Copyright © 2017-2022 Takashi YAMASAKI All right reserved. Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf) 124
125. 主な参考文献・参考資料 JSTQB/ISTQB関連 • ISTQB Glossary （用語集） • テスト技術者資格制度Advanced Levelシラバス日本語版テストマネージャ • テスト技術者資格制度Foundation Levelシラバス日本語版Version 2018V3.1.J03 • JSTQB認定ソフトウェアテスト技術者Foundation Levelトレーニングコース 資料（山﨑崇） ISO/IEC/IEEE 29119 • ISO/IEC/IEEE 29119-2:20２１ Software testing – Part 2: Test processes • ISO/IEC/IEEE 29119-3:20２１ Software testing – Part 3: Test documentation • ISO/IEC/IEEE 29119-4:20２１ 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