テストのパラダイム
SEA関西プロセス分科会の勉強会で紹介したリー・コープランド著「はじめて学ぶソフトウェアのテスト技法」のセクションⅢに「テストのパラダイム」の概要を説明します。
パラダイムは概念をモデル化したようなもので、「ルールと規範であり、境界を明確にし、成功するために、境界内でどう行動すればよいかを教えてくれるもの」です。情報の伝達や、教育、議論する際に役立ちますが、「いわば心理的フィルターなので、適合しないデータはふるい落とされる」というマイナス面もあります。
この本では、テストのパラダイムとしてスクリプトテストと探索的テストが取り上げられています。スクリプトテストは「要件を順番どおりに検証する」もので、いわゆるウォーターフォール型の開発で、通常行われている方法です。計画に従って、試験項目書などをあらかじめ作成し、それに基づいて試験を実施する方法で、IEEE829では8つのドキュメントが定義されているようです。
探索的テストは、テスト担当者が製品について学習(探索)しながら、テストの設計と実行を同時並行で行うものです。いい加減に行うものではなく、熟練したテスト担当者が「システムの適切な振る舞いについての仮説(メンタルモデル)」を作りながらテストするものです。「自由形式の探索的テスト」のほか、テスト担当者の方向付けのために「チャーター(指示書)」を用意することもあるようです。
それぞれ良いところがあって、スクリプトテストは、「再現性、客観性、監査性が重要なときに利用できる」ものなので、仕事をフェーズに分割できるほか、網羅的な試験が可能で、文書化により、理解や評価、管理などが可能になります。また、「最終段階では、テストケースが要件定義書を補える」と言う特徴もあります。その反面、システム要件の品質に依存し、柔軟性にかけ、試験の実施は「こなし仕事」になりがちなのでテストスキルを低下させるというマイナス面が指摘されています。
一方、探索的テストは、テストケースが事前に予測できず、直前のテスト結果にしたがって選択する必要があるときに有利です。たとえば、開発初期の段階でのパフォーマンスのベンチマークテストや、プロトタイプのテストなど開発の初期段階や、テストの終盤になり、試験項目がなくなったときなどに有効です。また、見つかった問題をさらに追求し、欠陥の規模、範囲、バリエーションなど十分に探索してフィードバックできることも利点です。しかし、「チャーター(指示書)」を用意すれば、テスト担当者にテスト対象や欠陥の種類などを方向付けられるものの、欠陥を予防する力は持っていませんし、わかりきった試験には向きません。また、ルールが定められているなら、それに従わねばならないので補完的な技法としてしか使えません。
この本では、テスト計画を古典的計画から適応型計画へ変更すべきだとしています。そして、計画の発見的な策定法として、以下のようにすべしと述べています。
- (利用可能な時間とリソースに基づいて)計画できるときに
- (利用可能な知識に基づいて)計画できるところまで計画するが
- 計画が可能になる前にはそれを行わない
そして、「目の前の問題に対し、意味のあることなら何でもしよう」と両者をうまく組み合わせて使うことをすすめています。
この構成と内容が何かに似ていると思ったのですが、そう、あのベーム先生の「アジャイルと規律」にそっくりです。あの本もパラダイムと読んでも良いような二つの開発方法の特徴を述べ、実際の現場にどのように適応させるかを書いています。「アジャイルと規律」はプロジェクトの分析方法まで踏み込んでいる点が優れていますが、「はじめて学ぶソフトウェアのテスト技法」は、テスト計画の説明であるべき姿を述べている点が優れています。
このテスト計画の説明ではアメリカ海兵隊の"Planning"という文書の「計画する際に注意すべき落とし穴」について触れています。
- あまり遠い将来まで事態を予想しようとすること
- あまりに詳細まで計画すること
- 計画の手法を制度化してしまい、計画のプロセスも計画書も固定して変えられないという硬直化した思考に陥ること
- 計画を、問題に対する変更不可能な唯一の解決策だと思い込んでしまうこと
- 計画の欠陥を識別して必要な調整を行うための、フィードバック機構の必要性を無視すること
この記述、メアリー・ポッペンディーク&トム・ポッペンディーク「リーンソフトウェア開発」にそっくりです。あの本でも、海兵隊の説明から変化に強い開発方法を述べていますので、その本質は同じと言っても良いでしょう。
この本を読んで感じたことは二つあります。一つは、「アジャイルと規律」にしろ、この本にしろ言っていることは、当たり前のことです。ウォーターフォールに向かないところは切り出してプロトタイピングするなど、すでに似たようなことは皆さんも工夫して実施されているでしょう。しかし、それを極端な二つのタイプにモデル化することで、その特徴を示し、より効率的な開発の仕方を示していることです。このような本は、好き嫌いが分かれますが、プロジェクト戦略を考える際に役に立つので、わたしは結構好きです。
もう一つは、アジャイルやプロセス改善がすでにブームでなくなり、実践の時代になったと言うことです。世の中のものは、流行りはじめに似て非なるものがでてその違いを理解するのも大変です。そして、徐々に淘汰されて残ったものにも限界が現れる。そして、ようやく実務でどう使うかのバランスの議論が始まり実践の時代になると思います。この本や「アジャイルと規律」はそのような実践の時代の到来を知らせる本だと思いました。
« 杏露酒(シンルチュウ) | トップページ | 自動改札機のユーザインタフェース »
「書籍・雑誌」カテゴリの記事
- Visual IoT 開発ツール Node-RED が盛り上がってきた - 新刊2冊 -(2017.10.14)
- 決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -(2017.10.07)
- [#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!(2016.09.14)
- Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール(日経BPムック)(2015.05.17)
- [#Redmine #TiDD] 日経SYSTEMSにRedmineの紹介記事を寄稿しました(2014.10.13)
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「本」カテゴリの記事
- Visual IoT 開発ツール Node-RED が盛り上がってきた - 新刊2冊 -(2017.10.14)
- 決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -(2017.10.07)
- [#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!(2016.09.14)
- Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール(日経BPムック)(2015.05.17)
- ソフトウェアと制約と自由 - 「納品」をなくせばうまくいくを読んで -(2014.08.03)
この記事へのコメントは終了しました。
コメント