探索的テストをするために、チャーターを作ろう～「経験がないから」で諦めないためにしたこと～

2023年6月24日

JaSST'23 Kansai

Copyright © TeamSpirit Inc. All Rights Reserved.

自己紹介

岡内 裕希
株式会社チームスピリット
シニアQAエンジニア➢ 新卒でSIerに入社➢ 第三者検証へ転職➢ 2021年06月より、現職➢ JSTQB AL Test-Analyst➢ JaSST Online 実行委員

Copyright © TeamSpirit Inc. All Rights Reserved.

1

目次
table of contents

1.

TeamSpiritとは

3

2.

この発表のきっかけとなる出来事

4

3.

「本当にもう大丈夫なの？」

5

4.

経験ベースのテスト技法を使おう

65.

探索的テストができないボトルネック

76.

テスト観点を導出しよう

8

7.

準備1：不具合分析をしてプロセスの弱点を探す

9

8.

準備2：対象機能のテスト観点をゼロから作成する

10

9.

準備3：テスト観点を選定する

11

10.

テスト観点を、チャーターにする

12

11.

実施した結果

13

12.

まとめ

14

Copyright © TeamSpirit Inc. All Rights Reserved.

2

TeamSpiritとはバックオフィス業務の管理をこれひとつでCopyright © TeamSpirit Inc. All Rights Reserved.

3

この発表のきっかけとなる出来事
2023年03月：お客様に不便を強いる不具合発生

社内

要件定義

仕様検討

オフショア

設計

実装

受入

テスト

オフショアに依頼した機能で不具合発生➢ 要件定義～設計は社内で行い、実装とテストはオフショアで実施した。
➢ コードレビューおよびテスト結果のレビューは社内で実施した。

不具合の解消だけでは、不安の払拭は不十分➢ 不具合を含む機能のリグレッションテストをしたところ、別の不具合を検出した。
➢ 新たに検出した不具合は、修正によって混入したものではなかった。
➢ オフショアでの開発で混入した。
➢ コードレビューおよびテスト結果のレビューでもすり抜けた。
Copyright © TeamSpirit Inc. All Rights Reserved.

4

「本当にもう大丈夫なの？」
これ以上重大な不具合はないか？どのように根拠を持てばよいか？

不具合

検出した不具合不安は少ない• 体系的なテストは実施している。
• 仕様ベース• 構造ベース

Copyright © TeamSpirit Inc. All Rights Reserved.

未知の不具合不安が大きい• 体系的なテストでは見つけられない。
• 例：暗黙の仕様

5

経験ベースのテスト技法を使おう「もう大丈夫？」の回答を、経験と知識を生かして導こう

今までの方法だけで「もう大丈夫？」の回答にならないなら、それにプラスアルファしよう。

➢ 開発チームのメンバーには、対象の機能に関するノウハウが蓄積されている。
➢ そもそもの不具合を検出したのも、開発者である。
経験ベースのテスト技法を使用する。

➢ 「もう大丈夫？」の回答になりうるテスト技法を選択する。
テスト技法「もう大丈夫？」の回答になるか採用可否

エラー推測

ならない
エラーを起因とした不具合ではないエラーが起きそうな動作は検証済

否

フォールト攻撃ならない
内部情報を引き出すような不具合ではない
脆弱性がないか検証済

否

探索的テストなる「この使い方をしても大丈夫か？」可チームにとっての課題発生

開発チームメンバーに、探索的テスト経験者が少ない
Copyright © TeamSpirit Inc. All Rights Reserved.

6

探索的テストができないボトルネック

探索的テストができない理由を特定
探索的テストができない

探索的テストの経験がない

チャーターを作ることができない

テスト観点を決めることができない

ボトルネックは、「テスト観点を決めることができない」

テスト観点を段階的に導出することで、ボトルネックを解消する。

Copyright © TeamSpirit Inc. All Rights Reserved.

7

