Slide 1

Slide 1 text

実践している探索的テストの進め方 テックタッチ株式会社 QAエンジニア Michiya Maki JaSST nano vol.44 2025/01/21

Slide 2

Slide 2 text

システムエンジニア 道内独立系IT企業・札幌市内ベンチャー企業 東証プライム 第三者検証企業 ITコンサルタント 10年 4年 自己紹介 焼き鳥が焼ける QAエンジニア 巻 宙弥(まき みちや) 主な担当業務 Saasベンダー企業、テックタッチ(株)のQAエンジニア 札幌でフルリモート勤務中 マイブームは“おうちやきとり” #札幌串打同盟 経歴 QAプロセス改善、標準化 QAチームメンバー育成 マネージャー 4年 コミュニティ JaSST Hokkaido 実行委員 JBUG札幌 運営 CanvaCampHokkaido 運営

Slide 3

Slide 3 text

本スライド中の用語は、JSTQB を参考としています。 便宜上、定義よりも分かりやすさを優先した表現がありま す。なお、個人の解釈も含まれます。 考えが正しいと主張するものではございません。 ご注意のほどよろしくお願いいたします。 可能な限り はじめに ※https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf ※

Slide 4

Slide 4 text

本日話すこと 抱えている問題と課題 1. 探索的テストとはなにか? 2. 実践している探索的テスト 3. まとめ 4.

Slide 5

Slide 5 text

1. 抱えている問題と課題 なぜ探索的テストなのか?

Slide 6

Slide 6 text

抱えている問題 増加し続ける手動のテストケース 1. テストレベルの混在 2. 限られたQAリソース 3. テストがリリースのボトルネック 4. 抱えている問題と課題

Slide 7

Slide 7 text

抱えている問題① 抱えている問題と課題 リリースごとに手動で約2,000〜4,000ケース実行 (全体では約12,000ケース) 増加し続ける手動のテストケース

Slide 8

Slide 8 text

抱えている問題② 抱えている問題と課題 受入テスト システム統合テスト システムテスト テストレベルが混在 テストケースが複雑でテストレベルが混在している コンポーネント統合テスト コンポーネントテスト

Slide 9

Slide 9 text

不具合改修 障害対応 新規機能 機能改善 抱えている問題③ 抱えている問題と課題 限られたQAリソースですべての変更をテストできない 不具合改修 障害対応 新規機能 機能改善 不具合改修 障害対応 新規機能 機能改善 不具合改修 障害対応 新規機能 機能改善

Slide 10

Slide 10 text

チームA開発 チームB開発 チームC開発 統 合 リリース前 テスト デ プ ロ イ リリース (3ヶ月毎) 抱えている問題④ 抱えている問題と課題 リリース前テストがボトルネックでリリースサイクルを早くしにくい 約2週間 約2週間

Slide 11

Slide 11 text

問題 課題 取り組み 増加し続ける手動のテストケース 手動から自動テストへの置き換え 適切な自動テスト対象の選定 テストスクラム テストレベルの混在 テストケースの最適化 テストレベル毎のテスト設計 テストリポジトリ整理 テスト管理ツール(Qase)活用 限られたQAリソース QAチームのスキルアップ 適材適所のリソースマネジメント TIY(Test It Your Self) リソース可視化(toggl) リリース前のテストがボトルネック テスト期間の短縮 テスト最適化 テスト自動化 問題解決の取り組み それぞれの問題に対処する課題に取り組み中 補足)一例です。実際は複雑に絡み合っています。 抱えている問題と課題 各取り組みの詳細は 最終ページに

Slide 12

Slide 12 text

なぜ探索的テストなのか? 問題 課題 取り組み 増加し続ける手動のテストケース 手動から自動テストへの置き換え 適切な自動テスト対象の選定 テストスクラム テストレベルの混在 テストケースの最適化 テストレベル毎のテスト設計 テストリポジトリ整理 テスト管理ツール(Qase)活用 限られたQAリソース QAチームのスキルアップ 適材適所のリソースマネジメント TIY(Test It Your Self) リソース可視化(toggl) リリース前のテストがボトルネック テスト期間の短縮 テスト最適化 テスト自動化 複数の課題解決に必要不可欠なテスト技法である。 補足)一例です。実際は複雑に絡み合っています。 抱えている問題と課題 各取り組みの詳細は 最終ページに

Slide 13

Slide 13 text

課題解決に必要不可欠な探索的テスト 課題 重要なポイント 手動から自動テストへの置き換え 適切な自動テスト対象の選定 ローレベルテストを自動化し、ハイレベルテストに注力できる テストケースの最適化 テストレベル毎のテスト設計 ハイレベルテストケースの設計で活かせる 要件のレビューに活かせる(シフトレフト) QAチームのスキルアップ QA・SETの採用 具体的な問題点を発見し、抽象化してテストにつなげる力がある AIとの差別化を図るスキルがある テスト期間の短縮 ー 探索的テストが課題解決後の状態を維持するための重要なポイントになる。 ※様々な潮流から行き着いた持論です 抱えている問題と課題 ※

