[論文レビュー] When, why and how to test spreadsheets

Louise Pryor|ArXiv.org|Jul 20, 2008

Spreadsheets and End-User Computing参考文献 3被引用数 15

ひとこと要約

本論文は、スプレッドシート開発におけるソフトウェアテスト原則を、いつ、なぜ、どのように適用するかに焦点を当てた実務者主導のフレームワークを提示する。テストとレビューの違いを明確にし、実用的なテスト手法を提示するとともに、一般的な問題を特定し、現実世界での利用におけるスプレッドシートの信頼性向上とエラー削減に向けた構造的なアプローチを貢献する。

ABSTRACT

Testing is a vital part of software development, and spreadsheets are like any other software in this respect. This paper discusses the testing of spreadsheets in the light of one practitioner's experience. It considers the concept of software testing and how it differs from reviewing, and describes when it might take place. Different types of testing are described, and some techniques for performing them presented. Some of the commonly encountered problems are discussed.

研究の動機と目的

• スプレッドシートが意思決定において広く使われているにもかかわらず、その開発における形式的なテスト手法の欠如に対処すること。
• スプレッドシート作業におけるテストとレビューの違いを明確にし、テストを能動的な検証プロセスとして強調すること。
• スプレッドシート開発ライフサイクルへのテストの統合を可能にする実用的フレームワークを提供すること。
• テストによって軽減可能な一般的なスプレッドシートのエラーと課題を特定すること。
• 現実世界への応用を通じて、スプレッドシート開発におけるソフトウェア工学のベストプラクティスを促進すること。

提案手法

• スプレッドシートの文脈内で、ユニットテスト、統合テスト、回帰テストといった標準的なソフトウェアテスト概念を採用すること。
• スプレッドシートの論理に特化したテストケース設計技法を適用すること。これには境界値分析と同値分割が含まれる。
• 式入力後、データ変更後、モデル更新後の各段階で、開発ライフサイクルの重要な段階にテストを統合すること。
• 視覚的および構造的分析を用いて、スプレッドシートの挙動における不一致や論理的欠陥を検出すること。
• 監査可能性と再現可能性を確保するため、テストケースの文書化とトレーサビリティを強調すること。
• 段階的テストアプローチを提唱する：個々のセルのユニットテスト、式グループの統合テスト、変更後の回帰テスト。

実験結果

リサーチクエスチョン

• RQ1 スプレッドシート開発ライフサイクルのどの段階でテストを実施すべきか？
• RQ2 スプレッドシートは非公式に使われているにもかかわらず、なぜテストが必要なのか？
• RQ3 スプレッドシートの独自の構造とユーザーの期待を考慮すると、どのようにしてテストを実用的に適用できるか？
• RQ4 スプレッドシート作業におけるレビューとテストの主な違いは何か？
• RQ5 どのような一般的なスプレッドシートの問題が、体系的なテストによって防げるか？

主な発見

• スプレッドシートの信頼性を確保するにはテストが不可欠であり、スプレッドシートも従来のソフトウェアと同様に論理的・機能的エラーにさらされるからである。
• レビューだけでは論理的エラーを特定できない。正しさを検証するには体系的なテストが不可欠である。
• テストは個々のセルの論理、式グループの挙動、全体のモデル整合性の3段階のレベルに適用されるべきである。
• 誤った式参照、データ型の不一致、論理的エラーといった一般的なスプレッドシートの問題は、構造的なテストによって防止可能である。
• 開発プロセスへのテストの統合は、意思決定に重要な応用分野におけるエラーのリスクを顕著に低減する。
• 境界テストやテストケースのトレーサビリティといった実用的テスト技法は、保守性と監査可能性を向上させる。