見出し画像

第109回：　経験ベースのテスト技法

Kouichi Akiyama

≡ はじめに

「ASTERセミナー標準テキスト」の150ページについてです。

前回は、「制御フローテストの設計」について書きました。今回は「経験ベースのテスト技法」について書きます。

これから「経験ベースのテスト技法」として、テキストにある「エラー推測」と「探索的テスト」と「チェックリストベースドテスト」について書こうとしているのですが、これらを「テスト設計技法」と呼んでよいのか、ちょっと疑問に思います。

技法をTechniqueと捉えますと、「（技法を）適用する目的」「適用にあたっての前提条件」、「適用の手順」、「終了判定基準」が明確に定義されていて、その効果も定量化されているものを期待します。

「エラー推測」と「探索的テスト」と「チェックリストベースドテスト」はTechniqueか？ というと、ちょっと違うように思います。

マイヤーズの『The Art of Software Testing』という本が翻訳され、『ソフトウェア・テストの技法』という書名になっています。
「経験ベースのテスト技法」でいう「技法」は「Technique」というよりも、「Art」のほうではないかと思います。

つまり、芸術は、基本的な手順はあれど、その手順をマスターしたら誰でも同じレベルの物を創作できるかというと、それはきっと無理なことです。

少しレベルが落ちた似たものを創作するだけでも、工房などで、共同作業などを通じて言葉にならない知恵のようなもの（暗黙知）を伝授してもらう必要があります。Artとは、そういうものだと思います。今回の「経験ベースのテスト技法」は、技法は技法でも「Art」のほうなのだろうなと思います。

以下で、テキストにある「エラー推測」と「探索的テスト」と「チェックリストベースドテスト」について書きますが、上記の意味で、このnoteを読んで理解したと言っても、機械的にできるものではないことを先にお断りしたいと思います。

前回の「制御フローテストの設計」は、Techniqueですので、例えば、ステートメントカバレッジの知識を取得して練習したら、誰でもステートメントカバレッジを計測しながら制御フローテストを進めることが出来ます。


≡ エラー推測

まずは、ISTQBの用語集を確認します。

エラー推測（error guessing）
テスト技法の1つ。テスト担当者の経験を駆使し、過去の故障の知識や故障モードの全般的な知識を使用して、テストを導出する。

「故障モード」という、人によって解釈が異なっていることが多い用語がエラー推測の定義に含まれていますので、こちらもISTQBの用語集を確認します。

故障モード（failure mode）
物理的または機能的な故障の兆候。たとえば、故障モードのシステムは、遅い運用、間違った出力、または実行の完全な打ち切りなどで特徴付けられる。

ちょっと内容がよくわからないので、英語での定義もISTQBの用語集で確認してみます。

failure mode
The physical or functional manifestation of a failure.

ええと、同じですね。💦
テキストの該当部分を引用します。

起こりえるエラー、欠陥、故障のリストを作り、それらの故障やそれらを引き起こす欠陥を検出するテストケースを設計する。エラー、欠陥、故障のリストは、テスト担当者の経験、欠陥や故障のデータ、ソフトウェアが不合格となる理由に関する一般的な知識に基づいて作成できる。

テスト技法の多くは、仕様書などのテストベースをもとにして、ソフトウェアへの入力や入力する順番について、それらの粒度を決めたうえで、漏れなくダブリなく操作することで、テスト対象の振る舞いを網羅的にテストするために使われます。

例えば、前回の「制御フローテスト」であれば、
　・　テストベース：　ソースコード
　・　入力や入力する順番：　処理フロー（＝　ロジック）
　・　粒度：　ステートメント、デシジョン、条件、複合条件、MC/DC
を決めて、漏れなくダブリのないテストとなるようにテストデータを用意してテストします。

ところが、エラー推測は、仕様書などのテストベースをもとにするところまでは同じですが、先に「（この仕様だと）開発者はこんな間違い（エラー）をしそうだ」と想定します。そして、「想定したエラーが発生するなら、その結果として、開発者は、こんな欠陥を作りこんでしまうだろう」と推測して、推測した欠陥をリストします。
あとは、リストした欠陥を見つけるためのテストケースを作ります。

2018年度版のFLシラバスを読みますと、エラー推測でいう「エラー」は、「ヒューマンエラー」や「ミステイク」だけを指すのではなく、fault（欠陥）やfailure（故障）についての知識、すなわち「エラー、欠陥、故障を引っくるめた間違いについての知識」を活用するテストのように読めます。
要は「エラー推測」は「間違いの知識と経験を用いて、それが存在すると仮定した時の振る舞いを推測するテスト」と言えます。

ところでSQuBOKにおけるエラー推測の分類は、経験ベースのテストではないって気が付いています？
SQuBOKでは、「フォールトに基づいたテスト」なんです。JCSQEの試験を受ける人は、要注意かな。
そんな問題はでないと思いますけど。

テキストにもありますが、推測は、「テスト担当者の経験、欠陥や故障のデータ、ソフトウェアが不合格となる理由に関する一般的な知識」に基づいて行います。
逆に言えば、経験と知識が貧弱であれば良い推測はできません。

エラー推測によるテストで良い結果を出すためには、深い経験と高度な知識が必要ということです。これは、他の「経験ベースのテスト技法」でも同様です。
セミナーやシンポジウムで「エラー推測のコツ」や「効果的な探索的テストの方法」といった講義や講演を聞くことがあるかもしれませんが、それらのコツや方法が活きるためには、深い経験と高度な知識を必要とします。

