« May 2011 | Main | July 2011 »

June 2011

25 June 2011

オランダの同好の士

今年の1月にTEF(ソフトウェアテスト技術者交流会)のメーリングリストで紹介したのですが、オランダのJoris Meertsという方がTesting Referencesというソフトウェアテストに関する情報をまとめたWebサイトを公開されています。

このサイトの中にあるソフトウェアテストの歴史のページ History of software testing はすごく内容が充実しています。作成には英国のDorothy Graham女史(ISTQBでも活躍)が協力されたそうです。私のソフトウェアテストの歴史年表でも多くの情報はカバーしていますが、このページを見て初めて知ったこともあります。また、私の年表は90年代以降はあまり充実できていないのですが、Testing Referencesは最近の状況も記載されています。

世界には「同好の士」がいるもんだなということで、昨年11月に彼にメールしてコンタクトしました。Webの感想を書いてWACATE2010冬で配布したテストの歴史年表やプレゼン資料なども送りました(大半は日本語なのですが(^^;))。また、彼のtimelineに書かれていないことや書籍についてコメントしました。

その後は特に情報交換はしていないのですが、先日Testing Referencesを見ていて Contributions to the History of Software Testing のページに以下のように私の名前が書かれていることに気づきました。

The History of Software Testing is created with the help of and generous contributions by the following people.
  ・ James Bach
  ・ Michael Bolton
  ・ Dorothy Graham
  ・ Rob Sabourin
  ・ Keizo Tatsumi
  ・ Gerald Weinberg

著名な方々の中で、すごく場違いな感じで気恥ずかしいですね。でも、うれしかったです。
テストの歴史をきっかけに、外国の人とコンタクトできるというのはおもしろいですね。

右サイドバーのWeb Pagesに「歴史Webサイト紹介」のページを作成し、ソフトウェアテストや品質に関する歴史、コンピュータの歴史がまとめられているサイトをまとめました。

---<以下はTEFで発信したメールの抜粋です>---

Testing References というWebサイトを見つけました。
  http://www.testingreferences.com/

★世界には同好の士(?)がいるものです!

去年6月にJoris Meertsというオランダの方が作られたWebサイトです。
 #名前の読み方は分かりませんが、ヨリス(Joris) メール(Meerts)と読むのかなと思います。詳しい方がいたら教えてください。
このWebで History of software testing や Software testing timelineが紹介されていますが、内容がすごいです。作成にはDorothy Grahamも協力しているそうです。
私のソフトウェアテスト・ヒストリー年表でも多くの情報はカバーしていましたが、次のことはこのWebを見て初めて知りました。
1) 最初のソフトウェアテストのチームは1958年にワインバーグ(当時IBM)が有人宇宙飛行計画のマーキュリー・プロジェクトで作った
2) ソフトウェアにFMEAを適用したのは1979年にDonald J. Reiferが最初(論文:"Software Failure Mode and Effects Analysis")

★彼がWebを立ち上げたきかっけは、来週のJaSST'2011 Tokyoに来るLee Copelandの講演 "The Nine Forgettings" だそうです。
  Copelandのこの講演のビデオはTesting Referencesサイトでリンクがあるので見ることができます。
     http://www.testingreferences.com/testingvideos.php
  この講演の中でCopelandはテストの歴史上の人物の話をしているようです。(英語リスニングできてません・・・)

★このTesting ReferencesのWebは情報満載です。
  ・Software testing literature → テスト関係の書籍が一杯
  ・History of software testing → 1822年のBabbageから現在までの歴史
  ・Software testing timeline → 年表がすごい(ちょっと見にくいけど)
  ・Competences in software testing → 規格、技法、ツールなどの情報
  ・Weblogs about software testing → 世界中のテスト関係のBlogのリンク
      Twitter http://www.twitter.com/testingref で更新情報も発信
  ・Videos on software testing → テストのエキスパートの講演ビデオ

★WebサイトのオーナーのJoris Meertsさんとコンタクトしました。
  「同好の士」ということで彼にメールしました。Webの感想を書いてWACATE2010冬で配布したテストの歴史年表もつけました(大半は日本語なのですが(^^;))。
  早速メールの返信があり、いろいろ私が書いたテストの歴史のことや日本のテストの状況など沢山質問を受けました。英語でのメールなので四苦八苦しながらまた返信しました。Meertsさんからは引き続き情報交換しましょうと言われています。
  彼は、今年5月にオランダでのコンファレンスでテストの歴史のプレゼンをするそうです。また、11月のEuroSTARでも発表するかもしれないとのことです。
  なお、彼のWebの History of software testing では国ごとの情報を抽出できるのですが、日本は石川馨先生の"What is Total Quality Control?"だけでした。日本のテスト界の状況としてJaSSTの話をメールに書いておいたので、そのうち彼のWebに載せてくれるかな。

