日本ソフトウェア科学会第 31 回大会 (2014 年度) 講演論文集

ドキュメントレビュー結果を利用したテスト項目作成
システムの開発
加藤 武文

大場 みち子

藤原 哲

ソフトウェア開発では，一定以上の品質を確保するために品質管理に取り組む必要がある．品質管理のための主な手段としてドキュメントレビューやソフトウェアのテストが挙げられる．工程毎の欠陥はそのドキュメントレビューでその工程内で確実に除去することが望ましいが，除去しきれずに残存した欠陥はテストで取り除かれる．しかし，テスト工程で欠陥を除去しきれない場合や網羅的なテストケースを作る際のコストが大きいといった課題がある．本研
究はそれらの欠陥を効率的にテスト工程で除去するために外部設計でのドキュメントレビューの結果をテストケース作成などの後工程作業に利用する手法とそれに沿った開発支援システムを提案する．

This paper attempts to improve eﬃciency of software quality management. There are documents review
and test to software quality management. Defects what wasn’t removed in documents review should beremoved in test. However, They are not removed in some cases. In addition, making exhaustive test cases
is very costly. This paper proposes the method of analyzing of documents review result and getting useful information to making test cases. The author surveyed relationship between documents review resultand defects in thinking method. The author will develop system of supporting software development inaccordance with the method.

えば，指摘された部分のみを修正したが他の部分にも

1 背景/目的同様の欠陥があった場合，指摘された欠陥の類似欠陥

ソフトウェアの開発において管理すべき要素であるや関連欠陥まで確認することができなかった場合，欠QCD(Quality Cost Delivery) の中でも Quality にあ陥を検出したにも関わらず不適切な修正をしてしまったる品質は顧客の満足度に直接関わるため特に重要視た場合などである．また，網羅的なテストケースの作される [3]．一定以上のソフトウェア品質を確保する成は難しい上に大きなコストがかかる [4]．本研究でためには品質管理を徹底する必要がある．品質管理とは，ソフトウェア開発における品質管理をより効率的して行われる主な作業としてドキュメントレビューやかつ確実に行えるようにすることを目的とする．そのソフトウェアのテストが挙げられる．各工程で作成さ目的の達成のためにドキュメントレビューで除去しきれたドキュメントに対してレビューを実施して欠陥をれなかった欠陥をテスト工程で効率的に除去できるよ除去し，そこで除去しきれなかった欠陥及び実装工程

うにテストケース作成を支援することを目標とする．

で作り込んだ欠陥をテスト工程で除去するというのが品質管理の基本的な流れである [6]．ドキュメント

2 関連研究レビューで指摘された欠陥は確実に修正する必要があ

ソフトウェア開発での品質管理を支援するための研るが，それらが後工程に残ってしまう場合がある．例

究として，過去の類似プロジェクトで蓄積された情報

Development of A Test Cases Generation System Using Document Review Results
Takefumi Kato
Michiko Oba
Tetsu Fujiwara, 公立はこだて未来大学, Dept. of Advanced Information
and Communication Tecnology, Future UniversityHakodate.

を用いるものがある．湯本らは，機能テストのテスト設計を効率的に行うために過去の開発プロジェクトでの欠陥の情報を利用している [1]．小川らもまた，過去の欠陥情報を分析することでドキュメントレビューにおいてその工程で除去すべき欠陥を重点的に探す

ための研究を行っている [2]．しかし，これらの研究が曖昧であるなどの理由から他にも欠陥が作り込までは現行のプロジェクトに類似したプロジェクトの欠れているというリスクが考えられる．また，類似した陥情報やドキュメントレビューの記録があるという条欠陥が数多く指摘された場合は他の箇所にもそれに件を前提としている．より多様なプロジェクトに適用関連した欠陥が見つかる可能性が高い．本研究では，できるようにするためには，現行プロジェクト内の情これらの関連が実際に存在しているか 2 件の予備実報だけで利用できる手法を検討しなければならない．

験により調査した．

また，ドキュメント内で曖昧な記述になっている点に着目してテストケースを作成する手法を提案した研4. 1 ドキュメントレビューに関する実験究がある [5]．曖昧な記述という情報を用いることで被験者に過去にリリースされたあるソフトウェアの欠陥作り込み率の高い部分に対応しているが，これだ外部設計を対象としてドキュメントレビューを行ってけでは全ての欠陥に対応することができないというもらった．

課題が残っている．

被験者 公立はこだて未来大学の学生 12 名
実験材料 過去に公立はこだて未来大学で開発さ3 研究課題れリリースされた施設予約システムの要件定義

