ソフトウェア教育の権威Cem Kaner氏へのインタビュー 優秀なテスターの育成と訓練方法The Rational Edge

 法学博士であるCem Kaner氏は、フロリダ工科大学のコンピュータサイエンスの教授であり、おそらく世界で最も著書と読者の多い作家、コンサルタント、教育者、そしてソフトウェアテストを専門にする弁護士でもある。今回Kaner氏には、テストのための教育とコンサルティング業務との関係に対する持論や、「アジャイル」ソフトウェア開発に対する見解を語ってもらった。

» 2002年09月14日 12時00分 公開
[Cem Kaner,@IT]

Guckenheimer フロリダ工科大で教鞭を執って2年が経過しましたが、ソフトウェアテスターの育成に関して何を学びましたか。営利企業と大学ではソフトウェアテスターの訓練方法に違いがあるのでしょうか。

Kaner 大学教授には、社会人に教えていたときにはなかった2つの大きな喜びがあります。まず、実際に学生にテストを受けさせることができるのですが、彼らにはそのテストを受け、合格する意欲が見られます。彼らに対して課題を出したり、評価を下すこともできるのです。これは社会人対象の講義では不可能なことです。社会人の場合は最後に非常に簡単なテストが出るだけで、(学生向けのように)仲間と共同で1週間も必死に作業しなくてはならない課題が出るわけではないのです。学生に課題を出し、それを採点することで私が学んだのは、自分が明確だと思っていた概念でも、テスト経験の乏しい人にとっては非常に分かりにくい場合がある、ということでした。

 例えば、ある状況を踏まえて「この場合の境界条件はどうなるだろうか?」と判断するにはかなりの練習が必要です。大半の学生がうまく評価できるようになるには少なくとも課題を3〜4回はこなす必要があります。採点をまったく、もしくはほとんど重視しない課題を用いて、同様の問題を何度も繰り返し行うことが必要なのです。講義を幾度となく繰り返すこともできるのですが、中心となる概念は「そうか、分かったぞ」というように学習の過程において学生の頭の中でパッとひらめかなくてはなりません。このようなひらめきは、一般には練習の積み重ねの中でしか起こり得ないのです。

 フロリダ工科大では現在、自分のペースで進めることのできる自問自答式の問題の草案作成に多くの時間を費やしています。例えば、私があなたにデータ入力フィールドを渡し、あなたがそのフィールドを分析して境界のサンプルを考え、それに対して私が自分たちで同じフィールドを分析した結果を示します。そして、調査中のフィールドが何か、あるいは変数が何かと問い掛ける文章問題を出し、それから範囲を拡大していくのです。

ALT 本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

 われわれが境界分析を教えるときの方法を考えてみてください。学生はあるフィールドに対して考え得る1番大きな数値を入力し、その最大値プラス1を入力して、その両方をテストします。このような特定の値を使うのはなぜでしょう? われわれは経験から、大きいが最大ではない有効値や、極大だが限度いっぱいではない無効値を使うよりも、これらの条件の方がやや高い確率でプログラムが障害を起こすことを知っているからです。そこで、われわれはこの例のようにして誤差論を教えます。つまり、“有効な数値すべて”、“極大値すべて”など、われわれが境界テストで行っているのはテスト事例のクラスの特定なのです。それから最大有効値、最小無効値、極大値など、これらのクラスを代表する値を見つけ出します。実行できるテストは無限にあり、クラスのすべての値をテストすることはできないので(だれにもそのための十分な時間はつくれません)、これはクラスのほかの値よりも障害を突き止められる可能性がやや高い、クラスを代表する数値だといえます。通常、テストに使うクラスの数値は、その数がどれも1つや2つといったごく少数に限られています。そのため、サンプルに使用する数値としては問題を発生させる可能性の高い優れた値が常に求められるのです。

 学生がシンプルな境界分析といくつかの異なる変数とにまたがる境界を組み合わせた問題で練習をしたら、リスクの特定方法としてほかに何があるか、という次の概念へと彼らを進ませます。リスクを明らかにするクラスや、リスクを明らかにしないクラスとタスク、そしてテストする価値のあるサンプルはどのように見つければよいかということです。

 私の経験では、自宅に持ち帰ってできるこのような練習問題を学生に数多くやらせればやらせるほど、彼らがその背景にある原理を理解する可能性も高まります。そこで、私は大学院生に多くの時間をかけて有用な練習問題を作成する方法を発見させているのです。そして結局は、数学や物理を勉強したことのある方ならおそらく使ったことのある「Schaum's Outlines」に出てくるような一連の資料にたどり着くと思うのです。これは数々の例を用いた技術資料を簡単にまとめたもので、練習問題も多数用意されており、最終的には特定のクラスの問題を解決できるようになります。

 私はコンサルタントとして、これらの概念に関してはいまよりもっと多くの練習が必要だと考えていました。しかし、私が教えるスタイルを企業の中でいろいろ試す機会はまったくありませんでしたし、ドリルを数多くこなす講義に時間の限られた社員が出席することも不可能だったのです。練習の必要な実作業をイメージして優れた練習問題を作成するには膨大な時間を要するのです。

 一方、大学教授としての私には、いうなれば、より良いカリキュラムを研究するための時間があり、そのための一連の不本意な学科もあります。講義が改善されると思えることをいろいろ試すことができますし、実際にもそれらの多くは改善に役立っています。講義を受講し、練習問題作りに非常に熱中した学生もいます。これらの優等生たちは何らかの単位を取得することになりますが、私が独立コンサルタントだったら給料を支払う余裕はありませんでした。

