米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を元に，ソフトウエア・テストの作業を細かいプロセスに分けて見ていきます。開発プロジェクトにおけるテストの位置付けとして，まず最初にテスト戦略を考え，目指すべき品質に対するテストの方向性を決めます。
たいていの場合，ソフトウエア・テストというと，どうやってテストをするのかといったテストの実施部分だけを思い浮かべるのではないでしょうか。しかし，テストを実施面だけでとらえていては，効果的なテストはできません。
そこで，米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を紹介しましょう（図1）。このモデルでは，開発とテストは最初から並行して進んでいくプロセスとして表現しています。先ほど，「テストは同時並行的に進めるライフサイクルプロセスである」という定義を引用しましたが，まさにそのイメージがWモデルになるわけです。
この考え方をベースに，さらにソフトウエア・テストの作業（アクティビティ）を細かいプロセスに分けたのが図2です。これを見ると「テスト実施」というのが，ソフトウエア・テストの全体の中で，ほんの一部でしかないことがわかりますね。つまり，図2に挙げたそれぞれの作業を確実にこなすことで，テストをマネジメントすることができるのです。では，図2の各プロセスで行う作業（アクティビティ）をそれぞれ詳しく見ていきましょう。
効率のよいテストは優れたテスト戦略/設計から
まず，開発プロジェクトにおけるテストの位置付けとして，最初に考えるべきことが「テスト戦略」です。
テスト戦略
「ユーザーの使用頻度が高い部分を中心にテストする」「変更部分を中心にテストする」「すべてのテスト要件を確実にテストする」「イテレィティブな開発に合わせて繰り返しテストを行う」などのように，目指すべき品質に対するテストの方向性を決めます。
テスト分析（テスト対象，品質リスク）
続いて重要なのが「テスト分析」です。作業は大きく分けて二つあります。一つは「テスト対象の分析」です。テストするシステムやソフトウエアの要件や設計を理解して，テストの対象になるテスト要件を洗い出す作業を指します。
もう一つが「品質リスクの分析」です。これはテスト分析でわかったテスト対象の全体から，テストをどの程度行うか強弱を付ける作業です。本来ならテストすべき部分に対して完璧にテストすることが理想ですが，現実には，時間的/経済的な制約からすべてをテストすることはできないでしょう。そうしたときに，限られた時間と費用で最も価値のあるテストを実施できるように，力を入れてテストする部分と力を抜く部分を選別するわです。これは医療における「トリアージ（災害時の医療現場で，負傷者を重傷度に応じて選別し，より多くの負傷者の治療を可能にすること）」と同じ考え方です。では，テストに力を入れるべきか，入れないかを判断する基準はどうすればいいのでしょうか。その基準が「品質リスク」になります。
品質リスクとは，「その機能が正しく動かないことによって受ける（かもしれない）損害」のことを指します。品質リスクを考える場合は，重要な機能が動かないほどユーザーの損害が大きくなるため，ユーザーが重要視している度合いと，ソフトウエアの修正コストが大きくなるため技術的に困難な度合いの二つの面からとらえるのが良いでしょう。
このように，テストを品質リスクの軽減策の一つだと位置付け，テストの仕方を決めていくことをリスク・ベース・テストと呼びます。ここでいう“リスク”は，プロジェクト・マネジメントの文献などに出てくる「プロジェクト計画上のリスク」とは少し考え方が異なるので，混乱しないようにしてください。
テスト計画
「テスト計画」では，図2のテスト計画の矢印より後の作業をどう行うかを決めていきます。肝になることは二つあります。
まず一つ目が，「テスト戦略」と「テスト分析」を元にアプローチの方法を考えることです。どのようなテスト・レベル（単体，結合，システムなど）を誰が行うのか，また，どのようなテストのタイプ（ホワイトボックス・テスト，機能テスト，パフォーマンス・テスト，構成テストなど）をどのテスト・レベルで適用するのかを決めます。どんな技法で設計して，「テスト実施」を自動化するかどうか，また設計レビューやコード・レビューなどの方法も決めていきます（表1）。
もう一つは，日程計画の中で「テスト・サイクル」をどう回していくかを決めることです。それには，
・いかにして効率よくテストを進められるか
・いかにして早く不具合を見つけられるか
の2点を念頭に置いておくべきでしょう。
テスト・サイクルは，テスト設計で作ったたくさんのテスト・ケースをどういう順番で実施していけば，早く多くテストしていけるかを推し量る作業です。品質目標が違えばテスト・サイクル数は変わりますし，テスト担当のスキル，テスト環境の充実具合，開発チームの体制（修正リリースがどの程度のスパンで行えるのか）によっても変わってきます。
