ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

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」となっていたとしても、やり直しです。
 人間、同じことを何度も繰り返すというのは、本当に苦痛ですよね。詳しくはシーシュポスの岩をご参照ください。

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

ずっと受けたかったソフトウェアエンジニアリングの授業1 増補改訂版

ずっと受けたかったソフトウェアエンジニアリングの授業1 増補改訂版

www.kzsuzuki.com

 ところが中国などでは違います。バグは仕事上のミスで、それは罪とみなされます。即刻給料に反映され、最悪の場合には解雇されることもあります。このような会社の社員は罪と罰を強く意識せざるを得ない環境にいます。そのため、自分たちのバグは絶対認めたがらないのです。

 とても、もったいないと思います。

 ・・・どうも、「シラバスに書いてあること」と「すずきの思い」が混じってしまっており、万が一このサイトを参考にしている人がいたら、誤解を招くかも知れません。「事実と意見を区別せよ」とはよく言ったものですが、ここではなされていませんので、みなさん、シラバスを読んでください。