概要
前回は、試験工程における要求発見について考えた。これは試験工程におけるテスト専門家による要求発見なので、試験工程で発見された要求について要求専門家の意見を聞く必要があるから、試験工程に要求専門家が参画していると考えることもできる。ということは、逆に要求定義工程にテスト専門家が参加できる可能性もある。実際に、要求定義へのテスト専門家の参画についての実践的な施策が提案されている[1]。 一方、要求とテストについては7つの神話があると指摘されている[2]。ソフトウェア工学で神話というのは、実際にはそうではないのに、そうであると思い込まれている見解のことである。以下では、まず要求とテストについての神話を紹介しよう。次に、神話を否定することで要求とテストの連携策を導いてみる。さらに、要求とテストの連携策を解説しこの結果と比較してみよう。最後にまとめとして、これらの施策をプロセス面とプロダクト面から分類してみよう。
要求とテストの7つの神話[2]
要求とテストについては、次のような7つの神話があるそうだ(表1)。
神話 | 姿勢と問題 | 対策 |
---|---|---|
要求が最初でテストが最後 | 「まだテストを考える段階ではない。要求に
集中すべきだ」 最終テスト段階で要求変更が発生 |
要求レビュにテスト専門家が参画すること
で良い要求を確認できる 顧客の参加が重要 |
システムができなと テストできない |
「テスト専門家はシステムの動きをみるだけだ。 紙ではテストできない」 欠陥の早期発見ができない |
事業目的に対して要求仕様書の完全性と 正当性をテストすべきである |
要求をテストで使えてもその逆はない | 「要求をテストするのではなく、要求を用いてテストせよ」 開発者は曖昧な仕様を書く傾向がある |
要求の具体例がテスト What if質問 特定のユーザを考える |
テスト作成が難しいの はテストだけの問題 | 「今のテスト専門家は我々の要求からテストを
作成できないようなので、別のテスト専門家を
探すのがよさそうだ」 曖昧な非機能要求の定義は困難 |
非機能要求を測定する適切な基準を考える ことでテストする |
小さな要求変更が プロジェクトに影響することはない |
「画面の入力欄を少し広げたい」 小さな変更の影響範囲が大きくなることがある |
変更によって影響を受ける状況でシステムが正常であることを確認 副作用の影響がないことを回帰テストで確認 |
テスト専門家は要求を必要としない | 「要求がなくてもシステムが何をしているかを確認できるだろう」 システムが何をしているかと何をすべきかの差を埋めることがテスト専門家の役割 |
テスト専門家は答を知っているのが前提 入力、事前条件、事後条件は要求がないと分からない |
テスト専門家は要求がないとテストできない | 「ちゃんとした要求がないとテストできない」 不十分な要求の下での変更に対してテスト専門家の知識に基づくテストが必要になる |
探索テストによりシステムの挙動を調査 テスト計画,テスト仕様などからなる テストウェアを要求仕様になる |
【神話その1】要求が最初でテストが最後
要求段階でテストのことを考えようとすると「まだテストを考える段階ではない。要求に集中すべきだ」と言われて、要求のテスト可能性を吟味しないでいると、最終テスト段階で要求変更が発生してあわててしまうことになる。
要求レビュにテスト専門家が参画することで、良い要求であることを確認できる。このとき、顧客にも参加してもらうことが重要になる。開発者とテスト専門家だけで確認しても、顧客が納得できる要求になっているかどうか分からない可能性があるからだ。
【神話その2】システムができないとテストできない
テストするためのシステムができていない段階で、要求をテストしようとすると、「動くシステムがないのにテスト専門家がテストできるわけがない」「テスト専門家はシステムの動きをみる必要がある。紙に書かれた要求は動かないからテストできないだろう」などと言われてしまう。しかし、システムができてから要求の欠陥を発見しても遅い。大きな手戻りが生じてしまうことになる。
したがって、事業目的に対して要求仕様書の完全性と正当性を机上でテストすべきである。
【神話その3】要求をテストで使えてもその逆はない
要求をシステムが満たしていることを確認することがテストだから、「要求をテストするのではなく、要求を用いてシステムをテストする必要がある」と考えられている。
しかし、現実のところ開発者は曖昧な仕様を書くことが多い。要求を厳密に記述することは、現場の技術者には難しいものである。要求に基づいてテストしようにもどうしていいか判断できず、途方にくれているテスト専門家が目に浮かぶようだ。
したがって要求の具体例を考えてみて、机上でこの具体例がテストできるかどうか調べることで要求のテスト可能性を確認しておくことが大切だ。これによって曖昧な要求を具体化できるだけでなく、テスト可能性を向上できることだろう。
この一つの方法として「What if質問」を要求に対して考えてみるといい。指定された要求に対して、「どんなユーザーが何を入力すると、どんな結果が提示されるだろうか」と考えてみるのである。これはテストを要求で使うことができることを示している。
【神話その4】テスト作成が難しいのはテストだけの問題
テスト専門家が曖昧な要求を前にしてテスト項目を設計できなくて困っていると、「今度のテスト専門家は、我々が書いた要求に基づいてなかなかテストを作成できないようだから、別のテスト専門家を探した方がよさそうだ」などと言われて曖昧な要求を書いた責任を棚に上げてテストが作成できないことの責任を押し付けられてしまうかもしれない。
とくに非機能要求が曖昧になりやすい。たとえば「操作性が良いこと」などと書かれても、具体的なユーザーの範囲や操作性をどのようにして客観的に測定するかを特定しないとテストできない。このように、非機能要求の定義が明確になっていなければテストすることは困難である。この場合、テストするために操作性などの非機能要求をテスト段階になってテスト専門家が定義していると考えることもできる。
したがって非機能要求を測定する適切な基準を設けておき、要求定義段階でテストすることが大切である。逆に言えば、テストを考えることで非機能要求を具体化できるとも言える。
【神話その5】小さな要求変更がプロジェクトに影響することはない
たとえば「画面の入力欄を少し広げたい」というような小さな要求変更が、システムが動き出してから発生することも良くある出来事だ。しかし表面上は小さな変更であっても、その影響範囲が大きくならないという保証はない。画面のデータ構成が対応するデータベースのテーブル構成に影響を与えるかもしれないし、それを操作する手続きへの変更も波及する可能性もある。
したがって、変更によって影響を受けたとしてもシステムが正常に動作できることを確認する必要がある。たとえば副作用の影響がないことを回帰テストで確認する。ここでもし要求とコードやテストとの追跡性を管理することができていれば、この追跡関係をたどることで要求変更の影響範囲の大きさを可視化できるはずだ。ただし追跡性の管理コストが大きくなるので、どのレベルで追跡性を管理するかということと影響範囲の可視化の精度とのトレードオフを考慮することが重要になる。
【神話その6】テスト専門家は要求を必要としない
テスト専門家はシステムの動きを見ているのだから「要求がなくてもシステムが何をしているかを確認できるだろう」と考えている人も多いのではないだろうか?コンパイラなどのテストを入社したときに何度も経験したことがある。言語処理系の仕様にしたがって個別的に確認するテストもあるが、具体的な共通例題を用意しておいて処理系ごとに繰り返し走行テストを実施することもあった。後者の場合には、正解値リストを用意しておいて結果が異なれば処理系に欠陥があることが分かる。数学関数などは頭の中に関数の意味が理解できているからいいが、それでも有効桁数や型変換の方法などは処理系依存になる可能性がある。これらについては、仕様が分からなければテストしても結果の妥当性を判断できない。また前回の連載でも指摘したが、システムの動作がテスト専門家にとっては異常であっても開発者にとっては正常であるということもある。開発者の、メンタルモデルとユーザーのメンタルモデルがずれていれば一方が正しいと思っても他方には欠陥になる。そういう経験を読者のみなさんもたくさんしているはずだ。
したがって、システムが何をしているかと何をすべきかの差を埋めることがテスト専門家の役割だとも言える。テスト専門家には要求を知る必要がないというのには、彼がシステム開発者と同じ答を知っているという前提がある。しかし現実はそうではないことの方が多い。システム機能に関する入力、事前条件、事後条件の関係は要求がないと分からないことである。しかし、具体的な入力と事前条件を与えることでシステムの動作結果を知ることはできる。この組合せを集めることでシステムの入力、事前条件、事後条件の関係を推定することもできる。
【神話その7】テスト専門家は要求がないとテストできない
今度は、神話その6の逆で「ちゃんとした要求がないとテストできない」とテスト専門家が反論することもある。しかし不十分な要求の下であっても、苦労しながらテストを実施している数多くのテストのプロがいるのも現実である。このような場合には、テスト専門家の経験知識に基づくテストが実施されていると思われる。
たとえば神話その6で述べたように、入力と結果を与える探索テストによってシステムの挙動を調査することができる。このような探索テストを系統的に実施するテスト計画やテスト仕様、テスト結果などをテストウェアとしてまとめることで要求仕様として用いることができるだろう。
神話から抽出した要求とテストの連携策
前述したテストと要求の神話に基づいて要求とテストの連携策をまとめると表2のようになる。
連携策 | 利点 | 課題 |
---|---|---|
要求レビュにテスト専門家が参画 | 最終テスト段階での要求変更の発生を抑止 |
顧客の参加が重要 |
事業目的に対して要求仕様書の完全性と正当性をテスト | 欠陥の早期発見 |
テスト専門家による事業目的の理解 |
要求を具体例でテスト | 曖昧な要求仕様の改善 |
要求の具体例がテスト What if質問 特定のユーザを考える |
非機能要求を測定する適切な基準を考えることでテストする | 曖昧な非機能要求の明確化 |
曖昧な非機能要求のテストは困難 顧客の参加が重要 |
副作用の影響がないことを回帰テストで確認 | 変更による影響に対してシステムが正常であることを確認 |
回帰テストのコスト |
入力,事前条件,事後条件の明確化 | システムが何をしているかと何をすべきかの差を解明 |
テスト専門家は答を知っているのが前提 要求がないと分からない |
探索テストによりシステムの挙動を調査 | テスト計画,テスト仕様などからなるテストウェアで要求仕様を代替可能 |
不十分な要求の下ではテスト専門家 の知識に依存 |
◆要求レビュにテスト専門家が参画
〈利点〉最終テスト段階での要求変更の発生を抑止。
〈課題〉顧客の参加が重要。
◆事業目的に対して要求仕様書の完全性と正当性をテスト
〈利点〉欠陥の早期発見。
〈課題〉テスト専門家による事業目的の理解。
◆要求を具体例でテスト
〈利点〉曖昧な要求仕様の改善。
〈課題〉What if質問のスキル。想定ユーザーの妥当性。
◆非機能要求を測定する適切な基準を考えることでテストする
〈利点〉曖昧な非機能要求の明確化。
〈課題〉曖昧な非機能要求のテストは困難。顧客の参加が重要。
◆副作用の影響がないことを回帰テストで確認
〈利点〉変更による影響に対してシステムが正常であることを確認。
〈課題〉回帰テストのコスト。
◆入力、事前条件、事後条件の明確化
〈利点〉システムが何をしているかと何をすべきかの差を解明。
〈課題〉テスト専門家は答を知っているのが前提。要求がないと分からない。
◆探索テストによりシステムの挙動を調査
〈利点〉テスト計画、テスト仕様などからなるテストウェアで要求仕様を代替可能。
〈課題〉不十分な要求の下ではテスト専門家の知識に依存。
要求とテストの5つの連携策
次に表3に示した要求とテストの5つの連携策を紹介しよう[1]。
連携策 | 利点 | 課題 |
---|---|---|
テスト専門家の早期参加 | 計画段階でのテスト活動の考慮 ドメイン知識の獲得 要求品質の向上 |
テスト専門家の確保 分散開発 開発プロセス |
要求レビュへの参加 | 要求の欠陥と漏れの摘出 テスト困難な要求の発見 |
間違った視点からの指摘 詳細すぎる指摘の増加 |
要求とテストの追跡性 | テスト網羅性の向上 変更管理の効率化 欠陥摘出の効率化 |
追跡性の維持が困難 高い要求品質が前提条件 |
要求担当とテスト専門家のコミュニケーション | テスト専門家による推測の削減 低い要求品質を補完 テスト結果の信頼性の向上 |
要求責任者の負荷が増加 業務知識専門家の確保が困難 情報の信頼性が絶対条件 |
テスト専門家による 要求発見 |
テスト可能性の向上 テスト工数削減と工期短縮 |
指摘内容の質の向上 指摘内容の優先順位 |
◆テスト担当の早期参加
〈利点〉要求段階でテスト活動を考慮することで、テスト専門家がドメイン知識を獲得できるだけでなく、要求の品質が向上する。
〈課題〉要求段階でテスト専門家の稼動を確保する必要がある。また要求とテストの専門家が地理的に異なる地域で作業する分散開発の場合にはテスト専門家の参加が困難になる。さらに開発プロセスの見直しが必要になる。
◆要求レビュへの参加
〈利点〉要求レビュにテスト専門家が参加することで要求の欠陥と漏れの摘出を容易化できる。また非機能要求などのテスト困難な要求を早期に発見できる。
〈課題〉テスト専門家の持つ知識や関心領域が要求専門家と異なる場合には、間違った視点からの指摘や詳細すぎる指摘が増加する可能性がある。
◆要求とテストの追跡性
〈利点〉要求とテストの追跡性を管理することにより、テスト網羅性を向上できるだけでなく、変更管理や欠陥摘出を効率化できる。
〈課題〉要求変更が多くなると、要求とテストとの追跡性の維持管理が困難になる。また前提条件として要求品質が高いことが求められる。
◆要求専門家とテスト専門家のコミュニケーション
〈利点〉両者のコミュニケーションを緊密にすることで、テスト専門家による要求に対する推測を削減できる。また低い要求品質をコミュニケーションによって補完できる。これらの結果として要求に対する相互理解が深まるのでテストの信頼性を向上できる。
〈課題〉テスト専門家の質問に答えるために要求責任者の負荷が増加する。またテスト段階での業務知識専門家の確保が困難である。さらに相互流通する情報の信頼性を確保する必要がある。
◆テスト専門家による要求発見
〈利点〉テスト専門家が要求をテストすることで要求のテスト可能性を向上できる。これによってテスト工数の削減と工期短縮が可能になる。
〈課題〉テスト専門家による指摘内容の質を向上する必要がある。そうでないと要求定義工数が必要以上に増加する可能性が高い。このため要求テストにおける指摘基準や指摘内容の優先順位などについて要求専門家とテスト専門家との間で予め合意しておくなどの対処も必要なる。
連携策の比較
図1に上述した要求とテストに関する連携策を比較した例を示した。要求とテストの7つの神話に基づく連携策をM1~M7で、後から述べた5つの連携策をP1~P5で示した。この結果、共通する連携策が多いこと、神話に基づく連携策の方がより具体的であることなどが分かる。
図1 要求とテストの連携策の比較
このような比較をしてみると、もっと系統的に要求とテストの連携策を導くことができそうである。
そこで、プロセスとプロダクトを横軸にして要求とテストを縦軸にとって、これらの連携策を配置してみると図2のようになる。この図には、表4で示したアジャイル要求工学の施策[3]も考慮に入れている。この理由は、アジャイル要求工学ではビジネス上最も重要だと思われる要求から実装していくので、要求が提示された段階ですぐに実行可能性つまりテスト可能性が確認されるはずである。したがってアジャイル要求工学の実践的な取組みも、要求とテストの連携策として利用できる可能性があると考えたからである。
図2 要求とテストの連携施策
連携策 | 利点 | 課題 |
---|---|---|
対面会議 | 顧客による要求進化の制御 情報共有による進化要求についての煩雑な文書化・承認手続きの回避 |
顧客と開発側による質の高い緊密な相互交流 対面時間の確保、コンセンサス、信頼関係 |
反復的要求工学 | 満足度の高い関係の構築 要求の明確化・理解容易化 |
経費と期間の見積り 最低限の文書化 非機能要求の除外 |
究極的優先順位付け | 要求に対する事業価値の明確化 優先順位の再定義の容易化 |
事業価値以外の視点の考慮 優先順位の不安定化 |
計画策定の持続化 | 致命的な要求変更の最小化 変更要求の削減 |
アーキテクチャ変更時の経費増大 |
試作 | 要求文書作成負荷の軽減 フィードバックの容易化 |
商用化移行リスク 期待の肥大化 |
テスト駆動開発 TDD(Test-driven development) |
要求、設計、コードの追跡性の向上 迅速なフィードバック あるべき振舞いのコード化 |
コード化前のテスト作成への習熟 要求の完全な理解 開発者と顧客の協力 |
レビュとテスト | 顧客への進捗報告 信頼関係の構築と問題の早期発見 管理層からの支援獲得 |
要求確認への集中 仕様の形式性の欠如 顧客の受入テスト作成能力 |
まとめ
本稿では、要求とテストについての実践的な連携策とその関係について紹介した。今後の課題としては、要求とテストのより緊密な連携やそれを考慮した開発プロセスを具体化することである。また要求とテストの相互作用について、実践に基づく経験を踏まえた有効性の評価や効果的な相互作用の方法論を構築することなどが期待される。
■参考文献
- [1] Eero J. Uusitalo, Marko Komssi, Marjo Kauppinen, Alan M. Davis, Linking Requirements and Testing in Practice, RE'08, pp. 265 - 270 , 2008
- [2] Dorothy Graham, Requirements and Testing: Seven Missing-Link Myths, September/ October, IEEE SOFTWARE, pp.15-17, 2002
- [3] Cao, L. Ramesh, B., Agile Requirements Engineering Practices: An Empirical Study, January/February, IEEE Software, pp. 60-67, 2008
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要