mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

テスト分析はどうやらテスト対象分析だけではダメで、テスト要求分析も必要らしい

テスト分析の記事について、識者の方々にありがたいコメントをいただきました

以下の記事について、識者の方々から多くのコメントをいただきました。ありがたいことです。

テスト分析についてなんとなくわかった気がする - mhlyc -presentation

そこで言われたのがタイトルの「テスト分析はどうやらテスト対象分析だけではダメで、テスト要求分析も必要らしい」ということです。また、一緒にするのも良くないです。

 

 

 

なんでテスト対象分析だけではダメなの?

自分の考えでは「テスト対象を理解して、何をテストすべきか明確にすることができれば、テスト戦略やテスト計画のインプットとしては十分」としていましたが

よく考えれば「それってほんとか?」という話ですね。

Oさんが言われていましたが「 実行時の優先度付けや、網羅度/強度を決めるのにテスト対象の情報以外のものが必要になる」ということです。

 

例えば、テスターのスキルやドメイン知識を持っているかどうかなどは直接テスト対象に関わりません。なので、テスト対象分析のスコープからは外れることになります。

しかしこれは確かにテスト戦略やテスト計画に大きく関わりますね。

 

要求?制約?

話が多少ずれますが、

テスターのスキル、リソースやスケジュールと聞くと、要求というより制約という印象が強いです。と、思ったのですがやっぱり要求なのかもしれません。

というのも、制約は「...な状態を〜〜に制限する」とか、基本的にマイナスの方向に働くと思うのですよね。

しかし、要求はというとそうとは限りません。「...という要求があるため、〜〜な対応をとる」となります。これはマイナスの働きとは限りません。

例えば、(あまりないかもしれませんが)「使用できるテスト用環境が増えたため、テスト環境を増やしてほしい」という要求は、要求ではありますが制約ではありませんね。なぜなら、テストは制約がかかるどころかむしろ対象範囲が広がっているからです。

 

テスト対象分析とテスト要求分析

テスト対象分析とテスト要求分析はそれぞれカバーする範囲が異なるわけですが

個人的にはテスト対象分析はエンジニアリング的側面が強い一方、テスト要求分析はマネジメント的側面が強いような気がします。なので、人の立場によって漏れが発生しやすい/しにくいとかあるかもしれません。例えば、自分は部下をマネジメントする立場にないのでテスト要求分析の話は少し想像しづらい部分がありました。

 

ソフトウェアテストに関する用語の統一の話 

以下、湯本さんがツイッターで言われていたことです。

 

これはまさにその通りで、反省する思いでいます。

自分の中では、テスト設計コンテストのチュートリアルだったり本に載ってるテストプロセスだったりISTQBだったりで全然言葉の表現も範囲も異なるので本当に混乱しています。それで自分なりに直した言葉がテスト分析の話でいうと「テスト対象分析」でした。これでは自分は理解できるかもしれませんが、結局それでは混乱に歯止めはかかりませんね。

 

今後は自分の中で理解をまとめつつも、人に話すときはISTQBとか国際標準の言葉ベースに直して話せるようにしていきたいです。実際、識者の方はそのあたりキチッと勉強されていて、何かしら共通の認識として持てる定義に基づいて話をするイメージがあります。