読者です 読者をやめる 読者になる 読者になる

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

SQuBOK V2をクオリアちゃん(仮名)と読んでいこう 第4話

ソフトウェアテスト ソフトウェア品質

前回までのあらすじ

mhlyc.hatenablog.com

 

 

 

登場人物紹介

※絵は書けないので、キャラの姿は想像で補ってください。

伊敷 孝男(いしき たかお)

意識高い系。口癖は「まあ、俺のモットーは"高品質"だから」。人の話は一応聞く。

 

佐藤 大輔(さとう だいすけ)

伊敷の同僚。いつも伊敷の尻拭いをやらされている。すぐ怒る。

 

菅さん(かん さん)

菅さん。今回のプロジェクトリーダー。

 

クオリアちゃん

突如、伊敷の部署に配属された中途採用の女性。本名は不明だが「クオリア」と名乗っている。見た目は女子大学生。品質の話になると語りだす。ツンデレ

 

第4話 「V&Vってなに?」

 伊敷と佐藤は、とあるバッチシステムの開発プロジェクトに参画していた。

現在は単体テスト工程の作業を進めている。

「よし、単体テスト完了!」

伊敷は大きく伸びをした。

「あ、終わったんだ。テストどうだった?」

佐藤が伊敷に声をかけた。

「もう、バッチリよ!さすが俺だぜ。まあ、俺のモットーは高品質だかr」

「あ、伊敷のこと、菅さんが呼んでるよ」

見ると、今回のプロジェクトリーダーの菅さんが呼んでいた。

「なんですか?」

伊敷は菅さんの席まで歩いて行った。

「ちょっといい?伊敷が作ったモジュールなんだけどさ」

「はい」

「どれくらい性能出るか、ちょっと測ってみてくれない?」

「性能…ですか?」

伊敷は戸惑った。伊敷が作成した単体テストケースに、性能のチェック項目なんてなかったからだ。

「えと…実行して処理が終わるまでの時間を測ればいいんですか?」

「そうそう、ちょっと調べておきたくてさ。それじゃ、お願いね」

そう言うと菅さんは打合せに行ってしまった。

自席に戻った伊敷は、なんとなく腑に落ちない表情をしてPCに向かっていた。

「菅さん、なんだって?」

「モジュール実行して、性能どれくらい出るか測ってくれってさ。正直、性能とかあんま気にしてなかったよ」

「性能かあ…あ、クオリアちゃん。お疲れ」

ちょうど、クオリアちゃんがコードレビューから戻ってきたところだった。

「お疲れさま。なに、性能測ってるの?」

「そうなんだよ。菅さんに言われてさ。でも、なんでやるのかよくわからないんだ。単体テストケースの項目にもなかったしさ」

「なるほどね。伊敷くんはV&Vって言葉、聞いたことある?」

「V&V…?」

「そう。V&Vっていうのは、Verification and Validation、すなわち検証と妥当性確認のことよ」

「検証…?妥当性確認…?」

伊敷はちんぷんかんぷんだ、という表情をした。

「聞いたことはありますけど、どっちがどっちだったかな…ってよく忘れちゃいますね」

佐藤は頭をかいた。

「そうね、混同してしまいがちだけれど、重要な概念だから覚えておいた方がいいわ。

まず、Boehmが検証と妥当性確認のことを言い換えて表現していて、

 

検証は、『正しく成果物を開発しているか』

妥当性確認は、『正しい成果物を開発しているか』

 

としているの。意味はわかる?」

「正しく、と正しい、の違いか…」

「そう。難しく言うなら、

 

検証は、『対象の開発工程の成果物が、その工程の開始時に決められた条件を満足しているか』

妥当性確認は、『対象の成果物が、あらかじめ決められた要求事項を満足しているか』

 

という説明になるわね」

「わかりづらいよ…」

伊敷が弱弱しく言った。

「まったく…ほら、図にするとこんな感じよ」

f:id:mhlyc:20151022232822j:plain

「これはV字モデル*1の左側半分にV&Vを適用した場合の図ね。検証の矢印がどこから出ているかに着目してみてほしいの」

「検証は前工程から、妥当性確認は常に要求定義の工程から矢印が伸びているな」

「そう。例えば、詳細設計工程の成果物の検証を考えるとする。すると、検証では詳細設計に対する条件となる、基本設計書の記載内容や、開発規約が詳細設計の結果に適切に反映されているかどうか確認することになる。そういう意味で、検証の矢印は前工程から伸びているのよ」

「じゃあ、妥当性確認は?」

伊敷が問いかけた。

「同じ詳細設計の例で説明するわね。妥当性確認は、利用者のニーズ、あるいはそれを具体的に表した要求定義を満足しているか確認することだから、すなわち詳細設計の成果物に対しても、要求定義工程で定めた要求事項を満たしているか確認することになるわ」

「うーん…」

伊敷は腑に落ちない様子だ。

「今、菅さんに言われた『性能を測ってくれ』っていうのも、妥当性確認の一つだと私は思うわ。おそらく、菅さんは要求定義工程でお客さんと合意した性能要件について心配しているんじゃないかしら」

「ああ、そういうことか!」

「もし仮に、伊敷くんの作ったモジュールに性能的な問題があったとする。今は単体テスト工程だから修正も比較的容易だけれど、これが統合テスト工程で発見された場合、手戻りが増えるわね。一般的に、プログラム修正は開発ライフサイクルのできるだけ早期に実施した方が、コストが低くなるから」

「なるほど…」

「このようにV&Vには、リスクの高い問題を早期に発見するという利点もあるのよ」

「菅さん、やっぱすごいな…」

佐藤と伊敷はしきりに感心している。

「V&Vは菅さんのようにプロジェクトを管理する立場の人や、QAのように第三者視点でプロジェクトの支援をする立場の人が実施することもあるし、もちろんチーム内で実施することもあるわ」

「チーム内でやるにはどうしたらいいんだ?」

「いろいろな技法があるけれど、基本的にはテストとレビューかな。ただ、チーム内で実施する場合は第三者的な目線でチェックするのが難しくなるから、より厳密に実施したい場合はQAとか第三者組織に依頼した方がいいわね。そのあたりの選択はプロジェクトのリスクレベルや難度にもよるわ」

「なるほど…」

「V&Vか…勉強になったよ!ありがとう、クオリアちゃん!」

「まずは性能評価して、性能要件と比較して問題ないレベルか確かめてみないとな!」

そう言うと伊敷はさっそく、性能テストに取り掛かった。

 

ー第5話に続く

 

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

参考URL:http://www.slideshare.net/Ikedon/ss-33986377

 

あとがき

 

今回はV&Vの話でした。

V&Vの話も広げようと思えばどこまでも広がるので、今回はそれとなく区切りをつけて書きました。

 

それでは、次回もよろしくお願いします!

*1:V&VとVモデルやWモデルと混同してしまうこともあるけれど、これらは全く独立した概念であることに注意が必要よ。 - クオリアちゃんより