Slide 14

Slide 14 text

2. 探索的テストとはなにか? 探索的テストは経験ベースのテスト技法

Slide 15

Slide 15 text

探索的テストは経験ベースのテスト技法 ブラックボックステスト技法 ホワイトボックステスト技法 経験ベースのテスト技法 経験ベースのテスト技法 テスト担当者がテスト対象やこれまでのテスト結果の知識や調 査情報を使用して、テストを動的に設計、および実行する。 引用)https://glossary.istqb.org/ja_JP 探索的テストとはなにか? 3つに分類されるテスト技法の一つ 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

Slide 16

Slide 16 text

JSTQBのシラバスをおさらい 探索的テストとはなにか? テストケースの設計と実装にテスト担当者の知識と経験を効果的に利用する テスト担当者のスキルに大きく依存する ブラックボックステストやホワイトボックスのテストでは見逃すような欠陥も検出できる 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf 経験ベースのテスト技法とは...

Slide 17

Slide 17 text

JSTQBのシラバスをおさらい 探索的テストとはなにか? テスト担当者がテスト対象について学習しながら、テストケースを同時に設計、実行、評 価する。テスト対象についてより深く知り、注力したテストでより深く探索し、まだテス トしていない領域のテストを作成するために使う。 仕様がほとんどなかったり、不十分であったり、テストのスケジュールに余裕がなかった りする場合に役立つ。他の形式的なテスト技法を補完する場合にも効果が大きい。テスト 担当者が経験豊富で、ドメインの知識があり、分析力、好奇心、創造性などの重要なスキ ルを高いレベルで持っている場合、より効果的になる。 探索的テストとは... 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

Slide 18

Slide 18 text

探索的テストとは 探索的テストとはなにか? テスト担当者の経験とスキルを最大限活用するテスト まだ見ぬ不具合を見つける(探索する)ためのテスト

Slide 19

Slide 19 text

他のテストとの違い スクリプトテスト アドホックテスト よく聞くテストの種類と比較してみます 探索的テストとはなにか?

Slide 20

Slide 20 text

スクリプトテストとの違い 手順と期待値を事前にテストケースとして準備するスクリプトテストとは違い、 事前にテストケースは作成せず、テスト実施中にテストすべき対象と期待値を決めて進めていく。 スクリプトテスト 探索的テスト 事前に準備した手順に沿って実施 実施中に次のテストを考える 探索的テストとはなにか?

Slide 21

Slide 21 text

アドホックテストとの違い 場当たり的に思いつきや勘で実施するアドホックテストと違い、 テストした結果を踏まえて、未だ見ぬ不具合を探索していくように進める。 アドホックテスト 探索的テスト 操作 結果 操作 結果 操作 結果 その場の思いつきや勘で実施 テスト結果を踏まえて手順を考える 探索的テストとはなにか?

Slide 22

Slide 22 text

3. 実践している探索的テスト QAプロセスで実践している探索的テストを紹介します。

Slide 23

Slide 23 text

探索的テストのアプローチ 実践している探索的テスト テストチャーターを用いたセッションベースドテスト を実施しています。 セッションベースドテストとは... 探索的テストをあらかじめ決められた時間枠内で行う。 テスト担当者はテスト目的を含むテストチャーターに従ってテスト実行をする。 テスト実施後には、QAチーム内で不具合を見分ける。 テスト目的はより抽象度の高いテストを意識する。 例)✕ テキストボックスに英字 12文字を入力する   ◯ テキストボックスにパスワードを入力する テスト担当者は実行した手順や発見した事象を(簡易に)文書に残す。 引用)https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

Slide 24

Slide 24 text

テスト対象 (何をテストするか) テスト方針 (どうやってテストするか) テスト観点 (どんな不具合を見つけたいか) 既存機能 よくある問い合わせからランダムに選定して操作する 仕様通り動作するか 特定の機能 (影響度の大きいもの) A x B x Cの組み合わせで有効値を確認する 期待値が誤っていないか 修正済み不具合 リリース待ちとなった不具合の周辺機能を操作する デグレードが発生していないか 新機能“AAA” システム統合テストのテストケースを実行しながら要 件の妥当性を確認する ユーザの価値を損なうおそれがな いか テストチャーターとは 実践している探索的テスト テストの目的や観点を記述したドキュメント テストチャーターの例

Slide 25

Slide 25 text

探索的テストのプロセス 実践している探索的テスト 情報を集める 計画を立てる チャーターを作る 手順を決める 気づきを記録 テスト フィードバック チャーターに 載せる 設計 実施 プロセス ドキュメンテーション 1セッションの時間 テストスコープ テスト開始条件 プロダクトリスク 要求/要件/設計 開発進捗 テスト環境 過去不具合 チャーターに 載せる テスト目的(なぜ実施するか?) テスト方針(どうやって実施するか?) テスト観点(何を確認するか?) チャーターに 載せる 時間内で操作を繰り返す 結果を記録する チャーターに 載せる

