JSTQB-ALシラバスのお勉強 - 2.5 - ソフトウェアの品質を学びまくる

　いろいろ書いてきますが、「明らかに間違ってるだろ」とか「それは違わなくない？」っていうご指摘があれば、ぜひくださいませ。わたしは修行中の身です。一人でしんみり学んでいると、読み合わせという活動の喜ばしさがよくわかります。

　・・・さあ、2.5は、テストの実装と実行です。

2.5.1 テストの実装

　「実装」とは分かりづらい言葉ですが、要は準備の総仕上げですね。これまで、テスト対象やテスト条件を見定めたり、必要な環境を分析してきたわけですが、ここにきて、それらを実際に準備することになります。具体的には以下の作業が。

スケジュール作り

　スケジューリングにおいて配慮すべき点は2つ。1つはもちろん、テストの目的を達成するために設定したプライオリティ。
　もう1つは、テスト環境やテストデータによって現れる制約。たとえば、実環境に近いくらい十分なダミーレコードをDB上に準備したのに、最初のテストアイテムは、レコード一括削除バッチ！ってどうなのよ。ってことですかね。

テストスクリプトの作成

　テストスクリプト（test script）は、

一般的にテスト手順を指して用いられる。特に自動化時のスクリプトを指す。 (JSTQB)

とあります。手動か自動かによって、意味が変わるので注意ですね。個人的には、手動なら「テスト手順」（英語で「test procedure」とか）、自動なら「テストスクリプト」と使い分けたいところですが。何しろ「手順」ですし。

テストデータの準備

　テストデータそのものだけでなく、それを自動生成するためのツールも含みます。単純なテキストデータであれば、Excelで簡易ツールを作ることも多いですよね。

テスト環境の準備

　当たり前ですが、テスト環境は事前に準備して、ちゃんと動くことを確認しておけと。しばしば後回しになりますが。
　ここで「環境」というのは、サーバやネットワーク機器、テスト端末などだけではなく、テスト支援アプリケーションなどのツール面や、テスト中にどのログを保存しておくかといったルール面の整備も含みます。

　最後の段落は、若干話が各論に飛んでいますが、スクリプトに基づかないテストを、場当たり的に行うなと。
　テストケースの消化と並行してテスト分析・設計を行う経験ベースの技法（experience-based techniques）は、攻撃（attacks）・エラー推測（error guessing）・探索的テスト（exploratory testing）などが考案されていますが、これらはあくまで、エキスパートがいて初めて成立する技法ですよと。「計画なんていらない！おれは経験ベースで行くだぜ～」などと安易な気持ちで、テストの自転車操業をしないでくださいねということですね。

　なお、ここで紹介された3つの技法については知識が足りていませんので、理解できたら紹介します。
　また、シラバスに「SBTMの項を参照」とあります。「SBTM」を日本語googleで調べると「Softbank Telecom」がヒットしてしまいますが、「Session-based test management」のことのようです。これについても、別途ふれたいと思います。

2.5.2 テストの実行

　ようやく、実行です。

　テスト担当者は、「実装」で決めたスケジュールに基づいてテストケースの消化を行うことになりますが、ある程度の自由裁量（latitude）はアリ。「そういえば、こう操作したらどうなるんだろ？」的な発想は、当然生かされるべきですよね。ただし、何をしたかの記録は必須です。

　テスト実行の主なお仕事は、テストケースで定めた期待結果と現実の結果が、一致するかしないかを見極めるということ（と、その記録！）です。一致しないならば、それはインシデントです。ちなみに、インシデントとは以下。

発生した事象の中で、調査が必要なもの (JSTQB)

　シラバス日本語版では明確に訳されていませんが、ここで「false negatives」「false positives」という言葉が出てきます。元々は統計の言葉ですよね。ソフトウェアテストでいうと、それぞれ、「正常なのに欠陥と判定してしまった」「欠陥なのに正常と判定してしまった」ってことです。

　インシデントの原因は、テストアイテムであるソフトウェアの欠陥とは限りません。用意した環境やデータが悪いのかも知れませんし、テストケースの元となったドキュメントが誤っているのかも知れません。
　テストベースが間違っていることが発覚したら、テスト担当者は号泣します。その間違った範囲に基づいて設計したテストケースのうち、消化して「OK」となっていたとしても、やり直しです。
　人間、同じことを何度も繰り返すというのは、本当に苦痛ですよね。詳しくはシーシュポスの岩をご参照ください。

　本節では、テストの実行状況・結果の記録の重要性が、繰り返し強調されます。
　インシデントの記録の方法は、実装段階で準備されているはずですが、これは組織として標準をもっておくといいですよね。これは単に、調査や修正の元ネタになるだけでなく、品質分析のためのネタでもあり、組織として共有すべきノウハウも含まれているかも知れない、宝の山だ！（と、上司に教えられました）。
　先日紹介した『ずっと受けたかったソフトウェアエンジニアリングの授業』に、「オフショア開発におけるバグの認識の違い」としてこんなことが書かれています。