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

ISTQB/JSTQBが公開しているアジャイルテストに関するシラバスをもとに、アジャイル開発チームはどのようにテストを行っていけばよいかを紹介しました。

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

2021/8/25 公開
初出 : 開発×テスト LT会 #devtestlt https://rakus.connpass.com/event/218754/

Transcript

1. ISTQB/JSTQBシラバスから学ぶ AgileTesting JSTQB Advanced Level 試験対策勉強会 たのっち 2021/8/25 於 :開発×テスト LT会 #devtestlt
2. はじめに • 本発表は個⼈の⾒解に基づく内容となります。 • ISTQB/JSTQBの公式⾒解ではありません。 • JSTQB公式⽇本語訳が存在しないシラバスや和書が出版されて いない⽂献は、⾃家翻訳を⾏った⽇本語訳を⽤いて引⽤して います。 • google翻訳、DeepLで翻訳を⾏ったうえで、⽤語の統⼀を⾏うなどの 修正を⾏ったものです。
3. About me • 某ITコンサル会社所属、ただの開発者 • 第⼀⾔語はGo⾔語 • JSTQB AdvancedLevel テストアナリスト/テストマネージャ • 趣味でソフトウェアテスト（の勉強会と問題集）をやっていま す。
4. JSTQB/ISTQB とは • テストエンジニア向け国際資格 • ⽇本の資格取得者は約2万⼈ • ⽇本国内では4区分の試験が実施さ れています。 • 学習⽤として4区分の⽇本語シラバ スが公開されています。 （試験未実施）
5. JSTQB Advanced Level 試験対策勉強会とは • 国内ではAdvancedLevelの公式教科書・問題 集・研修が存在しない • 「みんなで模擬問題を作って試験対策しよ う」と有志が集まり2018年11⽉から勉強会を 開催 • 勉強会内で作成した模擬問題をまとめた JSTQB”⾮認定”問題集を6区分で作成し同⼈誌 として頒布中 • 技術書典オンラインマーケット, booth.pmでお求め いただけます
6. 今⽇のお題 • Agile2区分のシラバスの内容の⼀部 を取り上げます • アジャイルテスト担当者シラバス3章 の⼀部 • Agile Technical Testerシラバス 1 章・2章の⼀部 • 詳細な内容, 正しい内容はシラバス や参考⽂献を参照してください。 • 該当する同⼈問題集は下記2冊
7. 最初にまとめ • 品質はチームのもの • リスク評価は「相対⾒積もり」でできる • より⾼リスクなプロダクト/システムは厚めにテストしよう • より⾼リスクなユーザーストーリーは⾃動テストを整備しよう • リスク分析結果も定期的にふりかえろう • 探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう • 要求エンジニアリングの技法を使ってテストを考えよう
8. 品質はチームのもの アジャイルプロジェクトにおいては、チーム全体が品質に対する 責任を持っている。チーム全体アプローチの本質は、テスト担当 者、開発者およびビジネス代表者が、開発プロセスの各ステップ で協⼒して作業することにある。 テスト担当者は、開発者およ びビジネス代表者と密接に連携し、望まれる品質レベルが確実に 達成されるようにする。これには、適切な受け⼊れテストを作成 できるようにビジネス代表者をサポートし協調すること、開発者 と協調して、テスト戦略に合意し、テスト⾃動化の⽅式を決定す ることが含まれる。このように、テスト担当者は、テストに関す る知識を他のチームメンバに伝達および展開して、プロダクトの 開発に良い影響をおよぼすことができる。 ISTQBテスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 ⽇本語版 Version 2014.J01 1.1.2 チーム全体アプローチより引⽤
9. 品質はチームのもの アジャイルプロジェクトにおいては、チーム全体が品質に対する 責任を持っている。チーム全体アプローチの本質は、テスト担当 者、開発者およびビジネス代表者が、開発プロセスの各ステップ で協⼒して作業することにある。 テスト担当者は、開発者およ びビジネス代表者と密接に連携し、望まれる品質レベルが確実に 達成されるようにする。これには、適切な受け⼊れテストを作成 できるようにビジネス代表者をサポートし協調すること、開発者 と協調して、テスト戦略に合意し、テスト⾃動化の⽅式を決定す ることが含まれる。このように、テスト担当者は、テストに関す る知識を他のチームメンバに伝達および展開して、プロダクトの 開発に良い影響をおよぼすことができる。 ISTQBテスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 ⽇本語版 Version 2014.J01 1.1.2 チーム全体アプローチより引⽤ 具体的に どういうことをするの？ ISTQB/JSTQBシラバスから いくつかピックアップします
10. まとめ ü品質はチームのもの • リスク評価は「相対⾒積もり」でできる • より⾼リスクなプロダクト/システムは厚めにテストしよう • より⾼リスクなユーザーストーリーは⾃動テストを整備しよう • リスク分析結果も定期的にふりかえろう • 探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう • 要求エンジニアリングの技法を使ってテストを考えよう
11. どちらを厚めにテストする？ 銀⾏システムとワクチン予約サイト ⾃動テストや仕様ベースのテストを充実させたほうがよいのはどちらでしょうか。
12. どちらを厚めにテストする？ 映画館のチケット発券機タッチパネル画⾯とチケット予約Web画⾯ ⾃動テストや仕様ベースのテストを充実させたほうがよいのはどちらでしょうか。
13. リスクを分析しよう • リスク分析中に、個々のシステムの機能について、リスクレベ ル（⾼、中、低など）が決定されます。 • 安全性が重要なシステムで使⽤できるさまざまなテスト⼿法 （探索的、⾃動、⼿動）の組み合わせの例です。 リスクレベル ⾃動テスト 探索的テスト ブラックボックステスト ⾼ ++ + ++ 中 + + + 低 o ++ + ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 2.2.1 Combining experience-based techniques and black-box tests より引⽤ ▪凡例 ++ （強く推奨） + （推奨） o （中⽴） - （⾮推奨） -- （使⽤しない）
14. リスクを分析しよう • リスク分析中に、個々のシステムの機能について、リスクレベ ル（⾼、中、低など）が決定されます。 • 安全性が重要でないシステムで使⽤される場合の、さまざまな テスト⼿法の組み合わせの例です。 ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 2.2.1 Combining experience-based techniques and black-box tests より引⽤ リスクレベル ⾃動テスト 探索的テスト ブラックボックステスト ⾼ + ++ + 中 o ++ o 低 -- ++ -- ▪凡例 ++ （強く推奨） + （推奨） o （中⽴） - （⾮推奨） -- （使⽤しない）
15. 銀⾏システムのほうがテスト厚くなる
16. プロダクトオーナー次第 どのような状況（セーフティクリティカルであろうとなかろうと）でも、仕様の組み 合わせはプロジェクトの特性によって異なります。 リスクレベル ⾃動テスト 探索的テスト ブラックボックス テスト ⾼ + ++ + 中 o ++ o 低 -- ++ -- ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 2.2.1 Combining experience-based techniques and black-box tests より引⽤
17. プロダクトオーナー次第 それぞれのシステムに対して、この表をもとにしてテストアプローチを考える（こと がAgile Technical Testerに求められる） リスクレベル ⾃動テスト 探索的テスト ブラックボックス テスト ⾼ + ++ + 中 o ++ o 低 -- ++ --
18. プロダクトオーナー次第 （例えば） Web予約の⽐率は多くない。 券売機がトラブル起こしたときにリアル店舗で運⽤回避できないの で、券売機のブラックボックステストを少し厚くしよう リスクレベル ⾃動テスト 探索的テスト ブラックボックス テスト ⾼ + ++ ++ 中 o ++ + 低 -- ++ o
19. プロダクトオーナー次第 （例えば） 券売機がトラブル起こしてもリアル店舗で運⽤回避できる。 Web予約中⼼なのでWeb予約システムが⽌まると⼤打撃なので Webシステムの⾃動テストを少し厚くしよう。 リスクレベル ⾃動テスト 探索的テスト ブラックボックス テスト ⾼ ++ ++ + 中 + ++ o 低 o ++ --
20. QAだけでなくPOも開発者もリスク評価を アジャイルプロジェクトでは、品質リスク分析を⼆つのタイミン グで⾏う。 • リリース計画： リリースのフィーチャを把握しているビジネス 代表者は、リスクについて⾼いレベルでの概要を規定し、テス ト担当者を含むチーム全体は、リスク識別と評価を⽀援する • イテレーション計画： チーム全体が品質リスクを識別し評価す る ISTQBテスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 ⽇本語版 Version 2014.J01 3.2.1 アジャイルプロジェクトにおける品質リスクの評価 より引⽤
21. まとめ ü品質はチームのもの • リスク評価は「相対⾒積もり」でできる üより⾼リスクなプロダクト/システムは厚めにテストしよう • より⾼リスクなユーザーストーリーは⾃動テストを整備しよう • リスク分析結果も定期的にふりかえろう • 探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう • 要求エンジニアリングの技法を使ってテストを考えよう
22. どちらが⾼リスク？ story1 来場者はクレジット カードでチケットを 購⼊できる story2 劇場スタッフは予約 開始前に関係者席を 確保できる 【背景】 関東地⽅で複数の映画館を運営するA社では⼈気作品公開の際に頻発する 「チケット争奪戦」に対処するため、 Web予約システムのリニューアルに向けたシステム開発を進めています。
23. Story3のリスクはどれくらい？ story1 来場者はクレジット カードでチケットを 購⼊できる story2 劇場スタッフは予約 開始前に関係者席を 確保できる Story3 来場者は⾼トラフィック な状態でも座席を選ぶこ とができる 【背景】 関東地⽅で複数の映画館を運営するA社では⼈気作品公開の際に頻発する 「チケット争奪戦」に対処するため、 Web予約システムのリニューアルに向けたシステム開発を進めています。
24. リスク評価は相対⾒積もりできる アジャイルプロジェクトの品質リスク分析プロセスをイテレーション計画時に実⾏する⽅ 法の例を、次に⽰す。 1. テスト担当者を含むアジャイルチームメンバを招集する 2. 現在のイテレーションのすべてのバックログアイテムを（タスクボードなどに）⼀覧 化する 3. 各アイテムに関係する品質リスクを、すべての関連する品質特性を考慮して識別する 4. 識別した各リスクを評価する。ここでは、⽋陥の影響と発⽣確率に基づいて、リスク の分類と、リスクレベルの決定という、⼆つの活動を⾏う 5. リスクレベルに応じて、テストの範囲を決定する 6. リスク、リスクレベルおよび関連する品質特性に基づいて、各リスクを軽減するため の適切なテスト技法を選択する ISTQBテスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 ⽇本語版 Version 2014.J01 3.2.1 アジャイルプロジェクトにおける品質リスクの評価 より引⽤
25. リスク評価は相対⾒積もりできる リスクポーカーは、⼀⽅では⼗分な品質と許容可能なリスク、他⽅では時間とリソースで 利⽤可能な制約の間の最適なバランスを達成するためのチーム全体のアプローチです。プ ロダクトバックログのユーザーストーリーをリスク項⽬と⾒なします。スクラムマスター はリスクポーカーセッションを開催しますが、ゲームには参加しません。ただし、プロダ クトオーナーはゲームに参加します。プロダクトオーナーはすべてのステークホルダーを 代表し、最も重要な影響について必要な情報を提供できるようになります。各バックログ 項⽬の質問は、このユーザーストーリーにどのレベルのリスクを関連付ける必要があるか ということです。 Agile Testing Foundations: An ISTQB Foundation Level Agile Tester guide 3. Agile testing methods, techniques and toolsより引⽤ リスク評価はプランニングポーカーと同じやり⽅でできる。
26. リスク評価は相対⾒積もりできる story1 来場者はクレジット カードでチケットを 購⼊できる story2 劇場スタッフは予約 開始前に関係者席を 確保できる Story3 来場者は⾼トラフィック な状態でも座席を選ぶこ とができる 低 （重⼤度） ⾼ ⾼ ︵ 頻 度 ︶ 低
27. どのくらいテストすればいいか割り出せる リスクレベル ⾃動（システム） テスト 探索的テスト ブラックボックス テスト ⾼ + ++ + 中 o ++ o 低 -- ++ -- story1 来場者はクレジット カードでチケットを 購⼊できる story2 劇場スタッフは予約 開始前に関係者席を 確保できる Story3 来場者は⾼トラ フィックな状態で も座席を選ぶこと ができる
28. QAだけでなくPOも開発者もリスク評価を アジャイルプロジェクトでは、品質リスク分析を⼆つのタイミン グで⾏う。 • リリース計画： リリースのフィーチャを把握しているビジネス 代表者は、リスクについて⾼いレベルでの概要を規定し、テス ト担当者を含むチーム全体は、リスク識別と評価を⽀援する • イテレーション計画： チーム全体が品質リスクを識別し評価す る ISTQBテスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 ⽇本語版 Version 2014.J01 3.2.1 アジャイルプロジェクトにおける品質リスクの評価 より引⽤
29. リスク分析結果もふりかえる • プロジェクトの期間中、テストチーム は、⼀連の品質リスク、または判明して いる品質リスクのリスクレベルを変更す る可能性のある追加情報を、常に認識し ている必要がある。テストの修正をもた らす品質リスク分析の⾒直しを、 定期的 に⾏うべきである。⾒直しには、新しい リスクの識別、既存のリスクレベルの再 評価およびリスク軽減活動の有効性の評 価を含む。 ISTQBテスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 ⽇本語版 Version 2014.J01 3.2.1 アジャイルプロジェクトにおける品質リスクの評価 より引⽤
30. リスク分析結果もふりかえる • Release plan / Iteration planの ふりかえりで「リスクレベル変わ るなぁ」というイベントが起きた らリスクレベルの基準やテストア プローチを⾒直そう。
31. まとめ ü品質はチームのもの üリスク評価は「相対⾒積もり」でできる üより⾼リスクなプロダクト/システムは厚めにテストしよう üより⾼リスクなユーザーストーリーは⾃動テストを整備しよう üリスク分析結果も定期的にふりかえろう • 探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう • 要求エンジニアリングの技法を使ってテストを考えよう
32. どうやって探索的テストするの？ リスクレベル ⾃動（システム） テスト 探索的テスト ブラックボックス テスト ⾼ + ++ + 中 o ++ o 低 -- ++ -- story1 来場者はクレジット カードでチケットを 購⼊できる story2 劇場スタッフは予約 開始前に関係者席を 確保できる Story3 来場者は⾼トラ フィックな状態で も座席を選ぶこと ができる 探索的テストは、事前にテストケースを⽤ 意せず、テスト対象の学習・テストの設 計・テスト実施を同時に⾏いながらテスト を実施する技法です。 （半⽥技術研究所 探索的テストの進め⽅ より）
33. セッションベースドかつテストチャーター を⽤いた探索的テスト テストチャーターを作成するためにエピックやユーザーストーリーを分析する際には、以下のことを 考慮する必要があります。 • このエピックやユーザーストーリーに登場するユーザーは誰か？ • そのエピックやユーザーストーリーの主な機能は何か。 • ユーザーが実⾏できるアクションは何か？（これは、ユーザーストーリーで定義されている受け ⼊れ基準リストから得ることができます） • ユーザーストーリーのゴールは、その機能が完了した時点で実現されますか？（あるいは、完了 の定義に影響を与える他のテストタスクがあるか？） 60分から120分のタイムボックスに収まるように、⼤きすぎてもいけません。探索的テストセッショ ンを実⾏する⽬的は、現象やバグが集中しているエリアなどに関して、質の⾼い決定を下すのに役⽴ つことです。 ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 2.2.2 Creating test charters and interpreting their results より引⽤
34. セッションベースドかつテストチャーター を⽤いた探索的テスト 探索的テスト担当者は、探索的テストセッションの作成と実⾏において、創造性を⾼めるために ヒューリスティックを使⽤します。これらは、テストチャーターの作成や、ユーザーストーリーやエ ピックを分析する際の創造的な思考にも使⽤できます。 Webヒューリスティック これらのヒューリスティックは、特にWebベースのアプリケーションに適⽤されます。 • 戻る、進む、履歴 • ユーザーは、Webアプリケーションを操作するか、ブラウザーの履歴機能（戻るボタン、進むボタン、履 歴など）を使⽤して、Webアプリケーション内を移動できます。リッチWebアプリケーションは、これを 常にうまく処理できるとは限りません。次の点に注意してください。 • POSTデータがサーバーに再送信されることに関する警告 • 重複したトランザクション • 404エラー • 部分的なデータのみで表⽰されるページ • 壊れた画像や壊れたリンクなどのエラー Explore It! Appendix 2: Test Heuristics Cheat Sheet より引⽤ ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 2.2.2 Creating test charters and interpreting their results より引⽤
35. セッションベースドかつテストチャーター を⽤いた探索的テスト story1 来場者はクレジットカードで チケットを購⼊できる ▪テストチャーター（テスト指⽰書） 対象ストーリー … Story1 来場者はクレジットカードでチケットを購⼊できる 環境 … スマホ（iOS safari, chrome / Android chrome）、PC（chrome, firefox） 登場するユーザー … ⼀般来場者、シニア、⾼校⽣、提携店舗カード会員 主な機能 … チケット購⼊ 実⾏できるアクション … 決済⽅法を選択する、決済ボタンを押す 影響する他のタスク … 作品選択、上映回選択、座席選択が為されていること 考慮すること … 特になし テスト時間 … 120分 90分 60分 ▪実施結果 テスト実⾏数 … 不具合発⾒数 … テストチャーター書いて みたよ。 決済ボタン⼆重押下や戻 る・進むボタンを考慮す る必要あるんじゃない？
36. まとめ ü品質はチームのもの üリスク評価は「相対⾒積もり」でできる üより⾼リスクなプロダクト/システムは厚めにテストしよう üより⾼リスクなユーザーストーリーは⾃動テストを整備しよう üリスク分析結果も定期的にふりかえろう ü探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう • 要求エンジニアリングの技法を使ってテストを考えよう
37. ⾃動テストのシナリオどうやって作る？ リスクレベル ⾃動（システム） テスト 探索的テスト ブラックボックス テスト ⾼ + ++ + 中 o ++ o 低 -- ++ -- story1 来場者はクレジット カードでチケットを 購⼊できる story2 劇場スタッフは予約 開始前に関係者席を 確保できる Story3 来場者は⾼トラ フィックな状態で も座席を選ぶこと ができる
38. 要求エンジニアリングの技法を使ってテス トを考える テスターとして、ユーザーストーリーやエピック、その他のアジャイル要件の明確化（場合によっては改 善）を⽀援するためには、これをサポートするさまざまな要件エンジニアリング技法を知り、理解し、選 択し、使⽤することが必要です。 そのような技術の例として、ストーリーボード、ストーリーマッピング、ペルソナ、ダイアグラム、ユー スケースがあります。 • ストーリーボード： ストーリーボード（アジャイルタスクボードまたはアジャイルユーザーストー リーボードと混同しないでください）は、システムを視覚的に表現したものです。ストーリーボード はテスト担当者が以下のことをするのに役⽴ちます。 • ユーザーストーリーの背後にある思考プロセスや全体的な「ストーリー」を⾒て、コンテキスト を提供し、システムの機能的な流れをすばやく確認し、ロジックのギャップを特定することがで きます。 （以下略） ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 1.1.1 Analyze user stories and epics using requirements engineering techniques より引⽤
39. 要求エンジニアリングの技法を使ってテスト を考える ストーリーボード • 全体のストーリーを参照 • テストアプローチの選択 • 受け⼊れ基準の特定 ストーリーマッピング • リスクレベルを決める • スモークテストを洗い出す ペルソナ • ユーザーの特定 • ユーザーストーリーの不整合を探す ユースケース • テスト可能で適切なサイズであるか • ユーザーストーリーの抜け漏れ ダイアグラム • システム機能のギャップを識別する ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 1.1.1 Analyze user stories and epics using requirements engineering techniques より 引⽤・ダイアグラム化
40. story1 来場者はクレジット カードでチケットを 購⼊できる Story3 来場者は⾼トラ フィックな状態で も座席を選ぶこと ができる Story1とStory3は同じストーリーボード で扱えそう。 「作品を選ぶ」も⼊れてスモークテス トを⾃動化すればよさそう。 要求エンジニアリングの技法を使ってテスト を考える ①作品を選ぶ ②座席を選ぶ ③決済をする ④チケット予約が完了する ⾼トラフィックは どうしよう
41. 要求エンジニアリングの技法を使ってテスト を考える ストーリーボード • 全体のストーリーを参照 • テストアプローチの選択 • 受け⼊れ基準の特定 ストーリーマッピング • リスクレベルを決める • スモークテストを洗い出す ペルソナ • ユーザーの特定 • ユーザーストーリーの不整合を探す ユースケース • テスト可能で適切なサイズであるか • ユーザーストーリーの抜け漏れ ダイアグラム • システム機能のギャップを識別する ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 1.1.1 Analyze user stories and epics using requirements engineering techniques より 引⽤・ダイアグラム化
42. story1 来場者はクレジット カードでチケットを 購⼊できる Story3 来場者は⾼トラフィックな 状態でも座席を選ぶことが できる 要求エンジニアリングの技法を使ってテスト を考える ⾼トラフィックなときに 予約するユーザーとそう でないユーザーって違う ね。 “⾼トラフィック”は 別のユーザーストー リーで扱えないかな。 ⼤和 猛 32才 ⼀般・Web予約有料会員 ⼥⼦⼤⽣が軍艦に乗って 戦艦道に邁進するアニメのファン。 新作が公開されるたびに「公開初⽇ 最初の上映回」予約争奪戦に参加する。 吉⽥ 昭, 吉⽥ 和予 67才, 66才 シニア・Web予約有料会員 映画好きで過去の名作を上映する 際に平⽇朝の上映回を予約する。 Story3ʼ 来場者は座席を選ぶことが できる “⾼トラフィック”っ てどれくらいのリク エスト数なのかな？
43. 要求エンジニアリングの技法を使ってテス トを考える 受け⼊れ基準を特定するために、テスターは次のような複数の引き出し技法を利⽤できます。 • 定量的アンケート： （中略）定量的アンケートは、多数のステークホルダーに向けて、特に⾮機能的 な受け⼊れ基準の引き出し技法として使⽤できます。 • 定性的アンケート： （中略）定性的アンケートは、処理に時間がかかるため、少数のステークホル ダー向けの引き出し技法として使⽤でき、機能的な受け⼊れ基準に適しています。 • 定性的インタビュー： 定性的インタビューは定量的な質問よりも柔軟性があり、主に背景、コンテキ スト、原因に関する情報を取得するために使⽤されます。確かなデータを返すことはほとんどありま せんが、ユーザーストーリーのコンテキストに関する回答から受け⼊れ基準を導き出すことができま す。定性的インタビューは、導き出した受け⼊れ基準を深めるために、あらゆるタイプのアンケート のフォローアップとなることができます。 他にも、観察テクニック（例：⾒習い）、創造技法（例：6つの帽⼦思考法）、サポート技法（例：ロー ファイプロトタイピング）など様々な引き出し技法が存在します。テスターのテクニックツールセット は、引き出された受け⼊れ基準の品質に影響を与えます。 今回は 関係者にインタビュー すればいいよね ISTQB® Advanced Level Syllabus Agile Technical Tester Version 1.1 1.1.2 Identifying acceptance criteria using requirements engineering and test techniques より引⽤
44. story1 来場者はクレジット カードでチケットを 購⼊できる Story3 来場者は⾼トラフィックな状態でも 座席を選ぶことが予約できる 受け⼊れ条件 1分間で1000件の「チケット予約」 ストーリーボードの内容を扱える 要求エンジニアリングの技法を使ってテスト を考える 座席選びだけでなく決済も 含まれるのですね。 ユーザーストーリーが変わ りますね。 Story3ʼ 来場者は座席を選ぶことができる 数えたことないのだけど。 Googleアナリティクス⾒れ ばいい？ 1分間で1000席を決済まで 終わらせるとかかな？ ⾼トラフィックは具体的 にどの程度のリクエスト 数なのでしょうか。 これでもう⼀度リスク分析 をしてみよう。 ベロシティも⾒積もろう。 リリースには必要だけど、 このイテレーションで扱う 必要性はあるのかな。
45. まとめ ü品質はチームのもの üリスク評価は「相対⾒積もり」でできる üより⾼リスクなプロダクト/システムは厚めにテストしよう üより⾼リスクなユーザーストーリーは⾃動テストを整備しよう üリスク分析結果も定期的にふりかえろう ü探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう ü要求エンジニアリングの技法を使ってテストを考えよう
46. 取り扱った学習⽬標 • 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 ユーザーストーリーとエピックを分析してテストチャーターを作成する
47. まとめ ü品質はチームのもの üリスク評価は「相対⾒積もり」でできる üより⾼リスクなプロダクト/システムは厚めにテストしよう üより⾼リスクなユーザーストーリーは⾃動テストを整備しよう üリスク分析結果も定期的にふりかえろう ü探索的テストはセッションベースドかつテストチャーターを⽤ いて⾏おう ü要求エンジニアリングの技法を使ってテストを考えよう ΑΓৄ͘͠஌Γ͍ͨํ͸γϥόεΛಡ΋͏ 同⼈問題集の解説がシラバス読むときの⾜がかりになるかもしれません。
48. 参考⽂献 • 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
49. 商標等 以下の登録商標を、本資料で使⽤している。 • ISTQBは、International Software Testing Qualifications Board の 登録商標である。 • JSTQBは、は特定⾮営利活動法⼈ ソフトウェアテスト技術振興協会 の登録商標である。 以下の画像を、本資料で使⽤している。 • いらすとや https://www.irasutoya.com/ • https://www.flaticon.com/free-icon/kiosk_866067 • https://commons.wikimedia.org/wiki/File:Extreme_Programming. svg