ISTQB/JSTQBシラバスから学ぶAgileTesting / A guide of agile testing based on ISTQB syllabus

ISTQB/JSTQBシラバスから学ぶ
AgileTesting
JSTQB Advanced Level 試験対策勉強会
たのっち
2021/8/25 於 :開発×テスト LT会 #devtestlt

View Slide

はじめに
• 本発表は個⼈の⾒解に基づく内容となります。
• ISTQB/JSTQBの公式⾒解ではありません。
• JSTQB公式⽇本語訳が存在しないシラバスや和書が出版されて
いない⽂献は、⾃家翻訳を⾏った⽇本語訳を⽤いて引⽤して
います。
• google翻訳、DeepLで翻訳を⾏ったうえで、⽤語の統⼀を⾏うなどの
修正を⾏ったものです。

View Slide

About me
• 某ITコンサル会社所属、ただの開発者
• 第⼀⾔語はGo⾔語
• JSTQB AdvancedLevel テストアナリスト/テストマネージャ
• 趣味でソフトウェアテスト（の勉強会と問題集）をやっていま
す。

View Slide

JSTQB/ISTQB とは
• テストエンジニア向け国際資格
• ⽇本の資格取得者は約2万⼈
• ⽇本国内では4区分の試験が実施さ
れています。
• 学習⽤として4区分の⽇本語シラバ
スが公開されています。
（試験未実施）

View Slide

JSTQB Advanced Level 試験対策勉強会とは
• 国内ではAdvancedLevelの公式教科書・問題
集・研修が存在しない
• 「みんなで模擬問題を作って試験対策しよ
う」と有志が集まり2018年11⽉から勉強会を
開催
• 勉強会内で作成した模擬問題をまとめた
JSTQB”⾮認定”問題集を6区分で作成し同⼈誌
として頒布中
• 技術書典オンラインマーケット, booth.pmでお求め
いただけます

View Slide

今⽇のお題
• Agile2区分のシラバスの内容の⼀部
を取り上げます
• アジャイルテスト担当者シラバス3章
の⼀部
• Agile Technical Testerシラバス 1
章・2章の⼀部
• 詳細な内容, 正しい内容はシラバス
や参考⽂献を参照してください。
• 該当する同⼈問題集は下記2冊

View Slide

最初にまとめ
• 品質はチームのもの
• リスク評価は「相対⾒積もり」でできる
• より⾼リスクなプロダクト/システムは厚めにテストしよう
• より⾼リスクなユーザーストーリーは⾃動テストを整備しよう
• リスク分析結果も定期的にふりかえろう
• 探索的テストはセッションベースドかつテストチャーターを⽤
いて⾏おう
• 要求エンジニアリングの技法を使ってテストを考えよう

View Slide

品質はチームのもの
アジャイルプロジェクトにおいては、チーム全体が品質に対する
責任を持っている。チーム全体アプローチの本質は、テスト担当
者、開発者およびビジネス代表者が、開発プロセスの各ステップ
で協⼒して作業することにある。テスト担当者は、開発者およ
びビジネス代表者と密接に連携し、望まれる品質レベルが確実に
達成されるようにする。これには、適切な受け⼊れテストを作成
できるようにビジネス代表者をサポートし協調すること、開発者
と協調して、テスト戦略に合意し、テスト⾃動化の⽅式を決定す
ることが含まれる。このように、テスト担当者は、テストに関す
る知識を他のチームメンバに伝達および展開して、プロダクトの
開発に良い影響をおよぼすことができる。
ISTQBテスト技術者資格制度Foundation Level Extension シラバスアジャイルテスト担当者⽇本語版 Version 2014.J01
1.1.2 チーム全体アプローチより引⽤

View Slide

品質はチームのもの
アジャイルプロジェクトにおいては、チーム全体が品質に対する
責任を持っている。チーム全体アプローチの本質は、テスト担当
者、開発者およびビジネス代表者が、開発プロセスの各ステップ
で協⼒して作業することにある。テスト担当者は、開発者およ
びビジネス代表者と密接に連携し、望まれる品質レベルが確実に
達成されるようにする。これには、適切な受け⼊れテストを作成
できるようにビジネス代表者をサポートし協調すること、開発者
と協調して、テスト戦略に合意し、テスト⾃動化の⽅式を決定す
ることが含まれる。このように、テスト担当者は、テストに関す
る知識を他のチームメンバに伝達および展開して、プロダクトの
開発に良い影響をおよぼすことができる。
1.1.2 チーム全体アプローチより引⽤
具体的に
どういうことをするの？
ISTQB/JSTQBシラバスから
いくつかピックアップします