セミナーやシンポジウムで実際にエラー推測や探索的テストの実演をしてくれる場合があります。「講師が考えていることを自分は思いつくかな？」と考えながら視聴してみてください。いかに彼らが経験豊富で目配りできているかを痛感する思います。

どうすれば、深い経験と高度な知識が身につくかというと、私は、一件一件のバグを大切にするしかないように思います。

具体的には、テストしてバグを見つけて直ってきたら、その原因について自分が納得するまで理解するの繰り返しです。どうしてこのバグは作り込まれたのかについて粘り強く開発者に食らい付いて、最初はウザがられるかもしれませんが、バグの知識を蓄えていく。それを意識的に蓄積していくしかないよなあと思います。成果はすぐに現れないですし、地味で大変なことですが。


≡ 探索的テスト

こちらも、まずは、ISTQBの用語集を確認します。

探索的テスト（exploratory testing）
テスト担当者がテストアイテムや以前のテストの結果の知識や調査情報を使用して、テストを動的に設計、および実行するテストアプローチ。

ええと、間違いではありませんが、探索的テストが何かについての説明としては省略しすぎているように思います。
そこで、こちらも、テキストの該当部分を引用します。

テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。

要するに、「テスト設計・実行・記録・評価を同時に行う」ということです。
このときに、テストの実行結果（実行時のテスト対象の振る舞いも含む）をもとに、今テストしたところについて、もっと深くバグ探しをするか、次の場所に移るかを決めながらテストを進めます。

テストスクリプトを作らずにテストを実施するときは、だいたいこんな感じですよね。テストスクリプトを作る人とテストを実行する人が同じ場合でかつ、テスト結果のエビデンスの提出が求められていないときには、テストスクリプトを書こうというモチベーションが湧きません。書いている時間が惜しいからです。
そんな時間があるなら、少しでも多く気になるところをツツいてみたいと思うものです。
また、探索的テストは、テストベースに加えてテスト実行結果の情報を元にしたテストを考えられるという大きなメリットが魅力的です。単純に考えて、テストを作る上での情報が増えている訳ですからより良いテストが出来ます。

「そうくるなら、これはどうだ！」という感じでテストを進めるのは楽しいものです。逆に「ほほう。ちゃんと考えて作ってるね。じゃあこの辺はバグがなさそうなので打ち切って、次のところをテストするか」というように、無駄なテストをしなくてすむところも探索的テストのメリットです。
私自身の話をすれば、仕様書を最低5回読んで、仕様とテストしたいところが身体に満ち満ちてきたらテストを始めてずっとテストする方法が好きです。
でも、仕事の時には他の人にテストの抜けについてレビューしてほしいので、6W2Hのツリーやラルフチャートを描いています。これらを描いているときに自分で自分自身の考えの浅さに気がつくこともありますし。しかたない。

しつこいですが、このメリットは深い経験と高い知識があってこそ得られるもので、初心者がテストのエキスパートと同じように深掘ったり打ち切ったりできる特別な手順があるわけではありません。

探索的テストは、アジャイル開発時などのテストケースを作成する時間が取れない場合に行われることが多くなりました。

多くなったので、せめて、効率よく網羅的に探索しようという工夫（チャーターの作成等）と、複数人で探索的テストを実施するならテストの結果情報（この辺が弱そうなソフトウェアだよといった情報等）を交換することで、より良い探索をしようといった工夫（タイムボックスで一定時間テストしたら情報を交換する等）がされています。

ところで、以前、こんなツイートをしました。

湯本さんや咳さんからのリプライが良いのでそちらも読んでほしいのですが、私のツイートの意図は、「（テストマネージャーが）メンバーに探索的テストを依頼するときには、気をつけてね」ということです。気をつける方法は、湯本さんがされているように「探索的テストをセッションベースで実施して、セッションごとにエキスパートが入って振り返りをする」方法も良いと思いますし、「エキスパートが全体を半日くらいで探索し、深掘りするポイントや深掘りの方法についてメンバーに指示する」という方法もあるでしょう。「エキスパートとのペアテスト」も良いと思います。

いずれにしても、スクリプトを作成するアプローチをとる時には、
　テスト分析→【識別したテスト観点やテスト条件のレビュー】
　→テスト設計→【適切にテスト技法を使ってテストケースを作っているかのレビュー】
　→テスト実装→【テストスクリプトのレビュー】
と、少なくとも3回のテストプロセスの中間成果物のレビューを実施するタイミングがありました。そして、そのレビューを通じて、レビューを受ける側のエンジニアは気付きを得て、成長できる機会がありました。探索的テストでもその良さが無くならないように気をつけてほしいと願います。


≡ チェックリストベースドテスト

こちらも、ISTQBの用語集を確認します。

チェックリストベースドテスト（checklist-based testing）
経験ベースのテスト技法であり、経験を積んだテスト担当者が、気づき、チェックし、あるいは記憶すべき項目の高位レベルのリストやルール集、検証すべき基準を使用して実施する。

どこをチェックするか、どんな基準で検証するかのチェックリストを事前に作っておいて、それを使ってテストする方法です。チェックリストは組織のノウハウを形式知化した資産となります。

インストールのテストなど、ある程度共通な動きをして、見るべきポイントが決まっているものでないと、チェックリストの活用は難しいと思います。ただし、静的テストのレビューについては、チェックリストが基本となります。


≡ 終わりに

今回は経験ベースのテスト技法について書きました。

知識を身につけて、経験を積んでから行ってください。←しつこい！！

4章が終わったので、次回は「82号：テストのコンサルティング（前編）」の続きを書きたいと思います。

この記事が気に入ったらサポートをしてみませんか？