テスト観点を導出しよう
いきなりチャーターを作るのではなく、したいことを整理する• 不具合分析をしてプロセスの弱点を探す
準備1• 対象機能のテスト観点をゼロから作成する
準備2• テスト観点を選定する
準備3

Copyright © TeamSpirit Inc. All Rights Reserved.

8

準備1：不具合分析をしてプロセスの弱点を探す
混入・流出したプロセスから弱点を特定し、テスト観点を抽出
混入・流出したプロセスの特定
どのプロセスで混入したか？

（混入防止）

見つけるとすれば、どのプロセスで発見すべきだったか？

（流出防止）

プロセスの弱点を考察混入したプロセスの弱点は？

発見すべきだったプロセスの弱点は？

弱点から観点を抽出プロセスの弱点からテスト観点を抽出する。
Copyright © TeamSpirit Inc. All Rights Reserved.

9準備2：対象機能のテスト観点をゼロから作成する

オフショア

社内

要件定義

仕様検討

設計

実装

受入

テスト

テスト観点の過不足がないか分析➢ 不具合発生前は、オフショアにテストケース作成から依頼していた。
➢ レビューは実施していたが、真っ新な状態でもう一度テスト観点を考えてみる。

Copyright © TeamSpirit Inc. All Rights Reserved.

10

準備3：テスト観点を選定する

準備1

準備2

準備1+2
除外できるものは、除外する。
➢ 例）該当機能に対するリグレッションテスト
➢ 例）不具合改修時のコードレビュー

テスト観点残ったものが、探索的テストのテスト観点➢ 例） ○○画面で、マニュアルには記載されない暗黙的な仕様で、正常系の操作でエラーが発生しないか？

Copyright © TeamSpirit Inc. All Rights Reserved.

11

テスト観点を、チャーターにする
探索的テストのチャーターにマージ➢ 下記の1～6で、観点や目的を記載する。
1. 実行者・実行日
2. 対象機能/画面
3. 観点
4. 目的/内容
5. 環境
6. テストデータ

Copyright © TeamSpirit Inc. All Rights Reserved.

12実施した結果探索的テストの観点を決定➢ 不具合分析と対象機能から、テスト観点を抽出することができた。
➢ 「探索的テストができない」に対するボトルネックが解消された。

お客様へ案内すべき事項を発見➢ 不具合を改修した直後に、お客様自身に実施いただくことがあった。
➢ 不具合ではない上にレアケースだが、マニュアルに記載されていなかったことがあった。

「もう大丈夫？」の回答➢ ソフトウェアが想定外の動作をする不具合は発見されなかった。
➢ プロセスの弱点や対象機能にゼロから向き合ったことで、出来ることはやり切ったと納得できた。

Copyright © TeamSpirit Inc. All Rights Reserved.

13

まとめ
「経験がないから」で諦めないためにしたことできないボトルネックを解消することで、探索的テストの経験がないチームでも実施できた➢ 探索的テストの準備をステップバイステップで実施し、やるべきことを整理した。
➢ 不具合を分析し、混入プロセス・流出プロセスの弱点を抽出した。
➢ 不具合が発生した機能のテスト観点を真っ新から考え直した。
➢ すでに確認できているテスト観点を除外した。
➢ 結果としてスクリプトテストだけ見つけられなかった問題が発見でき、自信を持って品質の説明責任を果たすことができた。

チームにとっての、今後の課題➢ 不具合の分析が出来るチームメンバーを増やす。
➢ 混入プロセス・流出プロセスの弱点を抽出できるメンバーが限られていた。

Copyright © TeamSpirit Inc. All Rights Reserved.

14本社／〒104-0031
東京都中央区京橋二丁目5番18号 京橋創生館4階
Mail／info@teamspirit.com
設立／1996年11月13日

代表取締役／荻島 浩司
製品サイト／https://www.teamspirit.com/ja-jp/
コーポレートサイト／https://corp.teamspirit.com

Copyright © TeamSpirit Inc. All Rights Reserved.