テスト開発について改めて考えてみよう！ ～ テスト分析やテスト設計を業務で上手くできるようになるための四方山話～

WACATE 2023 夏の講演スライドです。
https://wacate.jp/workshops/2023summer/program/#close_ses

Abostract
ソフトウェアテストの初学者が、必ずと言って良いほど学ぶ要素技術に、テスト技法（テスト設計技法）があります。実際に、テスト技法に関する書籍は非常に多く出版されていますし、JSTQB Foundation Levelにおいても、さまざまなテスト技法を習得することを求めています。
しかし、一方で、それらを学んでも、いざ業務となったときに上手い具合にテストケースを作れないというお悩みを聞く機会は少なくありません。
そんな、テスト技法を学んでみたり、JSTQBのFoundation Levelを取得してみたりしたけど、なかなか業務で活かせないという若手テスト技術者に向けて、あらためてテスト開発が何であるのか、それをひもといてみたいと思います。
また、ベテランのみなさまには、自身のテスト開発に関する知識の棚卸しとともに、自分が迷える若手にどのように手を差し伸べればよいのか、その一例として聞いていただければと思います。
ぜひ、明日からの業務でテスト分析やテスト設計をすこしでも上手くやるためのヒントを、一つでも多く持ち帰ってください。
なお、本講では、JaSST’17 TohokuやJaSST’21 Hokuriku、JaSST’22 Shikokuなどで講演した内容をベースとして、WACATEに参加するみなさん向けに再構成してお話しします。

Transcript

