はじめに
会社からJSTQBで資格をとれ、といわれて初めてテストについて勉強しました。
今までは過去のテスト仕様書を参考にシステムの仕様書見てケース作ってテストして、の繰り返しで、本来テストとはどうあるべきなのかとか何のためにこのテストが必要なのか、というのは正直考えたことありませんでした。
そんな状態から、Foundation Levelとテストアナリストを無事取得しまして、いろいろと思うところが、、、というかまずはいろんな人にテストについて知ってほしいな、と思いました（知らないで10数年過ごしてた自分ってかなり残念だなあとの反省もあり）
そんなわけで、テスト勉強していて意外に思った、というか想定外だったことを中心に書いてみたいと思います。
なぜテストが必要なのか
ソフトウェアが期待通りに動作しないと、何らかの不都合をユーザに与えることになり、作った側にもいろいろ悪いことが起こったりします。
-
経済的な損失
修正・再テストにかかるコストやユーザの業務停止による損害補償、機会損失への補償 -
時間的損失
修正作業による開発担当者の時間圧迫（他の製品の開発コストやスケジュールに影響を及ぼす）
マネジメント的な調整が必要になる -
信用の失墜
製品競争力の低下、会社そのもののイメージの低下、傷害や死亡事故
こんなことになると会社として立ち行かなくなるので、ソフトウェア開発においては、期待通りに動作するものを納品するのが第一目標なわけです。
スタート地点はここです。テストの価値は決して画面キャプチャの数やカバレッジではないのです。
#「期待通りに動作する」の「期待」って具体的にどんなこと？
普通はここで品質の話をするんだと思いますが（実際、JSTQBでもあたりまえ品質と魅力的品質の話とかFRUEMPとか出てきます）実際にはそれ以前のところで引っかかる方が多いよな、と思っています。
どういうことかというと、いわゆる開発あるあるネタ。
お客様に「カレー作って」と言われてカレーだけ作ったらご飯と福神漬けがついてないって怒られたとか、実はシチューが食べたかったっていわれたとか、、、、ありますよね。
原因の大半はコミュニケーション不足と言われたりしますが、実際のところ、欲しいなと思っているものを現実的なシステム仕様に変換するのって、思っている以上に難しいのだと思います。
それは、ユーザが求めているものが具体的な何かであるのに対して、システムで作るのはそのもとになる理論（ルール）だからです。
例えば月末に請求書出して、という要求があったとします。この要求の背景には多くのルールがあります。締めは末日なのか20日なのかとか、年末はどうするのか、末日が休日だったらとか。システムはルールを求めます。こうした見えないルールの存在に気づくことも、テスターに期待されるかのようにシラバスには書かれています。
困るのはこうした「ルール」の存在自体を発注者自身が理解してない時です。請け負った方も気づいていない、細かなルールはシステムが形になっていくにしたがって明らかになったりもします。（いわゆる「やってみなければわからない。」）
テスター像
従来のウォーターフォール型の開発工程では、要求とか要件とかは、かなり上流にあるものです。そうした場合、テスターは実装と同時か実装中にプロジェクトに参加することが多く、要件定義などの初期からかかわることはまれです。
ウォーターフォール式の開発の場合は特に、要件定義がしっかりできていないと後で大変なことになります。なのでJSTQBでは、要件定義に対するテスト、それが本当に顧客の要件を満たしているのか確認すること（レビュー）がちゃんと場所を占めています。
要求を要件に落とし込めているかをテストするためにも、テスターは開発の初期からプロジェクトにかかわるべきだといわれていますし、また、そうしたテスターの能力としては単にテストケースを実行するだけではなく、その案件に関する知識や経験（一般常識や法令も含めて）が必要とされています。
平たく言えばECサイトのテスト担当なら、そのサイトに支払いや配送に関する機能またはそうした機能との連携がなかったら変だな？と思えないとだめだよねってことなのです。
一般に「テストを実行する人＝テスター」という認識だと思っていましたが、それとはちょっと違うな、という印象をうけました。
どこまでテストするのか
もう一つ、有名な「テストの七原則」というのがあるのですが、その中に「全数テストは不可能」というものがあります。
例えば電卓機能を製品に持たせるとして、１＋１、１＋２、１＋３、と電卓で計算できるケースをすべて実行するのは不可能だよね、という話です。
ではそうした場合にどこまでテストするのか、というのが問題になるわけです。一般的な手法の話としては、境界値分析とか直交表とかペアワイズ法とか、あるいはC1カバレッジだとかいろいろあるのですが、そもそもどこまでやるべきなのか、どこまでやればいいのか、というのはまた別の話になります。
それはリスクとコスト、納期から決まります。決まる、というより決める、といったほうが正しいかも。
微に入り細に入りテストできるならしたほうが不具合は減るでしょう。でも現実問題として全数テストは不可能です。ならば、エラーが出たときに影響が大きいもの、またはエラーが出やすいものを中心にテストして、それらの範囲はコストと時間で決めましょう。というのがJSTQBのシラバス（多分アドバンストの方）に書かれていました。
完璧は無理。じゃあ次善の策としてどこまでやっとく？というのを決める（少なくとも決めるための材料を提供する）のもテスターの仕事のうちなのです。
終わりに
個人的な印象、感想を中心に書いてきましたが、テスターの試験だと思っていたので範囲の広さにちょっとびっくりでした。テスト手法とか、バグレポートの書き方とか、そういうものだけじゃなくて、むしろ開発方法や出荷に関わるようなネタも入っていて、自分のテストに対する見方が変わったかなと思います。
テスターだけでなく、プログラマやプロジェクトリーダーにも役に立つことがいろいろ書かれているので、ぜひ勉強してみてください！といいたいところなんですが、JSTQBのシラバスは日本語訳がちょっと。。。なので黒本から入るのがおすすめです。