View Slide

まとめ
ü品質はチームのもの
• より⾼リスクなプロダクト/システムは厚めにテストしよう
いて⾏おう

View Slide

どちらを厚めにテストする？
銀⾏システムとワクチン予約サイト
⾃動テストや仕様ベースのテストを充実させたほうがよいのはどちらでしょうか。

View Slide

どちらを厚めにテストする？
映画館のチケット発券機タッチパネル画⾯とチケット予約Web画⾯
⾃動テストや仕様ベースのテストを充実させたほうがよいのはどちらでしょうか。

View Slide

リスクを分析しよう
• リスク分析中に、個々のシステムの機能について、リスクレベ
ル（⾼、中、低など）が決定されます。
• 安全性が重要なシステムで使⽤できるさまざまなテスト⼿法
（探索的、⾃動、⼿動）の組み合わせの例です。
リスクレベル⾃動テスト探索的テストブラックボックステスト
⾼ ++ + ++
中 + + +
低 o ++ +
ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1
2.2.1 Combining experience-based techniques and black-box tests より引⽤
■凡例
++ （強く推奨）
+ （推奨）
o （中⽴）
- （⾮推奨）
-- （使⽤しない）

View Slide

リスクを分析しよう
• リスク分析中に、個々のシステムの機能について、リスクレベ
ル（⾼、中、低など）が決定されます。
• 安全性が重要でないシステムで使⽤される場合の、さまざまな
テスト⼿法の組み合わせの例です。
リスクレベル⾃動テスト探索的テストブラックボックステスト
⾼ + ++ +
中 o ++ o
低 -- ++ --
■凡例
++ （強く推奨）
+ （推奨）
o （中⽴）
- （⾮推奨）
-- （使⽤しない）

View Slide

銀⾏システムのほうがテスト厚くなる

View Slide

プロダクトオーナー次第
どのような状況（セーフティクリティカルであろうとなかろうと）でも、仕様の組み
合わせはプロジェクトの特性によって異なります。
リスクレベル⾃動テスト探索的テストブラックボックス
テスト
⾼ + ++ +
中 o ++ o
低 -- ++ --

View Slide

それぞれのシステムに対して、この表をもとにしてテストアプローチを考える（こと
がAgile Technical Testerに求められる）
テスト
⾼ + ++ +
中 o ++ o
低 -- ++ --

View Slide

（例えば）
Web予約の⽐率は多くない。
券売機がトラブル起こしたときにリアル店舗で運⽤回避できないの
で、券売機のブラックボックステストを少し厚くしよう
テスト
⾼ + ++ ++
中 o ++ +
低 -- ++ o

View Slide

（例えば）
券売機がトラブル起こしてもリアル店舗で運⽤回避できる。
Web予約中⼼なのでWeb予約システムが⽌まると⼤打撃なので
Webシステムの⾃動テストを少し厚くしよう。
テスト
⾼ ++ ++ +
中 + ++ o
低 o ++ --

View Slide

QAだけでなくPOも開発者もリスク評価を
アジャイルプロジェクトでは、品質リスク分析を⼆つのタイミン
グで⾏う。
• リリース計画：リリースのフィーチャを把握しているビジネス
代表者は、リスクについて⾼いレベルでの概要を規定し、テス
ト担当者を含むチーム全体は、リスク識別と評価を⽀援する
• イテレーション計画：チーム全体が品質リスクを識別し評価す
る
3.2.1 アジャイルプロジェクトにおける品質リスクの評価より引⽤

View Slide

まとめ
üより⾼リスクなプロダクト/システムは厚めにテストしよう
いて⾏おう

View Slide

どちらが⾼リスク？
story1
来場者はクレジット
カードでチケットを
購⼊できる
story2
劇場スタッフは予約
開始前に関係者席を
確保できる
【背景】
関東地⽅で複数の映画館を運営するA社では⼈気作品公開の際に頻発する
「チケット争奪戦」に対処するため、
Web予約システムのリニューアルに向けたシステム開発を進めています。