★おまけ
  昨年11月のEuroStar 2010の会議後のライトニングトークスの動画がありました。Joris Meertsさんのテストの歴史に関するものもあります。
  Dorothy Graham や Michael BoltonのLT動画もあります。(ちなみに、来週のLee Copelandのプレゼン資料の中にMichael Boltonの写真が載っているページがあります)。
  Lightning Talks night with EuroStar 2010
  http://testing.gershon.info/201012/eurostar2010-rebel-alliance-night/

|

18 June 2011

ソフトウェアテストの歴史年表の公開

「このBlogではテスト技術や品質技術の歴史を中心に書く」と言っておきながら三角形問題のテストケースの話題が続いてしまいましたので、今回は歴史に戻します。

ソフトウェア・テストPRESSで書いた「ソフトウェアテスト・ヒストリー」、「続・ソフトウェアテスト・ヒストリー(日本編)」では、世界、及び日本のソフトウェアテストに関する歴史年表も作成して掲載しました。
年表の作成にあたっては、テスト技術の歴史だけでなく、コンピュータのハードウェアやソフトウェア、それらを活用したシステム、更にソフトウェアの開発技術の歴史も記載して、いろいろな技術や活動の出現背景が見えるようにしたいと考えました。果たして、そのように見えるようになっているでしょうか?
右サイドバーのWeb Pagesに「ソフトウェアテストの歴史年表」のページを作成しましたのでご覧ください。

|

17 June 2011

三角形問題のテストの考え方いろいろ

前回の記事で三角形問題のテストに関するcomp.lang.rubyの一連の議論が、TDDにおけるテストの考え方やテスト専門家の考え方が分かり、非常に勉強になりそうだと書きました。
この一連の議論は以下のGoogle Groupsのリンクで読めます(comp.lang.ruby beck triangle binder で検索した結果です)。174スレッドあり25スレッドで1ページになっているので適宜ページを進めて読んでください(Expand allにするとよいです)。
John Roth dolt ( Re: A challenge to proponents of Unit Testing. )
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/2ee4bea87846ead3/e32568d860adc89b?hl=en&q=comp.lang.ruby+beck+triangle+binder&lnk=ol&#

以下に、私なりに理解した(と思った)ことや注目したことを書いてみます(ただし、私の英語の解釈の誤りや技術上の誤解があるかもしれません)。

1. BeckのTDDのテストケース作成の考え方
1)Beckの実装では何故6個のテストでよいのか
  ・SmalltalkのSetの機能を使っているので入力値の順序を入れ換える(permutation)テストケースは不要(注1)
    → Myersの13個のチェック項目の内、permutationの確認は3項目あります。
  ・Smalltalkは整数が整数として扱われる(限界値はない)ため入力値の限界値のテストケースは不要(注2)
    →Myersの13個のチェック項目の中に限界値の確認はありませんが、Binderのテストケースにはあります。
  ・BeckのテストケースにはMyersのチェック項目の中の「一辺がゼロ」「二辺の和が他の一辺より小さい」「全ての辺がゼロ」「入力する個数の誤り」が含まれていませんが、その理由は分かりません。「テスト駆動開発入門」で書いているように「テストがなくても実装の知識により自信が持てれば、そのテストは作成しない」ということかもしれません。

(注1)Setは集合に対して重複しない項目のみを含むので、3辺が(2,3,4)の場合はSetオブジェクトは(2,3,4)、(1,2,2)の場合は(1、2)、(2,2,2)の場合は(2)となります。また、Setは3辺の値の入力順序には無依存です。そしてSetオブジェクトの項目数が三角形の種類を表すことになるので、1は正三角形、2は二等辺三角形、3は不等辺三角形を表すことになります(Beckは後にSortedCollectionを使う実装に修正していますが集合の観点からは同等)。