Guckenheimer どのような経歴の学生がいて、彼らはそれぞれどのような道に進もうとしているのですか。

Kaner 現在は、コードの書ける学生しか対象にしておらず、彼らには自分の書いたコードもしくはクラスメートの書いたコードをテストする方法を教えています。私の講義を受講する学生は、全員がソフトウェアエンジニアリングもしくはコンピュータサイエンスの学科に在籍していて、すでにプログラミングの講義をいくつか受講しています。テストの最初の講義では従来のブラックボックス型テストをカバーし、2回目の講義は初日からJUnitを学びます。

 フロリダ工科大の学生は、その多くが卒業後はソフトウェア開発の会社でプロのテスターになります。われわれが試みていることの大半は次世代テスト設計者の教育だと思います。通常、このような人々にはソフトウェア開発に関する多くの識見があり、自分でツールを構築するか、ツールを評価して自分のスタッフにツールをうまく活用する方法を教え込むか、特定のツールを有用なものにするためのサポート資料を書かなくてはなりません。組織の問題すべてを解決してくれる、もしくは単独で完全に機能するテスト自動化ツールは1つもありません。テストのビジョンを変更する、もしくは選択したツールとの互換性を高めるようデータやコードを整理するため、会社の中では相当量の作業が常に必要となります。われわれは、この作業を支援する人材を大量に育成しようとしているのです。

Guckenheimer ソフトウェアテストの分野は実社会の意識や経験に欠ける学生では不十分だという意味ですか。

Kaner 実際のところ、私は実務経験のない人間はテストにおけるものの見方が欠如していると思っています。かつて(ある企業の)雇用担当マネージャだったころに、コンピュータサイエンスプログラムを修了した人の面接をしたのですが、これにはかなり失望しました。彼らが受講したテストの講義が完全に理論でしかないことに気付いたのです。彼らはこの理論を応用するすべをまったく知りませんでした。

 テストの講義を行う中で、実世界の数多くの例を示すのは大変な苦労を必要としました。サンプルアプリケーション(開発中のソフトウェア)をわざわざ探し出し、課題や講義の大半をこのプログラムの徹底的な議論に費やすようにしました。昨年はStar Officeを使いましたし、Microsoft PowerPointを使ったり、Texas Interactive Calculatorを使ったこともあります。今秋の講義ではどのアプリケーションを使うかまだ分かりませんが、これは学生が本物を経験するのに絶対不可欠です。これがなければ教えたことすべてが非実際的なものとなり、将来役に立たないものとなる可能性が高くなるでしょう。

 私は大学でまったく新しいメトリックスの講義も行っています。このクラスでは15人の学生が学んでいます。彼らは主に大学院生ですが、その中でソフトウェア開発の実務経験があるのはわずか5人しかいません。何かが使用されるタイミング、それが使用される流れ、それが間違って使用される場合、その測定手法を採用する組織にとってのリスクなどについて講義すると、実際の現場を経験している学生は私の話している内容を理解してくれました。しかし、残りの10人は私が説明しようとしているポイントを理解するのにかなり苦労したのです。しかも、どの手法がどこで便利なのか、ある手法に対してどのようなリスクが存在するのか、どこでその手法に妥当性を持たせるのか、そして収集した数値からどこで何を学び取るのかを理解する経験がなければ、あたかも使い方を知らないのに弾丸を装てんした銃を持つ、という状況になってしまうのです。

 ソフトウェアアーキテクチャを教える人々は、実務環境で比較的大規模なプログラムの設計に挑戦したことのある学生と、その経験のない学生との間で、理論の理解に大きな隔たりがあるのを感じています。従って、私はこの現象がテスト技法の教育に固有のことだとは思いません。多くの分野において、一度実社会に出てから戻ってきた学生の方が、社会経験のない学生よりも微妙な考えをうまく把握してくれる可能性は高いと思っています。