View Slide

Story3のリスクはどれくらい？
story1
購⼊できる
story2
確保できる
Story3
来場者は⾼トラフィック
な状態でも座席を選ぶこ
とができる
【背景】
関東地⽅で複数の映画館を運営するA社では⼈気作品公開の際に頻発する
「チケット争奪戦」に対処するため、
Web予約システムのリニューアルに向けたシステム開発を進めています。

View Slide

リスク評価は相対⾒積もりできる
アジャイルプロジェクトの品質リスク分析プロセスをイテレーション計画時に実⾏する⽅
法の例を、次に⽰す。
1. テスト担当者を含むアジャイルチームメンバを招集する
2. 現在のイテレーションのすべてのバックログアイテムを（タスクボードなどに）⼀覧
化する
3. 各アイテムに関係する品質リスクを、すべての関連する品質特性を考慮して識別する
4. 識別した各リスクを評価する。ここでは、⽋陥の影響と発⽣確率に基づいて、リスク
の分類と、リスクレベルの決定という、⼆つの活動を⾏う
5. リスクレベルに応じて、テストの範囲を決定する
6. リスク、リスクレベルおよび関連する品質特性に基づいて、各リスクを軽減するため
の適切なテスト技法を選択する

View Slide

リスクポーカーは、⼀⽅では⼗分な品質と許容可能なリスク、他⽅では時間とリソースで
利⽤可能な制約の間の最適なバランスを達成するためのチーム全体のアプローチです。プ
ロダクトバックログのユーザーストーリーをリスク項⽬と⾒なします。スクラムマスター
はリスクポーカーセッションを開催しますが、ゲームには参加しません。ただし、プロダ
クトオーナーはゲームに参加します。プロダクトオーナーはすべてのステークホルダーを
代表し、最も重要な影響について必要な情報を提供できるようになります。各バックログ
項⽬の質問は、このユーザーストーリーにどのレベルのリスクを関連付ける必要があるか
ということです。
Agile Testing Foundations: An ISTQB Foundation Level Agile Tester guide
3. Agile testing methods, techniques and toolsより引⽤
リスク評価はプランニングポーカーと同じやり⽅でできる。

View Slide

story1
購⼊できる
story2
確保できる
Story3
来場者は⾼トラフィック
な状態でも座席を選ぶこ
とができる
低（重⼤度）⾼
⾼
︵
頻
度
︶
低

View Slide

どのくらいテストすればいいか割り出せる
リスクレベル
⾃動（システム）
テスト探索的テスト
ブラックボックス
テスト
⾼ + ++ +
中 o ++ o
低 -- ++ --
story1
購⼊できる
story2
確保できる
Story3
来場者は⾼トラ
フィックな状態で
も座席を選ぶこと
ができる

View Slide

QAだけでなくPOも開発者もリスク評価を
アジャイルプロジェクトでは、品質リスク分析を⼆つのタイミン
グで⾏う。
• リリース計画：リリースのフィーチャを把握しているビジネス
代表者は、リスクについて⾼いレベルでの概要を規定し、テス
ト担当者を含むチーム全体は、リスク識別と評価を⽀援する
• イテレーション計画：チーム全体が品質リスクを識別し評価す
る

View Slide

リスク分析結果もふりかえる
• プロジェクトの期間中、テストチーム
は、⼀連の品質リスク、または判明して
いる品質リスクのリスクレベルを変更す
る可能性のある追加情報を、常に認識し
ている必要がある。テストの修正をもた
らす品質リスク分析の⾒直しを、定期的
に⾏うべきである。⾒直しには、新しい
リスクの識別、既存のリスクレベルの再
評価およびリスク軽減活動の有効性の評
価を含む。

View Slide

リスク分析結果もふりかえる
• Release plan / Iteration planの
ふりかえりで「リスクレベル変わ
るなぁ」というイベントが起きた
らリスクレベルの基準やテストア
プローチを⾒直そう。

View Slide

まとめ
üリスク評価は「相対⾒積もり」でできる
üより⾼リスクなユーザーストーリーは⾃動テストを整備しよう
üリスク分析結果も定期的にふりかえろう
いて⾏おう