(注2)「テスト駆動開発入門」のp.192に「たとえば、Smalltalkの整数は整数のように振る舞い、32ビットコンピュータのようには振る舞わないので、MAXINTをテストする意味はない。」と書かれています。初めて読んだときは意味がよく分かりませんでしたが、comp.lang.rubyの議論を読んで「整数は整数のように振る舞い」という文章が、そもそも整数には限界値(32ビットコンピュータのような2**32-1という上限値)はないという意味だと理解しました。

2)その他のBeckの発言で注目したもの
  ・この5つのテストケースは私の機能のMTBFに対して大きな確信(confidence)を与えてくれる。
  ・SmalltalkではなくJavaでコードを書いて2**31を入力したらどうなるかを確認したければそのようなテストを書けばよい。
  ・unit testsが大量で複雑になる場合、それは設計(design)に問題があるのであってテストの問題ではない。

2. Binderのテストケース作成の考え方
1)Myersの三角形問題のテスト
  ・典型的な三角形判別アルゴリズムでは辺の長さの和をとる処理があるので、少なくとも一つの辺は(2**32)-1をテストして計算オーバーフローの確認が必要
  ・また、二辺の確認だけで判定してしまうというバグがよくあるが、これがMyersがpermutingのテストを主張した理由

2)その他のBinderの発言で注目したもの
  ・テスト対象の実装の知識はテストを作成する助けにはなるが、危険を伴う。
  ・テスト作成のゴールはテストスィートを最小化することではなくバグ検出機会の最大化であるべき。
  ・テストのコミュニティでは適切なテスト(adequate testing)は少なくとも命令網羅(statement coverage)を達成することと定義されているが、このスレッドの一連の議論はそうではなさそうだ。(カバレッジに関してBinderとJeffriesが議論しているが、私はあまり内容が理解できていません)

3. その他の参加者のやりとりで注目したもの
1)コードを書く前にテストを書くというXPのルールに反しているのではないか?
  → 違う。XPにおけるテストはコードの作成と同時(concurrently)に書かれる。(Robert C. Martin)
2)あなたのテストは特定の実装に特有のものなので、他の実装では適切なテストにはならない。
  → その通り。unit testはwhite box testであり、設計の変更に影響を受ける。一方、acceptence testはblack box testであり設計の影響は受けない。どちらのテストも必要だ。(Robert C. Martin)
3)テスト対象の実装の知識は助けになるが危険を伴う(Binder)
  → その通り。XPではこのジレンマに対して2つのテストスィートを用意することで解決している。ひとつは開発者が書くwhite box unit test、もうひとつは顧客/QA部門が書くblack box acceptence test。(Robert C. Martin)

<感想>
・TDDは「最初にテストを書く」ということから、Black box testしかあり得ないと考えていましたが、どうもそうではないらしい。
・Beck、Martin、JeffriesとBinderらの議論は、現場の開発担当者とテスト/QA担当者との間でもあり得るやりとりのように感じました。
・検査部門に長年いた私としては、テストを現実的な(実施可能な)数に減らすために、開発担当者とのやりとりを通じて「確信をもって」減らす、あるいはズームアウトするようなグレーボックステストのアプローチが現実解ではないかと思います。

|

09 June 2011

三角形問題ではKent Beckにも見落としがあった!

みなさんは三角形問題に対していくつのテストケースがつくれたでしょうか?
Myersの当時の調査では「高度な経験をもつ専門プログラマの平均点数は14点満点でたった7.8点」だったそうです。みなさんも、Hammingが言うところの三角形問題の「隠れた前提(hidden assumption)」を見落として「よくできる学生でも(3,4,7)の組が不等辺三角形と呼ぶべきでないことを見い出して驚く(Gruenberger)」のと同じ状況になりませんでしたか?

もしそうだったとしてもがっかりすることはありません。
実はKent Beckですらこの見落としがあったのです。

前回の「三角形問題で必要なテストケース数」で、Kent Beckが「テスト駆動開発入門」の中で6個で十分と書いていることを紹介しましたが、この部分の記述は2001年12月のUSENETニュースグループcomp.lang.rubyで議論されたものがベースになっています。
この議論の中でBeckは最初に5個のテストケースを示したのですが、抜けがあるとの指摘を受けて1個追加して6個となったのです。

◆最初のメールで示した5個
1. 不等辺三角形(1,2,3)
2. 正三角形(2,2,2)
3. 二等辺三角形(1,2,2)
4. 入力値がnil(空)
5. 文字列(a,b,c)

