第290回： 「ALTAのテキストをつくろう」45 （経験ベースのテスト技法）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.2 ブラックボックステスト技法」の「3.2.8 技法の組み合わせ」について書きました。
各テスト技法についてよく知り、技法を組み合わせることで良いテストを作っていくという話でした。
適用範囲が広く強力なテスト技法であるCFD法、つくることが難しい原因結果グラフ、作成までに手間のかかる状態遷移テスト、不具合を90%以上を見つけてくれそうなペアワイズテスト等々を実施すると達成感があります。
また、テストケース数も数百を超え、多くのバグも見つかりますので安心してしまいがちです。
ところが、そのようなテストを実施した後に、全くアプローチや見方が異なるテスト（例えば、ユースケースを用いたシナリオテスト）を実行すれば、また、違うタイプのバグが見つかるものです。
残念ながら1つのテスト技法で全てのバグを検出することは不可能です。そこで、テスト技法を組み合わせることによって、広く、クリティカルな（重篤な）バグを見つけ切ろうというのが「技法の組み合わせ」の主旨です。
ソフトウェアに欠陥が残っていないことは証明できませんが、複数のテスト技法を適用することで、商品やサービスをリリースしても顧客先で重篤な不具合は出ないと確信を持って品質保証をされているはずです。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.3 経験ベースのテスト技法」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢2の「各テスト技法を補い合うため」が88%と最も多く、正解も2です。投票数は48票とまずまずで、正解率が高いので問題ないと思います。
実務では、テストで見逃してしまった欠陥についてどういうテストをしたらよかったのだろうと1件1件深く分析をすることが大切です。
深くとは具体的には、少なくとも1件4時間位かけて分析するということです。
ところで、開発者に欠陥の分析を依頼すると（当たり前ですが）、「テストで見逃してしまった要因」ではなく、「どうしてこの欠陥を作り込んでしまったのだろうという作り込みの要因」について分析してくれます。
そもそも欠陥を作り込まなければ、テストでどんなに失敗しても（手を抜いても）お客様先で問題はでません。でも、テストのプロとしては、どのような重篤な欠陥を持つソフトウェアであっても、「優秀なあなたがうっかりして欠陥を作り込んでしまったとしても、逃さずに見つけるから安心して開発に専念して」と開発者に言いたいですよね。
さて、テスト技法を組み合わせるという話題ですが、今回から始まる「3.3 経験ベースのテスト技法」が終わった後に、ブラックボックステストに経験ベースのテストを加えることを想定し「3.4 最善の技法の適用」として再度話題に上ります。だから、前回の復習はこのくらいでいいかな。
それでは、今回のnoteのテーマに移ります。
≡ 経験ベースのテスト技法
JSTQBのALTAシラバスには、経験ベースのテスト技法の長所と短所が書かれています。まずは、そこをキッチリ抑えましょう。
■ 経験ベースのテスト技法の長所
シラバスの内容を引用します。
● システムに関するドキュメントが不足する場合に、構造化されたアプローチに対する優れた代替となることができる。
● テスト時間が厳しく制限されている場合に適用できる。
● ドメインおよび技術で利用可能な専門知識を、テストに適用できる。これには、例えばビジネスアナリスト、顧客、クライアントなど、テストに関与しない人たちからの専門知識も含まれることがある。
● 開発者へ早期にフィードバックを提供できる。
● 作成するソフトウェアに関してチームが精通するのに役立つ。
● 運用上の故障を効果的に分析できる。
● 多様なテスト技法を適用できる
いったい、どんな経験を積んだらこんなスーパーマンになれるのでしょうか。
「人生３回目ですか？」、と、これは冗談ですが、上記リストを「経験ベースのテスト技法の長所」と呼んで良いのでしょうか。技法を習したら「そういうエンジニア」になるわけではなく、天才テスターの長所のような気がします。
前職で、まさに天才と呼ばれていた派遣テスターの方（以下Kさんとする）がいました。
Kさんは、独身男性で20代中頃の人でした。イケメンなのに浮いた話もなく、しかも、残業はほとんどされていなかったように記憶しています。
テスト技法は詳しくなかったけれど、プロダクトの仕様については、細かなところまで開発者以上に詳しく、私も度々、Kさんに仕様の質問をしたことがあります。（即答されていました）
バグをバンバン見つけて、Kさんがテストしたプロダクトはリリース後も大きな不具合もなく安定していたので、とても頼りにされていました。
でも、Kさん、数年で会社を辞めてしまったんですよね。
風のうわさで、株で大儲けをして数億円のたくわえが出来て、「もう、働かなくてよいのでハワイでのんびり暮らします」と言っていたと聞きました。私の生涯年収より多かったので、そのときは、「そりゃ辞めるでしょう」と思いました。
……今は、お金が十分にあっても働きたいと思うような気がします。お金持ちじゃないから本当にそう思うかどうかは分からないけれど。
Kさん、今はもうアラフィフかなあ、お元気かしら？
※ ということでデータ数1の情報ですが、「我こそ天才テスター」と自認するかたは投資にチャレンジしてもいいかもしれません。しらんけど。
閑話休題。シラバスの長所の例は本当か疑問が残ります。しかし、これを理解しているかどうかを確認する問題が試験にでる（と思います）ので、つまらないけど、ひとつずつ確認していきます。
❶ システムに関するドキュメントが不足する場合に、構造化されたアプローチに対する優れた代替となることができる。
稗田阿礼でもあるまいし……、人がドキュメント不足の代替になるはずがないと私は思います。
ドキュメントが不足していたら、開発部門に作るように働きかけて、それでも作らなかったら自分で作って間違っているかレビューしてもらい、以降は、それを正しいものとしてテストの期待結果に使うのが良いと思います。
❷ テスト時間が厳しく制限されている場合に適用できる。
シラバスのこの個所を書いた人、テストの目的を失念しているような気がします。きっとテストケースを書かないとかチャーターで代用することを想定しているのと思いますが、結構めちゃくちゃな話をしていると思います。
次いこ。次。
❸ ドメインおよび技術で利用可能な専門知識を、テストに適用できる。これには、例えばビジネスアナリスト、顧客、クライアントなど、テストに関与しない人たちからの専門知識も含まれることがある。
テスト対象物が価値を与える業務経験を持ってテストに臨むのは非常に良いことだと思います。業務に使ってみて初めて分かることもあります。
➍ 開発者へ早期にフィードバックを提供できる。
「経験ベースのテスト技法」と「テスト結果のフィードバックの速さ」は関係ないと思います。こちらは何を想定しているのかすら分かりませんでした。
➎ 作成するソフトウェアに関してチームが精通するのに役立つ。
こちらも、「経験ベースのテスト技法」とのつながりが分かりません。そんな気になるだけだと思いますし、テストをする前に作成するソフトウェアに関して熟知しておくことが大切と思います。
❻ 運用上の故障を効果的に分析できる。
運用上の故障って何だろう。
経験ベースのテスト技法で分析できるとは？ はて？？
❼ 多様なテスト技法を適用できる。
これが経験ベースのテスト技法の長所なのでしょうか？ブラックボックステスト技法の方が多様なテスト技法を適用できると思うのですが。
■ 経験ベースのテスト技法の短所
シラバスの内容を引用します。
● 詳細なテストドキュメントを必要とするシステムでは不適切なことがある。
● 高いレベルの再現性を達成することは困難である。
● テストカバレッジを精密に評価できない。
● テストケースがその後の自動化にあまり適さない。
「長所」のほうも、よくわからなかったけれど、「短所」については、本当に「ちょっと何言ってるか分かんない。」（富澤たけし）
「バグケチョンテスト」（松谷さんのYouTubeより）とかだと、こういう短所があるのかなあ？
少しでも記憶に残るようにひとつずつ確認しますね。
❶ 詳細なテストドキュメントを必要とするシステムでは不適切なことがある。
経験ベースのテストは、「経験」という暗黙知を使用するからドキュメント化には向かないということでしょうか。原文を確認します。
It may be inappropriate in systems requiring detailed test documentation.
「不適切」は「inappropriate」の訳なのですね。inappropriate は、例えば、フォーマルな場にジーンズで行っちゃった的な「ふさわしくない」の不適切です。経験ベースで気が向くままテストをするのは、確かに銀行のシステムをテストするときにたくさんのテストスクリプトを残すような方法をとる場面では不適切で使いどころではない感じなのでしょう。一方で、銀行のシステムのテストにおいても経験を使ってテストケースを捻りだす場合もあると思うのですが。
❷ 高いレベルの再現性を達成することは困難である。
High levels of repeatability are difficult to achieve.
どうやら、探索的テストのように、テストスクリプトを作らないタイプの経験ベースのテスト技法の話をされているようです。（違っていたらすみません）
ただ、テストスクリプトがあったら、高いレベルの再現性を達成できるかというと、そんなことはありません。
高いレベルの再現性がほしければ、動画を取っておくか、ペアテスト（二人組でテストを実施）をすればいいんじゃないでしょうか。
❸ テストカバレッジを精密に評価できない。
The ability to precisely assess coverage is limited.
こちらは、シラバスのもう少し先のところに「カバレッジについていくつかのアイデアを提示するが、経験ベースのテスト技法には、公式なカバレッジ基準が存在しないことに注意する必要がある。」と書いてありますので、ALTAのテストに出やすいかもしれません。「モデルベーステストのようにカバレッジを体系的に定義できない」ということを言いたいのだと思います。
➍ テストケースがその後の自動化にあまり適さない。
Tests are less suited for subsequent automation.
Testsをテストケースと訳していますが、テストケースを作らない探索的テストの話じゃなかったのかーい（笑）。
「テストは、その後の自動化にはあまり向いていない。」でもいいんじゃないかなあ。
❶～❸の「❶ テストドキュメントが作りにくいテスト」で、「❷ 再現性が低いテスト」で、「❸ テストカバレッジを求めにくいテスト」だから「➍ 自動化に適さない」と言いたいのかなと思いました。
ということで、一つずつ見ても私にはよくわからなかったので、今回は申し訳ありませんが、（ALTAの試験対策としては）暗記してください。
そんなに難しい問題は出ないと思うので、3回くらい読んでおけば十分と思います。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-3.3.1 （K2）経験ベースのテスト技法の原則と、ブラックボックステスト技法および欠陥ベースのテスト技法と比較した場合の長所と短所を説明する。
「K2」なので「理解」できたらOKということです。
（K2：理解、K3：適用、K4：分析）
ということでそんなに難しい問題はでません。
《問題》
経験ベースのテスト技法の長所では【ないもの】はどれですか。
1. ドキュメントが不足していても効果を発揮する
2. テスト時間が厳しく制限されている場合に適用できる
3. 運用上の故障を効果的に分析できる
4. テストカバレッジを精密に評価できる
答えは次回に書きます。
≡ おわりに
今回は、「経験ベースのテスト技法」がテーマでした。
類似したソフトウェアのテスト経験があるとないではテストの質が大きく変わります。
その一方で、製品は違うけど、そこだけ切り出せば似たようなものという見方もできます。
例えば、ゆもつよメソッドで使用している論理的機能構造図（下記図はこちらのページから引用しました。）まで抽象化してしまえば、どのようなテスト対象であっても当てはまります。
上記図に「論理的機能構造モデル」と書きましたが、テスト対象をある程度抽象化して捉えてきていたらその経験は新しい商品やサービスのテストでも役に立つはずです。
次回は、「3.3.1 エラー推測の定義」について書きます。
この記事が気に入ったらサポートをしてみませんか？