View Slide

どうやって探索的テストするの？
リスクレベル
テスト
⾼ + ++ +
中 o ++ o
低 -- ++ --
story1
購⼊できる
story2
確保できる
Story3
ができる
探索的テストは、事前にテストケースを⽤
意せず、テスト対象の学習・テストの設
計・テスト実施を同時に⾏いながらテスト
を実施する技法です。
（半⽥技術研究所探索的テストの進め⽅より）

View Slide

セッションベースドかつテストチャーター
を⽤いた探索的テスト
テストチャーターを作成するためにエピックやユーザーストーリーを分析する際には、以下のことを
考慮する必要があります。
• このエピックやユーザーストーリーに登場するユーザーは誰か？
• そのエピックやユーザーストーリーの主な機能は何か。
• ユーザーが実⾏できるアクションは何か？（これは、ユーザーストーリーで定義されている受け
⼊れ基準リストから得ることができます）
• ユーザーストーリーのゴールは、その機能が完了した時点で実現されますか？（あるいは、完了
の定義に影響を与える他のテストタスクがあるか？）
60分から120分のタイムボックスに収まるように、⼤きすぎてもいけません。探索的テストセッショ
ンを実⾏する⽬的は、現象やバグが集中しているエリアなどに関して、質の⾼い決定を下すのに役⽴
つことです。
2.2.2 Creating test charters and interpreting their results より引⽤

View Slide

探索的テスト担当者は、探索的テストセッションの作成と実⾏において、創造性を⾼めるために
ヒューリスティックを使⽤します。これらは、テストチャーターの作成や、ユーザーストーリーやエ
ピックを分析する際の創造的な思考にも使⽤できます。
Webヒューリスティック
これらのヒューリスティックは、特にWebベースのアプリケーションに適⽤されます。
• 戻る、進む、履歴
• ユーザーは、Webアプリケーションを操作するか、ブラウザーの履歴機能（戻るボタン、進むボタン、履
歴など）を使⽤して、Webアプリケーション内を移動できます。リッチWebアプリケーションは、これを
常にうまく処理できるとは限りません。次の点に注意してください。
• POSTデータがサーバーに再送信されることに関する警告
• 重複したトランザクション
• 404エラー
• 部分的なデータのみで表⽰されるページ
• 壊れた画像や壊れたリンクなどのエラー
Explore It!
Appendix 2: Test Heuristics Cheat Sheet より引⽤
2.2.2 Creating test charters and interpreting their results より引⽤

View Slide

story1
来場者はクレジットカードで
チケットを購⼊できる
■テストチャーター（テスト指⽰書）
対象ストーリー … Story1 来場者はクレジットカードでチケットを購⼊できる
環境 … スマホ（iOS safari, chrome / Android chrome）、PC（chrome, ﬁrefox）
登場するユーザー … ⼀般来場者、シニア、⾼校⽣、提携店舗カード会員
主な機能 … チケット購⼊
実⾏できるアクション … 決済⽅法を選択する、決済ボタンを押す
影響する他のタスク … 作品選択、上映回選択、座席選択が為されていること
考慮すること … 特になし
テスト時間 … 120分 90分 60分
■実施結果
テスト実⾏数 …
不具合発⾒数 …
テストチャーター書いて
みたよ。
決済ボタン⼆重押下や戻
る・進むボタンを考慮す
る必要あるんじゃない？

View Slide

まとめ
ü探索的テストはセッションベースドかつテストチャーターを⽤
いて⾏おう

View Slide

⾃動テストのシナリオどうやって作る？
リスクレベル
テスト
⾼ + ++ +
中 o ++ o
低 -- ++ --
story1
購⼊できる
story2
確保できる
Story3
ができる

View Slide

