品質特性に頼ったテスト設計は百害あって一利なし

Yasuharu NISHI @YasuharuNishi

お仕事系のガチなご質問なので、業務時間内にお答えしますね。 #Peing #質問箱 peing.net/ja/qs/878736250

Yasuharu NISHI @YasuharuNishi

品質特性と通常呼ばれるものは、一般にISO/IEC9126(JIS X 0129）ないしISO/IEC250xxシリーズ、通称SQuaREを指します。もちろんプロダクトやサービスごとに異なる品質特性が必要でそれぞれデザインしなくてはなりませんが、この文脈ではSQuaRE的なものを指します。

Yasuharu NISHI @YasuharuNishi

まず品質特性というのはテスト設計のために生み出された概念ではない、ということを頭に入れておかねばなりません。そして品質特性は何ら網羅的なものではない、ということも頭に入れておかねばなりません。

Yasuharu NISHI @YasuharuNishi

さて品質特性をテスト分析/テスト設計（面倒だから厳密に区別しなくてはいけない時以外はまとめてテスト設計と呼びます）で用いると何が起こるでしょうか。

Yasuharu NISHI @YasuharuNishi

一般に（経験の浅い）テストエンジニアが品質特性を見ると、外部品質特性すなわちソフトウェアがどんなふるまいをするか、だと解釈します。

Yasuharu NISHI @YasuharuNishi

次に（経験の浅い）テストエンジニアは、機能一覧や機能ツリー、もしくは主要なユーザーストーリーやユースケースに着目します。これらを「機能など」と呼びましょう。品質特性と機能などは、人によってどちらを先に着目するかが異なりますが、どちらでも構いません。

Yasuharu NISHI @YasuharuNishi

このように機能などと品質特性を組み合わせてテスト設計を行う方法を、私は「品質特性に頼ったテスト設計」と呼びました。これは一般に、「○○の機能などの場合に、××の品質特性が満たさせれていることを確認する」というテストケースに落とし込まれます。

Yasuharu NISHI @YasuharuNishi

このテストケースのテンプレ（a.k.a. テストフレーム）は、何かに似ていませんか？そう、仕様裏返しのテスト設計「○○の機能が動くことを確認する」にとても似ていますね。品質特性に頼ったテスト設計は、とてもテストケースを書き出しやすいのです。

Yasuharu NISHI @YasuharuNishi

ではそのテストケースを（経験の浅い）テストエンジニアはどう具体化するでしょうか。一つは「○○の機能など」を操作に落とし込みます。もう一つは「××の品質特性」を具体的な評価基準に落とし込みます。「t秒以内に反応が返ってくること」みたいに。

Yasuharu NISHI @YasuharuNishi

もちろん他の具体化がありうるというのは理解しています。あくまで一般論ね。

Yasuharu NISHI @YasuharuNishi

そうすると、いわゆる狭い意味のテスト条件、VSTePのモデリング種別で言うところのCIBFWのC、例えば負荷をかけるといった検討が抜けやすくなります。したがってテストケースは、単純機能などテストのテストケースが品質特性ごとに増殖します（○○の時の操作性、○○の時の効率性…）。

Yasuharu NISHI @YasuharuNishi

やってることはCPM法（コピー＆ペースト＆モディファイ法）と変わりません。

Yasuharu NISHI @YasuharuNishi

C（Condition）の検討が浅いと、I（Item）の検討も浅くなります。例えば省電力モードの時に○○機能などを動かす、みたいな状態の検討が抜けたりします。

Yasuharu NISHI @YasuharuNishi

品質特性「を用いた」テスト設計が悪いと言うつもりはありません。でもテスト設計には他にも考えるべきことがあり、製品やサービスをまたいだ標準化はできませんから、その都度きちんと検討して整理（＝モデリング）する必要があります。その一つの要素として品質特性を検討することは必要です。

Yasuharu NISHI @YasuharuNishi

でも品質特性「に頼った」テスト設計を行ってしまうと、品質特性以外の検討が疎かになる傾向が高いのです。コンテストでも実務でもたくさんのテスト設計を見てきましたが、残念ながらその傾向は高いというのが僕の意見です。

Yasuharu NISHI @YasuharuNishi

じゃあなぜ品質特性に頼ったテスト設計をしてしまうか。それはそういうテスト設計をする（経験の浅い）テストエンジニアが、仕様書だったり国際規格だったりといった「テストチームの外側にある絶対的な何か」こそが唯一の正解だと思ってしまっているからではないかと思います。

Yasuharu NISHI @YasuharuNishi

テスト設計で大事なのは、論理性と創造性です。テストチームの外側にある仕様書や国際規格をベースに論理的に様々に思考を派生させ、その一方でそこに書いていないものをベースにしたテスト設計を想像力豊かに創造していくのです。どちらが欠けても、よいテスト設計にはなりません。

Yasuharu NISHI @YasuharuNishi

質問箱に質問してくださった方は、以上の説明でご理解いただけたでしょうか？いくらでも質問に答えますので、また質問箱をご活用ください。

Yasuharu NISHI @YasuharuNishi

ちなみに今の話を実例付きで考えたい方は、今週の土曜日の午後に「テスト設計コンテスト'20予選」が開催されますので、そこの実例を見ながら考えてみるとより理解が進むと思います。オンライン懇親会もありますので、そこの席で私に聞いてもらっても構いませんよ。 (^_^) connpass.com/event/178151/