資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)

北村 俊之

tag: 組み込み

レポート 2013年2月13日

●資格認定ISTQBはソフトウェア・テストの何を変えたのか

 ISTQBとは,ソフトウェア・テストに関する国際的な資格認定団体である.ソフトウェア・テストのプロフェッショナルを認定する資格を設けることで,ソフトウェア・テスト技術者の育成を図ることを目的としており,2002年に英国Edinburghにて創設された.ISTQBには各国のソフトウェア・テスト技術資格認定運営組織が加盟しており,日本からはJSTQB(Japan Software Testing Qualifications Board)が加盟している.

 ISTQBの資格認定について「レベルが低い」と批判する人がいるが,同氏によると,ISTQBはテスト技術の底上げを目的としたものであり,この批判は的外れであるという.ISTQBが生まれたことにより,学習事項や用語を共通にできたし,テストは学ぶべきものという考え方が広まった.一方,管理者層のテストに対する理解不足や,大学におけるテスト教育の不足,テスト・ツールに対する誤解(万能であると思われている)については変化がないとする.

 

●見つけられなかった欠陥の数に注目する

 テストの価値を測る一つの指標として,DDP(Defect Detection Percentage;欠陥検出率)がある.欠陥検出率は,テスト・フェ-ズで摘出した欠陥の数を,テスト・フェ-ズおよびリリース以降の別のフェ-ズで見つけた欠陥の総数で割った値のパーセンテージで示される.同氏は,見つけた欠陥の数だけで良いテストかどうかは評価できない,むしろ,見つけられなかった欠陥数の方が重要である,と指摘する.

 アジャイル開発では,スプリント(固定日数ごとのひと区切りの期間)単位で欠陥検出率を算出できる.スプリントが終了した後に,その一つ前のスプリントの欠陥検出率を算出することで,そのスプリントのテスト・フェーズでは見つけられなかった欠陥数を把握でき,テストについてさまざまなことが分かるという(写真4).また欠陥検出率が高い場合は,その時のテスト対象のシステムが何であったのか,ユーザがそのシステムを利用しているのか,なども併せて調査する必要がある.逆に,欠陥検出率が低い場合は,テスト前の品質が低かった可能性を考慮に入れる必要がある.

 

写真4 アジャイルにおける欠陥検出率(DDP)の例

 

 

 同氏は欠陥検出率を,個々のテスト技術者の能力測定を目的として使うのではなく,チームの傾向をつかむ指標として利用するべきである,とした.また欠陥検出率の目標値を設定するのは避けるべきであるという.それを目指して調整してしまう恐れが出てくるからである.

 このほかリスクの増減を視覚化する手法として,同氏は「Risk Spider」を紹介した(写真5).Risk Spiderとは,週ごと(あるいは日ごと)のリスク要因を,CT(Code Turmoil;コード変更),DW(Defects found this week;今週見つかった欠陥),DT(Defects open in Total;総欠陥数),TS(Test Success Rate;テスト成功率),TC(Test Completion Rate;テスト実行率)を指標としてレーダ・チャートで示したものである.

 

写真5 Risk Spiderの例

 

 

●自動化で上がるのは「効果」ではなく「効率」

 同氏は,テストの自動化を続けていた技術者から,「不具合が出なくなったので,自動化をやめようと思っている」という話を聞いたことがあるという.しかしこれは大きな誤りである.テストの自動化で不具合を見つけるわけではない.不具合を発見するのはあくまでもテストであり,テストの目的と自動化の目的をはっきり線引きして考える必要がある.テストそのものと自動化の違いは,「効果」と「効率」の違いとも言える.自動化するとテストの効率は上がるが,重要なのはテストの質を上げることであり,テストの質を上げることによってテストの効果が高まる.自動化という手法は,良いテストを「早く」走らせるためには有効であると言える.

 ツールがあればテスト技術者は必要ないのではないか,という議論をよく耳にするが,そのようなことはありえない.「もしこうしたら,どうなるのだろう」と思考するのはテスト技術者であり,ツールではない.そのほかにも,テストのための分析なども必要になるため,テスト実行のみに目を向けてツールでテスト技術者を置き換えることは難しいといえる.その一方で,退屈でつまらない単純作業をツールに肩代わりさせることはできる.自動化によってテスト実行そのものの工数は下がるが,テストの設計や準備,分析などの工数を加味して比較すると,単純に自動化しただけでは全体の工数は増える(写真6).

 

写真6 自動化テストと手動テストの工数比較

 

 

●クラウドソーシングやソーシャル・メディアがテストを変える

 講演の締めくくりに同氏は,今後テスタの役割がどのように変化していくかについて述べた.一つには,クラウドソーシングやソーシャル・メディアなどの普及に伴って,ユーザがテスト技術者の役割を果たす可能性があるという(Googleが良い例だ).もう一つは,テストしやすい設計やテストの自動化などについて,テスト技術者が開発者に対してアドバイスを与える立場となる可能性もある.同氏は,「ソフトウェア・テストの未来には,非常に興味深いものがある」として講演を締めくくった.

 

参考文献
(1)Tom Gilb, Dorothy Graham; Software Inspection, Addison-Wesley Professional, 1993.
(2)Dorothy Graham, Mark Fewster; Experiences of Test Automation, Addison-Wesley Professional, 2012.
(3)William C. Hetzel; Program test methods, Prentice-Hall, 1973.
(4)Glenford J. Myers; The Art of Software Testing, Wiley, 1979.

 


きたむら・としゆき

 

 

«  1  2
組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日