Guckenheimer 先日、国立科学財団(NSF)がソフトウェアテストに関する有用な教育資料をより広範囲に提供するための補助金交付をあなたに対して認めましたが、これはこの分野の専門職もターゲットにしているのですか。この補助金について詳しく教えていただけますか。

Kaner この(ソフトウェアテスターの育成向上のための)補助金は、学校におけるソフトウェアテスト教育に焦点を合わせています。私は申請時に、講義も少なく、優れた教科書もなく、練習問題もないなど、ソフトウェアテスト技法の教育資源がほぼゼロに等しいことを強調しました。テスト技法の教育では、数学などを教えるのとは異なり、ごく一般的な手法がないのです。そこで私は、練習問題、講義メモのサンプル、テストツールなど、テスト技法の講義をもっと効果的に構築するために資料をまとめたいと考えたのです。

 例えば、われわれは、同時にテストをしなければならない多数の変数が含まれる環境で効率的な処理を実現できる「オールペア」(全組み合わせテスト)というテクニックのテストプログラムを書いていますが、これを使えば、ごくわずかのテストを実施するだけでコンフィグレーション関連の問題のほとんどを発見できるようになります。非常に優れた市販のオールペア用テストツールもありますが、合わせて10程度のわずかな数の変数をテストするには高価過ぎます。そこで、Nadim Rabbani君という学生の1人は、Hugh Thompson君という別の学生と共同で、それぞれが10程度の値を持ち、合計で最大10の変数を扱うオールペアテストツールを作ろうとしています。業界には手作業で処理しきれないレベルの問題を抱えている人がいるので、これらのツールが多少は役立つようになることでしょう。でも、これが最も役に立つのは講義の場なんです。学生には「組み合わせテストの概念はこう。厄介な組み合わせの問題はこう。まずは手作業で問題に挑戦し、それからツールを使って結果を比較しなさい」と指示します。これで彼らは無償ソフトウェアツールの威力を知ることになり、もっと複雑な環境に放り込まれた場合には、彼らが会社に投資額の上積みを検討させたくなる根拠を自分で理解していきます。

 そのほかにも、Giridhar Vijayaraghavan(Giri)君とAjay Jha君という2人の大学院生は、プログラムが障害を起こす仕組みを研究しています。Quality Week(米国で開催されるテストだけのカンファレンス)は間もなく、幅広い分野のリスクを分類するGiri君のショッピングカートソフトウェア問題の分類法を披露してくれます。もしあなたが米アマゾン・ドット・コムのショッピングカートのテストを考える場合、障害を起こしそうな場所をいくつか思い付くと思います。でも、Giri君の分類法を活用すれば、あなたは、特定のプログラムがどのように障害を引き起こすかについて類推することから思考を開始し、本当の問題を発見する数百種類ものテスト事例を導き出すことができるでしょう。

 資金援助を受けたこの作業の対象は学術研究ですが、テストは応用分野の1つであり、実世界でどのようにテストを実施するのか考慮せず教授法を考えるのは愚かです。われわれが教職員に提供する資料はすべて、われわれが間もなく立ち上げる「TestingEducation.org」というサイトを通じて企業の教育担当者や訓練担当者にも提供します。私の講義メモなどの資料は、だれでも無料でダウンロードできます。教育従事者は商用目的でも大学の授業向けでも専用のパスワードを入手し、生徒は見ることのできない試験資料、練習問題、講義のヒントなどを見ることができます。一方で、将来的には生徒にも練習問題を用意していきます。NSFの補助金は税金によって賄われていますので、このWebサイトはだれでも利用することができるのです。

Guckenheimer それは現場のテスターの方たちにとってかなりの朗報です。ただ、当然ながらRational Edgeの読者の多くはテスターでもテストマネージャでもありません。あなたの仕事は要件定義アナリストやデベロッパなど、開発ライフサイクルのほかの作業に携わる人にとってはどのような関連性があるのでしょうか。

Kaner 将来の希望進路がアーキテクト、要件定義アナリスト、プログラマ、あるいはテスターであれ、フロリダ工科大でソフトウェアエンジニアリング科に在籍する学生は全員がテスト技法の正式な単位を2つ取得しなくてはなりません。これは、開発に携わるすべての人間にとってはテスト技法が核となる能力だとわれわれが考えているためです。大半の人はそうですが、自分のコードをテストするプログラマは、この講義でさらに優れたテスト戦略を学ぶことになります。もう1つテスト技法の講義で学べるのは、多くのテスターが携わるプロジェクト管理についての知恵です。そして、私がお手伝いしたRationalの講義は、テスターがライフサイクルのどこに関与するのか、そして社内のほかの担当者たちとはどのように対話をするのかなど、数多くの知恵を与えてくれるのです。

 われわれのWebサイトは実践や訓練のためのスキルにフォーカスすることになりますが、これはテストの技術的な部分を必死に学ぼうという気持ちのない人にとってはかなり退屈なサイトになることを意味します。