どうでしょう。
おかしなところに気がつきましたか?

◆修正版のメールで示したもの
1. が(2,3,4)に修正されました  ※ 1. の(1,2,3)は三角形にならないですね。
6. に、三角形ではない(1,2,3)  が追加されました

◆「テスト駆動開発入門」では
4. nil(空)が負の値(-1,2,2)に変更されています  ※ 変更理由は分かりません

ところで、ここで書きたかったのはBeckでも見落としがあるということではなく、このcomp.lang.rubyの一連の議論のメールを読むと、三角形問題を題材にしてTDDにおけるテスト(unit tet)の考え方、それに対するテスト専門家などからの反論が分かり、非常に勉強になりそうだということです。ちなみに、この一連の議論の発言者の中には、Kent Beck以外にRon Jeffries、Robert C. Martin (Uncle Bob)というAgile Manifestoに名を連ねている人たち、及び"Testing Object-Oriented Systems: Models, Patterns, and Tools"の著者のRobert Binderがいます。
私自身は英語力やプログラミング知識の不足のため十分に理解できないので、興味のある人は是非読んでみて教えてください。勉強会の題材にするのもよいかもしれません。

取り敢えず、Beckの提示したテストケースに関する発言が読めるリンクを以下に書いておきます。
なお、Beckはいきなり5個のテストケースを示した訳ではなく、TDDのプロセスに沿って説明しています。すなわち、まず一つテストを書き、それがOKとなる実装を書く、その後にテストを追加して、それがOKとなるように新たな機能を実装に追加するという流れです。([ruby-talk:28069]を参照)

2001年10月26日 <Extreme Programming(XP)のYahoo! Groups>
  Binderのテスト書籍に関する質問があり、その返信の中でBeckは三角形問題のテストは5個で十分と発言。
Re: [XP] Test Suites
http://groups.yahoo.com/group/extremeprogramming/message/37242
The biggest problem is that it doesn't balance the cost and benefits of tests. He has a triangle example which he writes (I think) 29 tests for. The test-first version can be done confidently with 5 tests.
   (注)Binderが29個のテストを書いているというのはBeckの勘違い。

2001年12月7日 [ruby-talk:27796] Myersの三角形問題でどんなテストを書くか?
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/27796

2001年12月8日 XPのYahoo! GroupsのBeckの発言を紹介
http://groups.google.com/group/comp.object/msg/5d38c7804ace023e?hl=en

2001年12月8日 [ruby-talk:27813]  Beckの意図は何だろう?
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/27813

2001年12月8日 [ruby-talk:28069]  Kent Beck 5個のテストを提示
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/28069

2001年12月11日 [ruby-talk:28123] テストもれの指摘
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/28123

2001年12月11日 [ruby-talk:28183] Kent Beckが指摘に返信
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/28183

2001年12月12日 [ruby-talk:28294] Kent Beckが修正、追加を提示
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/28294

|

05 June 2011

三角形問題で必要なテストケース数

Myersは「ソフトウェア・テストの技法」で自己診断テストの採点用チェックリストを示しています。このリストには「xxxのテストケースをもっているか」という13の項目と、「期待出力結果を書いているか」という項目の合計14項目が書かれています。13項目の中には3つの整数値の入力順序を変える(permutation)ものが含まれているので別々に数えると、Myersのチェックリストに合格するには最低22個のテストケースが必要になります。
では、Myersの三角形問題の正解のテストケース数は22個なのでしょうか?

ソフトウェアテスト・ヒストリー(ソフトウェアテストPRESS Vol.8)のコラム「三角形問題の正解」で、米国のテスト・コンサルタントRoss Collardの"Exercise: Analyzing the Triangle Problem"を紹介しました。Collardは三角形問題のテストケース数について次のように書いています。

  • Paul Jorgensenは185個のテストケースを示している。
  • 私は4個で十分だと主張できる。
  • Kent Beckは彼の三角形問題のインプリメンテーションに対しては6個のテストケースで十分だと言い、Bob Binderの65個のテストケースと比べている。

  4人の専門家に依頼して、4から185の範囲の4つの異なる解答をもらって4人分のコンサルタント料を払うなんて悪い冗談だよね。

この4人のテストケースがどのようなものか調べてみました。