目的を達成するにあたって以下の 2 点の課題が挙書と外部設計書 (ユースケース記述，画面遷移図，げられる．
テストケース作成に利用できる情報の検討

画面仕様書，画面イメージ)
実験内容 被験者には，まず要件定義書を読んで関連研究として挙げた例では過去のプロジェクトシステムの仕様について理解するよう指示した．

で蓄積した欠陥情報やドキュメントレビュー情報

その後，外部設計書を対象としてドキュメントレを利用していたが，過去のプロジェクトと現行のビューをしてもらった．ドキュメントレビューにプロジェクトが類似していなければならないといおいて指摘情報として記録するよう指示した内う制約があった．その制約に囚われずに現行プロ

容を以下に示す．なお，指摘の分類については具ジェクトだけで完結する手法を検討するにあたっ体例を挙げた上でどのような観点で探すべきかて，現行プロジェクト内で蓄積されていてテストといった情報を提示した．

ケース作成に利用できる情報を検討する必要が• 指摘ドキュメントある．また，品質管理にかかるコストを抑えるた• 指摘箇所めにもその情報は提案する手法のために蓄積す• 指摘の分類るのではなく，従来の開発方法においても記録，– 不整合蓄積されているものが望ましい．

– 不明瞭

情報の記録/分析方法の検討– 系列漏れ

上述した課題で検討した情報をテストケース作– 項目誤り成やその他作業に利用できる形にするための分– 表記ミス (誤字，脱字，表記揺れなど)

析方法が必要となる．分析方法に伴って分析前の情報をどのような形で記録すべきかを表すフォー
マットを検討する必要がある．

• 指摘内容実験結果 ドキュメントレビューに関する実験の結果を図 1 に示す．指摘された欠陥内で特に多い
指摘分類はドキュメント間の不整合に関するもの

4 予備実験だった．合計指摘件数は 453 件であり，被験者一

本研究では，ドキュメントレビューで得た指摘とソ人当たりでは約 38 件の指摘件数である．

フトウェアの欠陥との関連に着目する．例えば，ドキュメントレビューで指摘の集中した機能には，仕様いて上述したような欠陥が見つかった．発見された欠陥の約半分はドキュメントレビュー時の指摘と関連を持った欠陥であるため，ドキュメントレビューの結果をテストケース作成に利用することで効率的に除去できると考えられる．

5 提案手法/システム
本研究では，予備実験の結果を受けてドキュメントレビューで得た指摘の情報を分析しテストケース作成
図1

ドキュメントレビューに関する実験結果に役立つ情報を得る手法を提案する．また，その手法に沿った開発支援システムを提案する．

4. 2 テストケース作成に関する実験
ドキュメントレビューに関する実験で得た指摘の情報を利用して，テストケース作成に関して実験した．
被験者 公立はこだて未来大学の学生 12 名
実験材料 過去に公立はこだて未来大学で開発さ5. 1 提案手法
ドキュメントレビューで得られた指摘を分析し，テストケース作成に役立つ情報を得る．
指摘の記録方法

れリリースされた施設予約システムの要件定義

指摘に関しては，どのドキュメントの，どの部分書と外部設計書 (ユースケース記述，画面遷移図，の，どのような分類の欠陥があるかといった情報画面仕様書，画面イメージ) 及びドキュメントレを蓄積する必要がある．指摘位置に関してはドビューに関する実験で得た指摘情報

キュメントのページで指定した場合はドキュメン

実験内容 被験者には，要件定義書，外部設計書をトの更新に伴って位置がずれてしまう可能性があ元にテストケースの作成を依頼した．特に，レる．そのため，指摘位置に関してはページ以外でビュー指摘周辺の欠陥が除去できているかを確認任意に記録できるものとする．指摘の記録内容をするテストケースを重点的に作成するよう依頼

まとめると以下の通りである．

した．テストケースの内容は以下の通りである．

• ドキュメント名• 確認内容• ドキュメント内の指摘箇所• 操作手順• 指摘分類• 関連する指摘• 指摘内容上記内容で作成してもらったテストケースに従っ• 指摘者て筆者が実際にテストした．その際にテストが通指摘の分析方法らなかったもの，つまり欠陥があると見なされた

上述した内容で記録した指摘に関して，以下の点

テストケースとそれに関連したドキュメントレに着目して分析する．

ビューの指摘からドキュメントレビューと欠陥の間にある関係について調べた．
実験結果 全体で 168 件のテストケースが作成さ指摘の集中箇所 指摘された位置に関する記録からドキュメント内で指摘の集中している箇所を分析する．