Guckenheimer 最後にもう1つ伺います。ここまでは開発のライフサイクルにおける参加者同士のつながりについて話をしてきました。フロリダ工科大での講義やご自身の研究を通じてRational Unified Process(RUP)に触れる機会があったと思いますが、RUPや、「アジャイル」コミュニティなどのそのほかのプロセス関連の活動や、これらのテスト技法への取り組みについて意見をお聞かせいただけますか。

Kaner 「アジャイル開発技法」については一般論を論じたくはありませんが、「エクストリームプログラミング(XP)」については一言。XPはRUPのようにライフサイクルに対する非常に強力なビジョンを持っているといえます。さらに、何らかのタイプのテスト技法に対する強力なビジョンも持っています。しかし、私の仲間や私が方法を知っていて最もスキルの高いテスト技法はXPのアプローチにはうまく適合しません。XPはテスト最優先で考えるプログラミング(これは素晴らしいやり方です)の代わりに、カスタマの話と、使用事例に基づくシナリオに非常に近いものに対してカスタマもしくはカスタマの代言者によるテストで代用してしまいます。このアプローチでもかなりの問題を明らかにすることはできますが、同時にかなりの問題を見過ごすことにもなってしまい、ほかにどのようなテスト技法があり、それがこのスキーマにどのように適合するのかといったオープンでインテリジェントな議論のフレームワークがまったくありません。XPは、作業への取り組み方についてかなり狭い範囲でパターン化された「正しい方法」であって、多くの状況においては優れていますが、これがあまり適していない状況もあるのです。

 一方のRUPは格段に柔軟です。これは多くの状況に合わせたカスタマイズが可能で、コンピュータゲームなど、かなり小規模のプロジェクトで反復ライフサイクルのアプローチが採用されることは容易に想像できます。しかも、これは大規模なテレフォニーシステムにまでスケーリングさせることが可能です。テストのスタイルは規模の大小によって大きく変える必要があり、異なるスタイルやこれらが必要になる時期の記述という点で、RUPで書く際に問題となり得るのです。例えば、境界条件をスタイルとするテスターは、関係者とやりとりをし、一連の特定の質問を通じて成果物を1種類用意しますが、使用事例やシステム向けに開発されたモデルに基づいて大半の作業を進めるシナリオスタイルのテスターは、ありとあらゆる質問をしてきます。そして、大規模プロジェクトではライフサイクルのさまざまなポイントで異なるスタイルのテストが要求されるようになってきます。

 私がテスター向けの講義でRationalの「Principles of Software Testing」を採用することにしたのは、RUPでテスターが参照できる実用的な手本をRationalに拡張していってほしいからです。私が教える大学院生の2人も講義で扱うテスト技法の手本にするためRUPの拡張を書いているところです。

 RUPには特に、反復開発ライフサイクルのテスターがどうやって異なるタイミングで異なる種類のテストを実施するのか、そして従来の基本に基づきながらも独自のテイストを持ったライフサイクルに従うプロジェクトチームにどうやって適合させるのか、という問題をさらに掘り下げてほしいと思います。RUPはテンプレートやチェックリストのライブラリを徐々に拡張し、バグの擁護など、講義の中で教えたスキルをカバーしていく必要があります。つまり、チーム内のほかのメンバーが適切な対応を取れるよう変更要求を効果的に伝達するのです。

Guckenheimer 講義でご一緒できたことをうれしく思うと同時に、これらの拡張が組み込めるようになるのを楽しみにしています。どうもありがとうございました。

 【@IT注】このインタビューが行われる前に、Guckenheimer氏はKaner氏へインタビューを行っている。インタビューの内容は、コンテキスト主導テストの概念と、過去1年間にわたってKaner氏が米Rational向けに行った講義の開発について、である。詳しくは、「An Interview with Cem Kaner, Software Testing Authority」で読める。

本記事は「The Rational Edge」に掲載された「An Interview with Cem Kaner, Software Testing Authority」をアットマーク・アイティが翻訳したものです。

聞き手:Sam Guckenheimer

Senior Director of Technology for Automated Test

Rational Software



「The Rational Edge」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.