シャノンでQAを担当しているinomataと申します。
シャノンに来てからはまだ1年半くらいですが、社会に出てソフトウェアテストしかやってないので、もう6年以上テストしてます。
そんな自分が今まで学んできたソフトウェアテストの技法を紹介していきたいと思います。
絵や動画とかありませんが、リファレンス的にさらっと見ていただければ幸いです。
静的解析
いわゆるコードレビューです。
論理判定のポイント、データと変数の使い方、コーディング規約の準拠等を見ます。
実施の方法も、複数人で行うウォークスルーから、個人で行う机上チェックなどあります。複数人で行う場合は人物評価にならないようにしなくてはならないように注意しなくてはなりませんが、多角的な意見が出るのでエラーの検出率は上がります。また他人のコードを見ることで学習できるという副次効果もあります。
また静的解析にはコードレビューのほかに、webサイトの構造を見るテストも含まれます。
動的解析
メモリリーク、ポインタの不正使用等の再現しにくい欠陥の検出のために行うテストです。
再現が困難な場合が多いので、一般的にツールを使用してテストを行うみたいです。
同値分割
おそらくテストの教科書を開けば2章あたりに乗ってたりする、一番最初に出てきそうなテスト技法です。（一章はテストとは？的なものだったりします）
ある入力、あるいは出力に対して有効同値と無効同値を識別し、それぞれの入力（出力）を実行するテストです。同値は数値であったり、バイトであったり、タイミングであったりします。このテストは如何に同値を識別できるかでテストケースの良し悪しが決まります。
また、出力による同値というのは、割と見落とされがちな気がします。
境界値分析
テストの教科書を開けば3章あたりに出てきそうなテスト技法です。
ある入力値と出力に対し、上限と下限を識別しそれぞれの端の値を入力（出力）し、実行するテストです。この場合の境界値とは実際の入力（出力）の限界ではなく、たとえばバイトの区切り、一画面の表示件数なども検討する必要があります。
とあるゲームの255個以上のセーブデータを作成できないというバグは、このテストをしっかりやってれば検出できたものでしょう。
デシジョンテーブル
組み合わせテスト技法のひとつ。論理回路のような記号でグラフで表すものもあります。
複数の設定値を持つ機能がいくつかある場合、それらを組み合わせたものを全部網羅するようにテストケースを作成します。
基本的に全部網羅するので欠陥の検出率はそれなりに高いです。また、表を作成することで仕様の不備も探せるという副次効果もあります。
組み合わせを全部網羅した場合、その数はトンデモナイ数字になったりするので、直行表、オールペア法等で間引く工夫が必要です。ただし、それらの方法を機械的に使用した場合、一番利用頻度の高い組み合わせが抜けてしまったりすると大変なので、作成した組み合わせはよくレビューしましょう。
状態遷移テスト
プログラムの状態の遷移を確認するテストです。
電気ポットの沸騰中→保温とか、HDDレコーダーの録画準備→録画など、各状態が条件によって正しく遷移するかを確認します。携帯電話であれば着信状態になる前のバリエーションを考えたりと、その遷移前、遷移後のバリエーションがポイントでしょうか。やはりこれも組み合わせがトンデモなくなってしまいます。その場合は状態遷移をグラフとして表し、先の直行表、オールペア法等で間引く工夫が必要です。
探索的テスト
プロダクトの学習、テストの計画、実行を同時に行う方法です。
ランダムテストのような行き当たりばったりなテストではなく、テストで必要な活動を同時進行で行います。
実際に動くものを見ながら、入力値の境界値や、設定の組み合わせを考えていったりする方が効率が良かったりします。もちろんテストに関してそれなりに経験、知識がないとできない方法ではあります。
個人的にはアジャイル開発プロセスのような、素早い開発にもっとも適した方法じゃないかなんて思ってます。ただその活動内の細かいドキュメントやメトリクスの収集までしっかりやろうとすると大変でしょう。
エラー推測
勘と経験の技法です。
勘と経験を侮ってはいけなません。培った経験はテストの技法のほかに扱う製品の知識もあるので、有用なテストケースを生みだします。しかし、仕様書に例外パターンが書いていないように、その経験を明文化するのが難しいものでもあります。この部分のテストを補完するには経験者のレビューを受けるのが一番だと思います。
ランダムテスト
行き当たりばったりで動かしてテストします。
数々の技法で検討されてきたテストに比べて、あまり有効なテストにならなそうなのは察しがつくでしょう。ただ、ある入力に対してランダムなものを入れてみるテストや、バグが収束後のダメ押しのテストとして実行しているのを見たことがあります。
形式ばったテストを行わないので、システムを俯瞰しやすいテストではあると思います。
機能部分テスト
機能が目的を達成できるかのテストです。
方法としては仕様書のレビュー、実業務と同じ手順でシステムを動かして機能が業務目的を達成できるのかを確認するテストです。出来上がったもの使い物にならないなんてことにならないように、第三者の視点を持って機能を確認します。
シャノンではシナリオテストと呼んでいるものです。
大容量テスト
プログラムに大量のデータを扱わせてみるテストです。巨大なデータを処理させたり、キューをいっぱいにしてみたりします。ユーザーの目的を達成できるデータを扱えるのはもちろん、ロバストネスな設計であることを確認することを目的とします。
このテストは時間的なコストがかかりがちなので、適切な量のテストを見極めるのが重要になります。
ストレステスト
プログラムに重い負荷をかけるテストです。
大容量テストと似ていますが、こちらは短時間に最大容量のデータを処理させるテストです。負荷をかける場所、方法など目的をはっきりさせて実行することがポイントとなります。場合によっては本番と同じ環境を用意する必要があったりと、コストのかかるテストです、しかしこのテストは大変重要で、ここで逃したバグは割とヒドイ結果で市場で発見されます。最近起きた新幹線の管制システムトラブルによる事故は直接的には人為的ミスですが、間接的な問題はこのテストを行っていれば防ぐことができたといえます。
ユーザビリティテスト
ユーザーが使いやすいシステムかどうかのテストです。
UIの見せ方、セットアップ手順などいろいろな観点があります。如何にユーザーが使いやすいかを見なくてはならず、第三者の視点が必要な分野です。webサービスのベータテスト、製品モニターみたいにいっそのこと第三者に見てもらおうというのもこの領域でしょう。家電ではユーザーが箱から取り出してセットアップするまでを観察するテストなんてものもあります。
セキュリティテスト
如何にセキュリティが強固にできているかを確認するテストです。
テスト方法としてはペネトレーションテストというものがあります。実際にシステムに攻撃を行い、セキュリティの堅牢性を確認します。似たシステムのセキュリティ問題を参考にテストケースを作成するのがポイントですが、専門の業者やツールを使用する場合が多いそうです。セキュリティの脆弱性が問題になるのは言うに及ばずですね。
構成テスト
プログラムをシステムに組み込んで行うテストです。
パッケージソフトならOSとの組み合わせだったり、家電だったらTVとBDレコーダーとホームシアターセットを組み合わせて使用できるか、なんてのを見たりします。遠隔医療システムのようなセーフクリティカルなシステムの場合、実際のシステム構成でテストを行うことは必須と言えるでしょう。「外部調達したルータのせいでシステムが動かない」なんてことが起こらないともいえません。
回復テスト
機能がいかにかに復帰するのかを確認するテストです。
システムにエラーを組み込んでどうやって復帰させるのかを行います。システムの復帰が自動なのか手動なのかは問いませんが、復帰手順を定義しMTTRを最小にすることを目的とします。どうやってエラーにさせるかというパターンがポイントでしょうか。
受け入れテスト
プラグラム的な欠陥を見つけるもではなく、導入時のエラーを見つけるテストです。
必要な手順、ファイル、ハードウェア構成が適当であることを確認します。マニュアルのレビューから実作業まで行って欠陥を洗い出します。
いかがでしょうか。結構ありますね。このほかにもまだあるでしょう。まあ沢山知っていれば偉いというわけではないですが、手持ちの武器は多いほうに越したことは無いでしょう。適材適所で効率の良いテストをしましょう！