1. ～テスト分析やテスト設計を業務でうまくできるようなるための四方山話～ 2023年6月11日(日) 於 WACATE 2023 夏 Copyright © 2023 Takashi YAMASAKI All right reserved. 1
2. 本資料の公開先 Copyright © 2023 Takashi YAMASAKI All right reserved. 2 https://bit.ly/42AvFLR
3. 山﨑 崇 （YAMASAKI Takashi） （株）ベリサーブ ソフトウェア品質コンサルティング部 兼 品質保証部プロジェクト推進課 課長 2001年からセキュリティ対策ベンダーにおいて、さまざまなプロジェクトのソフトウェアテスト 活動にQAエンジニアとして従事。その傍ら、さまざまなテストコミュニティに参画し、活動の場を 広げる。2015年にベリサーブに入社。現場への技術支援、教育、コンサルテーションなどを担い、 少しでも現場が幸せになるように日々奮闘中。 主な活動 • JaSST東京実行委員会 （’11～） • テスト設計コンテストU-30審査委員 （’16～） • ASTER テストプロセス改善研究会 （’16～） • JSTQB Foundation Level 認定講師 （’12～） • WACATE(’07～’14） など 主な著書・訳書 • 実践ソフトウェアエンジニアリング 第9版 （共訳） • 開発現場で役立つテスト「超」実践講座 第9回 （著） • テスト技術者資格制度Foundation Level Extensionシラバス アジャイルテスト担当者 （共訳） • システム開発ジャーナル Vol. 10 （共著） など 主な講演 • JaSST’21北陸 基調講演「テストを学び成長する」 🔗 • JaSST’17東北 基調講演「テストの極みを目指して」 🔗 • JaSST’15東京 チュートリアル「初心者からの脱出」 🔗 • テスト設計コンテストチュートリアル U-30クラス（’17～’19）ちびこん編（’21 🔗） • SQiP研究会 品質保証の基礎コース 第7回 「ソフトウェアテストの概観を識る」 （’17, ’20～） 🔗 • 第14回SPIトワイライトフォーラム 「テストプロセス改善モデルの最新動向」 🔗 など その他 https://www.linkedin.com/in/yamasaki696/ を参照 Copyright © 2023 Takashi YAMASAKI All right reserved. 3
4. 特技ソフトウェアテスト 趣味ソフトウェアテスト Yes, I'm loving Software Testing! @yamasaki696 Copyright © 2023 Takashi YAMASAKI All right reserved. 4
5. Copyright © 2023 Takashi YAMASAKI All right reserved. 5
6. テスト技法を勉強して演習で はうまく使えたのに実務では どうやって技法を適用すれば 良いのか分からずうまく使え ていません🥺 良く聴くお悩み Copyright © 2023 Takashi YAMASAKI All right reserved. 6
7. Test Design Technic Test Basis Test Cases Test Basis Test Cases Test Cases テ ス ト ベ ー ス ※ に 対 し て い き な り テスト設計技法を適用している？ ※テストベースとはテストを考える上で入力となる情報全般のこと。例えば要件定義書、仕様書、外部設計書など様々 Test Design Technics Copyright © 2023 Takashi YAMASAKI All right reserved. 7
8. Test Design Technic Test Basis Test Cases Test Basis Test Cases Test Cases Test Design Technics そ れ は 失 敗 フ ラ グ で す Copyright © 2023 Takashi YAMASAKI All right reserved. 8
9. テスト設計※またはテスト計画、テスト準備など表現は様々 テスト 実行 テスト 要求分析 テスト ｱｰｷﾃｸﾁｬ 設計 テスト 詳細設計 テスト 実装 テスト 実行 テスト分析 テスト設計 テスト実装 テスト 実行 昔の プロセス JSTQBの テスト開発 プロセス 最新の テスト開発 プロセス テストを実行する前の段階をより 詳細化してイメージできるようになろう Copyright © 2023 Takashi YAMASAKI All right reserved. 9
10. テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テスト開発 ＝ テスト分析 ＋ テスト設計 ＋ テスト実装 つまり、計画に基づいてテストを実行可能な状態にするために、テストを開発する一連の活動を範囲としている。 ただし、JSTQB FLシラバス(2018)以降では「テスト開発」や「テスト開発プロセス」という用語は使われなくなりました テストのライフサイクルにおける「テスト開発プロセス」の範囲 Copyright © 2023 Takashi YAMASAKI All right reserved. 10
11. テスト開発プロセスを一番俯瞰したPFD テスト開発 テストベース テスト Copyright © 2023 Takashi YAMASAKI All right reserved. 11
12. おおざっぱなPFD（Process Flow Diagram)の説明 要素 形状 説明 形状の別表現 プ ロ セ ス “作業を表します。 階層を持つ場合には線を太くしたり二重にす ると良いでしょう 成 果 物 “プロセスに出入りする成果物を表します。 ソースファイルや分冊の様子や、形になってい ない「ノウハウ」など、適当な記号を使います。 フ ロ ー “成果物とプロセスを繋ぐ線。両側に矢印を付 けて更新の意図をあらわしたり、線上に成果物 を構成する要素を書くこともできます。 出典: https://affordd.jp/koha_hp/process/PFDform3.pdf P.16 要素 Copyright © 2023 Takashi YAMASAKI All right reserved. 12
13. テスト開発プロセスを1段階深掘りしたPFD テスト分析 テストベース テスト条件 テストケース 仕様書 テスト手順 テスト設計 テスト実装 テストケース ※分かりやすくするためにテスト開発プロセスのすべてを表していない点に留意すること。 また、一方通行に進むのではなく各活動は反復して行われうる点にも留意すること Copyright © 2023 Takashi YAMASAKI All right reserved. 13
14. テスト開発プロセスをさらに深掘りしたPFD テストする フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト すべきことを 決める テスト条件 テストベース なにを網羅 すればテスト 条件を満た せるか考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果 などを定義する テストケース テストケースを 実行する単位に まとめる テストセット テストセットを 実行可能にする テスト手順を 実装する テスト手順 ※分かりやすくするためにテスト開発プロセスのすべてを表していない点に留意すること。 また、一方通行に進むのではなく各活動は反復して行われうる点にも留意すること Copyright © 2023 Takashi YAMASAKI All right reserved. 14
15. 見え方は異なるが、ISO/IEC/IEEE 29119-2:2013のテスト設計と実装プロセスと基本的に同じ Copyright © 2023 Takashi YAMASAKI All right reserved. 15 フィーチャー セットを 識別する (TD1) テスト条件を 得る (TD2) テスト カバレッジ アイテムを 得る(TD3) テスト ケースを 得る (TD4) テスト セットを まとめる (TD5) テスト 手順を 得る (TD6) テスト設計 仕様 テストケース 仕様 テスト 手順仕様 フィーチャー セット テスト条件 テストカバレッジ アイテム テストケース テストセット テスト手順& テストスクリプト ISO/IEC/IEEE 29119-2:2013 test processes, P.30 Figure 10 – Test Design and Implementation Process より。 翻訳は筆者による。
16. フィーチャー テスト条件 Copyright © 2023 Takashi YAMASAKI All right reserved. 16
17. 定義を見ても、よく分からないですよね・・・・（定義も変わったりするしね） JSTQBの用語定義 ISO/IEC/IEEE 29119での定義 フ ィ ー チ ャ ー フィーチャー： 要求仕様ドキュメントで、明示的、暗示 的に規定したコンポーネントやシステムの属性（たとえ ば、信頼性、使用性、設計上の制約など）。 フィーチャーセット： 後続のテスト設計活動でほかの フィーチャーセットとは独立して扱うことのできる、論 理的なテストアイテムの部分集合。 テ ス ト 条 件 • コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機 能、トランザクション、フィーチャ、品質特性、構造要 素など（昔の定義） • テストのための根拠となる、コンポーネントやシステ ムのテストが可能な一部分（新しい定義） コンポーネントやシステムにおけるテストの根拠として 識別された、機能、トランザクション、フィーチャー、品 質特性、構造要素など、テスト可能な側面。 ※最新のISTQBの用語集では、featureの定義がなくなっている Copyright © 2023 Takashi YAMASAKI All right reserved. 17 誤解を恐れずに言えば、フィーチャーやテスト条件に関する統一的な見解はないと言えます
18. 最新のISO/IEC/IEEE 29119-2:2021のテスト設計実装 プロセスではテスト条件じゃなくテストモデルですしね… テストモデルの 作成 (TD1) テストカバレッジ アイテムの識別 (TD2) テストケースの 導出 (TD3) テスト手順の 作成 (TD4) テストモデル テストカバレッジアイテム テストケース テスト手順 ISO/IEC/IEEE 29119-2：2021 P.32 Figure 10 Test design and implementation process より引用。翻訳は筆者による Copyright © 2023 Takashi YAMASAKI All right reserved. 18
19. Copyright © 2023 Takashi YAMASAKI All right reserved. 19
20. 発想を転換しよう！ Copyright © 2023 Takashi YAMASAKI All right reserved. 20 JSTQB や ISO/IEC/IEEE 29119 の 定 義 に 沿っているかどうかではなく、フィーチャーに 何をおいて、テスト条件に何をおくと、自分の考え たテストを説明しやすくなり、利害関係者と合意形 成しやすくなるのかで決めてみよう
21. あくまで一例ですが、このような整理でも良いと思います Copyright © 2023 Takashi YAMASAKI All right reserved. 21 ⚫ フィーチャー（feature）と厳密に対応する日本語はない。あえて言えば「特徴」や「特性」であ り、テスト対象が持つ特徴であれば、何でもフィーチャーとして捉えることができる ⚫ 誤解を恐れずに例えば、分かりやすさのためフィーチャーは機能や非機能や構造（もちろん、 それだけに限らない）とおいてみる ⚫ システムテストの機能テストでテスト分析するなら、例えばフィーチャーセットはシステムの機 能の一覧となる ⚫ もちろん、テストベースで◦◦機能と記述されるものが、システムテストの機能テストにお いて、丁度良い機能としての単位になっているかは限らないので、テストの観点から再整 理する必要があるかもしれない ⚫ 識別したある機能が、例えば複雑な論理条件の組み合わせによって動作を決定するような機 能なのであれば、その論理判定の処理が正しく動作するかどうかをテスト条件として識別し て、デシジョンテーブルテストを使ってみる。つまり、その機能がもつさまざまな側面をテスト 条件として識別して技法を適用してみる ⚫ 機能について、もちろん複数のテスト条件を識別しえます ⚫ 正しい、正しくないではなく、どう整理すると説明しやすくなるかで検討してみよう
22. Copyright © 2023 Takashi YAMASAKI All right reserved. 22 テストの導出結果は実施者によって異なります そもそも「全数テストは不可能※1」であり「テストは状況次第※2 」なので テストが一意的に収束することはなく、絶対的な正しいテストはない
23. Copyright © 2023 Takashi YAMASAKI All right reserved. 23 どんなテストをするのかを利害関係者と すり合わせて合意を得ることが重要であり、 そのためにはテストを説明できる必要がある
24. そのためにもテスト対象を理解するためにテストベースに深く深く潜っていく Copyright © 2023 Takashi YAMASAKI All right reserved. 24
25. 3色ボールペンでテストベースの情報を分析・補完した例 Copyright © 2023 Takashi YAMASAKI All right reserved. 25 • パスワードは8文字以上32文字以下の 英数字のみを許容する。 • パスワードを3分以内に連続して4回以上 間違って入力すると、アカウントを5分間 ロックする。 パスワードの文 字列長 パスワードの文 字種 許容しない場合 どうなる？ 要件を満たさない文字入力を はじくのか、エラーとして 処理するのか？ 誤入力回数管理 誤入力期間管理 ロック状態 保持期間 時間精度 ミリ秒の精度は手動では 無理。他の方法で担保する 必要がありそう アカウントの 状態遷移 4回目でロックに なって、ロック中に 再度入力するとど うなるの？ 秒？ミリ？ ★全体としてセキュリティの ための機能としては脆弱に 見える もしブルートフォース攻撃に対してセ キュリティを確保するためであるなら、 セキュリティ要件を満たしていない可 能性はないか？ 回数のクリア タイミング どれだけテストベースを汚せるかがポイントで、不明部分をテストの視点から洗い出す。 この時点で曖昧性や矛盾などを取り除くとともに書かれていない情報を補っていく。
26. 3色ボールペンの使い方の例 Copyright © 2023 Takashi YAMASAKI All right reserved. 26 ⚫ 赤： 客観的に見て、最も重要な箇所 ⚫ たとえばフィーチャーやテスト条件など ⚫ 青： 客観的に見て、まあ重要な箇所 ⚫ たとえばフィーチャーやテスト条件を構成する要素など ⚫ 緑： 主観的にみて、おかしいと感じた箇所 ⚫ たとえば不明点、疑問点など 正しく色を使い分けることを意識しすぎると、仕様書を汚せなくなるのであくまで色は目安。 色の選択に悩んでしまうくらいであれば、単色でもよいので仕様書を汚すことに注力しよう。 出典: 「ソフトウェア・テストPRESS Vol.2」 三色ボールペンで読む仕様書（鈴木三紀夫氏）
27. なぜ仕様書を汚して、情報を分析・補完するのか？ Copyright © 2023 Takashi YAMASAKI All right reserved. 27 ⚫ 多くの場合、分析対象のテストベースの仕様書などは十全ではない ⚫ テストに必要なすべての情報が記述されているわけではない ⚫ 抜け漏れや誤りを含んでいることもある ⚫ 多くの場合、分析対象のテストベースはテストのために作られていない ⚫ 開発とテストでは関心事が異なるが、仕様書や設計書は第一義に開発のための文書 ⚫ 開発のために構造化された情報は、テストを考える上での構造と異なることも多い
28. テスト担当者のスキルスペース TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf) Copyright © 2023 Takashi YAMASAKI All right reserved. 28
29. 深く潜るためにもテスト開発に限らずテスト担当者には テスト以外のスキルや知識も必要となります Copyright © 2023 Takashi YAMASAKI All right reserved. 29 TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)
30. テストのスキルだけでは駄目で、バランスが大事！ Copyright © 2023 Takashi YAMASAKI All right reserved. 30
31. 3色ボールペンで汚した仕様書を基に構造化した例 Copyright © 2023 Takashi YAMASAKI All right reserved. 31 パスワード判定 長さ 文字種 セッションの制御 ログイン状態 ロック中 ログイン中 ログアウト中 誤入力回数 誤入力期間 アカウント作成機能 ユーザー名の判定 アカウント フィーチャーとして「アカウント作成機 能」を識別して、アカウント作成時にパス ワードの長さや使用している文字種を 判定しているので、それらが仕様通りに 動作しているかをテスト条件として識別 するとよさそうかな？ テスト対象のシステムはセッションを管理して いるので、「セッションの制御」をフィーチャーと してまずは識別したほうがよいかな？それを構 成している要素を考えると、なにをテスト条件 として定義すると、テスト設計しやすいかな？
32. 3色ボールペンで汚した仕様書を基に構造化した例 Copyright © 2023 Takashi YAMASAKI All right reserved. 32 パスワード判定 長さ 文字種 セッションの制御 ログイン状態 ロック中 ログイン中 ログアウト中 誤入力回数 誤入力期間 アカウント作成機能 ユーザー名の判定 アカウント フィーチャーとして「アカウント作成機 能」を識別して、アカウント作成時にパス ワードの長さや使用している文字種を 判定しているので、それらが仕様通りに 動作しているかをテスト条件として識別 するとよさそうかな？ テスト対象のシステムはセッションを管理して いるので、「セッションの制御」をフィーチャーと してまずは識別したほうがよいかな？それを構 成している要素を考えると、なにをテスト条件 として定義すると、テスト設計しやすいかな？ 文字種は、文字という要素の集ま りだから、同値分割法を使うとよ いかもしれないな パスワードの長さは、何文字かを チェックしているから、境界値分析 を使うと説明しやすそうだな 全体としては、状態を制御して いるから、状態遷移テストで考 えると、これらの仕様を扱いや すいかもしれないな
33. なぜ構造化するのか？ Copyright © 2023 Takashi YAMASAKI All right reserved. 33 ⚫ 全体を俯瞰しやすい ⚫ 大量のテストケースやテスト手順は枝葉であり全体を俯瞰し難い ⚫ 木や森を見るには関心事に応じた抽象度のほうが分かりやすい ⚫ そして、ステークホルダ毎に関心事は異なる ⚫ 構造化した結果に基づいて議論しやすい ⚫ ぱっと見て把握しやすい ⚫ MECE（漏れなくダブりなく）であるかを把握しやすい ⚫ 関係性が分かりやすい など
34. Tiramisによる基本構造構成要素 Copyright © 2023 Takashi YAMASAKI All right reserved. 34 誰が 誰に 出力 入力 事前条件 事後条件 環境 蓄積 トリガー 目的 処理 鈴木三紀夫氏のTwitterおよび「高信頼化ソフトウェアのための 開発手法ハンドブック」 P.153 図6-3 「Tiramisで使用してい る基本構造構成要素」をもとに、デザインを変更して掲載
35. ゆもつよメソッドによる論理的機能構造 Copyright © 2023 Takashi YAMASAKI All right reserved. 35 フィーチャー 外部マネジメント 入力調整 出力調整 変換 サポート（自フィーチャー内部呼び出し） 相互作用（他フィーチャー呼び出し） 貯蔵 テスト実行 入力 出力 外部観察 できる仕様 内部に 関わる仕様 機能組合せ AUT * 外部 フィーチャー フィーチャー *ＡＵＴ: Application Under Test 「(2021年版) ソフトウェアテストの上流設計-4 テスト分析と論理的機能構造」湯本剛氏）の図表をもとに、一部変更
36. HAYST法によるラルフチャート Copyright © 2023 Takashi YAMASAKI All right reserved. 36 Read Write 内部変数の組合せ（＝State） 信号因子 m{m 1 , m 2 , m 3 , …} Noise/Active Noise 誤差号因子 z{z 1 , z 2 , z 3 , …} az{az 1 , az 2 , az 3 , …} Input 信号因子 M{M 1 , M 2 , M 3 , …} Output レスポンス R 対象 R = 𝑓 𝐼𝑛𝑝𝑢𝑡, 𝑆𝑡𝑎𝑡𝑒, 𝑁𝑜𝑖𝑧𝑒, 𝐴𝑐𝑡𝑖𝑣𝑒 𝑁𝑜𝑖𝑧𝑒 出典: 「高信頼化ソフトウェアのための開発手法ハンドブック」 P.204 図3-3 ラルフチャートより。一部変更
37. なぜ、これらのテンプレート的なモデルを使うと便利なのか？ Copyright © 2023 Takashi YAMASAKI All right reserved. 37 ⚫ テスト実行する単位に基づいて考えたいので ⚫ 動的テストの基本は、テストの対象に入力を与えて出力を観測することである ⚫ つまり、テストを実行するにあたり、入出力のインターフェースを識別するとよい ⚫ それに影響を及ぼす要素を識別したいので ⚫ テスト対象によっても、どのように要素を構造化すると便利なのかは異なる ⚫ 将来的にはテスト対象の特性に合ったモデルを、自ら作れるようになるとよい
38. 理想は、要求の段階から 整理されているとよいよね Copyright © 2023 Takashi YAMASAKI All right reserved. 38
39. 機能 入力データ 入力イベント 出力データ 出力イベント P.77 「図 5-2 一般的な機能に対するコントロールフロー図 」 in 「要求プロセスと技法入門要求開発の基礎知識」山本修一郎著（2019） Copyright © 2023 Takashi YAMASAKI All right reserved. 39
40. Copyright © 2023 Takashi YAMASAKI All right reserved. 40 機能 入力イベント イベント 出力イベント 非機能要求 入力データ 出力データ データ 対象 入力元対象 出力元対象 機能要求 トリガ関係 フロー関係 実現 入力 入力 出力 出力 出力 トリガ関係 フロー関係 「要求プロセスと技法入門要求開発の基礎知識」山本修一郎著（2019） P.78 「図5-3 要求のメタモデル」 より、一部改変
41. Copyright © 2023 Takashi YAMASAKI All right reserved. 41 要求仕様 危険運転を警告する 契機 機能 応答 応答対象 センサーログの更新 ①センシングデータに基づき、危 険運転を判別する。 • 速度超過運転 • ふらつき運転 • 急ブレーキ連続運転 ②運転者ならびに周辺者に指定 された警告条件で警告する。 バイブレーション警告 ハンドル 入力対象 入力 音声警告 スピーカー センサーログ 車輪の回転パルス 警告サイン 運転者用ランプ ハンドルの回転角 警告サイン 簡易モニター 車体の傾き 周辺音声警告 周辺者用スピーカー 光量 周辺光警告 周辺者用ランプ 湿度 出力 出力対象 車体振動 危険運転警告記録 警告ログ 前方の物体 危険運転判断情報 管理 自動走行条件 走行環境条件 危険運転警告条件 情報管理 警告条件 -- タイミング -- 間隔 -- 期間 「要求プロセスと技法入門要求開発の基礎知識」山本修一郎著（2019） P.80 「表5-8 要求記述表の例」
42. テストとは、テストとそれに関係するテスト以外のこと についても考えに考え抜いてそれらの本質を知ること Copyright © 2023 Takashi YAMASAKI All right reserved. 42
43. そのためにもテストに対する全体観を持とう！ Copyright © 2023 Takashi YAMASAKI All right reserved. 43 テストレベル テストプロセス テストタイプ テストの空間のどこに対する 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです
44. テストに対する全体観を持とう！ Copyright © 2023 Takashi YAMASAKI All right reserved. 44 テストレベル テストプロセス テストタイプ テストの空間のどこに対する 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです
45. 担っているテストレベルによってテストアイテムがことなり、 テストアイテムのによって入出力のインターフェースも異なる Copyright © 2023 Takashi YAMASAKI All right reserved. 45 受け入れテスト 開発したシステムがユーザの求めているものに合致して いるか確認する（受け入れ可能かどうか判断する）テスト システムテスト 最終的に統合されたシステム全体を、実環境 （またはそれに準ずる環境）で実施するテスト 統合テスト テスト済みのコンポーネントや システムを統合して行うテスト コンポーネントテスト 分離してテストが可能なソフトウェアコンポーネント （部品）ごとに単体で行うテスト テ ス ト 対 象 と し て 着 目 す る 詳 細 度 小 大
46. 要件定義 外部設計 内部設計 実装 テスト 実装終わったらテストって乱暴すぎよね Copyright © 2023 Takashi YAMASAKI All right reserved. 46
47. 上流工程の開発と下流工程のテストにおける責務との対応関係 外部設計 内部設計 実装 要件定義 コンポーネント テスト 統合テスト システムテスト 受け入れテスト 対応関係 段 階 的 な 詳 細 化 段 階 的 な 統 合 Copyright © 2023 Takashi YAMASAKI All right reserved. 47
48. テスト自動化のピラミッド 出典:「実践アジャイルテスト」 P.274「図14-2 テスト自動化のピラミッド」に軸を付け加えた図（図の左側を独自に追加している。 GUIテスト 受け入れテスト (APIレイヤー) ユニットテスト/コンポーネントテスト 手動テスト 高い 低い 低い 高い 遅い 速い 費 用 対 効 果 保 守 性 実 行 速 度 Copyright © 2023 Takashi YAMASAKI All right reserved. 48
49. DevOpsでの継続的テストのループ 出典：Dan AshbyのContinuous Testing in DevOpsを引用した書籍「A Practical Guide to Testing in Dev Ops」の翻訳本より Dev PLAN BRANCH CODE MERGE BUILD Ops RELEASE DEPLOY OPERATE MONITOR ここで テスト ここで テスト ここで テスト そして ここでも さらに ここでもテスト ここでテストしないの？ もちろんできます！ ここでも テスト さらに ここでも テスト そして ここも もちろん… Copyright © 2023 Takashi YAMASAKI All right reserved. 49
50. テ ス ト レ ベ ル の 本 質 を 考 え て い く と ソフトウェア開発ライフサイクルに留まらず ソフトウェアライフサイクル全般における テストの全体像を考えていくことに繋がる Copyright © 2023 Takashi YAMASAKI All right reserved. 50
51. テストに対する全体観を持とう！ Copyright © 2023 Takashi YAMASAKI All right reserved. 51 テストレベル テストプロセス テストタイプ テストの空間のどこに対する 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです
52. 担っているテストタイプによっても関心のある フィーチャーやテスト条件は異なる Copyright © 2023 Takashi YAMASAKI All right reserved. 52 テストタイプ 機能テスト 機能の品質特性、例えば完全、 正確および適 切であること などを評価する。 非機能テスト 非機能の品質特性、例えば信 頼性、性能効率性、セキュリ ティ、互換性、使用性などを評 価する。 ホワイトボックス テスト コンポーネントまたはシステム の、構造またはアーキテクチャ が正しく完全で仕様通りであ ることを評価する。 変更関連のテスト 欠陥が修正されていることを確認するなどの変更による影響を評価し（確認テスト）、 ソフトウェアや環境の変更によって意図しない振る舞いの変化が発生していないかを 探す（リグレッションテスト）。 テスト技術者資格制度 Foundation Levelシラバス日本語版Version 2018V3.1.J03「2.3テストタイプ」より文章を引用し、独自に作図。
53. “製品品質モデル “ from “JIS X 25010:2013” 図4 システム/ソフトウェア製品品質 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 • 機能完全性 • 機能正確性 • 機能適切性 • 時間効率性 • 資源効率性 • 容量満足性 • 共存性 • 相互運用性 • 適切度認識性 • 習得性 • 運用操作性 • ユーザエラー 防止性 • ユーザインター フェース快美性 • アクセシビリ ティ • 成熟性 • 可用性 • 障害許容性 (対故障性) • 回復性 • 機密性 • インテグリティ • 否認防止性 • 責任追跡性 • 真正性 • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性 • 適用性 • 設置性 • 置換性 ISO/IEC 25010の製品品質モデル Copyright © 2023 Takashi YAMASAKI All right reserved. 53
54. 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/IEC25010:2013も現在絶賛改訂作業中です。 また、製品品質以外にも、SQuaREには利用時の品質、データ品質、サービス品質なども規定されていています。 Copyright © 2023 Takashi YAMASAKI All right reserved. 54 変更 新規追加 既存 凡例 図は、現在策定中（まだリリースされていない、ISO/IEC 25010の新しい製品品質モデルの主特性と副特性の案が出典。 策定中の情報についてはオフィシャルに表にでていませんが、この規格を策定するワーキンググループのコンビーナ（議長）である込山さんの資料を参照してください。 https://speakerdeck.com/washizaki/squareguan-lian-falsebiao-zhun-hua-falsequan-ti-dong-xiang-25010-25019gai-yao-ip-shan-jun-bo
55. Copyright © 2023 Takashi YAMASAKI All right reserved. 55 • さまざまなテストを考慮するにあたり、品質モデルの各特性をガイドワードとして利用する のは良いですが、テストの中にすべて押し込むのは乱暴で、テストでは測りがたい特性もあ ります（たとえば、保守性とか移植性とか） • 前提として品質モデルはテストのために作られたモデルではないですし、各品質の特性は 相関関係があります。そして、すべての品質特性をフル天にすれば良いわけでもありません • 各特性が「どれくらいであるべきか」は、本来的には品質要求事項と品質測定量の目標値と して定める必要があり、テストではその要求を満たしているのかを確認することになります • 例えば、時間効率性（パフォーマンス）として、何msの応答であれば妥当であるかは品質 要求次第ですし、時間効率性と使用性のどちらを重要視するかも要求次第です
56. 図：品質属性間のプラスとマイナスの相関関係 Karl E.著「ソフトウェア要求 第3版」 P.333より。 ※なお、デザインに手を入れている 可 用 性 効 率 性 導 入 可 能 性 完 全 性 相 互 接 続 性 修 正 可 能 性 性 能 移 植 性 信 頼 性 再 利 用 性 堅 牢 性 安 全 性 拡 張 性 セ キ ュ リ テ ィ ユ ー ザ ビ リ テ ィ 検 証 可 能 性 可用性 ＋ ＋ 効率性 ＋ － － ＋ － － ＋ － 導入可能性 ＋ ＋ ＋ 完全性 － － － － ＋ ＋ － － 相互接続性 ＋ － － － ＋ ＋ ＋ － － 修正可能性 ＋ ＋ － － ＋ ＋ ＋ ＋ 性能 － － － － － － － 移植性 － ＋ － － ＋ － － ＋ 信頼性 ＋ － ＋ ＋ － ＋ ＋ ＋ ＋ ＋ 再利用性 － － ＋ ＋ － ＋ － ＋ 堅牢性 ＋ － ＋ ＋ ＋ － ＋ ＋ ＋ ＋ ＋ 安全性 － ＋ ＋ － ＋ ＋ － － 拡張性 ＋ ＋ ＋ ＋ ＋ ＋ ＋ セキュリティ ＋ ＋ ＋ － － ＋ ＋ ＋ － － ユーザビリティ － ＋ － － ＋ ＋ ＋ － 検証可能性 ＋ ＋ ＋ ＋ ＋ ＋ ＋ ＋ ＋ ＋ 品質特性間の相関関係の例 Copyright © 2023 Takashi YAMASAKI All right reserved. 56
57. 基本的に製品のライフサイクル全体で考えるのものです Copyright © 2023 Takashi YAMASAKI All right reserved. 57 JIS X 25000:2017（ISO/IEC 25000:2014）のP.14 図3 「製品の品質ライフサイクル」を基に、一部改変 要求事項 製品 実装 妥当性確認 検証 妥当性確認 検証 妥当性確認 システムの利用時の 品質要求事項 コンピュータ システムの 品質要求事項 ソフトウェア製品の 品質要求事項 システムの利用時の 品質 コンピュータ システムの 品質 ソフトウェア製品の 品質 利用時の品質の ニーズ 利用される 利用される 利用される システムの 利用時の 品質モデル 製品の品質モデル
58. テストタイプを突き詰めていくと開発している 製品やサービスに求められていること、それら の存在意義といった根源的なことに繋がる Copyright © 2023 Takashi YAMASAKI All right reserved. 58
59. テストに対する全体観を持とう！ Copyright © 2023 Takashi YAMASAKI All right reserved. 59 テストレベル テストプロセス テストタイプ テストの空間のどこに対する 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです
60. テストプロセスの例（JSTQB） テストプロジェクトのタイムライン テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 t Copyright © 2023 Takashi YAMASAKI All right reserved. 60
61. テスト モデルを 特定する 4つの テスト モデル モデルに 紐づいた テスト観点 テスト 観点を 詳細化 する 詳細化された テスト観点 (テストパラメータ) 網羅 基準を 設定する 網羅基準 テストケース (テスト値) 基準に 基づいて ケースを 導出する 網羅基準に 紐づいた テスト パラメータ テスト技法 テスト 観点間の 関係性を 見出す テスト フレーム 同じような 意味を持つ テスト観点や テストフレーム をまとめる テスト コンテナ テスト コンテナ間の 関連性を 整理する テスト アーキテクチャ テスト すべきことを 洗い出す テストベース 様々な テスト観点 テスト観点を 構造化する 構造化された テスト観点 (中間状態) ドメイン知識/ ガイドなど リファイン する 最終的に 構造化された テスト観点 JSTQB や ISO/IEC/IEEE 29119 の 通 り に や れ ば 良 い テ ス ト を 作れるわけではないので、どうやれば自分達のコンテキストでうまく テストを作れてるテスト（開発）プロセスを設計することを考えると良い Copyright © 2023 Takashi YAMASAKI All right reserved. 61
62. 外部設計 システムテスト 内部設計 コーディング 統合テスト 要件定義 受け入れテスト 同上 同上 同上 テスト完了 テスト実行 テスト実装 テスト設計 テスト分析 モニタリングおよびコントロール テスト 計画 ソフトウェアライフサイクルの中で継続的に行っていく 各 テ ス ト の 特 徴 を 見 据 え た プ ロ セ ス を 設 計 す る Copyright © 2023 Takashi YAMASAKI All right reserved. 62
63. Deploy Stage Test Build Commit 継続的Delivery（CD） 継続的インテグレーション（CI） 継続的デプロイメント（CD） ラ イ フ サ イ ク ル の 中 に パ イ プ ラ イ ン も 構 築 し て い く Copyright © 2023 Takashi YAMASAKI All right reserved. 63
64. テ ス ト プ ロ セ ス を 突 き 詰 め て 考 え て い く と テストを実現するためのプロセスだけではなく ソフトウェア開発ライフサイクルやソフトウェアライ フサイクルとの融合やパイプライン化に繋がる Copyright © 2023 Takashi YAMASAKI All right reserved. 64
65. すべてのテストを考える場合と 特定の一部のテストを考える場合 Copyright © 2023 Takashi YAMASAKI All right reserved. 65 特定の一部のテスト考える場合 ⚫ 大規模プロジェクトや、既にテストレベルやテストタイプが決まっている場合、テストの一 部を担い、そのスコープの中に閉じてテスト開発することになる ⚫ みなさんの実務的には、このパターンが多いかもしれない すべてのテストを考える場合 ⚫ 本質的には、テスト対象やテストのコンテキストを分析した結果としてテストレベルや テストタイプ自体を設計することももちろんある
66. テストに対する全体観を持とう！ Copyright © 2023 Takashi YAMASAKI All right reserved. 66 テストレベル テストプロセス テストタイプ テストの空間のどこに対する 要素であるかを意識した上で テスト技術などの要素を考える ※図はイメージです
67. テストの空間の第1面（テストタイプ×テストレベル） 受け入れテスト システムテスト 統合テスト コンポーネントテスト 機 能 テ ス ト セ キ ュ リ テ ィ テ ス ト 相 互 運 用 性 テ ス ト 使 用 性 テ ス ト ・・・ ホ ワ イ ト ボ ッ ク ス テ ス ト 変 更 関 連 の テ ス ト 非機能テスト Copyright © 2023 Takashi YAMASAKI All right reserved. 67
68. テストの空間の第2面（テストプロセス×テストレベル） 受け入れテスト システムテスト 統合テスト コンポーネントテスト テ ス ト 計 画 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テ ス ト 完 了 テ ス ト の Ｍ ＆ Ｃ Copyright © 2023 Takashi YAMASAKI All right reserved. 68
69. テストの空間の第３面（テストプロセス×テストタイプ） 機能テスト 非 機 能 テ ス ト セキュリティテスト 相互運用性テスト 使用性テスト ･･･ ホワイトボックステスト 変更関連のテスト テ ス ト 計 画 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 行 テ ス ト 完 了 テ ス ト の Ｍ ＆ Ｃ Copyright © 2023 Takashi YAMASAKI All right reserved. 69
70. Copyright © 2023 Takashi YAMASAKI All right reserved. 70
71. 写真素材 ご 静 聴 あ り が と う ご ざ い ま し た ！ 本講を切っ掛けにソフトウェアの深淵を覗く 旅 へ の 第 1 歩 を 踏 み 出 し て く だ さ い Copyright © 2023 Takashi YAMASAKI All right reserved. 71