ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

TABOK粗読による自動化の座学 - カテゴリー7「品質属性の最適化」(2)

 前回の続きです。

7.2 品質属性から見た自動化フレームワーク

 カテゴリー4で学んだフレームワークを、8つの品質属性の得手・不得手で整理しているのがこの章です。

www.kzsuzuki.com

 ・・・正直、あまり見やすい表じゃない。横軸を品質属性にして、整理してみようかなと。もちろんExcelでね。

レベル1フレームワーク

 リニア・フレームワークは、スコープの小さい限られた条件では、ユーザビリティ・性能面で長所があるとされています。
 レベルが上がるとともに、スクリプト作りは簡単に、フレームワーク作りは大変になることを考えると、少ししか自動化しないならレベル1の方が楽なんですよね。

レベル2フレームワーク

 データ駆動フレームワークも、基本的にはリニアとあまり変わりません。データ外出しによって、拡張性が向上する程度。
 機能分解フレームワークは、TABOKが「手始めに選ぶならコレ!」と何度も一押ししてくるフレームワーク。ほとんどの品質属性でいい点を取れます。ただし、4.2.3で説明があったように、部品を作るための基準があって、それがちゃんと守られていないと、ユーザビリティが不十分になります。

レベル3フレームワーク

 キーワード駆動フレームワークの長所・短所は機能分解とほぼ同様ですが、(テストを作るうえでの)ユーザビリティに大きなメリットがあります。ただし、フレームワーク自体の構築はいちばん大変。
 ぼくが読んでいて理解できなかったのは、性能面で弱さがあるという記述です。何故?自然言語からスクリプトに読み替えるのに、他のフレームワークにはないオーバーヘッドがあるということでしょうか。
 モデルベースは、この系列には乗りません。他のフレームワークを補完する位置づけです。
 なおここでも、「テスト自動化の目的が、exploratory testing の自動化にあるのなら・・・」という記述があります。以下の記事でも言及しましたが、やはり「exploratory testing」の意味が、いわゆる「探索的テスト」とは違うように思います。

7.3 キー属性の特定と、フレームワークの選択

 組織やプロジェクトの制約に応じて、どのフレームワークの選ぶかの説明です。ここで出てくるのは、4.1に出てきた謎のドレイク方程式。

www.kzsuzuki.com

 この式のパラメタに具体的な値を与えたうえで、8つの品質属性の優先度がどのようになるかをシミュレーションしています。
 結論は、TABOKにおいて例外的にボールドで書かれており、「機能分解がオススメだぜ!」

 さてこれで、macroscopicに属する7つのカテゴリーは終わり。後半のmicroscopicの5カテゴリーに移ります。読んで理解できるのか心配ですが、続けます。みなさんTABOKを買って読んで、コメントください。