Slide 26

Slide 26 text

探索的テストが効果的なテストレベル コンポーネント統合テスト、システムテスト、システム統合テストの前後で実施する。 各テストレベルの開始時、終了時にテストケース外の不具合を見つけることができている。 実践している探索的テスト

Slide 27

Slide 27 text

4.まとめ

Slide 28

Slide 28 text

探索的テストのメリット まとめ コストパフォーマンス 形式的なレビュープロセスを省略するためコスパが良い 仕様書や設計書が不十分な状態でも実施可能 きっかけとなりうる何かがあれば着手できる “テストの弱化”を回避できる 過去実績のあるテストを再現しているわけではない ※テストの弱化とは?(旧:殺虫剤のパラドックス) 同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる(Beizer 1990) 。この影響を克服するため、 テストとテストデータを変更したり新規にテストを作成したりする ことが必要になる場合がある。 しかし、例えば、自動化されたリグレッションテストのように、 同じテストを繰り返すことが有益な結果を示すことができる場合がある(JSTQBシラバス 2.2.3 項参照)

Slide 29

Slide 29 text

探索的テストのデメリット まとめ スキルと経験が必要 テストの基礎スキルとテスト対象に対する知識、ノウハウが無 いと充分なテストができない。 テストの全量が把握できない どこまでテスト実施すれば完了なのか定量的に示せない。 そのため、完了判断が難しい。 再現性がない その瞬間のテスト結果により判断が変化する。 そのため、同じテストが実施できない。

Slide 30

Slide 30 text

効果的な探索的テストのために 高スキルでハイスペックなテスト担当者でもコンポーネントレベルの品質がある 程度担保できていないと、細かい不具合の発見に終止してしまい、本来見つけた い不具合を見つけることができない。 コンポーネントテストまでの品質をできる限り担保することが重要。 重要 まとめ

Slide 31

Slide 31 text

型をつくって まとめ 情報を集める 計画を立てる チャーターを作る 手順を決める 気づきを記録 テスト実施 フィードバック チャーターに 載せる 設計 設計 プロセス ドキュメンテーション 1セッションの時間 テストのスコープ テストの開始条件 プロダクトリスク 要求/要件 開発の進捗 テスト環境 過去の不具合 チャーターに 載せる テスト目的(なぜ実施するか?) テスト方針(どうやって実施するか?) テスト観点(何を確認するか?) チャーターに 載せる 時間内で操作を繰り返す 結果を記録する チャーターに 載せる

Slide 32

Slide 32 text

開発プロセスに適応させる まとめ 情報を集める 計画を立てる チャーターを作る 手順を決める 気づきを記録 テスト実施 フィードバック チャーターに 載せる 設計 設計 プロセス ドキュメンテーション 1セッションの時間 テストのスコープ テストの開始条件 プロダクトリスク 要求/要件 開発の進捗 テスト環境 過去の不具合 チャーターに 載せる テスト目的(なぜ実施するか?) テスト方針(どうやって実施するか?) テスト観点(何を確認するか?) チャーターに 載せる メリットとデメリットを踏まえ、 開発プロセスに合ったタイミングと深さで適応させる 時間内で操作を繰り返す 結果を記録する チャーターに 載せる スクリプトテストで発見した不具合と探索的テストで 発見した不具合を分けて傾向を把握し、 次のテストに活かす

Slide 33

Slide 33 text

スモール探索的テスト ラージ探索的テスト ハイブリッド探索的テスト テストツアー 今後 探索的テストの体系を参考にプロダクトに合った探索的テストの プロセスを適用、QAメンバーの知識と経験をフル活用できる仕 組みづくりをしていきたい 探索的テストの考え方 ソフトウェア開発のテスト設計とテクニック James A. Whittaker (著), 杉浦清博 (翻訳) まとめ

Slide 34

Slide 34 text

大事にしたいこと

Slide 35

Slide 35 text

「私は不具合を探索しているんだ」 という強い意志が必要不可欠

Slide 36

Slide 36 text

ご清聴ありがとうございました ご清聴ありがとうございました

Slide 37

Slide 37 text

取り組み 詳細 テストスクラム 開発者とQAの越境で自動テストが増える開発プロセスを実現する @ソフトウェアテスト自動化カンファレンス2024 by 92thunder テストリポジトリ整理 テスト管理ツール(Qase)活用 リグレッションテスト期間の短縮を目指して @PayPay / Rakuten Group / Techtouch - QA Night #1 by Shutty 最高効率でテストをするためにQaseを選んだ理由 @Techtouch Developers Blog by mikaty TIY(Test It Your Self) 持続可能なQA活動のために @Qbook-隣のQA by Shutty E2Eテスト最適化 E2Eテスト自動化 開発プロセスに開発者主体のテストを組み込む - 自動テストで手動テ ストを減らすには? @TechRAMEN 2024 Conference by 92thunder おまけ)各取り組みの詳細 積極的にカジュアル面談受付中!