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

2024年10月18日(金) 2024年度版に更新しました

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

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

Transcript

1. ソフトウェアテストの概観を識る Ver. 7.00（2024年度版） 2024年10月18日(金) 於 日本科学技術連盟 ソフトウェア品質管理研究会（SQiP研究会） 基礎コース ソフトウェア品質保証の基礎 第6回 テスト技術 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 1
2. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 2 株式会社ベリサーブ品質保証部プロジェクト推進課 課長 兼 ソフトウェア品質コンサルティング部 山﨑 崇 （YAMASAKI Takashi） 2001年からセキュリティ対策ベンダーにおいて、さまざまなプロジェクトの ソフトウェアテスト活動にQAエンジニアとして従事。その傍ら、さまざまなテ ストコミュニティに参画し、活動の場を広げる。2015年にベリサーブに入社。 現場への技術支援、教育、コンサルテーションなどを担い、少しでも現場が幸 せになるように日々奮闘中。 主な活動 • JaSST東京実行委員会 （’11～） • テスト設計コンテストU-30審査委員 （’16～） • ASTER テストプロセス改善研究会 （’16～） • JSTQB Foundation Level 認定講師 （’12～） など 主な著書・訳書 • 実践ソフトウェアエンジニアリング 第9版 （共訳） • 今さら聞けないソフトウェアテストの国際規格： ISO/IEC/IEEE 29119シリーズを読みはじめる前に（著） • 開発現場で役立つテスト「超」実践講座 第9回 （著） • システム開発ジャーナル Vol.10 （共著） • テスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 （共訳） など 主な講演 • SQiPシンポジウム 2024併設チュートリアル「テスト戦略」 • WACATE2023夏 招待講演「テスト開発について改めて考 えてみよう～テスト分析やテスト設計を業務で上手くできる ようになるための四方山話」 • 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-2024 Takashi YAMASAKI All right reserved. 3
4. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. ありがたいことに日本語で得られるテストの 情報は2001年以降爆発的に増加しました 「図：テストを主題とした書籍の年別出版数」※著者当人の厳格ではない調査に基づいて作成したもの 4
5. 一方ではさまざまな情報の中から 自分の求めている情報を的確に 見つけるのが難しいとも言えます Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 5
6. この研修のゴール 1. ソフトウェアテストについての全体像を俯瞰し、整理できる 軸を持つことでさまざまなテストの用語がどういった特性 の言葉であるか判断できるようになりましょう 2. テストの要素技術に関するエントリーポイントを把握して、 効率よくテストについて学べる下地を持ちましょう Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 6
7. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 7
8. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 8
9. 理解への第一歩は 言葉を知ることから Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 9
10. ユニットテスト 統合テスト システムテスト 結合テスト アルファテスト ベータテスト 機能テスト 非機能テスト 性能テスト 負荷テスト 受け入れテスト スモークテスト モンキーテスト 探索的テスト ペネトレーションテスト セキュリティテスト コンパチビリティテスト パステスト ステートメントテスト デシジョンテーブルテスト テスト設計 テスト計画 テスト分析 テスト実装 テスト実行 テスト管理 テスト報告 テストケース テストウェア テストベース テストデータ テスト環境 テストツール テスト条件 テスト戦略 テストアプローチ テスト技法 ブラックボックステスト ホワイトボックステスト グレーボックステスト テスト手順 ロードテスト テスト駆動開発 テストフレームワーク でもこの業界「••テスト」や「テスト••」だらけ… Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 10
11. 「分かることは分けられること」 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 言葉を理解して区別できるようになりましょう 「思考・論理・分析 ―「正しく考え、正しく分かること」の論理と実践―」 波頭 亮(著) 11
12. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに位置しているかを 意識した上でテスト技術などの各種要 素を考えることで、文脈を理解しやすい ※図はイメージです 12
13. 同じ語を使っていても異なる意味を想像しているこ とも多いため、コミュニケーションを取る時には注 意が必要です 常に相手が異なる意味で使っていないかを疑って 適宜認識を合わせていかないと合意形成が上手く いかずに苦しむことになりがちです ギュスターヴ・ドレ『言語の混乱』 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 13
14. 共通言語としてJSTQB FL 取得のススメ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. ソフトウェアテスト技術者の認定資格で、 Foundation Level は 基 礎 レ ベ ル を 意味します ISTQBを通じて国際的にも有効な技術 資格で、日本でも多くの資格所有者が います JSTQBの言葉を借りてコミュニケーショ ンを取ると、合意形成が捗ります また、軸を持った上で学習すると、学習効 率も高まります 14 ※ JSTQB Foundation Levelシラバスが、v3.1 からv4.0にメジャーバージョンアップしました。試 験がv4.0に基づくのは2024年の11月からとな ります。なお、本資料は、v4.0の内容に準拠させて います（が一部旧シラバスからも引用しています）。
15. 本日使う道具はこの3点です Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 15
16. こんな感じで、随時 気になったキーワードを 独断と偏見によって貼り付けて いってください Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 16
17. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 17
18. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 18 みなさんが思う、ソフトウェアのテストとは、 どのようなイメージですか？
19. テストがなぜ必要なの？ テストって何だろう？ テストの目的とは？ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 19
20. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. ソフトウェアは人が作り、人は間違える生物 出典： テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「1.2．3 エラー、欠陥および故障」より（一部要約） 誘因① 納期のプレッシャー 誘因② 人間の誤りを犯しやすい性質 誘因③ プロジェクト参加者の経験不足または技術不足 誘因④ プロジェクト参加者間の誤ったコミュニケーション （要件や設計の誤ったコミュニケーションを含む） 誘因⑤ さまざまな複雑さ ※ コード、設計、アーキテクチャー、解決すべき根本的な問題, そして/または使用する技術の複雑さ 誘因⑥ システム内またはシステム間のインターフェースに対する誤解 ※ 特に、関連するシステム数が多い場合 誘因⑦ 新しく不慣れな技術 など 20
21. 結果として文書やコードに欠陥(バグ)が混入 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 21
22. Industry References:3 B. Boehm and V. Basili, “Software Defect Reduction Top 10 List” IEEE Computer Society, Vol. 34, No. 1, Jan 2001を Roger S. Pressman(他)が「実践ソフトウェアエンジニアリング」(第9版)で要約したグラフを基に作図 リリース後に見つかった欠陥の修正コストは高い Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 22
23. 品質コスト 予防コスト 欠陥の発生を防止するために 支出されるコスト 内部失敗コスト 出荷前に欠陥が発見された場 合の処理に付随して支出され るコスト 外部失敗コスト 出荷後に欠陥が発見された場 合の処理に付随して支出され るコスト 評価コスト 品質を評価することによって 品質レベルを維持するために 支出されるコスト 適合コスト 欠陥を回避するためにプロ ジェクトの期間中に支出するコ スト 不適合コスト 障害によりプロジェクト期間中 および期間後に支出するコス ト プロジェクトの期間中に 支出される品質コスト プロジェクト期間外に 支出される品質コスト 品質コストという考え方 23 Copyright © 2017-2024 Takashi YAMASAKI All right reserved.
24. ソフトウェアは社会のいたるところにあり、 最悪人が死んだり会社がつぶれたりします Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 24
25. ハードウェア 物質的実体 目に見える 触れられる 物理化学法則に基づくき 自由度は低く修正に関する 影響を把握しやすい ソフトウェア 論理的集合体 目に見えない 触れられない 物理化学法則に基づかず 自由度が高すぎ修正に関す る影響を把握しにくい 25 Copyright © 2017-2024 Takashi YAMASAKI All right reserved.
26. ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの 品質を評価するための一連の活動である。これらアーティファクトは、 テストをする際のテスト対象である。テストに関するよくある誤解の1つは、 テストはテスト実行（すなわち、ソフトウェアを実行しテスト結果を確認する） だけだというものである。しかし、ソフトウェアテストには他の活動も 含まれる。そして、ソフトウェア開発ライフサイクルと整合させなければばら ない。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. JSTQB FLシラバス ※ での定義(testing) 26 「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の1.1 テストとは何か？」より引用
27. 人によっても違うし成熟度によっても違うし千差万別 テストは行動ではない。大げさなテストをすることなく品質の 高いソフトウェアを作るための精神的な訓練である。 フェーズ4 テストの目的は、何かを証明することではなく、プログラムが 動かないことによって発生する危険性をある許容範囲までに 減らすことである。 フェーズ3 テストの目的は、ソフトウェアが動かないということを示すこと にある。 フェーズ2 テストの目的は、ソフトウェアが動くことを示すことである。 フェーズ1 テストとデバッグには何の差もない。 デバッグ以外にはテストには特別な目的はない。 フェーズ0 ボーリス・バイザー著 「ソフトウェアテスト技法」よりテスト担当者の精神面による区分を引用 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 27
28. テストの目的も一義的ではない Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の「1.1.1 テスト目的 」より引用 28 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する 故障を引き起こし、欠陥を発見する 求められるテスト対象のカバレッジを確保する ソフトウェア品質が不十分な場合のリスクレベルを下げる 仕様化した要件が満たされているかどうかを検証する テスト対象が契約、法律、規制の要件に適合していることを検証する ステークホルダーに根拠ある判断をしてもらうための情報を提供する テスト対象の品質に対する信頼を積み上げる テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの 妥当性確認をする 1 2 3 4 5 6 7 8 9
29. 「品質に関わる新たな 情報を得るための諸活動」 ※以下のテストの目的をすべて満たします 欠陥を摘出する 対象ソフトウェアの品質レベル が十分であることを確認する 意志決定のための 情報を示す 欠陥の作りこみを防ぐ 上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 「テストとは？」を整理すると Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 29
30. テストの原則 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 欠陥がないことは示せない 原則 1 全数テストは不可能 原則 2 早期テストで時間とコストを節約 原則 3 欠陥の偏在 原則 4 テストの弱化 原則 5 テストはコンテキスト次第 原則 6 「欠陥ゼロ」の落とし穴 原則 7 「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の「1.3 テストの原則 」より引用 テストは欠陥がある こ と は 示 せ る が 、 30
31. 早 い テストから得られる情報の 取得タイミングが早いほど価値が高い 安 い テストから得られる情報の 取得コストが安いほど価値が高い 旨 い テストから得られる情報がニーズに合致 していて正確で分かりやすいほど価値が高い 本質的にテストの価値は情報取得 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 31
32. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 32 テストを通じて得られた情報によって製品やサービスの 品 質 に 対 す る 確 信 度 合 い を 積 み 上 げ て い く 逆説的には、テストをしなくて済むのであれば、誰もがそれをしたくないけれども、ソフトウェアの特性や人の特性やソフト ウェア開発の背景などから、テストという手段を用いてその結果を見ないことには、リリースしても大丈夫であるかどうかを 判断する術がない
33. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 33 テストはテストのみでは存在し得ない活動 （テストのことだけ考えても意味がない） 情報はそれを使うことで意味を持つ
34. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 34 テ ス ト と は 、 テ ス ト と そ れ に 関 係 す る テスト以外のことについても考えに考え 抜 い て そ れ ら の 本 質 を 知 る こ と
35. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 35
36. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに位置しているかを 意識した上でテスト技術などの各種要 素を考えることで、文脈を理解しやすい ※図はイメージです 36
37. テストレベルとは？ テストレベルは、系統的にまとめ、マネジメント していくテストの活動のグループである。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. “ 具体的にインスタンス化したテストプロセス。 “ ISTQB Glossary「テストレベル」(Ver.2)より 「テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02」の「2.2 テストレベルとテストタイプ」より 37
38. テ ス ト 対 象 と し て 着 目 す る 詳 細 度 小 大 システム統合テスト テスト対象システムと他のシステム、外部サービスとのインターフェースのテストに焦点を当てたテストレベル システムテスト システム全体が特定の要件を満たしていることを確認することに焦点を当てたテストレベル コンポーネント統合テスト コンポーネント間のインターフェースや相互作用に焦点を当てたテストレベル コンポーネントテスト 個々のハードウェアまたはソフトウェアコンポーネントに焦点を当てたテストレベル さまざまなテストレベルが存在する Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 38 受け入れテスト 妥当性確認と、デプロイの準備ができていることの実証に焦点を当てたテストレベル
39. 要件定義 外部設計 内部設計 実装 テスト 「実装」が終わったら「テスト」って解像度粗いですよね Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 39
40. 対応関係 上流工程の開発と下流工程のテストにおける責務との対応関係 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 段 階 的 な 詳 細 化 段 階 的 な 統 合 40 要求分析 受け入れテスト アーキテクチャー設計 システム統合テスト 基本設計 システムテスト 詳細設計 コンポーネント統合テスト 実装 コンポーネントテスト
41. システム 要件 基本設計 詳細設計 実装 コンポーネント テストの計画 要求定義 テスト活動の 開始 システムテスト の計画 統合テストの 計画 コンポーネント テストの実施 デバッグと修正 統合テストの 実施 デバッグと修正 システムテスト の実施 デバッグと修正 受け入れテスト の実施 デバッグと修正 Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自 対応関係 サイクル:テスト、デバッグ、修正、再テスト Wモデル: テスト活動をフロントローディングすると効果的 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 41
42. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 42 ただ、Wモデルの実践は簡単ではありません 湯本さんの記事を読むと少しイメージが湧くかも https://note.mu/yumotsuyo/n/n83fee4567b5d
43. システム 要件 基本設計 詳細設計 実装 コンポーネント テストの計画 要求定義 テスト活動の 開始 システムテスト の計画 統合テストの 計画 コンポーネント テストの実施 デバッグと修正 統合テストの 実施 デバッグと修正 システムテスト の実施 デバッグと修正 受け入れテスト の実施 デバッグと修正 Andreas Spillner 著 The W-MODEL Strengthening the Bond Between Development and Test より引用。翻訳は独自 対応関係 サイクル:テスト、デバッグ、修正、再テスト Wモデル: テスト活動をフロントローディングすると効果的 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 43 （マスターテスト計画） プロジェクト テスト計画 project test plan 受け入れテストの レベルテスト計画 level test plan システムテストの レベルテスト計画 level test plan 統合テストの レベルテスト計画 level test plan コンポーネント テストの レベルテスト計画 level test plan 各テストレベルだけではなくテスト全体の絵を描こう
44. テスト実行の自動化は低いテストレベルから 出典：「実践アジャイルテスト」の「テスト自動化のピラミッド」を基に改変・追記 E2E テスト APIレベルの テスト ユニットテスト/ コンポーネントテスト 手動テスト 高 低 費 用 対 効 果 保 守 性 難 易 実 行 速 度 遅 速 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 44
45. コンポーネントテストレベルでの自動化 テスト駆動開発入門 ケント・ベック著/オーム社刊 コンポーネントテスト(ユニットテスト)レベルでの自 動化は、xUnitなどのテストフレームワークを使うこ とが多いので、開発言語など自分の状況に合ったも のを選択しましょう。 コンポーネントレベルでは実装とテストを同じ人が担 うことも多く、特定のアプローチとしてはテスト開発 駆動(TDD: Test Driven Development)が有 名です。 各地域のコミュニティが中心となって全国各地で TDD Boot Camp開催しているので、そこで体験し てみるのもお勧めです（コロナ禍以降活動休止中な様子）。 TDDの提唱者ケント・ベックの書籍。ピアソンショックにより絶版となってい たが、2017年にオーム社からt_wadaさんの新訳で復刊され、入手可能 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 45
46. 統合テストレベルでの自動化 継続的インテグレーション入門 著者多数/日経BP刊 統合テスト(インテグレーションテスト)レベルでの 自動化に関しては、CI環境を用いることが一般化 してきました。 継続的インテグレーション(CI: Continuous Integration)は、日毎、時毎、コミット毎といっ た短いサイクルでテストを走らすことで、統合に関 係する問題を素早く見つけることが目的です。 オープンソースではJenkinsが有名ですが商用の CIアプリやサービスなども存在するので自分たち にあったものを選択しましょう。 特定のCI環境に特化したものではなく、概念レベルからしっかりと解説して いる書籍。特定のCI環境に特化した書籍と合わせて読むと効果的かと。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 46
47. システムテストレベルでの自動化 シスエムテスト自動化標準ガイド マーク&ドロシー著/翔泳社刊 システムテストのテストレベルにおいても、自動化を 行うことは一般化してきました。 そのシステムテストレベルにおける自動化を扱った書 籍が左記のものです。 また、この書籍を翻訳したシステムテスト自動化研究 会が毎年開催してるシステムテスト自動化カンファレ ンス（STAC）の資料も公開も参考になります。 特に最近は、AIの技術を使ったテストスクリプトの オートヒーリングなどを備えた自動化ツールなどが、 利用されています。 テスト自動化研究会が翻訳した「Software Test Automation 」。著者は マーク&ドロシー。邦題はシステムテスト全般を指しているように見えるが機 能テストの自動化かメイン。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 47
48. 受け入れテストレベルでの自動化 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 継続的デリバリー Jez Humble & David Farley 著 ASCII DOWANGO刊 受け入れテストのテストレベルは、DevOpsや CD （ 継 続 的 デ リ バ リ ー Continuous Delivery, 継 続 的 デ プ ロ イ メ ン ト Continuous Delivery）の領域を考慮します。 左の書籍は、継続的デリバリーを主題に扱って います。 ソースコードに変更を加えてからデプロイまで の一連の流れを「デプロイメントパイプライン」 としてパイプライン化（つまり自動化）すること で、アジリティのある開発とリリースを可能にし ます。 48
49. DevOpsでの継続的テストのループ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 49 出典：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 ここで テスト ここで テスト ここで テスト そして ここでも さらに ここでもテスト ここでテストしないの？ もちろんできます！ ここでも テスト さらに ここでも テスト そして ここも もちろん…
50. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 50 テ ス ト レ ベ ル の 本 質 を 考 え て い く と ソフトウェア開発ライフサイクルに留まらず ソフトウェアライフサイクル全般における テストの全体像を考えていくことに繋がる
51. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 51
52. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに位置しているかを 意識した上でテスト技術などの各種要 素を考えることで、文脈を理解しやすい ※図はイメージです 52
53. テストタイプとは？ コンポーネントやシステムのある特性に対応したテスト の目的を基にテスト活動をまとめたもの。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. “ ISTQB Glossary https://glossary.istqb.org より引用 テストタイプは、以下に列挙する特定のテストの目的か ら見たソフトウェアシステム（あるいはシステムの一部 分）の特性をテストするための活動を束ねたものである。 テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より引用 “ 53
54. JSTQBによるテストタイプの分類 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 54 テスト技術者資格制度 Foundation Levelシラバス日本語版Ver.4.0J02「2.2.2 テストタイプ 」より文章を引用（強調と作図は独自）。 機能テスト コンポーネント、およびシステムが実行する機能を 評価する。機能とはテスト対象が「何」をすべきか である。機能テストの主な目的は、機能完全性、機 能正確性、および機能適切性をチェックすること である。 非機能テスト コンポーネント、およびシステムが実行する機能特 性以外の属性を評価する。非機能テストは、システ ムが「どのようにうまく振る舞うか」をテストする。 非機能テストの主な目的は、 非機能的なソフト ウェア品質特性をチェックすることである. ブラックボックステスト 仕様に基づき、テスト対象の外観を示すドキュメン トからテストを導出する。ブラックボックステスト の主な目的は、システムの動作をその仕様に照ら してチェックすることである。 ホワイトボックステスト 構造に基づき、システムの実装または内部構造 （コード、アーキテクチャー、ワークフロー、データ フローなど）からテストを導き出す（4.3 節参照）。 ホワイトボックステストの主な目的は、テストに よって基本的な構造を受け入れ可能なレベルまで カバーすることである。
55. ブラックボックステストとホワイトボックステストの区別 55 入力 出力 入力 出力 ブラックボックスとは、対象の中身（内部構造） が見えないことを言う一般名詞。 ブラックボックステストは、コンポーネントまた はシステムの内部構造を参照しない、機能また は非機能テストのこと。 ブラックボックステスト技法は、内部構造を参 照せずに、コンポーネントまたはシステムの仕 様（機能または非機能）の分析に基づいてテス トケースを導出および/または選択する手順の こと。 ホワイトボックスとは、対象の中身（内部構造） が見えることを言う一般名詞。 ホワイトボックステストは、コンポーネントまた はシステムの内部構造の分析に基づいたテス ト（テストタイプ）のこと。 ホワイトボックステスト技法は、コンポーネント またはシステムの内部構造の分析に基づいて、 テストケースを導出および/または選択する 手順のこと。
56. JIS X 25010:2013 図4「製品品質モデル」より引用（配色は独自） システム/ソフトウェア製品品質 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 • 機能完全性 • 機能正確性 • 機能適切性 • 時間効率性 • 資源効率性 • 容量満足性 • 共存性 • 相互運用性 • 適切度認識性 • 習得性 • 運用操作性 • ユーザエラー 防止性 • ユーザイン ターフェース 快美性 • アクセシビリ ティ • 成熟性 • 可用性 • 障害許容性 (対故障性) • 回復性 • 機密性 • インテグリ ティ • 否認防止性 • 責任追跡性 • 真正性 • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性 • 適用性 • 設置性 • 置換性 ISO/IEC 25010の製品品質モデル Copyright © 2017-2024 Takashi YAMASAKI All right reserved. ソフトウェアテストでは機能以外のさまざまな側面について考慮することも重要です 56 ※ISO/IEC 25010は2023に改訂されて、上記から構成が変わっています。
57. 29119-4における品質特性とテストタイプの紐付け テストのタイプ 品質特性 副特性 アクセシビリティテスト 使用性 アクセシビリティ 互換性テスト 互換性 共存性 コンバージョンテスト 機能適合性 機能完全性 機能正確性 機能適切性 ディザスタリカバリテスト （復旧災害テスト） 信頼性 成熟性 障害許容性(対故障性) 回復性 機能テスト 機能適合性 機能完全性 機能正確性 機能適切性 設置性テスト 移植性 設置性 相互運用性テスト 互換性 相互運用性 ローカライゼーションテスト （L10Nテスト） 機能適合性 機能完全性 機能正確性 機能適切性 使用性 適切度認識性 習得性 運用操作性 ユーザエラー防止性 ユーザインターフェー ス快美性 アクセシビリティ 移植性 適用性 保守性テスト 保守性 モジュール性 再利用性 解析性 ISO/IEC/IEEE 29119-4：2021 Table A.1 - 「ISO/IEC 25010 製品品質特性とテストタイプの紐付け」より引用 ※翻訳独自 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 57 テストのタイプ 品質特性 副特性 保守性テスト 保守性 モジュール性 再利用性 解析性 修正性 試験性 性能関連テスト 性能効率性 時間効率性 資源効率性 容量満足性 移植性テスト 移植性 適用性 設置性 置換性 手順テスト なし なし 信頼性テスト 信頼性 成熟性 可用性 障害許容性(対故障性) 回復性 セキュリティテスト セキュリティ 機密性 インテグリティ 否認防止性 責任追跡性 真正性 使用性テスト 使用性 適切度認識性 習得性 運用操作性 ユーザエラー防止性 ユーザインターフェー ス快美性 アクセシビリティ
58. • テストベースが不足している際に、製品品質モデルの各特性をガイドワードとしテス トを考えることは良いが、各特性が「どうあるべきか」は、本来的には品質要求事項 を識別し、品質測定量の目標値を定める必要がある • 例えば、「時間効率性」（パフォーマンス）に対する品質要求事項として、品質測定量 「平均応答時間」の目標値が何msであれば良いかというテストオラクルが必要 • すべての品質特性がテストによって測れるわけではなく、テストでは測りがたい特性 もある（例： 保守性とか移植性とか）し、すべての品質特性で100点を取るというも のでもないし、各品質の特性は相乗、相克、相反の関係を持つこともあるため、どの 特性をどれくらい優先するかが本来重要 • 前提として品質モデルはテストのために作られたモデルではなく、製品品質モデル が自分たちのテストにおいて、すべての品質の側面を提供してくれるわけではない （利用時の品質、データの品質、サービス品質、AIシステムの品質などもあるかもし れない） 製品品質モデルをいきなりテストの文脈で引っ張り出して、 テストの十分性や網羅性を示すのは難しい・・・ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 58
59. 製品品質特性間の関係の例 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 59 機能適合性 信頼性 性能効率性 使用性 セキュリティ 互換性 保守性 移植性 機能適合性 － － － － － － － 信頼性 ＋ ＋ 性能効率性 ＋ － 使用性 － － セキュリティ － － － － － － － 互換性 ＋ － － 保守性 － － 移植性 － － ＋ 記号説明 ＋： 正の効果（行の品質特性が列の品質特性に良い影響を与えることがある。） －： 府の効果（行の品質特性が列の品質特性に悪い影響を及ぼし、矛盾が発生することがある。） 「JIS X 25030:2021(ISO/IEC 25030:2019) 」P.39 「付属書G 製品品質特性間の関係の例」「表G.1 ― 製品品質特性間の関係の例」デザインを一部変更
60. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 60 変更 新規追加 既存 凡例 図はISO/IEC 25010:2023 Figure. 2 Product Quality Modelより引用。着色と凡例を独自に追加 製品品質のモデルも、時代とともに改訂を重ねてきており、ISO/IEC25010:2013も 2023に改訂されました。また、製品品質以外にも、SQuaREには利用時の品質、 データ品質、サービス品質、AIシステムの品質モデルなども規定されていています。 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
61. 品質はソフトウェアライフサイクル全体を通じて考えましょう Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 61 出典： SEC journal Vol.10 No.5 Jan. 2015 「システム・ソフトウェア品質標準SQuaREシリーズの歴史と概要」東基衞 をベースに一部改変
62. ライフサイクルでの品質 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 62 利用状況 プロセス品質 内部特徴 外部特徴 利用時の品質 プロセス測定 内部測定量 外部測定量 利用時の品質測定量 影響 影響 影響 依存 依存 依存 プロセス ソフトウェア製品 ソフトウェア製品の効果 図「ライフサイクルでの品質」/ JIS X 25010:2013(ISO/IEC 25010:2011) P-31 図C.2より
63. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 63 テストタイプを突き詰めていくと開発している 製品やサービスに求められていること、それら の存在意義といった根源的なことに繋がる
64. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 64
65. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに位置しているかを 意識した上でテスト技術などの各種要 素を考えることで、文脈を理解しやすい ※図はイメージです 65
66. テストプロセスとは？ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 相互に関連する活動のセット。テスト計画作業、 テストモニタリングとコントロール、テスト分析、 テスト設計、テスト実装、テスト実行、テスト完了 といった活動から構成される。 ISTQB Glossary 「テストプロセス」(Ver.2)より引用 “ 66
67. テストプロセスの例（JSTQB） テストプロジェクトのタイムライン Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 t 67
68. 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-2024 Takashi YAMASAKI All right reserved. テストマネジメントプロセス群 動的テストプロセス 組織的 テスト プロセス テスト 設計と実装 プロセス テスト環境と データ マネジメント プロセス テスト実行 プロセス テスト インシデント レポート プロセス テスト戦略と 計画プロセス テストの モニタリングと コントロール プロセス テスト完了 プロセス 68
69. ISO/IEC/IEEE 29119とJSTQBのテストプロセス対応関係 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 69 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 組織的 テスト プロセス テスト 設計と実装 プロセス テスト環境構築 とメンテナンス プロセス テスト実行 プロセス テスト インシデント 報告プロセス テスト計画 プロセス テストの モニタリングと コントロール プロセス テスト完了 プロセス
70. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 70 出典： ISO/IEC/IEEE 29119-3:2021 P. ix 「Figure 1 Overview of test documentation」。一部要約・改変。翻訳は独自。 テストポリシー プロジェクトテスト計画書 （例：マスターテスト計画など） テストモデル仕様書 組織的テストプラクティス テストインシデントレポート タイプテスト計画書 （例： セキュリティテスト計画など） テストステータスレポート テスト完了レポート テストケース仕様書 テスト手順仕様書 実際の結果とテスト結果 テスト実行ログ テストデータ要件 テストデータ準備レポート テスト環境要件 テスト環境準備レポート レベルテスト計画書 （例： システムテスト計画など）
71. テストツールまるわかりガイド ASTERテストツールWG著 一連のテストプロセスではさまざまな活動が あ り 、 効 率 や 効 果 の 観 点 か ら ツ ー ル の 活用を検討しましょう 左のものはさまざまなツールの情報をまとめた ガイドでありPDF版も公開されています 特 に 、 現 在 の プ ロ セ ス の 習 熟 度 に 沿 っ た 導入をアドバイスしてくれる診断ツールは面白い ので是非試してみてください ※テストプロセスの成熟度が低い場合はツール を 使 っ て も 効 果 が 得 ら れ に く い の で まだ利用する段階ではないと言われます テストプロセスを通じてツールの活用も検討 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 2020年にVersion 2.0.0が公開されました。「プロプライエタリのテストツー ルの追加情報やオープンソースのテストツールの情報については、今後は随時、 記事投稿を募集し、継続的に改訂していく予定です」（ASTERのWebサイトよ り） ※左の画像はVersion 1.0.1です 71
72. その他にもさまざまなテストプロセスモデルが 存在しているのでうまく活用しましょう！ 但し、本質的にはコンテキストに沿ったテストのプロセス設計やテーラリングが必要です Critical Testing Process (CTP) Systematic Test and Evaluation Process(STEP) Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 72
73. テストプロセスのためのプロセス改善モデルもいろいろあります TPI NEXT 2009年 (日本語版が2015年9月に発売) ISO/IEC 33063 2015年8月 (※現在改訂中 ISO/IEC CD 33063) TMMi Release 1.3 2022年 (version. 1.0は2008年) Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 73
74. 項目 TMMi TPI NEXT ISO/IEC 33063 所感 CMMIと同等の枠組み。CMMIのテスト プロセス部分を補完する。CMMIにつ いて既に経験や知識を持っている組織 であれば展開は比較的容易であろう 改善提案やコツなどまで含めたガイドと して利用可能。内容が具体的かつ実践的 で、現場でのセルフアセスメントなどにも 使いやすいものになっていると感じる 縦 軸 に ISO/IEC 33020 、 横 軸 に ISO/IEC/IEEE 29119-2を持つ新し いテストアセスメントモデル。GP、GR、 GWPなどの評価指標が示されている リリース年 2022年(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で定義されているプロセスは8プロセスのみであ るが、実践のために5プロセスが追加で示されている。こ れらはAnnexなどにnormativeとして記述されている ※3: ISO/IEC 33063のみでのページ数。関連規格を含めると 200ページを超える(Annexを含む) ※4: ISO/IEC 33063をJSA Web Storeで購入した場合の金額。 関連規格を含めると総額は10万円程となる ※5: (2023年10月時点では)JIS化されていない 各テストプロセス改善モデルの簡易比較 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 74
75. テストプロセスの中でも特に重要なのが テストケースを作るまでのイメージを持てること！ テスト設計※またはテスト準備、テスト計画など表現はさまざま テスト 実行 テスト 要求分析 テスト アーキテクチャー 設計 テスト 詳細設計 テスト 実装 テスト 実行 テスト分析 テスト設計 テスト実装 テスト 実行 未成熟な テスト開発 プロセス JSTQBの テスト開発 プロセス Test.SSFの テスト開発 プロセス この部分がテスト開発プロセス テストを作り込んでいく段階をより詳細化してイメージ できるようになればより良いテストが作れるようになる Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 75
76. テ ス ト 技 法 を 勉 強 し て 演 習 で は 上 手 く 使 え た の に 実 務 で は ど う や っ て 技 法 を 適 用 す れ ば 良 い の か 分 か ら ず 上手く使えていません(T_T) 良くあるパターン https://www.pakutaso.com/20141152308post-4790.html Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 76
77. Test Design Technic Test Basis Test Cases Test Basis Test Cases Test Cases テ ス ト ベ ー ス ※ に 対 し て い き な り テ ス ト 技 法 を 適 用 し て い る ？ ※テストベースとはテストを考える上で入力となる情報全般のこと。例えば要件定義書、仕様書、外部設計書などさまざま Test Technics Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 77
78. Test Design Technic Test Basis Test Cases Test Basis Test Cases Test Cases Test Technics それは失敗フラグです Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 78
79. JSTQBのテスト開発プロセスのイメージ例 テスト手順 テストケース テスト条件 テストベース 文書 A 文書 B 文書 D テスト設計 仕様 テスト設計 仕様 テスト設計 仕様 テストケース 仕様 テストケース 仕様 テストケース 仕様 テスト 手順仕様 テスト 手順仕様 テスト 手順仕様 テスト 手順仕様 テストケース 仕様 テスト 手順仕様 テスト 分析 テスト 設計 テスト 実装 文書 C 「テスト技術者資格制度Foundation Levelシラバス日本語版」を基に図にしたもの Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 79
80. ISO/IEC/IEEE 29119-2:2013におけるテスト開発プロセス （これは、基本的に、JSTQBのテスト開発プロセスと同じ） Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 80 フィーチャー セットを 識別する (TD1) テスト条件を 得る (TD2) テスト カバレッジ アイテムを 得る(TD3) テストケースを 得る (TD4) テストセットを まとめる (TD5) テスト手順を 得る (TD6) テスト設計 仕様 テストケース 仕様 テスト手順仕様 フィーチャー セット テスト条件 テストカバレッジ アイテム テストケース テストセット テスト手順& テストスクリプト ISO/IEC/IEEE 29119-2：2013 P.32 Figure 10 Test design and implementation process より一部抜粋。 翻訳は筆者による
81. ISO/IEC/IEEE 29119:2023でのテスト開発プロセスイメージ ISO/IEC/IEEE 29119-2：2021 P.32 Figure 10 Test design and implementation process より引用。翻訳は筆者による Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストモデルの 作成 (TD1) テストカバレッジ アイテムの識別 (TD2) テストケースの 導出 (TD3) テスト手順の 作成 (TD4) テストモデル テストカバレッジアイテム テストケース テスト手順 81
82. テスト設計コンテストのすゝめ 特にこの分野は日本がリードしており現在進行形で切磋琢磨している状態。 成果物も一部公開されており、具体的に見たい、知りたい人にも最適！ OpenクラスとU-30クラスがあるので、若い人の腕試しもできます。 また、チュートリアル資料と動画も公開されていますので勉強になります。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 82 画像はNPO法人ASTERのテスト設計コンテストのWebサイトより引用
83. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 83 テスト モデルを 特定する 4つの テスト モデル モデルに 紐付いた テスト観点 テスト 観点を 詳細化 する 詳細化された テスト観点 (テストパラメータ) 網羅 基準を 設定する 網羅基準 テストケース (テスト値) 基準に 基づいて ケースを 導出する 網羅基準に 紐付いた テスト パラメータ テスト技法 テスト 観点間の 関係性を 見出す テスト フレーム 同じような 意味を持つ テスト観点や テストフレーム をまとめる テスト コンテナ テスト コンテナ間の 関連性を 整理する テスト アーキテ クチャー テスト すべきことを 洗い出す テストベース さまざまな テスト観点 テスト観点を 構造化する 構造化された テスト観点 (中間状態) ドメイン知識/ ガイドなど リファイン する 最終的に 構造化された テスト観点 実際に自分たちがテスト開発できるだけの 詳 細 度 で プ ロ セ ス を 設 計 し ま し ょ う
84. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 84 ソフトウェアライフサイクルの中で継続的に行っていく 各 テ ス ト の 特 徴 を 見 据 え た プ ロ セ ス を 設 計 す る
85. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 85 ライフサイクルの中にパイプラインも構築していく Deploy Stage Test Build Commit 継続的デリバリー（CD） 継続的インテグレーション（CI） 継続的デプロイメント（CD）
86. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 86 テ ス ト プ ロ セ ス を 突 き 詰 め て 考 え て い く と テストを実現するためのプロセスだけではなく ソフトウェア開発ライフサイクルやソフトウェアライ フサイクルとの融合やパイプライン化に繋がる
87. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 87
88. テスト技法とは？ テスト条件の定義、テストケースの設 計、およびテストデータの明確化をす るための手続き。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. “ ISTQB Glossary https://glossary.istqb.org より引用 88
89. 入力 出力 ブラックボックステスト技法 テスト対象の(内部)構造には着目せ ずにテストケースを導出するテスト技 法の総称 ホワイトボックステスト技法 テスト対象の(内部)構造に着目して、 テストケースを導出するテスト技法の 総称 入力 出力 昔ながらのテスト技法の分類 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 89
90. JSTQBによるテスト技法の分類 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 90 ブラックボックステスト技法 別名: 仕様ベースの技法 「テスト対象の内部構造を参照することなく、仕様上の振る舞 いの分析に基づくもの」 ホワイトボックステスト技法 別名: 構造ベースの技法 「テスト対象の内部構造や処理の分析に基づくもの」 経験ベースのテスト技法 別名: 特になし 「テストケースの設計と実装にテスト担当者の知識と経験を 効果的に利用するもの」 同値分割法 境界値分析 デシジョンテーブルテスト 状態遷移テスト その他 ステートメントテスト ブランチテスト その他 エラー推測 探索的テスト チェックリストベースドテスト その他 《 補 完 す る 》
91. ISO/IEC/IEEE 29119-4:2021 Figure 2. The set of test design techniques presented in this document より引用。翻訳は独自 ISO/IEC/IEEE 29119によるテスト技法の分類 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 91 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とでは同じ分類となっている。 要件ベースドテスト
92. 探索的テストはテスト技法なの？ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 断片的な テストケース チャーター 役割 フリースタイルの探索 純然たる スクリプト 漠然とした スクリプト 上図はCem Kaner & James Bach著「The Nature of Exploratory Testing」P.14 より引用。翻訳は筆者による スクリプトテスト テストを実施するにあたってテストケース（スクリ プト）を事前に作成し、テストケースに記載されて いる手順通りに実行するテストの方法で、探索的テ ストの対義語的に使われることも多いです。どこま で詳細にスクリプト化するかに幅があります 探索的テスト 対象を触ってその反応を観察し、知識・経験・直感 を駆使して次のアクションを決めるテストの方法で、 テストの設計・実行・学習を同時に行い、フィード バックサイクルを繰り返すのが特徴です。どこまで 探索をテスト実行者にゆだねるかに幅があります。 ISTQBの文脈においてはテスト技法ですが、テスト技法ではなくテストの実施方法 やスタイルと言われることもあります。 VS 92
93. なぜちゃんとテスト設計 しなければならないのか？ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 93
94. より少ないケースで網羅性を確保しつつ も、より多くのバグを摘出することが重 要になってくる そもそも「全数テストは不可能 ※ 」 そのための技術がテスト技法 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 94 ※テストの原則より
95. テスト技法を最初に学ぶにはこちらをオススメ ソフトウェアテスト技法ドリル 第2版 秋山浩一著/日科技連出版刊 代表的なブラックボックステストの技法を取り扱った書 籍。非常に分かりやすい文章でお勧め。特にさまざまな 技法を次元という観点でまとめているところが秀逸。 はじめて学ぶソフトウェアのテスト技法 リー・コープランド著/日経BP刊 ブラックボックステストとホワイトボックステストのさ まざまなテスト技法を掲載。いろいろなテスト技法を 知るとっかかりとしてお勧め。 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 95
96. 将来的にはこれらの書籍もあたってみましょう ソフトウェアテスト技法 ボーリス・バイザー著/日経BP刊 バイザーによるテスト技法を詳細に説明した書 籍。ホワイトボックステストのテスト技法をしっ かり学びたいならこれしかない！ブラックボッ クステストについても書かれている。 実践的プログラムテスト入門 ボーリス・バイザー著/日経BP刊 バイザーのブラックボックステスト本。右の書籍からブ ラックボックステストに特化した書籍。いかんせん、 ちょっと右の書籍は読むのがハードな部分もあるの で、それよりはハードルが少し低いかも？ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 96
97. 同値分割法 同じ結果が得られるグループ（同値パーティション）に分割し、その中から 代表値をテストケースとして選定することで、少ないテストケースで効率 的なテストが可能（数学の集合論で考えると分かりやすいかもしれない） Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 97 A B C 代表値𝒂𝒊 代表値𝒄𝒌 代表値𝒃𝒋 テストしたい全要素が3つの同値パーティションとし て分割できる（全集合𝑈 = 𝐴 + 𝐵 + 𝐶）場合、 1. 𝐴 = 𝑎1 , 𝑎2 , 𝑎3 , ⋯ , 𝑎𝑥 から代表値𝑎𝑖 を選定し、 𝑎𝑖 をテストすることで、同値パーティション𝐴 が 含む同値であるすべての要素(𝑎1 ⋯ 𝑎𝑥 )をテス トしたこととみなす 2. 𝐵 = 𝑏1 , 𝑏2 , 𝑏3 , ⋯ , 𝑏𝑦 から代表値𝑏𝑗 を選定し、 以下同文 3. 𝐶 = 𝑐1 , 𝑐2 , 𝑐3 , ⋯ , 𝑐𝑧 から代表値𝑐𝑘 を選定し、 以下同文
98. 同値分割法のカバレッジ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 98 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 同値パーティションカバレッジ N: 実行したテストケースによってカバーされるパーティション数 T: 識別されたパーティションの総数
99. 着目する点 • 等価とみなせる値のグループ(同値パーティション)に着目 ポイント • 同値パーティションから代表値1つを選ぶことで、その グループの値すべてをテストしたことと等価とみなす • 同値パーティションを考える時は、有効な値だけでなく、無 効な値のパーティションも考慮する • 各同値パーティションから漏れなく代表値を選ぶ • 無効同値は単独でテストする(隠蔽の可能性に注意) メリット • より少ないテストケース数で対象範囲を網羅できる キーワード • 同値パーティション（同値クラスとも呼ぶ） • 有効パーティション • 無効パーティション 同値分割法の特徴 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 99
100. • 同値分割法の要素に順序性がある場合（数値/時間/回数など）、代 表値を任意に選ぶのではなく、同値パーティションの境界に着目し て境界の値を代表値（境界値）として選ぶ • 分割した同値パーティションの境界付近に欠陥が潜んでいる可能性 が高い • 境界値とは、分割した同値パーティションの端、あるいは端のどち らか側で最小の増加的距離にある値 • 境界値分析も、すべてのテストレベルで適用できる 境界値分析 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 100
101. 以下の、パスワードの長さに関する仕様について境界値分析をすると、 • パスワードの長さは、8文字以上24文字以内の範囲とする • 24文字を越える場合、文字の入力を受け付けない 境界値分析の例 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 101 7 8 24 25 パスワードとして適切な 長さの有効同値 パーティション パスワードとしては 短い無効同値 パーティション パスワードとしては 長すぎる無効同値 パーティション 0 ※25文字目は存在しないが、入力を 無 効 化 す る 機 能を テス ト す る ため の 論理的な値として25文字を上限とする。 ※文字数が負の数はあり えないので0を下限とする 有効な境界値 無効な境界値
102. 境界値分析のカバレッジ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 102 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: 境界値分析カバレッジ N: 実行したテストケースによってカバーされる明確な境界値の数 T: 境界値の総数
103. 着目する点 • 同値パーティションの要素に順序性がある場合、 その境界付近に着目 ポイント • 境界付近に欠陥が埋め込まれるやすいという経験則に基づいて いる（例: ＞を≧の誤りなど） • 上限や下限が定まっていないなど、範囲が開いている場合は、確 認の上、決める必要が出てくる（十分に小さい値、十分に大きい値 をすり合わせる） メリット • 少ないテストケースで、よりバグが潜んでいそうな箇所を狙い打 てる（同値分割法よりケース数が増えるが、同値分割法だけでは 見つからない欠陥を見つけられる可能性が高まる） キーワード • 最小の増加的距離 • 境界値（本講では扱わないが2値BVAと3値BVAの二流派ある） 境界値分析の特徴 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 103
104. 1 2 3 4 タイムサービス時間内である Y Y Y N 対象商品である Y N N - 会員である - Y N - 15％割引する X - - - 5％割引する - X - - 割引なし - - X X • デシジョンテーブルテストは、デシジョンテーブルを基にテ ストを導出するテスト技法 • デシジョンテーブルとは、論理（ロジック）条件の組み合わせ を包括的にテーブルとて記述したもの デシジョンテーブルテスト Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 104
105. デシジョンテーブルテストのカバレッジ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 105 29119-4ではこの技法のカバレッジを以下のように示している。 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆 = N T × 𝟏𝟎𝟎 % 𝑪𝒐𝒗𝒆𝒓𝒂𝒈𝒆: デシジョンテーブルテストカバレッジ N: 実行したテストケースによってカバーされる、実行可能な判定規則の数 T: 実行可能な判定規則の総数
106. 着目する点 • 論理関係に着目(条件の組み合わせによって動作が確定する ようなロジックを持つもの) ポイント • IF文のような判定文をはじめ、論理関係があるものはすべて デシジョンテーブルとして表現できる • テーブルを簡単化する場合は、グレーボックステストとしての アプローチを取り、条件判定の処理順序が確定していることを 確認しておかないと、テストの抜け漏れのリスクがある メリット • 複 数 の 条 件 に よ っ て 動 作 が 異 な る よ う な ロ ジ ッ ク を 漏れなく整理することができる キーワード • デシジョンテーブル（決定表）、制限指定、拡張指定 • 制限記入テーブル/拡張記入テーブル/混合記入テーブル • 条件部/動作部/記述部/指定部、規則 • テーブルの簡単化（圧縮） デシジョンテーブルテストの特徴 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 106
107. • 状態遷移モデルを基にテストを導出するテスト技法 • 状態遷移モデルは、ソフトウェアの状態と、その遷移に着 目したモデル • 状態遷移モデルには、状態遷移図と状態遷移表がある • UML（Unified Modeling Language）のステート マシン図も状態遷移モデルの1つ 状態遷移テスト Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 107
108. 状態遷移図の例 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 108 凡 例 遷移 イベント[ガード条件]/アクション 状態 終了 状態 疑似 開始 状態 注1: ガード条件がない場合は、[]とともに省略する。 注2: アクションしないか示す必要がない場合は/とともに省略する 未登録 試用中 契約中 期限切れ 新規登録 /有効日数=30日 ライセンス確認 [有効日数>=0] /有効日数-=1 ライセンス購入 /有効日数＋=365日 ライセンス確認 [有効日数<0] ライセンス確認 [有効日数<0] ライセンス購入 /有効日数+=365日 ライセンス確認 [有効日数>=0] /有効日数-=1 ライセンス購入 /有効日数+=365日 ※ ミリーチャート、ムーアチャート、ハレルチャート、UMLのステートマシン図など、状態遷移図の表現は さまざま存在している。本資料ではミリーチャートをベースに独自にカスタマイズした記法を用いている。
109. 状態遷移表の例 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 109 イベント 遷移前状態 新規作成 ライセンス購入 ライセンス確認 [有効日数<0] [有効日数>=0] 未登録 有効期間 ＝ 30日 試用中 N/A N/A N/A 試用中 有効日数 ＋＝ 365 ― 有効日数 －＝ 1 N/A 契約期間中 期限切れ 試用中 契約期間中 有効日数 ＋＝ 365 ― 有効日数 －＝ 1 N/A 契約期間中 期限切れ 契約期間中 期限切れ 有効日数 ＝ 365 N/A 契約期間中 N/A N/A ※ アクションを省略しているものや、状態×状態で表したものなど、状態遷移表の表現もさまざま存在している。
110. 着目する点 • テスト対象の状態や、遷移、イベントに着目 ポイント • 故障が発生するのは遷移したタイミングとは限らない （例：ある遷移で内部変数を壊しても、故障として 現れるのは、壊した内部変数を参照した時になる） • 特定の経路や状態をテストするのか、すべての状態を網羅するの か、遷移を網羅するのか、nスイッチカバレッジを網羅するのかを 決定する メリット • 状態遷移モデルにすることで、取り得る経路を整理でき、nスイッ チカバレッジなども網羅基準を基に、テストケースを導出できる キーワード • 状態、遷移、イベント、ガード条件、アクション • 状態遷移表、状態遷移図、ステートマシン図 • nスイッチ 状態遷移テストの特徴 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 110
111. 状態遷移テストのカバレッジ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 111 29119-4ではこの技法のカバレッジとして次の4つを示している。 1. 全状態カバレッジ (all states coverage) 2. 0スイッチカバレッジ (0-switch coverage) 3. 全遷移カバレッジ (all transitions coverage) 4. Nスイッチカバレッジ (N-switch coverage)
112. ブラックボックステスト技法に対するツールの支援 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 112
113. 本講の構成 研修の目的 ソフトウェアテストとは？ テストレベル テストタイプ テストプロセス テスト技法 まとめ Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 113
114. この研修のゴール 1. ソフトウェアテストについての全体像を俯瞰し、整理できる 軸を持つことでさまざまなテストの用語がどういった特性 の言葉であるか判断できるようになりましょう 2. テストの要素技術に関するエントリーポイントを把握して、 効率よくテストについて学べる下地を持ちましょう Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 114
115. Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 115
116. その際にはSQuBOKガイドなどもオススメします 全体の軸を持った上でSQuBOK ガイドなどを効率よく知識を吸収し ていけます 品質やテストに関する用語で分か らないものがあればまずはこれに あたり詳細についてはガイドが示 す参考資料をあたるのをオススメ します Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 116
117. Copyright © 2017-2024 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層）」より 117
118. 「品質に関わる新たな 情報を得るための諸活動」 ※以下のテストの目的をすべて満たします 欠陥を摘出する 対象ソフトウェアの品質レベル が十分であることを確認する 意志決定のための 情報を示す 欠陥の作りこみを防ぐ 上記4つのテストの目的は、テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 「テストとは？」を整理すると Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 118
119. 分けるためにも概観できるテストの軸が重要 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テストの空間のどこに位置しているかを 意識した上でテスト技術などの各種要 素を考えることで、文脈を理解しやすい ※図はイメージです 119
120. テストプロセスの例（JSTQB） プロジェクトタイムライン Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 120
121. 対応関係 上流工程の開発と下流工程のテストにおける責務との対応関係 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 段 階 的 な 詳 細 化 段 階 的 な 統 合 121 要求分析 受け入れテスト アーキテクチャー設計 システム統合テスト 基本設計 システムテスト 詳細設計 コンポーネント統合テスト 実装 コンポーネントテスト
122. JSTQBによるテストタイプの分類 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 122 テスト技術者資格制度 Foundation Levelシラバス日本語版Ver.4.0J02「2.2.2 テストタイプ 」より文章を引用（強調と作図は独自）。 機能テスト コンポーネント、およびシステムが実行する機能を 評価する。機能とはテスト対象が「何」をすべきか である。機能テストの主な目的は、機能完全性、機 能正確性、および機能適切性をチェックすること である。 非機能テスト コンポーネント、およびシステムが実行する機能特 性以外の属性を評価する。非機能テストは、システ ムが「どのようにうまく振る舞うか」をテストする。 非機能テストの主な目的は、 非機能的なソフト ウェア品質特性をチェックすることである. ブラックボックステスト 仕様に基づき、テスト対象の外観を示すドキュメン トからテストを導出する。ブラックボックステスト の主な目的は、システムの動作をその仕様に照ら してチェックすることである。 ホワイトボックステスト 構造に基づき、システムの実装または内部構造 （コード、アーキテクチャー、ワークフロー、データ フローなど）からテストを導き出す（4.3 節参照）。 ホワイトボックステストの主な目的は、テストに よって基本的な構造を受け入れ可能なレベルまで カバーすることである。
123. テストの空間の第1面（テストタイプ×テストレベル） Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 123 受け入れテスト システム統合テスト システムテスト コンポーネント統合テスト コンポーネントテスト 機 能 テ ス ト セ キ ュ リ テ ィ テ ス ト 相 互 運 用 性 テ ス ト 使 用 性 テ ス ト ・・・ ホ ワ イ ト ボ ッ ク ス テ ス ト そ の 他 の テ ス ト タ イ プ 非機能テスト
124. テストの空間の第2面（テストプロセス×テストレベル） Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 124 受け入れテスト システム統合テスト システムテスト コンポーネント統合テスト コンポーネントテスト テ ス ト 計 画 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テ ス ト 完 了 テ ス ト の Ｍ ＆ Ｃ
125. テストの空間の第3面（テストプロセス×テストタイプ） Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 125 機能テスト 非 機 能 テ ス ト セキュリティテスト 相互運用性テスト 使用性テスト ･･･ ホワイトボックステスト その他のテストタイプ テ ス ト 計 画 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テ ス ト 完 了 テ ス ト の Ｍ ＆ Ｃ
126. テスト空間のどの文脈？かの例 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. テストレベル テストプロセス テストタイプ テスト自動化 ※図はイメージです 126 機能テスト システムテスト テスト実行
127. 教科書通りにそのままやろうとしても駄目 テーラリングが大事 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 127
128. テストの技術だけでは駄目 バランスが大事 Copyright © 2017-2024 Takashi YAMASAKI All right reserved. 128
129. テスターのスキルスペース Copyright © 2017-2024 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) 129
130. テスト以外の知識も必要です TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Copyright © 2017-2024 Takashi YAMASAKI All right reserved. Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf) 130
131. 本講を切っ掛けにソフトウェアテストの 頂への第一歩を踏み出してください！！ http://images.freeimages.com/static/images/logo.png フ リ ー 写 真 素 材 ぱ く た そ ・ 無 料 ダ ウ ン ロ ー ド 主な参考文献・参考資料 JSTQB/ISTQB関連 • ISTQB Glossary （用語集） • テスト技術者資格制度Foundation Level シラバス Version 2023V4.0.J02 • テスト技術者資格制度Advanced Levelシラバス日本語版テストマネージャ • 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-2024 Takashi YAMASAKI All right reserved. 131