れ，9 件からテスト時に欠陥が発見された．9 件

頻出する指摘分類 ドキュメントレビューにおのうち 4 件はドキュメントレビューでの指摘と対いて頻出した指摘分類とそれらの指摘に多応付けられる欠陥であった．

く見られた特徴語を分析する．

考察 実験対象のシステムはすでにリリースされ欠陥作り込み率の高い担当者 指 摘 さ れ た 件

利用されているものであるが，今回の実験にお数の多いドキュメント作成担当者と，その担当範囲を分析する．

トレビューの全ての指摘をシステムに入力，蓄積する．

5. 2 提案システム
提案した手法に沿ってソフトウェア開発を支援す指摘一覧，レポートの出力 実験車は，入力した指摘情報から指摘一覧，レポートを出力する．

るシステムを提案する．システムはドキュメントレ

テストケース作成 被験者は，出力した指摘一覧，ビューの指摘を利用し，以下のような機能を持つ．

レポートを参照しながら対象システムの要件定

ドキュメントレビューでの指摘記録 ドキュメント

義書，外部設計ドキュメントについてテストケーレビュー時に，指摘の記録担当者が提案システムのフォームで指摘内容を入力し，記録する．指摘は対象ドキュメントとそのバージョン毎に分けて記録する．フォームの内容は以下の通りである．

スを作成する．
テスト実施 実験者は，テストケースに沿ってテストを実施する．
上記手順で得たテストケースの件数，内容と被験者• ドキュメント内の指摘箇所に対するヒアリングから，提案システムによるレポー• 指摘分類トの有効性を評価する．また，テストケース作成を効• 指摘内容

率的に行えたかどうかを評価するためにテストケー• 指摘者

ス 1 件辺りにかかった作業時間の平均も比較する．

指摘一覧の出力 蓄積したレビューでの指摘をドキュメント別に一覧として出力する．ドキュメン
トの修正担当者はこの一覧を参考にしながらドキュメントを修正する．

7 まとめ
品質管理を効率的に行えるようにすることを目的としてテストケース作成の支援を目標に設定した．目

指摘の分析とレポートの出力 提案手法に沿って蓄標を達成するためにドキュメントレビューの結果をテ積された指摘を分析し，分析結果をレポートとしストケース作成に役立てるための手法とそれに沿ったて出力する．

開発支援システムを提案した．今後は，提案したシス

テストケースの作成，管理 システムから得た分テムを実装して有効性を評価する．

析結果や指摘一覧を参考にしながらテストケースを作成する．テストケースはドキュメントレ
ビューの指摘と同様にドキュメントのどの部分に謝辞 本論文は科研費 (23591158) の助成を受けたものである．

関してのテストかを明確に記録できるようにする．テストした結果についてもシステム上で管理

参 考 文 献する．

[1] 湯本剛, 松尾谷徹, 津田和彦：効率的な機能テスト設計のための欠陥情報の活用方法, 全国大会講演論文集
2013(1), 321-323, 2013-03-06.
[2] 小川睦子, 森崎修司：過去の欠陥データの深刻度と修正工数に着目した重点検出欠陥の選択手法, 情報処理学会研究報告, ソフトウェア工学研究会報告 2012-SE-177(9),1-8, 2012-07-12.
[3] 福島利彦, 春日君夫, 山田茂：QCD 定量化分析によるプロジェクトマネジメントの向上, 日本オペレーショ
ンズ・リサーチ学会春季研究発表会アブストラクト集
2007, 38-39, 2007-03-28.
[4] 丹野治門, 張暁晶, 星野隆：結合テストにおけるテスト項目自動生成手法の提案と評価, 電子情報通信学会
技術研究報告, SS, ソフトウェアサイエンス 110(227),
37-42, 2010-10-07.
[5] 河野哲也, 西康晴：ソフトウェア開発における外部機
能の仕様記述の曖昧さに着目したテスト項目設計法, 品6 評価
提案したシステムを実装したものを被験者に利用してもらうことで評価する．テストケースを作成する
対象のシステムは予備実験と同様のものとして，予備実験時に得たドキュメントレビューの指摘を利用す
る．実験は以下の手順で実施するが，レポート機能については被験者を利用するグループと利用しないグループの２つに分ける．レポート機能を利用しないグループは指摘一覧のみを利用する．
指摘の入力 実験者は，予備実験で得たドキュメン

質, 42(3), 400-411, 2012-07-15.
[6] SQuBOK 策定部会 (2007)，「ソフトウェア品質知識体系ガイド-SQuBOK Guide-」，オーム社