mhlyc -practice

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

独断と偏見で選ぶ!〜SQuBOK V2の必読ページはこれだ!〜

SQuBOK V2読破会Advent Calendar2015

SQuBOK V2読破会メンバーのmhlycです。

読破会メンバーによるAdvent Calendar2015、いよいよ開幕です!

www.adventar.org

 

読破会そのものの説明については、12/1のいけどんさんの記事を参照くださいね。

SQuBOK V2 読破会で Advent Calendar 2015 ! | Software Quality Topics.

  

普段、お仕事が忙しい人のために厳選しました

皆さん、SQuBOKに対して一体どんなイメージを持っていますでしょうか?

 

 ええ、わかります。きっと

「辞書でしょ?」

「普通、頭から読んだりしないよね」

「必要な時にだけ読めばいいんじゃないの」

「何書いてあるのか知らない」

とかそんな感じでしょう。それは仕方ありません。実際、読破会でも読み切るのに一年近くかかってますし、なかなかまとまった時間をとって読める方は少ないでしょう。

 

ところが、SQuBOKの厳選された必読ページを紹介されたら、皆さんどうですか?

私が独断と偏見で厳選した結果、必読ページはたったの9ページです。もう一度言います。必読ページは9ページです。もちろん全て読んだ方がいいほどの本ですが、私が苦心に苦心して厳選した結果、必読ページはたったの9ページになりました。9ページです。(もういいよ)

「それくらいなら…」と、読んでみようという気になりませんか?

そうです。それこそが私のねらいです。

この記事では、そんな皆さんが気になるSQuBOK V2の必読ページをご紹介します。

 

SQuBOK V2の必読ページはこれだ!

それでは、準備はいいですか!いきますよ!

某番組のようなカウントダウンなどせず、一気に本題です。

必読ページ1:p.12〜p.13

1.1 KA:品質の概念 (1)品質の定義

 

そもそも品質ってなにさ?という疑問に対するアンサーページです。といっても、「品質の定義はこれだ!」という答えが載っているわけではありません。なぜなら、品質という言葉は非常に広く、深い意味を持ち、さらに時代の変遷につれて顧客のニーズも変化し、品質という言葉の使われ方も変わってきたからです。品質ってこれだよ。と簡単に言えるものではありません。

このページでは、品質を本質的に理解するために「顧客の要求把握」「要求の実現」「結果として得られる顧客満足」という三つの要素の組み合わせで考えると良いとしています。これらについて、簡単に内容を要約してみます。

 

顧客の要求は明示的要求や規制要求事項に限定されず、常識的な要求、あるいは潜在的ニーズや期待を含むことがあります。そして、その要求をソフトウェアの要求に変換して実現するのが、要求の実現です。しかし、要求が実現できればそれで顧客満足が得られる、というほど簡単なものではありません。高度化かつ成熟した現代においては、顧客の行動様式の変化をもたらすような、いわば「コトづくり」が求められているのです。

 

繰り返しますが品質は単純に定義できるものではありません。場面に応じて品質の意味するところを理解し、使い分けていく必要性があります。

ぜひこのページを一読して、品質の定義について考えてみてください。

 

必読ページ2:p.94〜p.95

2.2.3.1 T:ウォーターフォールモデル

 

皆さんご存知、ウォーターフォールモデルについての解説ページです。

「もう知ってるよ」と思う方が多いかと思います。が、

ぜひ読んでみてください。

皆さんはウォーターフォールモデルを本当に理解していますか?

「要求定義、分析、設計、実装、テスト…みたいに、順番に実施していくアプローチでしょう?」

ウォーターフォールモデルは要求がなかなか確定できないと使いづらいよね」

もちろん、それは正解です。しかし、それだけではありません。

 

ウォーターフォールモデルを導入することによる効果は?」

ウォーターフォールモデルはロイスが提唱したって言われているけど、ほんと?」

ウォーターフォールモデルは欠点があるとよく槍玉に上がりますが、ではなぜ今多くのSI企業などで採用されているのでしょうか。そして、ウォーターフォールモデルがどのような形で提唱されたものか理解されている方は、どれだけいらっしゃるでしょうか。

 

このページを読んで、今一度ウォーターフォールモデルについて再考してみるのも良いのではと思います。

 

必読ページ3:p.312〜p.314

3.9.9.1 T:機能的なテスト設計と構造的なテスト設計の組み合わせ

 

一般的に、機能的なテスト設計はブラックボックステスト、構造的なテスト設計はホワイトボックステストとみなすことが多いと思います。

これらはどちらか片方だけやればいいという話ではなく、上手に補完的に適用していく必要があります。

しかし、テスト対象の規模が大きくなるにつれ、「補完的に適用する」というだけでは対応できなくなってきます。

そこで、機能的なテスト設計と構造的なテスト設計の両者のメリット・デメリットを整理し、テスト対象の規模に応じた使い分けをするにはどうしたらいいのかをまとめてあるのがこのページです。グレーボックステストについても触れられています。

たった3ページですが、非常に内容が濃いです。自分は一度読むだけでは理解できず、何度も読み返した記憶があります。

 

必読ページ4:p.314〜p.316

3.9.9.2 T:確定的なテスト設計と非確定的なテスト設計の組み合わせ

 

 私の一番のおすすめページです。

このページだけ印刷してプロジェクトのメンバーに配布したいくらい、おすすめのページです。

 

確定的なテスト設計では、機能やデータ、環境などテストケースを構成する要素はあらかじめ決めておきます。これに対して非確定的なテスト設計では、テストケースを構成する要素の一部あるいは全部を決めないままテストをスタートさせ、実施しながら随時テストケースの要素を決めていきます。

したがって実際には、確定的なテスト設計と非確定的なテスト設計とを組み合わせる必要があるわけですが

「どう組み合わせたらいいの?」

「組み合わせを失敗するとどんなことが起こるの?」

といったノウハウがこのページには詰め込まれています。

 

テスト設計のしかたによって、テストを設計している組織の能力向上が大きく左右されます。

したがって、テスト組織のマネージャは必読のページだといえるでしょう。

 

ぜひSQuBOK V2を読んでみてください!

いかがでしたでしょうか?

自分が紹介したページはほんのわずかですが、これを読むだけでもきっとSQuBOKの良さがわかっていただけるのではと考えています。

 

ぜひSQuBOK V2を読んで、一緒にソフトウェア品質について学んでいきましょう!

参考文献:「ソフトウェア品質知識体系ガイド(第2版) SQuBOK Guide V2」, 2014