Paul Jorgensen
  "Software Testing: A Craftsman's Approach"のBoundary Value Testingの章で三角形問題に対するテストケースが掲載されています。この章で示されている"Worst-Case testing"手法でテストケースを作成すると次の数になります(minは下限値、maxは上限値、nomは中間値、+は1大きい、-は1小さい)。
 ・Worst-Case test case
  3辺の min, min+, nom, max-, max を全て組み合わせた125個(=5の3乗)
 ・Robust Worst-Case test case
  3辺の min-, min, min+, nom, max-, max, max+ を全て組み合わせた343個(=7の3乗)
Collardは185個と書いていますが、私がJorgensenの本を調べた範囲では125個、または343個でした。

Ross Collard
  正三角形(3,3,3)、二等辺三角形(3,3,2)、不等辺三角形(3,4,5)、不正値(3,3,?)の4個のテストケース

Robert Binder
  "Testing Object-Oriented Systems: Models, Patterns, and Tools"も最初の章(Chapter 1 A Small Challenge)は三角形問題で始まります。ここで次のように、Myersのテストケース+α(最大値の入力を確認するもの)からなるテスト(Basic Test Case)と、オブジェクト指向の特性を考慮したテスト要件にもとづくテストとして65個のテストケースを示しています。
・Basic Test Caseとして33個
・Test Requirements for Bugs Related to Encapslation and Persistenceとして29個
・Test Requirements Related to Inheritance and Polymorphismとして3個

Kent Beck
  「テスト駆動開発入門(TDD: Test-Driven Development By Example)」で、正三角形(2,2,2)、二等辺三角形(1,2,2)、不等辺三角形(2,3,4)、三角形ではない(1,2,3)、負の値(-1,2,2)、文字列(a,b,c)の6個のテストケースを示しています。

この状況に対してCollardは前述の論文で次のように続けています。

正しい解答は何だろう?全ての環境にあてはまるような解答がただひとつあるわけではなく、それぞれの状況(context)に応じて最も適切な解答が存在するというのが解答である。

Jorgensenのような文字通りのブラックボックステスト技法とBeckのような内部の処理が分かった上でのテストでこれくらいのテストケース数の差が出るという例として興味深いですね。

|

01 June 2011

三角形問題の種類と使われ方

Myersの三角形問題は、3辺の長さをあらわす3つの整数を読み、不等辺三角形(scalene)、二等辺三角形(isosceles)、正三角形(equilateral)のどれなのかを判別して表示するプログラムのテストケースを書いてみよというものですが、三角形問題の発案者のWeinbergのものは辺だけでなく角も判別、すなわち、直角三角形(right)、鋭角三角形(acute)、鈍角三角形(obtuse)かも判別する問題になっています。
Gruenbergerが「いきな問題(dandy problem)」と評したRichard Hammingの"Computers and Society"(1972)に書かれた三角形問題は辺と角を判別するプログラムですが、同時期に書かれたTRW社のJohn Brownの論文"Practical Applications of Automated Software Tools"(1972)では辺の判別だけになっています。
まあ、どちらでなければいけないというものではなく、三角形問題を使って何を説明したいかによって、辺だけの判別にするか角も含めるかということでしょう。「Myersの三角形問題」という時は辺だけの判別ということになると思います。

三角形問題の使われ方は、外部仕様の例題として使われる場合と、プログラムの解析の題材として使われる場合の二つに大別できそうです。後者は、外部仕様そのものは大概の人が知っているので、いきなりプログラムの内部の話に入れるという便利さがあるからだと思います。前述のBrownの論文はこれにあたり、カバレッジ測定の題材にしています。一方、前者の外部仕様の例題として使っているのがHammingです。
Hammingは、(1)三角形の定義(3辺の関係)に基づく判別、(2)ピタゴラスの定理に基づく角の判別、という論理ブロックの流れを説明し、更に詳細なフローチャートへ展開するプロセスを説明しているのですが、この展開を説明する前にこの問題には「隠れた前提(hidden assumption)」があると書いています。すなわち、「三角形の二辺の和は他の一辺より長くなければいけない」という暗黙の前提です。そして、現実世界でも与えられた文章(仕様)は十分ではなく、見落としもあるということを、この三角形問題を例にして説明しています。Myersの三角形問題でも、このケースの見落としが多いのではなかったでしょうか。Gruenbergerが「いきな問題」と言ったのはこのような見落としがあることを気づかせるためのよい例題だったからでした。

Computers_and_Society

|

« May 2011 | Main | July 2011 »