テスト分析とは？

　さて、派遣エンジニアとして勤務を開始して6ヵ月程度が経過しました。最初はいわゆる「テスター」のような作業中心の業務だったのですが、ようやく「テスト設計」のチャンスが巡ってきました。

　最初のフェーズはテスト分析。まずは仕様書を読んで機能を把握して、どの機能に対してどういうテストをしていくか？を考える所からかな？と思っていましたが、お客様からの指示は「まずは仕様書からソフトウェアの動作に関係する因子と水準を全て洗い出せ」とのこと。

「急に組み合わせテストの話？この製品が持っている機能と、それぞれの機能に対してどういうテストをするべきか？はいつ誰が考えるの？組み合わせじゃなくって、まずは仕様書通りに動くよね？っていう観点のテストはいつ誰が考えるの？」というのは聞いてみたものの、プロジェクトとして曖昧になっているようで回答は有耶無耶に。ということで、まずは見たこともない製品の要求仕様書400ページ程度をひたすらに読みながら因子と水準を抜き出しています。こういう作業は人の目と手でやると必ず抜け、漏れが発生するので、何か良いツールができないものですかねぇ。

　「テスト分析」とは何なのか。私はまともにシステムテストの設計なんてやったことはありませんが、まずはどういう機能があるのか、それぞれの機能に対してどういうテストが必要なのかを明確にする。そして状態遷移テストが必要なら状態遷移図を書くし、組み合わせテストが必要なら該当機能に関係する因子と水準を洗い出す、といったことをする工程なのかな？というイメージがありました。「まずは400ページ程度の仕様書を読み進めながら因子と水準を洗い出す」これもテスト分析の一つのやり方なのでしょうかね。組み合わせテストだけに着目すれば、このやり方もアリなのか、とってもモヤモヤしています。

　話は変わり、元々は開発を担当していて、要求仕様書や外部設計書なんかを書く立場だったのですが、これらの仕様書の中に必ず入れているモノがありました。「用語一覧」と「動作に関係する要因（設定や外部要因）一覧」です。新たにメンバーが加入したときにわかりやすいように、と配慮してこれらを入れていましたが、テスト設計者の観点で仕様書を見たとき、これらがないと仕様の理解に非常に苦しむ、ということに気が付きました。我ながら「オレって意外とイイ仕事していたのかもな」なんて思ってしまいました。

　開発規模は小規模で「自分で作ったものくらい自分でテストしろ」という会社だったので、私が書いた設計書を他の人が読む機会なんてほとんどありませんでしたけどね。