要求エンジニアリングの技法を使ってテス
トを考える
テスターとして、ユーザーストーリーやエピック、その他のアジャイル要件の明確化（場合によっては改
善）を⽀援するためには、これをサポートするさまざまな要件エンジニアリング技法を知り、理解し、選
択し、使⽤することが必要です。
そのような技術の例として、ストーリーボード、ストーリーマッピング、ペルソナ、ダイアグラム、ユー
スケースがあります。
• ストーリーボード：ストーリーボード（アジャイルタスクボードまたはアジャイルユーザーストー
リーボードと混同しないでください）は、システムを視覚的に表現したものです。ストーリーボード
はテスト担当者が以下のことをするのに役⽴ちます。
• ユーザーストーリーの背後にある思考プロセスや全体的な「ストーリー」を⾒て、コンテキスト
を提供し、システムの機能的な流れをすばやく確認し、ロジックのギャップを特定することがで
きます。
（以下略）
1.1.1 Analyze user stories and epics using requirements engineering techniques より引⽤

View Slide

要求エンジニアリングの技法を使ってテスト
を考える
ストーリーボード
• 全体のストーリーを参照
• テストアプローチの選択
• 受け⼊れ基準の特定
ストーリーマッピング
• リスクレベルを決める
• スモークテストを洗い出す
ペルソナ
• ユーザーの特定
• ユーザーストーリーの不整合を探す
ユースケース
• テスト可能で適切なサイズであるか
• ユーザーストーリーの抜け漏れ
ダイアグラム
• システム機能のギャップを識別する ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1
1.1.1 Analyze user stories and epics using requirements engineering techniques より
引⽤・ダイアグラム化

View Slide

story1
購⼊できる
Story3
ができる
Story1とStory3は同じストーリーボード
で扱えそう。
「作品を選ぶ」も⼊れてスモークテス
トを⾃動化すればよさそう。
を考える
①作品を選ぶ ②座席を選ぶ
③決済をする ④チケット予約が完了する
⾼トラフィックは
どうしよう

View Slide

を考える
ストーリーボード
• 全体のストーリーを参照
• テストアプローチの選択
• 受け⼊れ基準の特定
ストーリーマッピング
• リスクレベルを決める
• スモークテストを洗い出す
ペルソナ
• ユーザーの特定
• ユーザーストーリーの不整合を探す
ユースケース
• テスト可能で適切なサイズであるか
• ユーザーストーリーの抜け漏れ
ダイアグラム
• システム機能のギャップを識別する ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1
1.1.1 Analyze user stories and epics using requirements engineering techniques より
引⽤・ダイアグラム化

View Slide

story1
購⼊できる
Story3
来場者は⾼トラフィックな
状態でも座席を選ぶことが
できる
を考える
⾼トラフィックなときに
予約するユーザーとそう
でないユーザーって違う
ね。
“⾼トラフィック”は
別のユーザーストー
リーで扱えないかな。
⼤和猛 32才⼀般・Web予約有料会員
⼥⼦⼤⽣が軍艦に乗って
戦艦道に邁進するアニメのファン。
新作が公開されるたびに「公開初⽇
最初の上映回」予約争奪戦に参加する。
吉⽥昭, 吉⽥和予 67才, 66才
シニア・Web予約有料会員
映画好きで過去の名作を上映する
際に平⽇朝の上映回を予約する。
Story3ʼ
来場者は座席を選ぶことが
できる
“⾼トラフィック”っ
てどれくらいのリク
エスト数なのかな？

View Slide

要求エンジニアリングの技法を使ってテス
トを考える
受け⼊れ基準を特定するために、テスターは次のような複数の引き出し技法を利⽤できます。
• 定量的アンケート：（中略）定量的アンケートは、多数のステークホルダーに向けて、特に⾮機能的
な受け⼊れ基準の引き出し技法として使⽤できます。
• 定性的アンケート：（中略）定性的アンケートは、処理に時間がかかるため、少数のステークホル
ダー向けの引き出し技法として使⽤でき、機能的な受け⼊れ基準に適しています。
• 定性的インタビュー：定性的インタビューは定量的な質問よりも柔軟性があり、主に背景、コンテキ
スト、原因に関する情報を取得するために使⽤されます。確かなデータを返すことはほとんどありま
せんが、ユーザーストーリーのコンテキストに関する回答から受け⼊れ基準を導き出すことができま
す。定性的インタビューは、導き出した受け⼊れ基準を深めるために、あらゆるタイプのアンケート
のフォローアップとなることができます。
他にも、観察テクニック（例：⾒習い）、創造技法（例：6つの帽⼦思考法）、サポート技法（例：ロー
ファイプロトタイピング）など様々な引き出し技法が存在します。テスターのテクニックツールセット
は、引き出された受け⼊れ基準の品質に影響を与えます。
今回は
関係者にインタビュー
すればいいよね
1.1.2 Identifying acceptance criteria using requirements engineering and test techniques
より引⽤

View Slide

story1
購⼊できる
Story3
来場者は⾼トラフィックな状態でも
座席を選ぶことが予約できる
受け⼊れ条件
1分間で1000件の「チケット予約」
ストーリーボードの内容を扱える
を考える
座席選びだけでなく決済も
含まれるのですね。
ユーザーストーリーが変わ
りますね。
Story3ʼ
来場者は座席を選ぶことができる
数えたことないのだけど。
Googleアナリティクス⾒れ
ばいい？
1分間で1000席を決済まで
終わらせるとかかな？
⾼トラフィックは具体的
にどの程度のリクエスト
数なのでしょうか。
これでもう⼀度リスク分析
をしてみよう。
ベロシティも⾒積もろう。
リリースには必要だけど、
このイテレーションで扱う
必要性はあるのかな。

View Slide

まとめ
いて⾏おう
ü要求エンジニアリングの技法を使ってテストを考えよう

View Slide

取り扱った学習⽬標
• ISTQBテスト技術者資格制度 Foundation Level Extension シラバスアジャイル
テスト担当者⽇本語版 Version 2014.J01
• FA-3.2.1 アジャイルプロジェクト内の品質リスクを評価する。
• FA-3.3.1 テスト活動をサポートするために関連情報を理解する。
• FA-3.3.2 テスト可能な受け⼊れ基準を定義する⽅法をビジネスステークホルダに説
明する。
• ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1
• ATT-1.1.1-1 要求エンジニアリング技術を使⽤してユーザーストーリーとエピックを
分析する
• ATT-1.1.2-1 要求エンジニアリングおよびテスト⼿法を使⽤して、特定のユーザース
トーリーのテスト可能な受け⼊れ基準を作成および評価します
• ATT-2.2.1-1 アジャイルプロジェクトの特定のシナリオに対して他のアプローチ（リ
スクベースのテストを含む）を使⽤して作成された、テスト⾃動化、経験ベースの
テスト、およびブラックボックステストを使⽤したテストアプローチの作成を分析
します。
• ATT-2.2.2-1 ユーザーストーリーとエピックを分析してテストチャーターを作成する

View Slide

まとめ
いて⾏おう
ü要求エンジニアリングの技法を使ってテストを考えよう
ΑΓৄ͘͠஌Γ͍ͨํ͸γϥόεΛಡ΋͏
同⼈問題集の解説がシラバス読むときの⾜がかりになるかもしれません。

View Slide

参考⽂献
• JSTQBシラバス（ http://jstqb.jp/syllabus.html ）
• ISTQBテスト技術者資格制度 Foundation Level Extension シラバスア
ジャイルテスト担当者⽇本語版 Version 2014.J01
• ISTQBシラバス、サンプル問題（ https://www.istqb.org/ ）
• ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1
• Rex Black, Agile Testing Foundations: An ISTQB Foundation
Level Agile Tester guide, BCS Learning & Development
Limited, 2017
• Elisabeth Hendrickson, Explore It!, Pragmatic Bookshelf,
2013
• 半⽥技術研究所, 探索的テストの進め⽅,2019,
https://booth.pm/ja/items/1305980

View Slide

商標等
以下の登録商標を、本資料で使⽤している。
• ISTQBは、International Software Testing Qualiﬁcations Board の
登録商標である。
• JSTQBは、は特定⾮営利活動法⼈ソフトウェアテスト技術振興協会
の登録商標である。
以下の画像を、本資料で使⽤している。
• いらすとや https://www.irasutoya.com/
• https://www.ﬂaticon.com/free-icon/kiosk_866067
• https://commons.wikimedia.org/wiki/File:Extreme_Programming.
svg

View Slide

ISTQB/JSTQBシラバスから学ぶAgileTesting / A guide of agile testing based on ISTQB syllabus

ISTQB/JSTQBシラバスから学ぶAgileTesting / A guide of agile testing based on ISTQB syllabus

dproject21

More Decks by dproject21

Other Decks in Technology

Featured

Transcript