Software Testing

TL;DR

1位:品質エンジニア。2位:QMエンジニア。ただし広いQAとエンジニアリングマインドを指向しよう。そうすれば品質は持続的に向上していきます。頑張りましょう!

イントロ

私たちが働いているソフトウェアやITと呼ばれる業界には、QA(品質保証)エンジニアやテストエンジニア、テスターなどの職種があります。最近ではどうもその定義は曖昧で、新たに品質エンジニアという呼び方も出てきました。その違いについてJaSST nano Vol.6で「Quality Engineeringって何なのそれ美味しいの?」というLTをしましたが、その続きについて少し考えてみようと思います。長い割にグダグダ書いているだけなので、ヒマな時にお読みください。

QAとは

QAはQuality Assuranceの略であり、日本では品質保証と呼ばれます。

もともと日本には製造業を中心にTQC(Total Quality Control、全社的品質管理)やTQM(Total Quality Management、総合的品質管理)というマインドセット・技術体系があり、多くの企業での高品質の達成に大きく寄与してきました。TQCやTQMについて勉強したい方は、「日本的品質管理」や「現代品質管理総論」を読むとよいでしょう。

さて最近、面白い本が出ました。「TQM みんなの“大誤解”を斬る!」という本です(以下「誤解本」)。この本の中に、TQCやTQMという文脈でのQAについて書かれているので、少し引用してみましょう。

QAのドーナツ化現象

「1960年ごろ…『品質管理のドーナツ化現象』といわれる現象が起きました…品質管理の手法を使って、原価低減、生産性向上…などの改善が盛んに行われ」

たそうです。2021年末頃の私たちになぞらえて言えば、見かけのベロシティを上げるためにふり返りミーティングで単体テストを書かないようになる、といった感じでしょうか。確かに、これはまずいですね。

このドーナツ化現象への対処として「品質保証」という用語が使い始められたそうです。ここでの品質保証の定義は

「お客様が安心して使っていただけるような製品・サービスを提供するためのすべての活動」

です。私たちがQAエンジニアと聞いてイメージするお仕事よりも広いですね。この定義だと、シフトレフトなどが必要なのは当たり前だと思えます。

ISO9000という黒船

「ISO9000」という言葉を見聞きした人は多いかもしれません。例えば引っ越し屋さんの宣伝やトラックなどに「ISO9000認証取得」などと書いてありますね。これは、ISOという国際標準化団体が策定した品質マネジメントおよび品質保証に関する国際規格群で、初版は1987年に発行されています。

あまり品質管理や品質保証に詳しくない方は、日本で発展したTQCやTQMが国際規格になったものがISO9000シリーズだと勘違いしがちです。現在では日本からのISO委員たちの尽力によってその差はずいぶん埋まったようですが、本質的な差があります。誤解本には、以下のように書かれています。

「日本での意味は、お客様との間で明示的に約束しようがしまいが、とにかく徹底的に満足させてやろうとすることです。」

「日本人は、総合的な品質保証、品質管理、品質経営を自慢しているのですが、欧米人から見れば、品質保証をきちんとするとは、仕様どおりの製品・サービスを提供している証拠の提示みたいなものです」

確かに、かなり違いますね。日本では1950年代から一生懸命品質管理や品質保証を発展させてきたのですが、1980年代後半からISO9000という黒船が来航して、品質保証という考え方に混乱や誤解が発生したわけです。

引っ越し屋さんは、お客様との間で契約された業務内容をきっちり遂行するタイプの仕事です。あまり引っ越し屋さんで旅館のおもてなしのようにお客様に感動を与えるという話は聞いたことがありませんね。ですからISO9000がよく馴染むようです。

ちなみにこの「証拠」というのは、私たちテスト系の技術者が想像するテスト結果だけではなく、品質保証の体系やプロセスの実証ですので、テストよりもかなり広い範囲を含みます。

品質管理と品質保証

さぁ、ここまでの短い文章でも、似たような言葉が出てきて皆さんは混乱したと思います。品質保証、品質管理(Quality Control)、品質マネジメントは何が違うようのでしょうか。誤解本では、以下のように説明されています。

品質マネジメント = 品質方針+品質方針の実施

品質方針の実施 = 品質計画+品質保証+品質管理+品質改善

「QCは、ISO9000の世界では、抜取検査、デザインレビュー、手順書、内部監査などの、品質管理手法品質管理活動要素というような意味です」

そうすると、私たちソフトウェアやITのテスト系の技術者に置きかえてみると、テスト技術はQCの一部となるでしょうし、テストの活動や結果はQAの一部となるでしょう。いずれにせよ、QCやQAはテストよりも広い概念だということが分かります。

一方で、TQMは元々TQCと呼ばれていたことからも分かるように、日本でのQCは手法や要素だけでなく品質マネジメント全体を穏やかに意味しています。誤解本には以下のように書かれています。

「日本は相当早い時期に、品質管理をずっと広い概念と受け止め、QCという用語を、ISO9000でいうQMと同じような意味で使っていました。」

日本的QAと欧米的QA

ここまで紹介してきたISO9000の世界でのQAの概念は、欧米の話であり、ソフトウェアやITではない産業の話です。ざっくりとISO9000のQAを「契約型の狭いQA」、日本におけるQAを「実質型の広いQA」と呼ぶとしましょう。

私には、アジャイル開発の普及という契約型から実質型へのシフトに伴って、欧米でのQAの意味も契約型の狭いQAから実質型の広いQAにシフトしてきたように感じます。特にアジャイル開発では、切り分けられた単一の仕事しかしないし興味のない単能工型エンジニアスタイルではなく、全ての仕事に興味を持ち関わっていく多能工型エンジニアスタイルが推奨されますので、より相性のよい定義になった気がしています。とはいえ、現場がアジャイル開発を行っていても企業や産業がミッションクリティカルだと、契約型のQAも重要な位置づけになります。その場合はきっと、2種類のQAを別の職種として分けた方がいいでしょう。

文化や産業構造と職種の関係

職種定義というのはその企業や産業の事情のみで決まるものではなく、その国の文化を反映します。文化というのは大げさですかね。雇用慣行と呼びましょうか。

日本では入社前のインターンシップはまだまだ盛んではなく、新卒一括採用で総合職や技術職といった大まかな職務記述が一般的です。そのため、多能工型エンジニアリングスタイルが馴染みやすい雇用慣行であり、大学での教育も割とそれに対応して広めに教えるようになっています。大括り入試と呼びますが、細かく学科やコース、プログラムといった単位で入試をするのではなく、大まかに学部や類、系といった単位で入試をしておき、入学後に色々勉強しながら専門を決めていく、という方針をお役所が打ち出したりしています。要するに、日本人は自分の専門に関して柔軟な気がしています。

すると、日本人は狭いQAよりも広いQAに向いているということになります。言い換えると、決められたことだけを行うのを推奨されるのではなく、品質や組織能力の向上などといった目的を達成するために必要なことは全て行うのを推奨されやすい文化であると言えます。でも本当でしょうか?

バブル期を過ぎてからの日本は、なかなかに悲惨な道を歩んできました。特に景気の減退に伴う経営状態の悪化によって、派遣化や外注化が進められました。ソフトウェア開発の世界では、プロジェクトマネジメントブームの到来やオフショア開発のブームがありました。これらは単能工型の狭いスタイルを強制することによって単価や賃金を下げるという目的に利用されました。言い換えると、多能工型の広いスタイルは正社員や一次請けが担うというものです。さぁ2021年の現在、こうしたやり方はどういう結末を迎えたでしょうか。皆さんもご存じの通り、少なくともソフトウェアやITの世界の多くの企業では、単能工型の狭いスタイルを強制すると一時的にコストが下がるものの、目的を達成するために必要なことをする人が組織に減って組織能力が低くなり、技術的負債が増えて、競争力がガタ落ちしたわけです(もちろん上手にやった組織もあるにはあるでしょう)。要するに、苦手なことを強制して能力を落としてきたと言えます。そのアンチテーゼとして、アジャイル開発や内製化、開発組織統合などが現在ブームになっているわけですね。そしてQAエンジニアも、なんと欧米から、シフトレフトなど広いQAをしなさいよと言われてしまっているわけです。

さて皆さんはこうした背景の中で、自分のキャリアを狭いQAに限定しますか?それとも広いQAを目指しますか?

QAとQCとQM

先ほどQA(品質保証)とQC(品質管理)とQM(品質マネジメント)という用語が出てきました。そしてQAエンジニアという職種も出てきました。また私たちの業界ではテスターやテストエンジニアという名前でも呼ばれています。どう呼ぶのは適切なのでしょうか?

まず自分のキャリアを広いものにすると仮定しましょう。日本ではQCエンジニアと呼んでも構わないと思います。しかし欧米ではQCエンジニアと呼んでしまうと、手法や要素しか意味しなくなってしまう可能性がありますから、QCはボツ。

QAエンジニアはどうでしょう。日本的な意味であれば問題ありません。しかし欧米では、本当は、品質方針の策定にも品質計画の立案にも改善にも携わらない意味になる可能性があります。確かにソフトウェアテストの国際規格であるISO/IEC/IEEE29119シリーズには(現在のところ)品質方針の策定や品質計画の立案、改善に関する記述はありません。ですから、本来はボツ。

では最も広く捉えるのであれば、QMエンジニアと呼ぶのがよいことになります。しかしこの頭文字を展開してカタカナで書いてみましょう。品質マネジメントエンジニア…。なんだか違和感がありませんか?

エンジニアリングとマネジメント

その違和感の正体は、日本ではエンジニアリングとマネジメントが対立概念として捉えられてきたという歴史にあると思っています。エンジニアは技術者でマネジャーは管理職。モノをつくるのはエンジニアで、人を回すのが管理職。生涯現場一筋のように出世に興味がないのがエンジニアで、出世していくのがマネジャー。ひどい産業では、エンジニアは理系でマネジャーは文系。ここまでひどくないにしても、まぁこんな感じのイメージがありますよね。

でも本当は、エンジニアリングとマネジメントは対立概念ではないんです。TQC/TQMではそこを整理するために「固有技術」と「管理技術」という呼び分けをしてきました。対立概念を持つ人たちは管理が上手であることを人間性やセンスに帰着させたり、コツと呼んだりしていますね。しかし(TQC/TQMに携わる人たちの多くが理系っぽいこともあるでしょうが)、管理を上手に行うにはそれ相応の技術が必要なんです。

その「技術」は確かに物理化学法則とは関係ありませんし数式でも表しにくいものですが、組織構成などに依存はするものの、ものごとを上手に行う再現可能で一般化可能なことの体系です。もうこうなると技術の定義の話になりますので、これ以上踏み込まないことにしますが、例えばプロジェクトマネジメントで使われるPERT図やアジャイル開発でのバーンダウンチャートなどは、管理のための技術として分かりやすいと思います。

誤解本にはこう書いてあります。
「効果的・効率的な目的達成のためには、その分野に固有の専門知識・技能とともに、それらを組織的に活用するための方法論としてのマネジメントが重要である。…固有技術にあたるエンジンや駆動輪と、管理技術にあたるステアリング、ブレーキ、アクセルなどの車両制御の両方の機能がなければ、車はまともには動きません。」

つまりQMエンジニアとは、品質に関する管理技術を用いて(固有技術を最大限に活用し向上させ続けることによって)お客様が安心して使っていただけるような製品・サービスを提供するためのすべての活動を行う人、ということになります。ふむ、悪くありません。

では開発エンジニアとはどのように定義されるでしょう。それは固有技術を用いてお客様が安心して使っていただけるような製品・サービスを提供するためのすべての活動を行う人、となります。まぁただ、ある産業における固有技術と管理技術の境界線は、他の産業でも同じとは限りませんし、境界線そのものも曖昧だったりします(境界線を明確にしようとするスタンスが「広いQA」とは相容れません)。

エンジアリングマインド

ではQMエンジニアでいいじゃないか、という考え方は確かに成立します。私はこれも嫌いではありません。しかし2021年現在のソフトウェアやITの世界では、少し異なる事情があります。それはDX(デジタルトランスフォーメーション)です。もう少し平たく言うと、開発の自動化・自律化です。

DevOpsやCI/CDという言葉は既に一般的になりました。知らない人はいないでしょう。テストの自動化も話題ですし、自動化の先にはAIを使って自律的にテストしていくという話題も出ています。開発に関しては、自動デバッグや自動プログラミングといった話もチラホラ聞こえてきます。つまり2021年現在のソフトウェアやITの世界の課題やブームは、自動化や自律化です。

テストは開発に比べて「受けの技術」です。テストだけで一から十までやり方を決めることはできず、色々なことが開発に依存します。そのため柔軟性が必要で、自動化があまり発展してきませんでした。しかしスピードが重視される世界に突入して、人力のテストでは間に合わなくなってきて、自動化が急速に必要になってきました。

この人力のテストと自動化されたテストとの間に、2021年現在の日本のソフトウェアやITの開発やQAの現場では、まだまだギャップがあります。私たちは現在、そのギャップを一生懸命埋めなくてはなりません。そのために必要なマインドセットが、エンジニアリングマインドです。これはどうも一般的な用語ではないですが、要するに「機械にやらせられることは全部機械にやらせて、人間は人間にしかできない創造的な仕事をしよう」という考え方です。そしてそのサブセットには、機械にやらせるために必要な考え方がぶら下がります。例えばLarry Wallの「プログラマの三大美徳」などですね。

ややこしいのは、自動化によって「管理技術に関する固有技術」が生まれたってことです。まぁでもこの辺は、テスト技術が固有技術に含まれるってことも含めて、また場を改めて議論します。

さて、エンジニアリングマインドを阻害するのが「安いから人間にやらせよう(i.e. 安い第三者検証会社に発注しよう)」「バラバラで面倒だから人間にやらせよう」「とりあえず納期があるからここは人間にやらせてしまおう」などの木こりマインドです。木こりというのはもうご存じですね。木こりのジレンマという逸話に出てくる、なまくらな斧を研がずにずっと無駄な仕事を長時間し続ける人です。

ソフトウェアやITの世界では、ここ20年ほど単能工型の狭いスタイルを強制することによって単価や賃金を下げてきました。その時に活躍するのは、エンジニアリングマインドの無い、管理技術を身につけておらず固有技術への敬意も無い、品質意識にはほど遠い、クソ管理職です。彼らにはエンジニアリングマインドはカケラもありません。しかし彼らは管理職であり「マネジャー」などと呼ばれています。

そうです。日本では木こりマインドとマネジメントが混同されている現場が数多くあり、エンジニアリングマインドの普及や浸透の邪魔になっています。そうした現場で「品質マネジメントエンジニア」という呼び方をしてしまうと、品質+木こりマインド+エンジニアリングマインドという矛盾した印象を与えてしまいかねないのです。というわけで、QMエンジニアはボツ。そしてQxマネジャーは全てボツ。

テスターとテストエンジニア

私は大学を卒業してから数年、小さな第三者検証会社に在籍していました。その会社は、他の会社の下請けを色々とやっており、とても低単価な仕事も請けていました。そうした仕事に携わる人たちは、高い技術を持っていたとしても、蔑みを込めてテスターと呼ばれていたりしました。他には、テスターさん、外注(呼び捨て・さん付け)、派遣さん、協力会社さん、パートナーさん、BPさん(ビジネスパートナーの略)など色々呼ばれていましたが、少なくない現場で開発よりも下に見られていました。

そうした会社では、低単価のためロクに技術教育もされず、新しい技術に触れる機会もほとんどなく、常駐先にずっといて自社にほとんど戻らず、単純作業のテスト実行やCPM法によるテストケース増殖しかさせてもらえず、一度テスターになったらもう開発には戻れないとキャリアに絶望している人たちがいました。今でもいるかもしれません。私は彼(女)らに、自分はテストエンジニアだと、エンジニアだと、技術者だと誇りを持って欲しいですし、そうした会社には彼(女)らをエンジニアとして処遇するようになって欲しいと考えています。そもそもそういう会社の経営者はテスト技術に敬意が無く、軽作業派遣と同様だと思っていたりしますしね。

なので私はずっと一貫して「テストエンジニア」と呼んできました。これは私の闘争です。VSTePがダイアグラムを使うのもその一部です。Excelだけだとエンジニアっぽくないですからね(偏見)。ですから、最近では「海外ではテスターと呼んでいるからテスターでいいじゃないか」と主張するキラキラしたWeb系のテストエンジニアさんがいらっしゃいますが、キラキラしてていいなぁ、と思います。まぁそんなわけで、個人的な闘争として、テスターとは呼びたくないなぁ、と感じています。これはあくまで私の個人的な闘争の話なので、木こりマインドに満ちている第三者検証会社さんやその卒業生の皆さんには同意してもらえると思いますが、他の人に強制しようとは思いません。

でも、テスターちゃんは、テストエンジニアちゃん、だとなんか変ですね。私の記憶にあるテスターという嫌な響きを洗い流してくれるという意味でも、テスターちゃんは本当に素晴らしい作品だと思います。

では何と呼べばいいの?

テスターとテストエンジニアという呼称は、狭い印象を与えてしまうのでイマイチ。QCとQAとQMだとQM > QA > QC。マネジメントやマネジャーという用語が入ると、エンジニアリングマインドが強調されにくい。

というわけで、結局LTと同じ結論になりますが、品質エンジニア(QE)という呼称はあり寄りのありかな、と思います。次点はQMエンジニアですかね。決して略語を展開しないこと。

ただし大事なことは、品質エンジニアの職務は実質型の広いQAであり、仕様や契約にかかわらず、とにかく徹底的にお客様(組織)を満足させようとする、という意識です。QM全体が職務だと認識することです。そして、木こりマインドを見つけたらエンジニアリングマインドを浸透しようとすることです。

また品質エンジニアと呼べば何でも解決できるわけではありません。SEA-SIGSQAでは、評価方面と自動化方面と組織能力向上方面とで分けるといいよね、と言っていますが、品質エンジニアのミッションや職務を定義し、見直し続けることです。そしてプロセス改善担当やISO26262担当のように、もし自組織に昔から品質に関係する職務があれば、それらを含めてきちんと整理して、広いQAを指向してもらうようにすることです。

そうすれば、必ず皆さんの組織の品質は持続的に向上していきます。頑張りましょう!

VSTeP

おねだり ~オープンソースのテスト観点図エディタを一緒につくりませんか?~・ソフトウェアテストアドベントカレンダー 2019/12/21編

にし やすはる

この記事は「ソフトウェアテスト Advent Calendar 2019」の21日目の記事です。20日目の@tomohiro_odanさんからバトンを受け取りました。

Advent Calendarってものは普通、クリスマスまで毎日カレンダーの小窓を開けると何かもらえるものです。したがいましてこの小窓記事も何か差し上げないといけません。しかし私は皆さんに差し上げるものなんて何もありませんので、コンセプトを変えて、皆さんにおねだりをしようと思います。

皆さんはソフトウェアテストで何が欲しいですか?便利なツール、難しくないのに強力なテスト技法、短時間でテスト戦略やテスト計画を作る方法、テストチームをマネジメントするコツ、テストについて理解が深い上司や開発。そんな皆さんは、 ソフトウェアテスト Advent Calendar 2019ソフトウェアテストの小ネタAdvent Calendar 2019の小窓を開けましょう。色々と手に入ります。よかったね!

僕はテストをする時に、VSTePという割とマイナーな方法論を使っているので、テスト観点図というツリー状の図を描くことになります。自分で描く時はXMindを使います。入力しやすいし、見栄えがよいのですよ。ただ凝った使い方をしようとすると、有償の機能を使わなきゃいけない。自分で描く時は購入しているので問題ないのですが、他人に勧める時にはちと気が引ける。そんな時はFreeMindがよいですね。無料だし、日本語も使える。ただちょっと見栄えがあまりよくない。まぁでも単にテスト観点図を描くだけなら、別に問題にはなりません。

しかしXMindもFreeMindも普通はGUIで描きます。でもPlantUMLのようにテキストで描くのもカッコいいですよね。まぁXMindやFreeMindのファイルをXMLで書けばいいんですが、それもねぇ。

もちろんastah*Enterprise Architectでいいじゃんという考え方もあります。僕もastah*やEAのユーザさんにはそれらを使うよう勧めています。でもQAやテストの組織の導入率って低いのよね。理想的にはastah*やEAでテスト観点図を描いてUML Testing Profileに準拠したテストのモデリングを行い、開発でつくった様々なUMLのダイアグラムと連動するのがよいのですが、なかなか道のりは遠い。

既存のツールの最大の問題点は、連携性です。FreeMindやXMindは統合開発環境ではありません。astah*やEAはそれに近いですが、様々な連携はそれぞれのベンダさん頼みです。なぜ連携性が重要なのでしょうか。

VSTePの理想的な使い方は、テスト要求分析でテスト観点図を描いてきちんとモデリングしたり、テストアーキテクチャ設計でテストコンテナ図を描いてきちんとモデリングするだけではありません(もちろんモデリングは大事ですよ!)。VSTePの醍醐味は、Fully-automated VSTeP(FaVSTeP)です。この資料のp.88に書いてあるやつですね。要するに、テストの自動設計と自動実行ができるVSTePのことです。

FaVSTePを行うためには、テスト観点図やテストコンテナ図と、仕様書や設計書、ソースコードなどの開発情報、テスト自動設計(モデルベースドテスト)のツール、テスト自動実行のツール(Seleniumなど)、テストマネジメントツールなどが連携しなくてはなりません。MBD(モデルベース開発)やMDD(モデル駆動開発)、E2Eも含めたCI/CDに既に取り組んでいる組織では、それほど突飛な話ではないことが想像できると思いますし、開発だけをモデルベースにしてQAを人力でやるというのはナンセンスだと考えているはずです。実際に僕らは、ある組織でUFTを使ってFaVSTePを実現させました。ある国のある組織では、連携するツールを内製して実現させています。devOpsやAI/MLのQAをきちんと行うにはFEET(Frequent, Entire and Exhaustive Test:テスト対象全体を全て頻繁にテストすること)が必要になりますから、こうしたFully-automatedなテストに取り組まねばなりません。

もちろんこうしたツールは、astah*やEAと一緒に動作するのがよいわけですが、まぁベンダさんとしては「それを作るとどんだけ売れるの?」という問いに定量的かつ確定的に答えられないと開発投資を行えません。慈善事業じゃありませんから。彼らは何も悪くありません。

じゃあどうする。パンが無ければケーキを食べればいいじゃないというマリーアントワネットメソッドを用いると、自分たちでつくってしまえばいいわけです。別にマリーアントワネットは自分でケーキを作ろうとしたわけじゃありませんが、まぁ細かいことは気にしない。オープンソースで自分で作ればいいのです。しかし僕にはピアノが無い。君に聴かせる腕も無い。心はいつでも半開きなんです。残念ながら僕は開発がド下手。自分で作ると数万年かかる。

というわけで、作ってもらいました。おっと慌てないで。作ってもらったのは、テスト観点図エディタのコアのコアだけ。今すぐFreeMindやXMindの代わりにもなりませんし、astah*やEAと連携してもくれませんし、テストケースを自動生成して自動実行してもくれません。がっかりした?いやいや思い出して。この記事のタイトルを。この記事は、僕が皆さんにおねだりするのがテーマなんだよ。

このツールには、名前はまだありません。仮にOpen NGT Editorとでも呼びましょうか。略して仮ONE。仮ONEは、Eclipse Cheの上で動作します。最終的に仮ONEはFaVSTeP全体をカバーするように進化して欲しいわけなんですが、エディタや描画エンジンまで自分たちで開発するのは重複投資です。ここはオープンソースの強みを活かして、既存の環境の上に乗せてしまいましょう。そこでEclipseですよ。しかも今はブラウザベースで動くEclipse Cheがあるときた。これに乗らない手はありません。しかもEclipseはモデリングツールとしても機能するわけですからね。至れり尽くせり。というわけで、以前からお話ししていた合同会社もなみ屋さんの代表社員である@monamour555さん(邑中雅樹さん)にお願いして、つくって頂きました。Eclipse Cheの情報をさがすと必ず邑中さんに行き着くはずです。凄腕。Eclipse Cheと関係なく凄腕。ぜひ皆さん、何か高額だけど凄腕が必要な開発案件があったら、依頼してみてください。後悔しません。

仮ONEのスクショはこちらです。

(仮)Open NGT Editorの動作画面

この(仮)Open NGT Editorはまだどんなライセンスかも決まっていませんが、オープンソースにすることは決まっています(最初からその趣旨でお願いしてます)。インターフェースを公開してさまざまなツールと連携していく予定です。

というわけで本題のおねだりなんですが、一緒にこの仮ONEをつくってくれる仲間を募集します。一緒につくってくれるどころか、勝手にどんどんやっちゃっていいです。そして僕に、オープンソースプロジェクトについて教えてください。お願いします。

また類似のツールや連携先のツールを既に商用で作ってらっしゃる企業さんとも、インターフェースを共通化して相互連携できるようにしようね、なんて話もしてます。テストを提供する企業さんや自社でテストを行っている企業さんは仕事で使えますので、投資も大歓迎です。自社で全部作るよりも遙かに安い投資で、テスト観点図エディタが手に入りますし、そのうちテストケースの自動生成や自動実行とも連携してくれます。

というわけで、仮ONEを入口にしてどんどん広がっていくFaVSTePの世界に興味がある方は、ぜひ@YasuharuNishiまでメンションやDMをお願いします。きっと楽しいぞ~。

以上、アドベントカレンダーの趣旨を全く理解していない、おねだりでした。明日は@mty_mnoさんの、ちゃんとした記事です。お楽しみに!

VSTeP

モデルと作戦盤・ソフトウェアテストアドベントカレンダー 2018/12/23編

にし やすはる

この記事は「ソフトウェアテスト Advent Calendar 2018」の23日目記事です。22日目の@mty_mnoさんからバトンを受け取りました。

実はこの記事、姉妹編の「ソフトウェアテスト #2 Advent Calendar 2018」がまだスカスカだった頃に埋め草で書いたものなんです。ところが、書いたらすぐにドシドシみんな登録し始めましてね、あれよあれよという間に全日登録されてしまったわけです。まぁそれならそれで業界の健全な発展を考えると素晴らしいことでしかないため、オレのクソみたいな埋め草なんぞは闇に葬ろうと思ったわけですよ。

そしたらWordPressの設定を間違えて一般公開にしてしまい、間の悪いことに@akiyama924がそれを偶然読んでツイートしやがったことによって、存在が知られることになりました。もちろん即非公開にしたけど時すでに遅し。だって埋め草のクソ記事だぜ。そしたらソフトウェアテスト界のガンジーこと@ToshiManaPlus1から載せろとのリクエスト。ガンジー物好きだなオイ。

そうこうしてる間に#1も#2も小ネタも完売したので放っておいたら、アインパメちゃんがリザーブしてた#1の12/23分を頂けることになったので、お恥ずかしながら載せてみるか、と思うに至る。なんか今年も力作が多いので、箸休めにどーでもいい記事が一つくらい載っていてもいいかな、と思った次第。書き直そうかな、とも思ったんだけど、そのまま載せることにした。しかも@akiyama924が内容を読んだ上で「Hほげほげ法は作戦盤じゃなくて手順書」とツイートしやがったので、いつか決着を付けねばならぬは人のなさぬなりけり。

まぁそんなわけで、21世紀になって目にすることも珍しい阿部寛ばりの<hr>タグの先に埋め草をそのまま載せておきますので、連休がヒマでヒマでしょうがない人は鼻クソでもほじりながら読んでやってくださいませ。 m(_)m

23日目のアドベントカレンダーはテストラジオのパーソナリティで有名な@okauchiwaniさんです。お楽しみに!


モデルと作戦盤・ソフトウェアテストアドベントカレンダー#2 2018/12/某日編の草稿

にし やすはる

テストやQAは一般に、WordやExcelで何か手順書を書くものという相場があるらしい。試しに、皆さんの組織で用いられる手順書や社内標準、過去の成果物などをチェックしてみてほしい。.doc(x)や.xls(x)という拡張子のはずだ。まぁ皆さんが「TDDこそテストであるキリッ」と主張されるのであればその限りではないが、別にこの後の議論は拡張子が.cでも.cppでも.javaでも.pyでも、何ならCOBOLでもアセンブラでも同じである。何が同じかというと、それらを書く際に多分モデルのようなものは描かないだろう、という点において同じである。オレはModel-based testingのプロだからモデル描いてるぜ、という方も、話の骨子は似たようなものだったりするので途中を飛ばしても構わないから結論から読むとよいだろう。

手順書というのはなかなか罪作りな奴で、二つの意味で皆さんの心を捉えて離さない。一つは、手順書があるとそれに洩れなく従いたくなるという気持ちが発生する。洩れ?漏れ?モレ?初めてこの「洩れ」という感じを使ってみたが、漏れよりも洩れの方がモレが少ない感じがして、一生懸命頑張ったのにそれでもモレてしまったという悲しさを引き起こしている感じがして大嫌い。まぁそんなことどうでもいいや。空いてるアドベントカレンダーを埋めたくなったという理由を隠れ蓑に、実はやらなきゃならない仕事から海外出張先のオーストラリアで逃避するという最悪の心理的危険を、珍しく技術的にあんまり内容が濃いわけじゃないエモい文章を書くことで見ないようにしているだけだからな。砂漠で天敵が来たら頭だけ隠すラクダみたいなもん。こんなことしてると確実に木曜日にStuart Reidにコロサレルけど、一度書き始めてしまったので使命感も逃避行動に拍車をかけている。これがポジティブフィードバックという奴か。心は超ネガティブなのにな。どうでもいいけどコロサレルってエルサレムに似てる。そう書くと何だか深遠に見えるから不思議だ。

第2段落から脱線とは先が思いやられる。でも別にいい。速攻で埋まったソフトウェアテストアドベントカレンダー本体を尻目に一向に埋まらないアドベントカレンダー#2の哀しみを分かち合って、誰も書く人がいない日が訪れる地球最後の日的な恐怖をほんの少し先送りするだけの文章だからだ。というよりも、現実逃避で書き始めた文章から現実逃避しているという再帰的現実逃避を皆さんは目の当たりにしている。こんなクズなかなかいないから、こんなクソ文章を読む機会もなかなかない。皆さん運がいい。クソ忙しい年末の貴重な時間をムダにしているのだから。

何の話だっけ。そうそう、手順書が罪作りだって話。手順書があると従いたくなる。皆さんの心の中に潜むマゾヒスト性、もしくは被緊縛願望を刺激するわけだ。手順書に従う度に、なんだか縄目がちょっとずつ肌に食い込んでくるような、痛いような抱きしめられているような、抗いたいような安心するような、そんな捕まった女潜入捜査官のような気持ちになる。共感したかい?共感した人はAVの見過ぎだから、今すぐ動画サイトのサブスクリプションを解除しよう。そしてもう一つの意味で手順書が皆さんの心を捉えて離さないのは、皆さんの心の中に潜むサディズム性、もしくは緊縛願望。手順書の項目を一つ一つ書きながら、なんだか心の中の肉奴隷に一周ずつ縄をかけて絞り上げていくような、支配欲を満たすような背徳感を感じてしまうような、縄に力を込める自分の手の痛みを通して相手の肌の痛みを感じ取ってしまうような、そんな女潜入捜査官を捕まえた麻薬王のような気持ちになる。共感したかい?共感した人はAVの(以下略)。

手順書は奴隷を作るが、安心も与える。自分が何か他に頼る対象を持っている時、もしくは自分自身を頼れる時は、奴隷は手順書から逃れようとする。しかし自分が何も他に頼る対象を持っていない時、奴隷は信者に変わる。この世に何か唯一絶対の正解があってそれに従っていると幸せになるのであれば、それに従いたくなるのが人間というものではないか。例えその正解が他人を不幸に陥れるものであったとしても。

テストやQAを生業とする人は、どうも暗黙的にこのことを知っているのだろう。だからすぐに手順書を作ろうとする。手順書を作るという行為にすがり、作った手順書にすがる。そして他人である開発者にもすがることを強制する。なぜならそれは、宗教だからだ。もし開発者がすがることを拒否したらどうなるか。自分が信じるものを冒涜したものとして徹底的に攻撃すると同時に、もしかしたら自分自身を頼れる強い心を持つものに激しく嫉妬する。そして頑なになり、意固地になり、周囲もろとも煉獄の業火で焼かれてしまう。残るものは灰だけである。

手順書には、手順書を作る手順書がある。手順書を作る手順書のことを方法論と呼んだりする。方法論と聞くと何だか難しそうだが、どうということはない。手順書を作る手順書に過ぎない。もっとも方法論を構築した人は例外なく手順書と呼ばれることを嫌がるけどな。ともあれ方法論は、手順書としてのカッチリさ(方法論としての決定性)の多少はあれど、手順書と同じ性質を備えている。どんな性質かって?分からない人はこのコラムを最初から読むがいいわオホホホホ肉奴隷めピシッ。従うと安心する、という特性である。

世の中にはモデルを用いる様々な方法論がある。開発方法論はあまた星の数ほどあろう。テストでは手前味噌ながらNGT/VSTeP。システム安全性であればSTAMP/STPAなどがそれにあたる。ちなみにソフトウェア安全性という用語を使う人がいるが、ソフトウェアは物理的実体を持たないので人を殺したり怪我させたりしない。よってソフトウェア安全性という言葉は論理矛盾を起こしている。ソフトウェアがシステムのごく一部のふるまいしか担っていないのであれば、機構部位で安全性は担保できる。したがって厳密に使う時は、ソフトウェアが多くのふるまいを規定するシステムの安全性、と言うべきだよワトソン君覚えておきたまえ。NGT/VSTePではテスト観点図、STAMP/STPAではコントロール構造図といったモデルを用いる。しかしcontrol structureってすっげぇ一般的な英語だよな。ワープロに"Word"って付けちゃうくらいのオレオレセンス。日本人はそのオレオレセンスを微妙に回避するために、一般的用語としてはきっと制御構造となるところを、カタカナにして固有名詞っぽくするカウンターセンスを存分に発揮する。だからコントロールストラクチャー。チャーだぞチャー。ストラクチャじゃないんだぞ。IPAという雲の上の国の組織がチャーって言ってんだからチャー。ランチアストラトスじゃなくてチャー。日本で一番ギターが上手い人チャー。ちなみに二番目はゴンチチな。(諸説あり)

日本人のカウンターセンスは嫌いではないが、このコラムではあんまりチャーの話を続けたくないので折衷案を採用する。STAMP/STPAのコントロール構造図では制御関係やガイドワードが、NGT/VSTePではテスト観点という概念の抽象具体関係が、それぞれ描かれる。言い換えると、STAMP/STPAは制御関係やガイドワードの手順書であり、NGT/VSTePはテスト観点と抽象具体関係の手順書であると言える。提案者たちは虫酸が走るほど嫌がる表現だろうけど、真実だから仕方が無い。STAMP/STPAは手順書だぞナンシー。やーい手順書作ってやんの。どうでもいいけどナンシーって書くとシドとナンシーみたいでカッコイイな。実際のところNancy Leveson(STAMP/STPAの提唱者でMITの偉い先生)も結構パンクだけどな。カッコイイぞ。ちなみにオレに向かって「NGT/VSTePって手順書ですよね所詮」とオレの目の前で少しでも口にしやがったらその場でギッタンギッタンのバッタンバッタンにしてやるので気をつけるように。

HAZOPやFTA、FMEAなどのシステム安全性の技術を修めた人は皆STAMP/STPAの心もとなさを口にする。皆さんの周りにキラキラした目をして1オクターブ高い声で「STAMP/STPAって最高ですよね!」と尻尾を振る奴がいたら無視して構わない。もしくはこのコラムを100回音読させろ。NASAがうんちゃら米軍がどうちゃらトヨタがほにゃららと言われても、おいおいこんな雑な方法論で洩れなく安全性が確保できるのかよ、と心配になるのがまともなエンジニアである(初見ね)。同様に、Hほげほげ法やゆもふがふがメソッドなどの他のテスト方法論を修めた人は皆NGT/VSTePの自由度の高さに不安を覚える。テスト観点って何だよ定義を教えろよ。第1レベルの観点(全体像)はどう決めればいいんだよ。抽象度を落とすって何だよ。子観点は網羅できてんのかどうやったら分かるんだよ。それに比べてラルフほげほげや論理的ふがふがはオレたちに安心を与えてくれる。あんな風にできないのかこのクソ白髪コンサルがっ!みたいな。うんできないごめん。それはオレの完全なる力不足であり、他の方法論提唱者の方が優れているからに他なりません。なのでここからはSTAMP/STPAの話だけします。

この件についてNancyと話したわけじゃないから分からない。片平さんと話した時に感じた表現なんだけど合意できてるかどうかも分からない。だから正しいことを言ってるというエビデンスなんかない。これはオレのモデリングやコンサルティングの経験から感じたポエムに過ぎない。でもね多分、STAMP/STPAはあえて自由度や拡張性の高い方法論に留めていて、手順書のレベルには落とし込んでいないんだよね。やろうと思えば適用ドメインを何らか分類してかなり細かい手順書レベルまで落とし込むことはできると思う。でも大事なことは、そこじゃないってこと。「あえて」自由度や拡張性を高く保っているってこと。

そう言われると手順書信者は叫び出すと思うし暴れ出すと思うし血管ブチ切れると思う。George Boxって知ってるかな?イギリスの統計学者。時系列解析におけるモデル同定のBox-Jenkins法のBoxさんと言えば分かるね。彼はこう言ってる。"All models are wrong".そう、モデルってのは常に間違ってる、ってこと。まぁこう書くと英語厨が「それはall~not的意味だから部分否定で~」とか言い出す気がするので、受験英語大好きな人は調べてみるといい。この構文は全部否定。大事なことだからもう一度言う。モデルというのは常に間違っている。どんなモデルであっても。

数学や物理学だととても分かりやすく直感的である。モデルというのは常に近似である。Boxは1molの理想気体の状態方程式PV=RTを例にしたようだが、プラモデルだってモデルルームだってファッションモデルだって近似である。読者モデルなんてモデルのモデルすなわち近似の近似だから真実からえらい遠いところにいるぞ。しかしソフトウェアの世界ではその直感が通じない。なぜなら、モデルはプログラムすなわち実行コードを導き、コンピュータはその実行コードどおりに動くからだ。言い換えれば、モデルは正確にコンピュータの動作を写し取っている(厳密には実行コードがモデルを写し取っているんだけどね)。従ってモデルが実世界を正確に写し取らないと、コンピュータは正しく動作しない。したがってモデルが近似なんてありえない。Q.E.D.

ここって結構、理系の中でもスタンスが分かれるところなんだと思う。だからかもしれないが、アメリカの大学の情報系のカリキュラム標準では、工学的常識(ちょっと言いすぎかな)という講義がある。ひっくり返すと、情報系の学生や先生には工学的常識が欠けている傾向があるわけだ。これは情報系の先生に聞かせると確実に怒られるやつだからナイショね。

そう、モデルは近似なのだ、どんなに方法論を手順書に近づけたとしても。すなわちSTAMP/STPAにおいてどんなに詳細で膨大な手順や知識ベース、実例を作ったところで、そこから作られるモデルは近似に過ぎず、不安全な部分が必ず存在するわけだ。これは怖い。考えれば考えるほど怖い。どんなに一生懸命やっても安全を「保証」することはできないのだから。どんなに一生懸命やっても自分の関わったシステムによって誰かが怪我をしたり命を落としたりする。それは自分かもしれないし、自分の大事な誰かかもしれない。そう考えると怖くてたまらない。何かにすがらずにはいられない。

でもそんなSTAMP/STPAを盲信する程度の技術力や経験の安全技術者は、何かを「保証」するということを軽く考えすぎている。どこか遠くの救世主が考えてくれた何かに従っておけば、不安全なところを洩れなく指摘して安全を保証できるに違いない。だからその何かである手順書は細かく書いて欲しい。なぜなら、正解がないことを知ってるから。すがりたいから。ユーザに安心を提供するのではなく、自分自身が安心したいから。手順書の奴隷に成り下がっているから。そして手順書の奴隷は、自分が盲信して作った成果物を盲信することを強制する。盲信した結果を実際に見せろと迫る。エビデンスという名の踏み絵によって。

違う。違うよきっと。STAMP/STPAは手順書じゃない。あえて自由度や拡張性を高めているんだ。それはきっと、安全エンジニアを信じているから。そして「保証」という行為は結局のところ、開発エンジニアが劣った考えをする可能性よりも、安全エンジニアが優れた考えをする可能性を高めることに他ならないと分かっているからだ。安全エンジニアが劣った考えしかできなければ、どんなに厳密にトレーサビリティを確保してもSPOF(単一故障点)分析を行っても膨大なレビューやテストを行っても必ず事故は起こる。大事なことは手順書に従うことや従わせることじゃなくて、安全エンジニアに優れた考えをしてもらうことであり、その環境をつくることなんだ。

作戦盤、って知ってるかな?団体スポーツを経験した人は、どこかで目にしたことがあると思う。競技固有の白線の引かれたコートやフィールドを模した鉄板と、選手を模したマグネットのこと。試合中の作戦タイムの時に監督やコーチが作戦を指示したり、練習中に選手同士でフォーメーションを考える道具である。英語ではTactic(s) boardと言ったりCoaching boardと言うらしい。ちなみに、消える魔球が投げられる野球盤のことではない。発想が昭和だなオレ。

STAMP/STPAのコントロール構造図は、きっと作戦盤なんだと思う。監督やコーチが一方的に作戦を支持するための作戦盤じゃなくて、選手も監督もコーチもみんなで、こいつが動けば敵がこう動く、そしたらあいつはこう動けばいい、でも敵がこう動いたらどうする、あーだこーだどーだこーだとケンケンガクガク議論する作戦盤。皆が自分の考えをビジュアライズしてリアライズしてシミュレートしてエネミーにリアクションしてディスカッションをファシリテートしてトゥギャザーしようぜ的なルー大柴的な。皆が自分の考えを作戦盤の上に図示し盤上で敵味方の動きをダイナミックに検討することで、どんどん新しいアイデアが出てきて勝利の可能性の高い作戦が創られるような。そういう作戦盤なんだと思う。

モデルは常に間違っている、とするならば、作戦盤で創ったモデルもまた間違っている。そう、間違っている。それでいい。まず僕たちは、モデルは常に間違っているということを受け入れなくてはならない。そして作戦盤を使い、自分たちの知恵や発想、想像力の限りを尽くして考えなくちゃいけない。開発エンジニアが考え落としたところ、考えが及ばなかったところ、到底考えるわけがないところ、ありえないと最初から考えなかったところ、ありとあらゆるところに考え至るように議論しなくちゃいけない。安全を保証しきった自信は正直無いけれど、開発エンジニアよりも考え尽くした自信はある。そういう状態を目指さなきゃならない。

そしてもしそれでも事故が起きたなら、それはとてもとても不幸なことで、自分たちの技術力の低さを痛感し、二度とそんなことを起こさないように原因を分析して改善しなくてはならない。その話はまたいつかどこかで。

テストも同じ。手順書はモデルの一つであり、方法論だってモデルの一つである。したがって、あらゆる方法論は常に間違っているし、あらゆる手順書は常に間違っている。だから方法論にすがっちゃいけないし、手順書にすがっちゃいけない。その方法論を使って十二分に検討しきった自信は持てるのか。開発エンジニアが考え落としたところ、考えが及ばなかったところ、到底考えるわけがないところ、ありえないと最初から考えなかったところ、ありとあらゆるところに考え至るように議論したか。手順書に書かれていないところは無いか、手順書は本当に正しいのか、手順書を作る時の前提は今も成り立っているのか、いつも考えながら仕事をしなきゃいけない。これはしんどい。すがれない。気が抜けない。だからこの、高度に人間らしい仕事に集中するために、人間らしくない単純(にできる)作業は自動化しなきゃいけない。その話もまたいつかどこかで。

モデルは作戦盤。手順書は作戦盤。方法論も作戦盤。ついでに言えばプロセスも作戦盤。大事なことは、開発エンジニアより優れた考えをするために考え尽くしたという自信を持つこと。自分たちの外に正解なんか無いって思い知ること。誰かにすがっても自信は持てないって実感すること。「保証」は、結局のところ自信を持つことだってこと。

もう十分現実逃避したし、なんかこう飽きてきちゃったからもういいや。コラムっていいね。いつでも好きなときに終われるから。別に昨日からバトンをもらった覚えはないし、別に明日にバトンを渡す気はないけど、何かよいバトンが知らないうちに渡ってるといいな。あれ、埋まってる…。このまま埋まるとこのポエム公開されないぞ…。まぁいいか別に現実逃避の産物だし…。

おしまい。

VSTeP

~腕利きソフトウェアテストコンサルタントが支える優理の事件簿・アドベントカレンダー2017/12/20番外編~

著者: にし やすはる

「それはさぁ、テスト観点というよりも目的機能なんじゃないかな。いやお前の言うことは分かるよ、論理的機能構造に照らし合わせるとテストカテゴリだって言うんだろ?でもさぁ…」

年末のシアトル系コーヒーショップの簡素な丸テーブルを挟んで、若い男性が激論を交わしていた。イマドキの若者らしく、手元のPCにはこれでもかとステッカーが貼ってある。その横では、スリーブの付いた大きめの紙カップが存在を忘れられたかのごとく議論を見守っている。混みあった店内は7割がカップル。残りは意識の高そうなエンジニア。年末らしく店内にはちらほらと赤や緑の装飾が見え隠れする。フランク・シナトラが大きな歌声でクリスマスを祝っている。

親友。鳥刈は目の前の男性で口角泡を飛ばす若者をそう思っている。自分よりセンスのよい服装。自分よりセンスのよいメガネ。自分よりセンスのよい人の多そうな職場。出会ったときはボサボサの天然パーマだったが、最近はなんだかエリアーだっけ?エアリーだっけ?アリエールだっけ?そういうセンスのよい髪型になってきた。やっぱり職場環境って大事だ。いいなぁ。でも自分は彼にコンプレックスを感じることなく話ができて、議論もできる。学校も違う、会社も違う。生まれも違う。でも親友。年末に彼女とクリスマスデートなんてしなくても、こうして親友と技術の議論ができるだけで自分は幸せ者だ。そう思いながら鳥刈は目の前の「親友」との議論に没頭していた。

顔見知り。古里は目の前で要を得ない若者との関係を他人に説明できずに困っていた。住所は知らない。電話番号も知らない。年賀状もやりとりしない。学校も違う。会社も違う。生まれも違う。だから顔見知り。本名だって時々忘れてしまう。実家の親にどんな人かを根掘り葉掘り聞かれた時に答えられないのであれば、友達とは言えないのではないか。平成と昭和の狭間に生まれた自分でも、それくらいの伝統的考え方はある。でもSNSで毎日ガンガン会話をする。勉強会で毎週会って毎回呑みに行く。こうやって土日に二人で会って技術的な議論をしたり会社のグチをこぼし合う。高校のクラスメートよりもよっぽど彼のことを知っている。でも別に関係なんて他人に説明するもんでもないし、そんな機会もない。仲が良いという事実だけでいいじゃないか。それが合理的だ。そう思いながら古里は目の前の「顔見知り」との議論に没頭していた。

             ☆                  ☆

休日出勤かぁ。この業界にいるとしばしば遭遇する。自分の仕事をどんなにカンペキにこなしたとしても発生する。分かってはいるから怒らないけど、待ち合わせの夕方までどうやって時間を潰すか。水元はヒマをもてあましていた。クリスマスプレゼントは昨日買ったから商業施設巡りも必要無い。一人でラブストーリーを観てもしょうがない。お腹はそんなに減ってない。身体を動かすほどの時間はない。ないない尽くしの休日の昼下がり。コーヒーを飲むほど喉も渇いてはいないのだが、座ってヒマつぶしを考えるための場所代を払わないと行くところがない。全てが消去法で決まっていく状況。この状況を水元は好まない。そういう状況に嵌まっている現場を導くのが彼の仕事。いつのまにか消去法を嫌がる体質になってしまった。よし、書店が併設されているコーヒーショップに行こう。本を読んでもいいし、雑誌を買って物欲を増幅させてもいい。何なら久しぶりにパズルに没頭してもいい。選択肢は多いほどいい。本当のところコーヒーを飲むことと本を読むことの二つしか選択肢は無いのだが、水元は自分にそう言い聞かせると少し上機嫌でシアトル系コーヒーショップに入っていった。

コーヒーの種類、ホットかアイスか、サイズ、シロップの種類、それ以外にパラメータは何があるんだろう。エスプレッソのショットを増やせたっけ。あぁデカフェにもできたな。そう言えば自分はいつも豆乳だ。ついつい組み合わせを考えてしまうのはやはり職業病だ。年末のシアトル系コーヒーショップは賑やかで、カップルが多い。聞くとはなしに店内の会話に耳が向くと、急に頭の中のS/N比が変わった気がした。聞いたことのある声が、聞いたことのある単語を発している。誰だ…、いや誰とかじゃない。昨日会った若者だ。水元はスマートフォンの名刺アプリを開いた。鳥刈さん。そう、そんな名前。将来有望、かな?ともかく、元気な若者だった。クライアント先でいつもの担当の方がお休みだったので、代わりに質問してこられたのだ。観点の蒸留の話をしたけど、分かってくれたかな。いやいやちょっと待て。今日は休日で今はプライベートだ。仕事の話はしないぞ。しない。絶対にしない。だって今日は休日だから。休みをきちんと取らないと、よい仕事ができない。だから鳥刈さんに見つからないように店を出よう。そうだ、そうしよう。水元はその直前までコーヒーの組み合わせについて考えていた自分のことをすっかり忘れ、コーヒーを受け取るべくオレンジ色のランプの下まで大股で移動した。

             ☆                  ☆

「あ、水元さんだ。鳥刈、あの人知ってる?テストのコンサルタント。前に講演を聴いたことがあるんだ。」

古里は目ざとく、コーヒーの受取口に向かった水元を見つけた。鳥刈は聞いた名前だなと思いつつ身体をねじると、昨日親切に色々教えてくれた優しいコンサルタントさんが目に入った。知ってるとも、と誇らしげに言うが早いか、鳥刈は水元のところに向かった。

「水元さん、昨日はありがとうございました。今日はどうされたんですか?お一人ですか?もしよろしければ、一緒にいかがですか?」

あー、見つかった。水元は自分の運の悪さを呪った。なんでこの店に入っちゃったんだろう、なんでコーヒーなんか飲もうと思ったんだろう。そうだ、休日出勤なんかするからだ。でも彼女が悪いわけじゃないし。やはり運が悪いのか。朝の星占いは何位だったっけ。そうか今日は休日だから…。いやいやそんなことを考えていてもしょうがない。どうせヒマなんだ。少し世間話でもしながら、頃合いを見て場所を移そう。

「こちらこそ、昨日はありがとうございました。奇遇ですね。せっかくですので、ご一緒させて頂いてもよろしいですか?」

腕のよいコンサルタントは、休日でも優雅だ。突然なのに受け答えも優雅だ。自分はこんな凄いコンサルタントに昨日付きっきりで指導を受けたんだ。鳥刈はなんだか嬉しくなって、自分のテーブルに急いで戻って他のテーブルから余っている席を運んできた。

海老と蟹。家を出る前に耳に入ったピザのCMのせいか、反射的に水元はそう感じた。瓜実顔の鳥刈さんは海老。もう一人の初対面の同じ年の頃の若者は蟹。仕事柄出会う人が多すぎるので、こうやって何か別のものを連想すると覚えやすいという法則が身体に染みついている。水元は用意された木製の簡素な椅子に座ると、蟹の方に向かって自己紹介した。蟹が古里と名乗ったところで、鳥刈が蟹は以前天然パーマで見るからにブロッコリーのような風貌だったと口を挟んだ。余計な情報を笑顔で受け流すと水元は聞いた。

「お二人は、お友達ですか?」

「親友です」「顔見知りです」

鳥刈と古里は同時に答え、お互いの顔を見合わせた。鳥刈は驚いた顔を、古里はバツの悪そうな顔をお互いに見せた。おっとまずいな、水元は直感して言葉をつなげた。

「ある人にとって親友という仲の良さであっても、別の人にとって顔見知りと表現されることはままあることです。大事なことは、こうやって年末の休日に二人で仲良く話していることだと思いますよ。私の言葉遣いでは、お二人は『とても仲の良い友達』だと思います。合ってますか?」

古里はホッとした顔で頷いた。鳥刈は嬉しそうに何度も頷いた。

「自分の使っている言葉と他人が使っている言葉というのは、常に異なるものなんです。だからまず大事なのは、自分の理解。次に、自分が理解したものを自分はどういう言葉で表現するか。そして最後に、自分が理解したものを他人はどういう言葉で表現するか、をマッピングすることです。この順序を逆にすると痛い目に遭います。自分があまりよく理解していないうちに他人の言葉を借りて表現しようとばかりすると、余計に混乱するんですよ。そういう経験、ありません?」

水元がすっかり仕事モードで話をまとめると、二人は同時にこう叫んだ。

「そうなんです!ちょうど今それで困ってたんですよ!」

             ☆                  ☆

欧米人は何かをすする音が大嫌いだ。日本人とは違ってスープや麺も音を立てない。自分もレストランでスープを飲むときは音を立てないようにする。でもカップの蓋のこの小さい穴から熱いコーヒーを冷ますように飲むときだけは音が出てしまうのではないかな。音が出るのは一すすり目かな、それとも一すすり目と二すすり目の間かな。音が出る時の唇の上下動はどのくらいだろう。水元が集中を始める時の癖だ。周りの音が遮断され、その時気になっていることが頭を占める割合が上がっていく。視野はどんどんミニマルになる。感覚が研ぎ澄まされていく。頭の中がクリアになっていく。概念を扱うモード。問題を解決するモード。いまにも問題にダイブしようとするモード。心地よい状態遷移。

「何に困っているんですか?」

水元はミニマルな質問を投げた。

「昨日コンサルティングを受けて、その時はテスト観点について分かった気がしたんです。でも今日古里くんと話しているとやっぱり分からなくなっちゃって…。テスト観点とかテスト条件とか目的機能とか論理的機能構造とかテストカテゴリとかテストレベルとかテストタイプとか色々あるじゃないですか。話せば話すほど混乱してくるんです。分からなくなってくるんです。答えが欲しいんです。だってそうじゃないですか。答えが無いのにどうやって仕事…」

「待て、鳥刈。落ち着け。ゆっくり話そう。」

左手で鳥刈の言葉を制しながら古里は続けた。

「テスト観点って、何ですか?」

             ☆                  ☆

水元は快適な集中から一気に現実に引き戻された。鼓膜に周囲の喧噪が直接響いてくる。急に頭の中にもやがかかった。だーかーらー昨日言ったでしょ。胃の辺りから喉の上辺ギリギリまでその言葉が上がってきたが、無理矢理押し留めた。よいコンサルタントの法則、第一条。コンサルタントは迂闊に物事を判断してはならない。うん、大丈夫。落ち着け。昨日のことをきちんと思い出そう。昨日したのはテスト観点の蒸留の話だ。その時にテスト観点はテストケースの意図であるという説明を何度もしたはずだし、鳥刈さんも深く理解していたはずだ。ともあれ、もう少し詳しく聞いてみよう。

「ふむ…。よい質問ですね。もう少し詳しく教えてもらえませんか?」

鳥刈は見惚れた。ゆったりとした仕草。柔らかな微笑み。ほんのり立ち上ってくるいい香り。自分たちが散々話しても分からなかったことなのに、きっとこの人には当たり前すぎることなんだろう。自分もこんな凄い人みたいになりたいなぁ。おい奥村くん。こんなことも分かんないのか。先輩のくせに情けないぞ。毎日家に帰らずに酒ばかり飲んでいるからだ。あぁ安達部長。それはこのようにすればカンペキですよ。この部署はやはり私がいないと回りませんね。はい社長、新しいビジネスのアイデアなら…。

質問に質問で返すのか、この人信用ならないな。古里は警戒した。大体コンサルタントなんてものはインチキだって相場が決まってる。現場で手を動かす技術者の言うことじゃないと裏付けが無い。テストケースを書いて書いて書きまくった先にこそ真実があるんだ。気をつけて話をしなきゃ。向こうのペースに乗ってはいけない。百戦錬磨の営業マンなんだ。騙されちゃいけない。少し語気を強めて古里は繰り返した。

「だから、テスト観点って、何ですか?」

休日に人を突然巻き込んでおいて対話の意思を示さないのか。若さって素晴らしい。若さって傲慢だ。若さって暴力的。この若さが、彼らを成長させる原動力になると祈ろう。今は問題に集中だ。この手合いは、単純に定義を示しても納得しない。おや、昨日も同じことを思ったぞ…。

『この質問に答えはないからだ。なぜ答えがないのか。質問者は字面としてテスト観点の定義を質問してくる。しかし実のところ彼らが聞きたいのは「良い」テスト観点の挙げ方であり、それが「良い」ことの保証である。質問にまともに答えるとずいぶん哲学的な定義の話になるし、モヤモヤは消えず不承不承納得した表情をして話は終わりになる。誰も得をしない。だからといって「良い」テスト観点について答えるのも難しい。結果として得られたテスト観点の良し悪しよりも、そこに至る過程でどこまでケンケンガクガクあーでもないこーでもないと議論して、時には白熱して、そして皆が納得感を共感することが大事だからである。誰かから「良い」テスト観点をもらってきたとしても、すぐに陳腐化する。水元はそのことをよく知っているし、少なくないエネルギーを費やしたコンサルティングの成果がクライアント側で水の泡になってしまって臍を噛んだこともある。どうしたものか...。』

             ☆                  ☆

「テストケースの意図、と昨日説明した気がするんですが…。」

よいコンサルタントの法則、第二条。コンサルタントは微笑みを絶やしてはならない、クライアントにどんなに失礼なことを言われようとも。水元は88%の微笑みと10%の困惑、そして2%の叱責からなる表情で鳥刈に問いかけた。

「は、はい。それは言えます。テストケースの意図ですよね、テスト観点って。昨日たっぷり説明して頂きました。ありがとうございました。」

「いえいえこちらこそありがとうございました。そうすると、どの辺りが悩みどころですかね。人間というのは、どんなことであっても聞いてすぐ本当に理解したりはできません。ですから、そうやって悩まれているのはとても自然なことだと思いますし、より深く理解しようとしているわけなので素晴らしいと覆いますよ。古里さんとは、どの辺を議論していましたか?」

「目的機能とかテストカテゴリとか、似たようなものが色々あるじゃないですか。テスト観点との違いが分からないんです。テストタイプとかテストレベルとの違いも知りたいです。ラルフチャートとか論理的機能構造とかとの関係も興味があります!」

将来広辞苑がVRで読めるようになったらドヤ顔の項目にはこの顔が出てくるだろうな、と古里は思った。どうして質問をしているのにそんな誇らしい顔ができるんだろう。分からないことは、恥ずかしいことだ。分からないなんて他人に言いたくない。悔しい。

「分かるには分かるんすけど、なんかしっくり来ないというか。モヤモヤしてるんすよね。いや分かるんすよ。でもなんか念のため聞いておきたいというか、そういう感じっすね。」

古里の語尾の敬語が崩れてきていることを水元は聞き逃さなかった。古里の上半身がやや後傾になったことを水元は見逃さなかった。多分そんなこと思っていないんだろう、古里さんは。防御的な心理を隠すための親密さ。クライアント先への初回の訪問で現場の問題を尋ねた時の返答でよく体験する。対応を間違えるとこじれてしまう面倒くさいパターンだ。水元は細心の注意を払いながら、古里を受容するメッセージを発した。

「そうですよね。分かっているのに、分かったような分からないような、そんな感じになるのが普通です。自然ですよ。当然です。分かっているからこそ、の感想ですよね。」

ほんの刹那、息を深く吐いた。防御的態度が需要されたことの安心感だ。この人は自分を評価してくれている。古里は少し肩の力を抜いて謙遜した。

「いや分かっているなんて言われると困っちゃいますけど、鳥刈よりはマシかな、なんて思います。」

「えー、古里も分かってないと思ってたのになぁ。裏切り者。」

仲いいな。水元はいちゃいちゃし始めた若い男性の様子を懐かしく思った。自分も学生の頃はそうだったな。

「どうして違いが知りたいんですか?多分、理解したいんですよね。新しい言葉や聞き慣れない用語を聞くと、理解したくなる。自然な感情です…」

「そうですそうです。理解したいんです!」

水元が言い終わる前に、鳥刈は縦に大きく首を振りながら言葉をかぶせてきた。

「分かった分かった、落ち着け鳥刈。」

古里は左手で鳥刈を制しながら、まなざしで水元に続きを促した。あまりにもスムーズな二人の掛け合いは既に伝統芸能だ。

「でもそれは、あまり役に立ちません。知識をたくさん仕入れて他人に自慢したいのであれば別ですが。お二人は、自慢するために理解したいのではありませんよね?」

二人は同時に、同じ角度で同じ大きさでかぶりを振った。

「よいテスト設計をしたいんです。できれば自分の職場で、それぞれのいいとこ取りをして活用したいんです。だから、色々知りたいんです。」

古里は真面目な面持ちで答えた。これは本心だ。

「なるほど。いいとこ取り。確かに魅力的ですね。ではひとつ質問しましょう。和食と中華とフレンチのいいとこ取りをして新しい料理を生み出せるのは、どんなシェフでしょう。和食も中華もフレンチも、どの料理も作ったことの無いシェフですかね?そんなわけはありません。まずどれか一つに精通した上で残りを学んでいくからこそ、いいとこ取りができるわけです。どれも中途半端であれば、できるのは単にレトルトを混ぜ合わせただけの紛い物です。」

「レトルトの混ぜ合わせですか…。それは嫌ですね。せっかくだったら本物を作りたい。」

「嫌です嫌ですレトルトなんて。僕レトルト苦手なんですよ。インスタントもあんまり得意じゃないんです。油っぽいし。」

「鳥刈、それはちょっと違う話かな。ちゃんと水元さんの話を聞けよ。」

古里は苦笑しながら続けた。

「ということは、違いを知りたいのは意味が無いということですか?」

「それぞれの定義を字面で比較したところで、よいテスト設計にはつながりません。でもそれぞれのテスト設計の方法論を活用した上で、それぞれの弱点を他の方法論で補完できれば、よいテスト設計につながりますね。そういう意味です。」

「じゃあどの方法論から始めればいいですか?」

鳥刈はポジティブでアクティブだなぁ。あいつは安直だからもっとよく考えるべきだ、なんて批判する人もいるが、色んなことを考えすぎてつい後手に回ってしまう自分には足りないところだ。素直に見習わなきゃ。古里は心の中で敬意を表しながら、水元の答えに耳を傾けた。

「好みです。どれでもいいんですよ。ただ大事なことは、方法論を学ぶだけで終わらずに、必ずテスト設計をしてみること。何度か繰り返してコツを掴み、自分の最初のテスト設計とコツを掴んだ後のテスト設計とをレビューして比較して、どの辺が成長したのかを読み取るといいですね。お二人のように、友達同士で比較してもいいでしょう。もちろん、その方法論を使う前と、使ってみてコツを掴んだ後とで比べても構いません。成長したところが、きっと、その方法論の得意なところです。」

「古里、やろうよ。」「面白そうだね、鳥刈。」

             ☆                  ☆

「例えばテスト観点を使う方法論の場合、最初は機能ばかり挙がります。いわゆる非機能は申し訳程度にしか挙がりません。」

「そういうテスト観点リストを配っているサイトもありますね。」

「でも最初はそれでいいんです。そういうテスト観点図を描いたら、次に自分でレビューしてみましょう。作ったテスト観点図だけを見ていてもよく分かりませんから、『もしテスト観点図を使わないとどんなテスト設計をするか』と想像してレビューするとたくさん問題点を見つけられます。例えばお二人なら、どんな風にそういうテスト観点図を成長させますか?」

「SQuaREシリーズで品質特性を網羅します!ISOで決められた国際規格ですから、それを使えばバッチリですよ!」

鳥刈の眼が輝いた。勉強の成果を活かせる場面が来た。たくさん勉強したんだ。でも会社の人たちは理解してくれない。奥村先輩なんていつも「鳥刈、勉強だけじゃダメなんだぞ」とか言って呑んでばかりいる。でも違う。僕が正しいんだ。勉強したことを実務で活かすんだ。

「SQuaREを参考にするのはよいことですね。でも気をつけないといけないのは、SQuaREも他の国際規格も完璧なものは無いですし、きちんと意味を理解して使わないといけないという点です。国際規格だから網羅されている、というのは正しくありません。国際規格は議論と投票で決まりますからね。」

鳥刈の目が泳いだ。水元は気にせず続けた。

「SQuaREの製品品質では主に外部から観測できる品質特性を扱っていますので、性能やセキュリティといったテスト対象の“ふるまい”を評価したいという意図のテスト観点を挙げる時に便利です。期待結果をしっかり考慮してテスト設計したい時にも、私は品質特性と一緒に“ふるまい”としてテスト観点を挙げますね。」

             ☆                  ☆

「性能テストと負荷テストって、どう考えたらいいですか?」

古里は尋ねた。

「よい質問ですね。例えば性能テストの時には、負荷をかけた時の性能低下を検出したいことがあります。でも負荷をかけない通常時の性能を測定したいこともあります。負荷テストの時にも、負荷をかけた時の性能低下を検出したいことがあります。負荷をかけてシステムがダウンしてしまうかどうかだけをテストしたいこともあります。」

「なんだかこんがらがってきました。」

「そうなんです。“~テスト”というようにくくってしまうと、一体どんな意図でテストしているのかが分かりにくくなってしまいますね。“~テスト”というのを一般的に、テストタイプと呼ぶのは知っていますね?そうすると、何が欲しくなりますか?」

「テストタイプとテスト観点との対応表です。どのテストタイプにどのテスト観点が含まれているのか、を整理したいです。」

古里は勘がいい。

「そうですね。Excelが好きなら対応表でもよいでしょう。モデリングツールが好きなら、包含関係を表すモデルを描いてもいいと思います。私は“テストコンテナ図”と呼んでいます。」

「コ、コンテナ?また新しい言葉が出てきた。覚えなきゃ。定義を教えてください!」

知識欲モンスター鳥刈が食いついた。

「別に難しい話ではありませんよ。機能テストって聞いたことあります?」

「えぇ。テストレベルの一つだったりそうじゃなかったり。」

古里が答えた。

「鳥刈さん、品質特性の一つに似たようなやつありません?」

「ありますありますあります。機能適合性です。機能完全性と機能正確性と機能適切性から構成されます。」

鳥刈が誇らしげに答えた。

「一般論として、品質特性を評価するような“~テスト”はテストタイプですよね。では機能適合性を評価する“機能テスト”があったとしたら、それはテストレベルですかね?それともテストタイプですかね?」

水元の微笑みが意地悪そうなものに変わっていたことに、鳥刈と古里は気付く術も無かった。

「機能テストはテストレベルだけど、機能適合性テストはテストタイプで…」

鳥刈の顔が混乱で赤くなり、いまにも湯気が出そうになっている。古里は数学の期末テストに答えるような顔で言った。

「解けません。解が二つあります。テストレベルでもあり、テストタイプでもあります。まるでシュレーディンガーの猫ですね。」

「はい。量子力学のように存在確率の雲を定義するわけにはいきませんから、いっそのことテストレベルとテストタイプを区別するのを諦めてしまえば話は簡単になります。そこで“テストコンテナ”という新しい用語が出てくるわけです。ついでに、テストサイクルとかテストラウンドとかそういうのも含めてしまえと。テストコンテナは、テスト観点をひとまとめにしただけのものだと考えておけばよいでしょう。この話は“テストアーキテクチャ設計”につながりますので、長くなります。今日は踏み込まないでおきましょう。」

「テストアーキテクチャ!それも分からないんです。でもなんだかカッコイイですよね。テストアーキテクチャ。テストアーキテクトになってみたいんですよ、将来的には。僕のキャリアパスの一つなんです。」

いまの赤さは興奮の色のようだ。鳥刈には興奮の種が尽きない。水元の微笑みが優しさに戻った。

「テストコンテナがどんなテスト観点を含むかという情報は、普通はテスト計画書に文章で書かれます。でも文章だと抜けが出やすいですし、類似のテストプロジェクトから丸ごと流用されやすい部分でもあります。対応表なりテストコンテナ図をつくって、きちんと検討できるようにしておいた方がよいですね。」

             ☆                  ☆

「話を戻しましょう。性能はふるまいでした。では負荷はふるまいですか?」

「いいえ、負荷はふるまいじゃないですね。なんだろう、条件かな?」

古里は答えた。

「では“条件”と呼びましょう。さっき最初に作ったテスト観点図にはふるまいの他に、負荷とかタイミング、長時間稼働などといった“条件”を表すテスト観点が足りないことが分かりましたね。他にはどういう種類のテスト観点があるでしょう。鳥刈さん、お腹は減ってませんか?」

「そういえば、おなか空いてきました。古里、晩ごはん何にする?」

「肉。オレ、野菜は嫌いなんだ。特にブロッコリー。」

「お二人の献立は後でゆっくり決めて頂くとして、鳥刈さんはいまお腹が減っているという“状態”にあるわけです。異なるドメインのテストに携わると分かりますが、テスト対象を表現する方法はいくつもあります。機能で表現する方法が一番ポピュラーですかね。ソースコードやクラスといったソフトウェア構造で表現する方法も有名です。組込みでは状態遷移で表現することも多いです。制御式や通信シーケンスで表現することもあります。ハードウェアの構成やネットワークが含まれることもありますね。テストではそれぞれのテスト対象の構成要素を網羅したり、怪しい構成要素を選んだりします。つまりこういった“テスト対象”もテスト観点の一種になるわけです。」

「テスト対象の表現って、色々あるんですね。」

「テスト設計をする時に機能を考えるというのは大事なことですが、機能さえ網羅していればテストが十分なわけではありませんし、機能に頼りきったテスト設計をすると機能以外を漏らしてしまうかもしれません。」

「確かに機能と非機能という構造のテスト観点リストを見た時に、状態が色んな機能に散在していて、これで網羅できるのかなと思いました。」

「だったらむしろ、状態というコーナーを作ってまとめてしまう方が挙げやすいし、読みやすいですよね。というわけで、テスト観点にはふるまいと条件の他に、テスト対象というのも含まれることが分かってきました。ところで古里さん、ブロッコリーは嫌いなんですか?」

「えぇ。なんだか食べてるとゾワゾワしてくるんです。」

「共食い?」

「共食い言うな。」

ブロッコリーというより蟹だろう、と言いかけて水元は口をつぐんだ。よいコンサルタントの法則、第三条。コンサルタントは余計なことを言ってはならない。

「嫌なもの、って誰にもありますよね。開発でもあります。バグにつながりやすい仕様や設計。怪しいソースコード。作り込まれやすいバグのパターン。お金が失われたり怪我をしたりといった絶対に起きて欲しくないこと。こういうのを狙ってテスト設計をすることも多いですね。ならば、テスト観点として挙げましょう。」

「なるほど。探索的テストとかに役立ちそうですね。」

「ここまでで四つの種類が挙がりました。他にもありますよ。ゲームなんかですと、重課金ユーザなのかライトユーザなのか、その生活サイクルはどうか。どういうビジネスモデルで運営をするのか。つまりテスト対象の周りの“世界”に焦点を当ててテスト設計をするわけです。色々ありますね。」

「ホントです。テストって、奥が深いですね。」

古里は感心しながら言った。

「別にこのCIBFW、“条件(Condition)”、“テスト対象(test Item)”、“ふるまい(Behaviour)”、“嫌なこと(things Faulty or hazardous)”、”世界(World)”にいつも分ける必要はありません。自分がテスト設計の時に意図することを好きなだけ入れて、整理してやればいいんです。」

「好きなだけ?」

「好きなだけ。もしお二人が、目的機能を意図してテストする方法論を次に覚えたら、目的機能というテスト観点を入れて、それ以外のテスト観点やテストコンテナとの関係を整理すればいいわけです。テストカテゴリも同様です。その上で、自分が一番使いやすいテスト観点の種類のセットを馴染みの道具としていつも携えておく、と。大事なことは、特定のテスト観点群を暗記しておけば、もしくはテスト観点の定義を暗記しておけばよいテスト設計ができるわけではなくて、自分が何を意図しているかを挙げて整理して理解することです。基本的にテスト観点は具体化していくとテストケースの構成要素になりますから、テスト観点を列挙して整理して理解できればテストケースが設計しやすくなります。」

「できるかな?」

鳥刈が始めて不安そうな顔を見せた。

「できますよ。少しずつでいいんです。最初から完璧に網羅できて完璧に整理できて完璧に理解できる人はいません。自分の実力を、テスト観点とともに育てていけばいいんです。もし手がかりが欲しければ、ラルフチャートや論理的機能構造のようなシステムを抽象化したモデルを参照するとテスト観点が挙げやすくなると思います。」

「ラルフチャート、カッコイイですよね。僕もラルフになりたいです!」

そろそろ鳥刈は限界だ。外も暗くなってきた。頃合いだな。水元は付け加えた。

「あとコツは、あまり厳密になりすぎないことです。先ほどビジネスモデルはテスト観点だと言いましたが、ビジネスモデルが直接テストケースの構成要素になるというよりは、条件やユーザといった他のテスト観点を挙げるためのヒントとして使うだけかもしれません。でももしかしたら、ビジネスモデルが直接テストケースの構成要素になる場合だってあるかもしれません。ヒントなのか構成要素なのかによってテスト観点かどうかを区別する手間をかけるくらいだったら、ふんわり両方ともテスト観点だと考えておく方が気が楽ですよ。」

「ふんわり!」

二人は顔を見合わせながら叫んだ。

「ふんわり。」

水元は微笑みながら答えた。

「ふんわり?」

二人は同じ角度で同じ大きさだけ首をかしげて、再度尋ねた。

「ふんわり。どんどんテスト設計の経験を積んで厳密に考えられるようになったら、少しずつ厳密にしていけばいいと思います。テスト観点などの概念は、よいテスト設計のための道具にすぎません。道具に振り回されて混乱するのは、もったいないですよ。」

水元はスリーブを身に纏ったグランデの紙カップを右手でゆらゆらと振って、ほらコーヒーが無くなるくらい時間が経ちましたよ、と微笑んだ。古里はそれを見て慌てて言った。

「ほら鳥刈、水元さんだって予定があるんだよ。あんまりオレたちで捕まえてちゃ申し訳ないぞ。そろそろ遠慮しないと。」

「いやでも、ここから本題に入るんだよ。テストアーキテクチャ。テストアーキテクチャの話ききたい!」

左手で鳥刈を制しながら古里は頭を下げた。

「水元さん、ありがとうございました。ちょっと僕たちでよく考えて見ます。でも、とっても面白かったです。また分からなかったら教えて頂いてもいいですか?」

どうやら認めてもらったらしいな。水元は殊勝に頭を下げる古里を見ながら、こっそり胸を撫で下ろした。よいコンサルタントの法則、第四条。コンサルタントは心配を気取られてはいけない。

「もちろんです。私もお二人と議論できて、とても楽しかったですよ。ではお肉パーティ、楽しんできてください。」

自動ドアを空けて外に出る頃にはもう侃々諤々の議論を始めているエネルギーにあふれた若い二人を後に、水元はLEDが彩る街に戻った。ちょうど待ち合わせに間に合う頃合いだ。もしかしたらこの後も、似たような議論に付き合わされながらのディナーになるかもしれない。よいコンサルタントの法則、第五条。コンサルタントはクライアントとの議論を楽しまなくてはならない。たとえそれが恋人とのディナーであったとしても。

To be, or not to be continued into the main story…

VSTeP

~腕利きソフトウェアテストコンサルタントが支える優理の事件簿・アドベントカレンダー2016/12/15番外編~

著者: にし やすはる

「あ~、忙しい忙しい。やることは山ほどあるのに、時間は全然足りないよ。でも早く一人前のQAマンにならなくちゃ。頑張るぞ!」

鳥刈は誰かに聞いて欲しいわけでもなく、しかし独り言にしてはずいぶん大きな声で呟きながら会議室のセッティングをしていた。今日はいつも先輩が受けているコンサルティングを自分一人で受けられる、またとないチャンスだ。勉強ならたくさんしている。本もいくつも読んだ。いろんな勉強会に出席した。SNSでも凄い人たちと友達のように会話できる。その成果をコンサルの人に誉めてもらおう。奥村先輩はいっつも「お前は熱心なんだけどさ、ちょっと空回りなんだよなぁ...。」と苦笑するけど、あんな呑んでばっかりの人じゃ分かってくれない。優秀なコンサルなら分かってくれるはずだ。こないだだって、開発の安達部長から「期待してるよ」って声をかけてもらったんだぞ...と言わんばかりに、全く汚れていないテーブルを、頼まれてもいないのに力を込めて一生懸命拭いている。20代の若さの分だけ机がキュッキュと音を立てた。

「こんにちは。いつもお世話に...あれ?奥村さんはどうされました?」

ここのところずいぶん寒くなったのにジャケットだけで登場する姿はスマートだ。母さんの手編みの毛糸のマフラーをしている僕とは違う。一瞬同性に見惚れてしまった鳥刈は、すぐに我に返って軽く声を上ずらせながら答えた。

「すみません、急病で奥村先輩はお休みなんです。あいにくQA部長も出張で留守にしてまして、もしよろしければ私だけでお話を伺ってもよろしいでしょうか。」

水元は、首から上だけのお辞儀で恐縮した風を見せながら気負っている雰囲気が漏れ出てくる若さに微笑みつつ、「構いませんよ。でも前回の宿題は...?」と尋ねながら席に着いた。コンサルタントという職業柄、クライアントがバグ対応で欠席するなど珍しくもなんともない。会社の前まで来て中止のメールが来たこともある。熱心な若者の力になれるのであれば嬉しい限りだ。

「すみません。そちらも次に回して頂けますでしょうか。今日はちょっと『テスト観点』についてお伺いしたいんです。」

なんかさ、よろしくやっといてよ、と先輩は電話で言った。うん、言った。僕はそう聞いた。だったら、せっかくの機会なんだから自分の実力アップに使おう。こないだ呑み会で先輩は「お前の信じる道を行け」とも行ってくれたじゃないか。なんだか覚えてなさそうだけど。

「ふむ...いいですよ。どんな質問ですか?」

「インターネットで各社の動向を調査したんです。『テストの切り口』とか『どうテストするか』とか抽象的には分かります。でも具体的なものが欲しいと思ってテスト観点の表みたいなものをダウンロードすると、なんか違和感があって...。ずっとモヤモヤしてるんです。教えてください。テスト観点って、なんですか?」

どうして不明点を説明し終わってドヤ顔をしているんだろう、という疑問が頭をかすめたが、水元の頭脳の焦点はそれどころではなかった。この質問に答えはないからだ。

なぜ答えがないのか。質問者は字面としてテスト観点の定義を質問してくる。しかし実のところ彼らが聞きたいのは「良い」テスト観点の挙げ方であり、それが「良い」ことの保証である。質問にまともに答えるとずいぶん哲学的な定義の話になるし、モヤモヤは消えず不承不承納得した表情をして話は終わりになる。誰も得をしない。

だからといって「良い」テスト観点について答えるのも難しい。結果として得られたテスト観点の良し悪しよりも、そこに至る過程でどこまでケンケンガクガクあーでもないこーでもないと議論して、時には白熱して、そして皆が納得感を共感することが大事だからである。誰かから「良い」テスト観点をもらってきたとしても、すぐに陳腐化する。水元はそのことをよく知っているし、少なくないエネルギーを費やしたコンサルティングの成果がクライアント側で水の泡になってしまって臍を噛んだこともある。どうしたものか...。

「百聞は一見にしかず、とか、論より証拠、と言いますよね。せっかく今日は鳥刈さんのお話をゆっくり伺えるので、ちょっと手を動かしながら実例を見てみましょうか。」

実例!そう、僕に足りないのは経験だ。勉強はたっぷりした。勉強会に出て凄い人たちの経験談も聞いた。でも先輩は微妙な顔をする。きっと僕に足りないのは経験だ。経験さえ積めば先輩も分かってくれる。それには実例が一番だ。さすが腕こきのコンサルタント。高いだけあって、クライアントのニーズに的確に答えてくれる。

「そうですね!よろしくお願いします!」

             ☆                  ☆

「あまり大きな実例ではかえって話が分からなくなりますから、すごく小さな例にしましょう。でもご心配なく。とても大事なエッセンスが詰まっていますから。」

えー。小さな例なら、勉強会でも聞けるじゃないか。鳥刈は少しがっかりした。

「鳥刈さんがダウンロードしたテスト観点の表は、どんな表でしたか?」

「なんだか機能仕様書から抜き書きして非機能要求をおまけに付けた感じだったり、あれしろこれしろここ見ろあそこ見ろのリストだったりして、なんだか歴史の年号の暗記みたいでした。あれを見て上手にテストできる感じはしませんでした。」

「なるほど。じゃあ実際に、手を動かしてみましょう。ここからダウンロードして...そうです。で、こうするとテキストファイルが開けますね。これは、+Lhacaという解凍ソフトのReadmeファイルです。読んだら、解凍のあたりのテスト観点図を作ってみて下さい。部分的で構いません。そんなに難しくないですね。」

水元はにこやかに促した。Xmindを立ち上げてすぐに、鳥刈は図を完成させた。

「おっ、早いですね。勉強熱心という噂は聞いていますよ。さすがです。」

誉められた!やはり見る目がある人は違う。先輩と大違いだ。鳥刈は鼻息が荒くなったことに気づかず、しかし意識の高い社会人に必要な謙譲の振る舞いとして顔の前で右手を振った。




【テスト観点図1】

「ふむ、なるほど。このテスト観点図の『意図』はなんでしょう?」

水元はまっすぐ鳥刈の目を見て言った。鳥刈はそのまま真っ向から見返して答えた。

「解凍機能の仕様確認です!」

「なるほど。まず、この段階ではそれで構いません。でも実際にテストをする時には、もう少し何か工夫をしませんか?」

「あー、そうですね。『1M以上』と書いてありますが、『とても大きい』にしてみると思います。」

「じゃあテスト観点図をリファインしてみましょう。」




【テスト観点図2】

「『1M以上』を『とても大きい』にしたのはなぜですか?」

鳥刈の目が少し泳いだ。

「何となく、何かが起きるかもしれないと思ったからです。」

「直感ですよね。直感、いいんです。大事にしましょう。さて改めて、とても大きくすると何が起きるでしょうね?」

「うーん、なんかあふれたり、とか?」

「なるほど。そうすると鳥刈さんのテストの“意図”は、『とても大きいサイズのファイルを解凍すると、なんかあふれるかも』なんですね。」

水元は注意深く、鳥刈の言葉を丁寧に紡いで投げ返した。誘導してしまうと、後で気づいて余計にモヤモヤするからだ。

「はい。そうなりますね。そうです。段々そうだって思ってきました。なんか元々そう思ってた気がします。」

鳥刈は暗示にかかりやすい。水元は、誘導してしまったかと心の中で軽く苦笑した。

             ☆                  ☆

「ところで、『あふれる』ってなんでしょう?」

水元は尋ねた。

「えーと、ディスクが一杯になって動かなくなる、とか。」

「その方が、テストの“意図”がはっきりしますね。言い直すと、『とても大きいサイズのファイルを解凍して、ディスクを一杯にして動かなくする』がこのテストの意図ですかね。このテストの意図は、2つの部分に分けられるんですが...

1) とても大きいサイズのファイルを解凍する

2) ディスクを一杯にして動かなくする

...本当に鳥刈さんがテストしたいのは、どちらでしょう?」

「2)です。」

「その場合、サイズが大きくなって欲しいのは、解凍前のファイルですか?」

「あー、違いますね。解凍後です。」

「じゃあテスト観点図をまたリファインしてみましょう。ただし分かりやすくするために、プログレスバーの確認は別で考えることにしましょう。」




【テスト観点図3】

「さっきより意図がはっきりした、すなわち“意図の解像度が上がった”気がすると思いますが、いかがですか?」

「うーん、確かにそうなんですが、まだモヤモヤしますね。」

鳥刈は首をひねりながら答えた。腕を組んで右手はアゴの下に当てている。首を左右交互に倒しているので、ばね細工のようだ。

「なぜでしょう?」

「解凍前のファイルと解凍後のファイルと両方あるからかな」

「解凍前のファイルは大きくなくてよいのですか?」

「いえ、解凍前が大きければ、解凍後も大きいですから。」

「圧縮形式は関係ない?」

「あー、もしかしたら関係するかも。いや、形式じゃないな。圧縮率とかだな。」

鳥刈の声が心持ち大きくなったことに二人は気づいていない。

「圧縮率?」

「はい、解凍前のファイルが大きくて、圧縮率が高ければ、解凍後のファイルも大きくなります。」

「なるほど。じゃあテスト観点図をリファインしてみましょう。




【テスト観点図4】

「ずいぶん“意図”がはっきりした気がしますね。」

「そうですね。そんな気がします。」

水元はこの答えの源泉が実感なのか暗示なのか不安だったが、これは実感してくれていると自分に暗示をかけて先に進むしかなかった。

             ☆                  ☆

「でもこのテスト観点図だと、相変わらずテストの意図は『解凍機能の仕様確認』になってますが、構いませんか?」

「いえ違います。『ディスクを一杯にして動かなくする』が意図ですから。」

「じゃあリファインしてみましょう。」




【テスト観点図5】

「こう、ですかね...?」

鳥刈は正解に向けて進んでいるのか不安になりつつある自分と、ほんの少しだが分かってきたという気持ちを臍のあたりで感じている自分との同居に戸惑っていた。水元はその戸惑いの理由を見透かして、鳥刈の背中を押すことにした。

「さっきのテスト観点図と今のテスト観点図を見比べて、気がついたことはありませんか?」

「あー、そうですね。別に解凍機能以外でもディスクを一杯にするテストってできるのかもしれません。圧縮とか。」

「じゃあまたリファインしましょう。ちょっとずつたくさんリファインしていいんですよ。中間作業成果物だと思うとやれ版管理だとかが気になりますが、いまのテスト観点図は鳥刈さんの理解を助ける相棒なんです。相棒と一緒に理解を深めているというイメージを持ってくださいね。」

「相棒...。相棒か...。」

鳥刈はまじまじとテスト観点図を見つめた。相棒と言われると、なんだか急に親しみが湧いてきた。嬉しくなってきた。また鼻息が荒くなってきた。




【テスト観点図6】

「どうですか?」

鳥刈は我に返った。

「いや...なんかムダっぽいです。同じようなテスト観点が並んでます...。」

相棒だったのに。一生懸命やったのに。ムダだった。もうダメだ。全然分からない。QAなんて向いてない。やっぱり開発の技術がなければテストなんてできないんだ。僕の人生はムダだった。鳥刈はポジティブな暗示にもかかりやすい分、ネガティブな暗示にもかかりやすい。肩を落としていると、水元はそんな鳥刈の顔を覗き込んでいたずらそうな顔でこう提案した。

「開発と同じですよ。似たようなソースコードがあれば共通化してサブルーチンとかライブラリにしますよね。テスト観点図で同じような構造が見えたら、テスト観点を一段階抽象化して、共通化しましょう。抽象化だと難しく聞こえるかもしれませんが、同じ役割をするものをグループにまとめて名前を付けるだけです。例えば、解凍と圧縮をまとめて『処理』と呼んでみましょうか。」




【テスト観点図7】

「どうですか?」

「すっきりしてきました...でももう少しすっきりできるかもしれません。」




【テスト観点図8】

鳥刈は目をぱちくりさせて、自分がいまリファインしたばかりのテスト観点図を眺めた。ずいぶん変わったな。

「なるほど。確かに、この方が意図が明確ですね。」

「ずいぶん分かりやすくなりました。変われば変わるもんですね。」

「でも、相変わらずテストの意図は『仕様確認』になってませんか?」

「あー、すぐ直します。」




【テスト観点図9】

「分かりやすいね。まぁ関連線をわざと描いてないのもあるけど。」

「分かりやすいですね...。意図がはっきり見えます。」

「ここまで分かりやすくなると、何か増やしたくなってこない?」

勝負所。誘導してはいけない。ここで誘導すると、すべてが水の泡。軽い口調で、あえて目を合わせず。言葉でも身振りでも指先でも目線でも、呼吸ですらもヒントを与えないように。水元は全身の筋肉がこわばり、汗が噴き出すのを感じていた。

「そうですねぇ...うーん...あー、ファイルのサイズが大きくなくても数が多ければいい、とか?」

水元の苦労など全く感じ取らず、鳥刈は答えた。水元は安心した。鳥刈はどうやら、ダイブと水元が呼ぶ状態に入っているようだ。考えている対象に集中でき、匂いや手触りを感じられるほどありありとイメージできる状態。潜っているのだ。クライアントがダイブしてくれたら、そのコンサルティングは成功である。放っておいても理解は進むし成果は出る。

「おー、新しい観点が出てきましたね。素晴らしい!じゃあリファインしましょう。」




【テスト観点図10】

「他に考えておくべき観点はありますか?」

「そうすると、ディスクの容量を減らしておいてもいいですね。」

「また新しい観点ですね!いいですよ、鳥刈さん、実にいい。さらにリファインしましょう。」




【テスト観点図11】

「なんか、いい感じですね。」

「なんか、いい感じですね。」

二人で目を合わせて、にんまりした。水元もまた、ダイブしているのだ。

「じゃあさらに一歩踏み込みましょう。一杯にできるのって、ディスクだけですかね?」

「メモリ!メモリも一杯にできます。そうすると、こうですかね。」




【テスト観点図12】

「そして抽象化。『記憶域』ですね。」

鳥刈はまるで10年以上もテスト観点図を作っているような調子で進めている。水元はその様子をウキウキしながら見ている。




【テスト観点図13】

水元はニヤリとしながら口を開いた。

「なにか違和感ない?」

テスト観点図に目線を一周させて、すぐに鳥刈は答えた。

「あります。『ファイル』だけやけに具体的。あと『圧縮率』も。」

「具体的って思うなら、抽象化してみましょう。」

「そうですね。ファイルは『リソース』かな。メモリだったらデータや文字列とかですかね。」

「圧縮率は『処理パラメータ』あたりにしておきましょうか。」




【テスト観点図14】

「どうですか?」

「なんだか、他のソフトのテストでも役立ちそうな感じです。圧縮ソフト以外でも。」

鳥刈は改めて驚いたようだった。

「最初のテスト観点図は役立ちそう?」

「いえ、あれは圧縮ソフト専用です。他のソフトには使えません。」

水元は立ち上がり、人差し指でリズムを取りながら解説を始めた。

「今日は鳥刈さんに『テスト観点の蒸留』という技を体験して頂きました。テスト観点図を描くときに網羅とかMECEばかりに気を取られると、仕様書やユーザマニュアルのコピペが主になってしまいますし、何より描きっぱなしになってしまいます。」

水元は頷いて肯定するように鳥刈を見つめて、言った。

「最初はそれでもいいんです、最初は。でもその後に、自分たちの意図を再検討したり、解像度を上げたりしながら、テスト観点図を何度もリファインしなくてはなりません。そうすると、テストの“知恵”が“蒸留”されてテスト観点図の上の方に浮かんできます。テストの知恵が蒸留されると、フロントローディングをして蒸留で品質を確保しやすくなります。逆に言うと、最初から完全なテスト観点図を描こうとしない方がいいですし、社外からテスト観点を買ってくるのも弊害が大きいんです。蒸留の過程で自分たちが分かっていくことそのものが大事ですから。」

             ☆                  ☆

「なるほど、テストの知恵かー。」

鳥刈は感心したように何度も頷いた。

「最後にできたテスト観点図が完全な模範解答なわけではありません。引き続き鳥刈さんが考えてリファインしていく必要があります。でも“蒸留”する感じは掴めましたかね。では、ポイントをまとめましょう。

1) 最初は仕様書やユーザマニュアルのコピペのテスト観点図でも構わない。まず描くことが大事。

2) 描いてみたら、ほんの少しでいいし経験や直感で構わないから、テスト観点図に工夫を加えてみる

3) 「意図のリバース」を行う。テスト観点図に加えられた工夫や、自然に描いたところから、一体自分はどういう意図でこのテスト観点を描いてるんだろう、と再検討してみる

4) 「意図の解像度の向上」を行う。テスト観点図に描かれた意図がはっきりするように、テスト観点図をリファインしたり、より深く検討してみる

5) 「知恵の蒸留」を行う。意図のリバースと解像度の向上をしながらテスト観点図をリファインすると、意図が徐々にトップに近い観点に浮かび上がってくる。

7) 「テスト観点の拡充」を行う。蒸留された知恵がテストのモデルのようなものになっているので、足りない構成要素を追加したり、そのモデルに該当する他のものに応用してみる。」

「テスト観点を育てる、って感じですね。子育てはしたことないけど、こういう風に無理せず見守りながら育てられたらいいなー。」

まだ実感がこもっていない。無理もない、鳥刈はまだ20代の若手だからだ。

「複数のテストエンジニアでテスト観点図を描いてるのであれば、『みんなでテスト観点図を育む(はぐくむ)』のかもしれません。愛を育むように、たくさん意図を話してお互いで理解しあって共通認識をどんどん改めていって、テスト観点図を囲んでいつでもみんながみんなのことをわかり合ってる状態だといいですね。テスト観点図に正解はないんです。大事なことは、みんなで育むことなんです。」

一足早く仕事終わったことを感じ取ったのか、鳥刈は雑談モードに入ったようだ。

「水元さんは、愛を育んでいるんですか?」

「もちろん。これから大事な人のために、クリスマスのプレゼントを買いに行きます。鳥刈さんは、クリスマスはどうされるんですか?」

「ぼ、ボクはカノジョとか軽薄な感じじゃなくて、一人で自宅で技術書読んでバリバリ勉強しますよ!最強のQAになりたいんですから!サンタさんにもお願いしてます!モテないんじゃないです!プロの独身なんです!」

自分で話を振っておいて狼狽するあたりを可愛いと言ってくれる女子は探せばいるんじゃないかな世の中広いんだし、とは口に出さず、片付けを終えて水元は立ち上がった。

「はっはっは。まぁ、無理しない程度にクリスマスを楽しんでくださいね。そうそう、テストエンジニアに恋人になってもらうといいですよ。色々気を配ってくれますから。ではお疲れ様でした。メリークリスマス♪」

To be, or not to be continued into the main story…

29119

このページでは、ISO/IEC/IEEE 29119シリーズに関する論争についてまとめています。

翻訳は日本のテストコミュニティの有志によって行われています。私たちは、ISO/IEC/IEEE 29119シリーズについて技術的にフェアな理解と議論が日本で行われるために、翻訳を行いました。

あらゆる技術・手法・ツール・記法・規格・標準・法規は良い点と悪い点を備えています。そのどちらかからも目を背けることなく、かつ両者を技術的にフェアに理解することによって、技術・手法・ツール・記法・規格・標準・法規は適切に活用することができます。

私たちは日本の組織が、ISO/IEC/IEEE 29119シリーズが自組織に適しているかをきちんと判断し、導入すべきところと導入すべきでないところを見分け、盲目的に従うのではなく導入の目的にかなうように導入することを望んでいます。この翻訳群が、その一助になれば幸いです。

29119

(訳注:このページは、Context-Driven-TestingのWebサイト()に掲載されている"Please sign the Petition to Stop ISO 29119“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書は著者であるCem Kanerに翻訳および公開を許諾されています。翻訳はKazu Suzukiが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、qualab.jpの管理人であるYasuharu.Nishi@uec.ac.jpまでお知らせ下さい。)

Please sign this petition: http://www.ipetitions.com/petition/stop29119

この請願に署名をお願いします: http://www.ipetitions.com/petition/stop29119

I rarely rant about software engineering standards because it seems like a waste of time. Many of the participants in the software engineering standards movement are fine people who I respect. Some of them I call friends, or would be happy to have as friends. But several groups stand to benefit from being able to claim that they are following, selling, or training a collection of processes that are simplistic and easily described, even if they are ineffective and enormously wasteful. These groups can afford to invest a lot of money dominating the standards committees that, in turn, have come to serve their interests. They can also afford to invest a lot in public relations to promote the perceived legitimacy of those committees’ work.

ソフトウェアエンジニアリングの標準について、わたしがわめき立てることなどめったにない。時間の無駄としか思えないからだ。ソフトウェアエンジニアリングの標準化の活動に参画する人の多くは立派な人だし、尊敬もしている。その中には友人と呼べる人もいれば、友人になれたらと思える人もいる。
しかし一部のグループは、単純化されて簡単に説明できるようなプロセスの集合に自分たちが従っているとか、そのプロセスを売り込んだり研修を行ったりしていると主張できるようになることで利益を得る立場にある。たとえそのプロセスに大した効果がなく、きわめて無駄なものであったとしてもだ。そういったグループは、標準化委員会を支配して自分たちが利益を得られるように潤沢な金を投資する余裕がある。また、委員会の作業が正統なものと広く認められるように、PRに多くを投資することもできるのだ。

My experiences with the IEEE software engineering standards (which are the main basis for these ISO standards), began when I first came to Silicon Valley in 1983. They have been uniformly negative. I finally left IEEE in 2010 or 2011, at that point a Senior Member who had been recognized by IEEE for my work on their standards and even been appointed by Congress to the United States’ Election Assistance Commission’s Technical Guidelines Development Committee at IEEE’s request. (TGDC wrote technical standards and much of its work was guided by an IEEE standard that I had worked on.) I left IEEE as a protest against a software engineering standards process that I see as a closed vehicle that serves the interests of a relatively small portion of the software engineering community.

IEEEのソフトウェアエンジニアリングの標準(ISO標準の主な土台でもある)に関するわたしの経験は、初めてシリコンバレーに来た1983年に始まった。その経験は一様にネガティブなものであり、わたしは2010年か2011年についにIEEEを去った。その時点でわたしは、IEEEの標準に対する仕事を認められたシニアメンバーであり、またIEEEの要請により、米国の選挙支援委員会の技術ガイドライン開発委員会(TGDC)の委員として、議会から任命されていた(TGDCは技術的な標準を書いたが、その作業の大半は、わたしが携わったIEEEの標準に方向づけられたものである)。わたしから見て、ソフトウェアエンジニアリングの標準化のプロセスはクローズドな進め方であり、それがもたらす利益を受けるのは、ソフトウェアエンジニアリングのコミュニティの比較的小さなグループである。そのようなプロセスへの抵抗として、わたしはIEEEを去った。

Context-driven testing developed as the antithesis of what is being pushed through ISO. They represent opposite points of view.

コンテキスト駆動テスティングは、ISOを通じて推進されてきたもののアンチテーゼとして開発された。両者はまったく逆の立場を代表している。

Standards are political documents and sometimes legal ones. The existence of a standard makes it easier for a court (or a regulator) to rule that the standard-approved approach is the professionally correct one, and the non-approved approaches (or the ones that conflict with the approved one) are professionally incorrect and therefore improper. The imposition of a standard that imposes practices and views on a community that would not otherwise agree to them, is a political power play.

標準とは政治的なドキュメントであり、時には法的なドキュメントでもある。標準があれば、その標準に認められたアプローチが専門的に正しいものであり、認められていないアプローチ(あるいは認められたものとアプローチに衝突するアプローチ)は専門的に正しいものではなく、つまり適切でないと判断を下すことが、裁判所(あるいは規制を行う機関)にとって容易になる。標準を課すというのは、それに賛成していないコミュニティにプラクティスや考え方を押し付けることであり、政治的な権力争いなのだ。

If ISO 29119 is adopted and then broadly accepted as a legitimate description of good professional practice in software testing, then context-driven testing will be an example of something you should not do, a way of thinking you should avoid.

もしISO 29119が採択され、それがソフトウェアテスティングに関する専門的で適切なプラクティスの正統な説明であると広く受け入れられれば、コンテキスト駆動テスティングは、行うべきでないことの例、避けるべき考え方ということになってしまうだろう。

I don’t think it will do much good to sign a petition against ISO 29119, but I would rather say that I protested against it than simply accept its consequences in silence.

ISO 29119に対する請願に署名することでどうにかなるとは思わない。しかし、わたしは単に黙って結果を受け入れるのではなく、それに抵抗したのだと言いたい。

I recommend that you do the same.

あなたも同じようにすることをお勧めする。

29119

(訳注:このページは、DevelopSenseのWebサイト(http://www.developsense.com/)に掲載されている"Blog: Frequently-Asked Questions About the 29119 Controversy“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書は著者であるMichael Boltonに翻訳および公開を許諾されています。翻訳はKazu Suzukiが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、qualab.jpの管理人であるYasuharu.Nishi@uec.ac.jpまでお知らせ下さい。)

This is a first stab at a frequently-asked questions list about the movement to stop ISO 29119. Here I speak for myself, and not for the community. If you see “we”, it refers to my perception of the community at large, but not necessarily to the whole community; your mileage may vary. There is plenty of discussion in the community; Huib Schoots is curating a collection of resources on the controversy. If you’ve got a different perception or a different opinion, please share it and let me know. Meanwhile, I hasten to point out that absolutely everyone is welcome and encouraged to share my opinions.

 この記事は、「stop ISO 29119」活動におけるFAQのリストの最初の試みである。自分のためのものであり、コミュニティに向けたものではない。「we」という場合、コミュニティ一般に対するわたしの認識について述べているのであって、必ずしもコミュニティ全体に対するものではない。「個人の感想です」ということだ。
コミュニティにおいて、多くのディスカッションがなされている。Huib Schoots氏が、この問題における資料を一覧として選別してくれている。あなたが違う考え方、違う意見を持っているのであれば、それを共有し、わたしに教えてほしい。一方で、みなさんにぜひ、わたしの意見を広めてほしいと付け加えておこう。

Q. Why bother with a community attack on ISO 29119? Isn’t it irrelevant to most testers? And why now? / なぜコミュニティはISO 29119に対する批判などに関わっているのか。ほとんどのテスターには関係のないことでは? それに、なぜ今なのか。

To start with, we believe that ISO 29119 is irrelevant to all testers, in the sense that it seems to be an overstructured process model, focused on relentless, ponderous, wasteful bureaucracy and paperwork, with negligible content on actual testing. If your organization is in the business of producing pointless documentation, so be it, but that’s not what we call testing. The approaches suggested by 29119 might be useful to people who are more interested in ass coverage than in test coverage.

 まず第一にわたしたちは、ISO 29119が過度に構造化されたプロセスモデルであり、実際のテスティングにおいては取るに足らない内容とともに、過酷で、重く、無駄な官僚主義と書類仕事にフォーカスしているように見えるという意味で、すべてのテスターにとってこの標準は見当違いなものであると考える。あなたの組織が的外れなドキュメント作りを仕事にしているのであれば好きにすればよいが、わたしたちはそれをテスティングとは呼ばない。29119で提示しているアプローチは、テストカバレッジではなく、人間の許可のカバレッジ(訳注 ass coverage: 周囲のステークホルダーにどれだけ承認をもらえたかを気にする文化への皮肉と思われる)に興味がある者には有用かもしれない。

Originators and supporters of the petition are trying to establish a pattern of opposition to the standard. This becomes important when lawyers or auditors ask “Why didn’t you follow ‘an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation’?” Loud voices of opposition—not only to the standard, but also to the process by which it was created and by which it will be marketed—will help to show that the suggestion of “international agreement” is meaningless; that the standard misrepresents testing as many prominent testers see it; that the standard is overly complex and opaque; that it is both too vague here and too specific there to be useful in “any” organisation; and that radically different contexts for testing—quite appropriately—require radically different approaches for testing.

 この請願への起案者・賛同者は、ISO 29119への反対意見のパターンを確立しようとしている。これは、弁護士や監査官に「なぜあなたは、いかなるソフトウェア開発のライフサイクルにも、組織にも適用できる『国際的に合意されたソフトウェアテスティングに関する標準一式』に従わなかったのか」と問われた時に重要になってくる。声の大きな反対意見ーーー標準への反対であるだけでなく、それが作成されたプロセス、そしてそれが売り込まれるプロセスへの反対でもあるーーーは、「国際的な合意」という言葉に何の意味もないこと、その標準はテスティングを不正確に伝えていると多くの卓越したテスターが考えていること、過度に複雑で不可解であること、曖昧すぎる部分もあれば、「いかなる」組織にとっても有用であるというには細かすぎる部分もあるということ、そしてコンテキストが根本的に違えば、当然ながらテスティングに求められるアプローチも根本的に異なるということを示す助けになるだろう。

As to the “why now” question, there’s another reason for the groundswell that I think we’re discovering as we go: over the years, in fits and starts, the context-driven community has become much larger and more capable of acting like a community. And that despite the fact that people who aspire to be fiercely independent thinkers can be a fairly fractious bunch. A community that welcomes serious disagreement will have serious disagreements, and there have been some. Yet it seems that, every now and then, there are some things that are just odious enough to unite us. Personally, I’m treating this as a trial run and a learning experience to prepare for something seriously important.

 「なぜ今なのか」という問いには、別の理由がある。わたしたちが見出しつつある大きなうねりのためだ。何年にも渡って、次第にではあるが、コンテキスト駆動のコミュニティはずっと大きくなり、コミュニティらしくふるまうこともできるようになってきた。他に依存せず考えぬこうとする者たちは時として、非常に気難しい集団になりかねないという現実にも関わらずである。
深刻な意見の不一致を歓迎するコミュニティには、深刻な意見の不一致が生まれるもので、実際わたしたちにもいくつかの不一致はある。しかしわたしたちを団結させるほど不愉快なものが、時として現れるのだ。個人的には、そういったものは試運転のようなものであり、非常に重要なもののために備えて学ぶべき経験であると考えている。

Q. The promoters of the standard insist that it’s not mandatory, so what’s the fuss? / 標準の推進者は、標準が強制のものではないと言っているのに、なぜこのように騒ぎ立てるのか。

The promoters of the standard who say that the standard is not mandatory are being disingenuous. They are well aware of this idea:

 この標準が強制のものではないと言っている推進者は、誠実ではない。彼らは次のようなことがよくわかっているのだ:

“Still another classification scheme distinguishes between voluntary standards, which by themselves impose no obligations regarding use, and mandatory standards. A mandatory standard is generally published as part of a code, rule or regulation by a regulatory government body and imposes an obligation on specified parties to conform to it. However, the distinction between these two categories may be lost when voluntary consensus standards are referenced in government regulations, effectively making them mandatory standards.”
(Source: http://www.nist.gov/standardsgov/definestandards.cfm)

 使用するにあたって、それ自体は何ら義務を課さない任意の標準と、強制の標準を区別する方法には、別の分け方もある。強制の標準は通常、規制を行う行政機関によって規定・ルール・規制の一部として発行され、その標準に準拠する義務を特定の集団に課す。しかし、行政機関が規制の中で参照すると、任意の標準は強制の標準になり、2つのカテゴリーの区別がなくなることがある。
(引用もよ: http://www.nist.gov/standardsgov/definestandards.cfm)

The 29119 promoters begin by using appeal to authority (in this case, the reputation of ISO) to declare a standard. If it so happens that a regulator or bureaucrat, uninformed about testing, happens upon “an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation” and refers to them in government regulations, well, then, so much the better for aspiring rent-seekers who might have been involved in drafting the standard.

 29119の推進者は、権威(この場合、ISOの評判)に訴えることで、標準を宣言し始めている。もし規制者や官僚が、テスティングを均一なものにしようとして「いかなるソフトウェア開発のライフサイクルにも、組織にも適用できる、国際的に合意されたソフトウェアテスティングに関する標準一式」を見つけ、行政の規制の中でそれに言及すれば、標準の策定に参加してレントシーカー(訳注:公的機関による規制などを利用として利益を得ようとする者を指す)になろうとしている者には好都合だろう。

Q. If ISO 29119 is so terrible, won’t it disappear under its own weight? / ISO 29119がそんなにひどいものなら、それ自身の重みで消えてしまうのでは?

Yes, it probably will in most places. But for a while, some organizations (including public ones; your tax dollars at work, remember) will dally with it at great cost—including the easily foreseeable costs of unnecessary compliance, goal displacement, misrepresentation of testing, and yet another round of marketing of bogus certifications, whereby rent-seekers obtain an opportunity to pick the pockets of the naïve and the cynical.

 たぶん多くのところでそうなるだろう。しかししばらくの間は、莫大なコストをかけてこの標準にかかずらう組織(公的機関も含む。そこでの仕事にはあなたの税金が使われていることを思い出してほしい)もあるだろう。必要もないものへの準拠、目標の喪失、テスティングに対する誤った説明、さらにはいんちきな認証といったコストは容易に想像できる。一方でレントシーカーは、世間知らずや皮肉屋から金を巻き上げるチャンスを得るというわけだ。

Q. Aren’t you just griping because you’re worried that your non-standard approach to testing will put you out of business? / あなたは、標準にそぐわない自分のテスティングアプローチではビジネスにならなくなることを心配しているだけではないか?

Here’s how I answered this question on one blog (with a couple of minor edits for typos and clarity):

 この質問にはあるブログで答えているので紹介しよう。(誤記の修正と論旨を明確にするために、いくつか小さい修正をいれている)

“In one sense, it won’t make any difference to my business if 29119-1, 29119-2, and 29119-3 are left to stand, and if 29119-4 and 29119-5 move from draft to accepted. Rapid Software Testing is about actual testing skills—exploration, experimentation, critical thinking, scientific thinking, articulate reporting, and so forth. That doesn’t compete with 29119, in the same kind of way that a fish restaurant doesn’t compete with the companies that make canned tuna. We object to people manipulating the market and the ISO standards development process to suggest to the wider world that canned tuna is the only food fit for people to eat. I discuss that here: http://www.developsense.com/blog/2014/08/rising-against-the-rent-seekers/

 「ある意味で、29119-1、29119-2、29119-3がそのままであろうと、29119-4や29119-5がドラフトから採択になろうと、わたしのビジネスには何の違いもない。「高速ソフトウェアテスティング」は、現実におけるテスティング技術だ。探索、実験、クリティカルシンキング、科学的な考え方、明確なレポートなどなど。魚料理のレストランがツナ缶を作る企業と競合しないように、わたしたちのアプローチは29119と競合しない。わたしたちは、「ツナ缶は人々が食べるにふさわしい唯一の食べ物だ」と世の中に広く主張するために、市場やISOの標準の開発プロセスを操ろうとする者たちに反対しているのだ。このことについては以下で議論している。
http://www.developsense.com/blog/2014/08/rising-against-the-rent-seekers/

“In another sense, 29119 could be fantastic for my business. It would offer me a way to extend the brand: how to do excellent, cost-effective testing that stands up to scrutiny in contexts where some bureaucrat, a long way away from the development project, was fooled into believing that 29119 was important. At the moment, I’m happy to refer that kind of business to colleagues of mine, but I suspect that it would be something of a gold mine for me. Yet still I oppose 29119, because what’s in my interest may not be in the interests of my clients and of society at large.

 「またある意味で、29119はわたしのビジネスにとって素晴らしいものになるかもしれない。名声を広める道をもたらしてくれる可能性もある。開発プロジェクトから遠く離れたところにいる官僚たちが29119が重要なものだと信じるようだまされている状況で、素晴らしく、コスト効果があり、精査にも耐えうるテスティングを行うにはどうすればいいか、といったものだ。今のところ、この種の仕事を同僚に頼むことはやぶさかではないが、わたしにとって宝の山なのではないかと思う。それでもやはり、わたしは29119には反対だ。わたしの利益が必ずしも、わたしの顧客の、あるいは広く社会の利益であるとは限らないからだ。

“Let me be specific: There are existing standards for medical devices, for avionics, and the like. Those standards matter, and many of them are concise and well-written, and were created by genuine collaboration among interested parties. Testers who are working on medical devices or on avionics software have a limited number of minutes in the working day. As someone who flies a lot, and as someone who is likely to require the help of medical devices in the foreseeable future, I would prefer that those testers spend as many minutes as humanly possible actually investigating the software, rather than complying (authentically, pathetically, or maliciously) to an unnecessary standard for process modeling, documentation, and strategising (a standard for developing a strategy—imagine that!).”

 「もう少し具体的に言おう。医療機器、航空といったものにはすでに規格がある。これらは重要なものであり、その多くは簡潔でうまく記述されているし、関係する団体の誠実な協働によって作り上げられている。医療機器や航空のソフトウェア開発で働いているテスターは、平日には限られた時間しかない。たくさん飛行機を利用する者として、また遠くない将来に医療機器の助けが必要になるであろう者として、テスターにはできる限り多くの時間をソフトウェアを調べることに使ってもらいたい。プロセスモデリングのための不必要な標準、ドキュメンテーション、戦略作り(戦略を作るための標準・・・想像できるか?)のための不必要な標準なんかを(正しい形にせよ、痛ましいやり方にせよ、あるいは悪意をもってにせよ)守ろうとするよりも。

Q. You just don’t like standards. Isn’t that it? / あなたは単に標準が嫌いなだけではないのか?

Nope. I love standards when they’re used appropriately.

 そうではない。適切に使われるのであれば、標準は大好きだ。

As I emphasized in a 2011 PNSQC presentation called “Standards and Deviations“, it is possible and often desirable to describe and standardize widgets—tangible, physical things that have quantifiably measurable attributes, and that must interface, interact, or fit with other things. Thank goodness for standardized screws and screwdrivers, CDs, and SATA hard drives! Bravo to the EU for mandating that power supplies for smartphones standardize on USB! Yet even with widgets, there are issues related to the tension between standards and an advancing state of the art. Here’s one of the best-ever articles on problems with standards: Joel Spolsky on Martian Headsets.

 2011年のPNSQCにおいて「標準と逸脱」というプレゼンテーションで協調したように、手で触れられて、定量的に測定可能な属性を持つ物理的なものであれば、そしてそれが他のものと接続されたり、相互作用したり、他の物とうまく合う必要があるものであれば、標準化することは可能だし、望ましいことでもある。

It is more difficult and to describe processes, since the description is, by necessity, a model of the process. It’s difficult for many people to avoid reifying the model—that is, to avoid treating the model—idea-stuff—as though it were a thing. For an example of reification of testing, take a few moments to reflect on the notion of representing testing work in terms of test cases; then read “Test Cases Are Not Testing: Toward a Culture of Test Performance” by James Bach & Aaron Hodder. More generally, 29119’s focus on the artifacts and the process model displace and de-centre the most important part of any testing effort: the skill set and the mindset of the individual tester.

 プロセスを説明しようとすると必然的に、プロセスのモデルを説明することになるので、もっと難しい。多くの人にとって、モデルを具体化して考えないようにする、つまり、イデアたるそのモデルを、モノであるかのように扱わないでおくことは難しい。テスティングを具体化する例として、「テストケース」という用語でテスティングの作業を表現するということについて、少しの時間考えてみてほしい。それから、James BachとAaron Hodderの『テストケースはテスティングではない。テストというパフォーマンスという文化に向かって』を読んでほしい。より一般的に言うと、29119は中間成果物やプロセスモデルに注目するあまり、テスティングの作業においてもっとも重要な部分をどこか隅っこに追いやってしまっている。つまり、個々のテスターのスキルセットやマインドセットというものだ。

Q. Do you really believe that ISO 29119 can be stopped? / あなたは本当に、ISO 29119を止められると思っているのか?

No, of course we don’t. Curtis Stuehrenberg puts it perfectly in a discussion on LinkedIn: “The petition is not about stopping the publication any more than an anti-war march is about a reasonable expectation of ending a war through a parade. The point of the petition and the general chatter is to make sure at least some people hear there is a significant portion of the testing community who was not represented and who espouse different viewpoints and practices for software testing as a professional discipline.” If we can’t get the standard stopped by the ISO’s mechanisms, at least we can show that there is an absence of consensus outside of the 29119 working groups.

 いや、もちろん思っていない。Curtis Stuehrenbergが、LinkedInでの議論の中でそれを完璧に表現している。「この請願は、発行と止めようとするものではない。反戦マーチが、パレードを通して戦争が終わることをほどほどの期待するのと同じだ。この嘆願ややりとりにおいて大事なことは、ソフトウェアテスティングにおいて、プロフェッショナルな規律として別の考え方ややり方を支持する大きな集まりがあり、推進者の中にその代表者はいないということを、少なくとも一部の人々が耳にしたということをはっきりさせることなのだ」。もしISOの構造により規格を止められないとしても、わたしたちは少なくとも、29119のワーキンググループの外部においてはコンセンサスが得られていないことを示すことができるのだ。

Q. The standard has been in development for the last seven years; why have you waited so long? / この規格は7年に渡って進めれれている。なぜこんなに待っていたのか。

Some of us haven’t been waiting. For example, I gave this presentation in 2011. Some of us have been busy objecting to certification schemes. (There’s only so much rent-seeking one can oppose at once.) Several of us have argued at length and in public with some of the more prominent figures promoting the standard at conferences. They sometimes seem not to understand our objections. However, as Upton Sinclair said, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” (http://en.wikiquote.org/wiki/Upton_Sinclair) Whether through terrible argumentation or deliberate guile, the responses in those discussions usually took the form of non-sequiturs: “The standard is optional; something is better than nothing; many people were involved; the perfect is the enemy of the good; we’re trying to help all those poor people who don’t know what to do.” The standards promoters should (and probably do) know that those statements would apply to any process model that any person or group could offer. Constructing bogus authority into the ISO, and then appealing to that authority, looks an awful lot like rent-seeking to me.

 誰もが待っていたわけではない。たとえばわたしは2011年にプレゼンテーションを行っている。認定のスキームへの反対に力を入れていた者もいる(一人の人間が一度に反対できるレントシーキングは限られているのだ)。カンファレンスなど公の場において長く、規格推進の大物と議論している者もいる。彼らは時に、わたしたちの反対を理解していないように見えるが、Upton Sinclairが言うように、「誰かに何かを理解してもらうのは難しい。彼がそれを理解していないがゆえに給料をもらえているとしたら」(http://en.wikiquote.org/wiki/Upton_Sinclair)。ひどい論争を通してであろうと、意図的な悪知恵であろうと、その議論における反応は、不合理な結論という形ととる。「規格は任意のものだ。どんなものであれ、ないよりはましだ。多くの人がそれに関わった。完璧は善の敵だ。わたしたちは、何をすればいいかわからない可哀想な人たちを助けようとしているのだ」。規格の推進者は、こういった主張が、いかなる人間・グループによって提案されたいかなるプロセスモデルにも当てはまることだということに気付くべきだ(し、おそらく気づいているのだろう)。ISOにいんちきな権威を作り出し、その権威に訴えることは、わたしには本当にレントシーキングに見える。

there has been begged
Moreover, it strains believe that the standard has undergone serious development when some of the basic models (for example, 29119’s model for the test planning process) have gone essentially unchanged over four years—a period that included the rise of smartphones and mobile technology, the aftermath of the financial crisis, and the emergence of tablet computing. Testing in an Agile context reportedly garners little more than a few hand-waving references. I can’t say I’m surprised that testing and checking don’t appear on 29119’s radar either.

 さらに、この規格はずいぶんと進んだが、基本的なモデル(たとえば29119のテスト計画プロセス)には4年以上の間、本質的な変更がなかった。この時期には、スマートフォンやモバイルテクノロジーの勃興や金融危機の直後、そしてタブレットコンピューティングの登場を含まれる。聞くところによると、アジャイルのコンテキストにおけるテスティングについては、お茶を濁す程度の言及しかないとのことだ。「テスティングとチェッキング」が、29119のレーダーには引っかからないということには、驚きもしなかった。

Q. Why didn’t you object using the formal process set up by ISO? / あなたはなぜ、ISOの正式なプロセスにのっとって反対しないのか。

As James Bach points out, the real question there has been begged: why should the craft have to defend itself against a standards process that is set up to favour the determined and the well-funded? ISO is a commercial organization; not an organ of the United Nations, emanating from elected representative governments; not an academic institution; not a representative group of practitioners; not ordained by any deity. The burden is on ISO to show the relevance of the standard, even under its own terms. Simon Morley deconstructs that.

 James Bachが指摘するように、本当に問われているのは以下のことだ:権力のある者、金を持っている者に有利に働くように定められた標準に対し、なぜ技術者の方が抗弁しなければならないのか。ISOは営利機関である。政府に選ばれた代表者から成る国連の組織ではないし、学術団体でもない。実務家の代表でもない。何らかの神格に定められたものでもないのだ。規格の妥当性と、自分たちの言葉で説明することが責務があるのは、ISOの方である。Simon Morleyがそれを分析してくれている。

Q. Wouldn’t it be good to have an international common language for software testing? / ソフトウェアテスティングについて、国際的な共通言語ができるのはいいことではないか?

Great idea! In fact, it would be good to have an international common language for everything. And in order to be truly international and to represent the majority of people in the world, let’s make that language Mandarin, or Hindi.

 いい考えだ! 事実、どんなものにでも国際的な共通言語があるといいだろう。そしてその共通言語を真に国際的なものにし、世界の多数派を代表するものにするために、その言語を中国標準語かヒンズー語にしよう。

There are many arguments to show that a common language for software testing is neither desirable nor possible. I’ve blogged about a few of them, and I’ve done that more than once.

 多くの議論が、ソフトウェアテスティングに関する共通言語は望ましいものでもなく、また実現できるものでもないということを示している。わたしもいくつかを、一度ならずブログに書いている。

Q. Why are you always against stuff? Don’t you want to be for something? / なぜあなたはいつも、何かに反対しているのか。何かに賛成したくはないのか。

You don’t have to be for something to be against something that’s odious. But as a matter of fact, I am for something that is more important than any standard: freedom and responsibility for the quality of my work (as I hope all testers are for freedom and responsibility for the quality of their own work). That includes the responsibility to make my work capable, credible, open to scrutiny, and as cost-effective as possible. I must be responsible to my clients, to my craft, and to society as a whole. In my view, those responsibilities do not and should not include compliance with unnecessary, time-consuming, unrepresentative standards created by self-appointed documentation and process-model enthusiasts.

 不愉快なものに反対するために、何かに賛成する必要はない。とはいえ実際は、標準なんかよりもっと大事なものに賛成してはいるのだ。自分の仕事の質に対する自由と責任である(同様に、すべてのテスターが自身の仕事の質に対する自由と責任に賛成してほしい)。それは、自分の仕事を有効で、信頼できるものであり、批判に対して開かれており、そしてできる限り費用効果のあるものにする責任を含む。わたしは自分の顧客、自分の職業、そして全体としては社会に対しても責任を持たなければならない。わたしの考えでは、自称「ドキュメンテーションとプロセスモデルの愛好者」によって作られた、不必要で時間ばかり食う、誰を代表するわけでもない標準に準拠することは、責任に含まれていないし、含まれるべきでもない。

Some other things I’m for: the premises of Rapid Software Testing; the Rapid Testing framework; studying the structures of exploratory testing; the Heuristic Test Strategy Model; a set of commitments for testers to make to their clients; practicing the skill of test framing; excellent reporting; and a host of other things. This is unrepresentative of the wider testing community… so I bet you’re glad that compliance with standards set by James and me is voluntary. In fact, compliance with our standards requires you to invent testing for yourself; to adopt standards that help; and to resist the ones that don’t, including ours. But if you find something else that works for you, tell us. Tell everybody.

 わたしが賛成するのはもっと別のもだ。高速ソフトウェア開発の前提条件、高速テスティングフレームワーク、探索的テストの構造を学ぶこと、ヒューリスティックなテスト戦略モデル、顧客に対してテスターが持つべきコミットメント、テスト立案のスキルの修練、他たくさんのものだ。これはテストのコミュニティを広く代表するものではないので、Jamesとわたしが定めた標準に従うかどうかは任意だということは、歓迎されるだろう。事実、わたしたちの標準に従うということは、あなた自身のためにテスティングを発明することを求められる。そのためになる標準には従い、(わたしたちの標準を含めて)そうでないものには抵抗する。あなたのためになる何か別のものを見つけたなら、わたしたちに教えてほしい。みんなに教えてほしい。

Q. What about the poor people who need guidance on how to test? / どうテストすればいいかのガイドを必要とする可哀想な人たちについてはどうする?

My (free) offerings to those poor people include those just above. Those poor people are welcome to use these suggestions and to investigate the alternatives that anyone else offers. That may be harder than referring to an ISO standard and appealing to its authority. (It may be considerably easier, too.) But my first piece of guidance on how to test is this: learn about testing, and learn how to test, through study and practice. I argue that ISO 29119 will not help you with that.

 そのような人たちへのわたしの(無償の)提案には、上に挙げたようなものも含まれている。これらぜひ使ってほしいし、他の人が考えた別の代替案についても調べてみてほしい。ISOの標準に参照し、権威に訴えるするよりもずっと難しいかもしれない(ずっと簡単かもしれないが)。ただ、「どのようにテストするか」という質問に対してはまず、「学習と実践を通してテスティングについて学び、どうテストするかを学ぼう」とアドバイスしたい。ISO 29119はその手助けにはならないと主張したい。

Q. Okay, despite the Quixotic nature of the petition, I’m convinced. Where do I sign? / わかった、この請願は非現実的なものではあるが、納得した。どこで署名すればいいのか。

Go to http://www.ipetitions.com/petition/stop29119. And thank you.

 http://www.ipetitions.com/petition/stop29119を訪れてほしい。感謝する。

29119

(訳注:このページは、uTestのWebサイト(http://www.utest.com/)に掲載されている"ISO 29119: Why is the Debate One-Sided?“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書は著者であるJames Christieに翻訳および公開を許諾されています。翻訳はgoyoki@gmail.comが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、qualab.jpの管理人であるYasuharu.Nishi@uec.ac.jpまでお知らせ下さい。)

In August, the Stop 29119 campaign and petition kicked off at CAST 2014 in New York. In September, I wrote on the uTest Blog about why the new ISO/IEC/IEEE 29119 software testing standards are dangerous to the software testing community and good testing.

8月、ニューヨークでのCAST2014において、Stop 29119のキャンペーンと請願活動が開始された。
9月には、ソフトウェアテストのコミュニティや良いテストにとって、ISO/IEC/IEEE 29119の新しいソフトウェアテスト標準がなぜ危険なのかについて、私はuTest Blogに書いた。

I was amazed at the commotion ‘Stop 29119′ caused. It was the biggest talking point in testing in 2014. Over six months have passed, and it’s time to look back. What has actually happened?

Stop 29199の騒動が引き起こしたものに私は驚かされた。それは2014年のテストの話題として、最も大きなものとなった。騒動が始まって6ヶ月以上が経過したが、振り返るべきタイミングだ。これまで実際に何が起こっただろうか?

The remarkable answer is – very little. The Stop 29119 campaigners haven’t given up. There have been a steady stream of blogs and articles. However, there has been no real debate; the discussion has been almost entirely one-sided.

注目に値するものは、何も起こらなかった。
Stop 29119の活動者はとどまることがなかった。ブログや記事は途絶えることなく安定して出てきた。ただ現実でディベートが行われることなく、議論はほとんど一方的なものになった。

There has been only one response from ISO. In September, Dr. Stuart Reid, the convener of the working group that produced the standard, issued a statement attempting to rebut the arguments of Stop 29119. That was it. ISO then retreated into its bunker and ignored invitations to debate.

ISOからの反応は一つだけだった。9月に、Stuart Reid博士(標準を作成するワーキンググループのコンビナー)が、Stop 29119の主張への反論を試みる声明を出した。そしてISOは身を引いて、ディベートへの誘いを無視した。それだけだった。

Dr. Reid’s response was interesting, both in its content and the way it engaged with the arguments of Stop 29119. The Stop 29119 petition was initiated by the board of the International Society for Software Testing. ISST’s website had a link to the petition, and a long list of blogs and articles from highly credible testing experts criticizing ISO 29119. It is a basic rule of debate that one always tackles an opponent’s strongest points.

However, Dr. Reid ignored these authoritative arguments and responded to a series of points that he quoted from the comments on the petition site.
To be more accurate, Dr. Reid paraphrased a selection of the comments and criticisms from elsewhere, framing them in a way that made it easier to refute them. Some of these points were no more than strawmen.

Reid博士の反応は、内容、およびStop 29119の主張への噛み合い方の点で興味深いものだった。
Stop 29119の請願活動は、ISST(International Society for Software Testing)の委員会より始められたものだ。ISSTのウェブサイトでは請願へのリンクを設けた。またISO 29119を非難している、強く信頼できるテストの専門家たちのブログや記事の長大なリンクのリストも用意した。

ディベートならば、主張のうちもっとも強い論点に向き合うのが基本ルールだ。
ただReid博士は信頼し得るそれら引用を無視して、請願サイトのコメントから引用したいくつかの論点に応える形をとった。より厳密にいうと、Reid博士は、反対主張をどこからか持ってきた批判やコメントで言い換えて論破しやすいように仕立てあげた。それらのいくつかは藁人形論法での藁人形(Strawmen)でしかなかった。

So Cem Kaner argued that IEEE adopts a “software engineering standards process that I see as a closed vehicle that serves the interests of a relatively small portion of the software engineering community… The imposition of a standard that imposes practices and views on a community that would not otherwise agree to them, is a political power play.”

例えばCem Kanerは「ソフトウェアエンジニアリングの限られたコミュニティの権益の得るための、閉鎖的なソフトウェアエンジニアリングの標準プロセスを、IEEEは適用しようとしている。同意しないコミュニティにその施行や見解を押し付ける標準の強制は、政治的パワープレイでしかない」と主張した。

Dr. Reid presented such arguments as “no one outside the Working Group is allowed to participate”and “the standards ‘movement’ is politicized and driven by big business to the exclusion of others.”

These arguments were then dismissed by stating that anyone can join the Working Group, which consists of people from all parts of the industry. Dr. Reid also emphasized that “consensus” applies only to those within the ISO process, failing to address the criticism that this excludes those who believe, with compelling evidence, that ISO-style standardization is inappropriate for testing.

するとReid博士は、そうした主張を「ワーキンググループには、外部からの参加は誰も許されていない」「標準化活動は、巨額な利益を生むビジネスを囲い込むために生み出され、駆動されている」という主張であると表現した。そしてそれらを「ワーキンググループはだれでも参加できることになっている。またワーキンググループは、産業のさまざまな人達で構成している」という主張で退けた。

また、信頼できる証拠を伴う「ISOスタイルの標準化がテストにとって不適切である、と考えている人々を除外している」という批判に対して、Reid博士は「ISOプロセスが生み出してきた標準にはコンセンサスを確保する」ことを強調するだけで、批判に対応しなかった。

These criticisms had been made forcefully for many years, in articles and at conferences, yet Dr. Reid blithely presented the strawman that “no one knew about the standards and the Working Group worked in isolation.” He then effortlessly demolished the argument that nobody was making.

こうした批判は複数年にわたって、記事やカンファレンスでも強く行われてきたものだ。しかし今でもRied博士はこれら批判を「誰も知らぬまま、標準やワーキンググループを密室で決めている」という藁人形に矮小化した。そして彼はだれも言ってもいないその声明に、楽々と反論した。

What about the content? There were concerns about how ISO 29119 deals with Agile and Exploratory Testing. For example, Rikard Edgren offered a critique arguing that the standards tried but failed to deal with Agile. Similarly, Huib Schoots argued that a close reading of the standards revealed that the writers didn’t understand exploratory testing at all.

内容についてはどうだろうか?そこではISO29119でのアジャイルや探索的テストの扱いについて懸念が存在する。例えば、Rikard Edgrenは「標準をアジャイルに適用しようとしたが失敗した」という批判を提示した。同じように、Huib Schootsは「標準の執筆者は探索的テストを何もわかっていないことが、標準を読むと明白だ」と主張した。

These are serious arguments that defenders of the standard must deal with if they are to appear credible. What was the ISO response?

これらは、標準の信頼を確保するために、標準の擁護者が対応すべき重大な主張だ。
ではISOの反応はどうだっただだろうか?

Dr. Reid reduced such concerns with bland and inaccurate statements that “the standards represent an old-fashioned view and do not address testing on agile projects” and ”the testing standards do not allow exploratory testing to be used.” Again, these were strawmen that he could dismiss easily.

Reid博士は、そういった懸念を「標準は時代遅れの見解に基づいており、アジャイルプロジェクトでのテストに対応していない」「テスト標準は探索的テストを許容していない」という声明に矮小化した。これらは容易に反論できる藁人形だ。

I could go on to highlight in detail other flaws in the ISO response — the failure to address the criticism that the standards weren’t based on research or experience that demonstrates the validity of that approach, the failure to answer the concern that the standards will lead to compulsion by the back door, the failure to address the charge from the founders of Context-Driven Testing that the standards are the antithesis of CDT, and the evasion of the documented links between certification and standards.

その他、ISOの反応には「妥当性を示す研究または経験に標準が基づいていない」という批判に対応できていないこと、標準を内輪で決めて押し付けて来るという懸念に対応できていないこと、コンテキスト駆動テストの提唱者からの「標準はコンテキスト駆動テストと正反対である」という批判に対応できていないこと、認証と標準の文書による紐付けについての責任逃れ、といった手落ちをハイライトすることができる。

In the case of research, Dr. Reid told us of the distinctly underwhelming claims from a Finnish PhD thesis that the standards represent “a feasible process model for a practical organization with some limitations.” These limitations are pretty serious — “too detailed” and “the standard model is top-heavy.” It’s interesting to note that the PhD study was produced before ISO 29119 part 3 was issued; the study does not mention part 3 in the references. The study can therefore offer no support for the heavyweight documentation approach that ISO 29119 embodies.

このうち研究についての反応では、Reid博士は「標準は『若干の制約を伴う、現実的な組織で有効なプロセスモデル』だ」という、明らかにがっかりさせられるフィンランドの博士の論文を提示している。
ここでいう「制約」は若干でなくかなり深刻である。あまりに詳細すぎ、頭でっかちな標準モデルである点でだ。
またその博士の研究が、ISO29119 Part3の発行前に作られており、Part 3への参照がないのに留意すべきだ。提示されている研究が、ISO29119の重量級のドキュメンテーションのアプローチの支持として、有効でないということだ。

So instead of standards based on credible research, we see a search for any research offering even lukewarm support for standards that have already been developed. That is not the way to advance knowledge and practice.

信頼できる研究に基づいて標準を作るのではなく、すでに開発された既存の標準を中途半端にサポートする研究を見つけてきているのが目につく。これは知識やプラクティスを進化させる方法ではない。

These are all huge concerns, and the software testing community has received no satisfactory answers. As I said, we should always confront our opponents’ strongest arguments in a debate. In this case, I’ve run through the only arguments that ISO have presented. Is it any wonder that the ‘Stop 29119′ campaigners don’t believe we have been given any credible answers at all?

強い懸念が存在するまま、結局ソフトウェアテストのコミュニティは満足できる返答をもらえなかった。
前述の通り、ディベートでは常に最も強い声明に対して正面から対応すべきだ。
今回のケースでは、ISOが提示した唯一の声明に目を通した。Stop 29119の推進者が信頼できる解答を得られたと考えていない現状は、奇妙ではないだろうか?

What will ISO do? Does it wish to avoid public discussion in the hope that the ISO brand and the magic word “standards” will help them embed the standards in the profession? That might have worked in the past. Now, in the era of social media and blogging, there is no hiding place. Anyone searching for information about ISO 29119 will have no difficulty finding persuasive argumentsagainst it. They will not find equally strong arguments in favor of the standards. That seems to be ISO’s chice. I wonder why.

これからISOは何をするだろうか?ISOブランドと”標準”という魔法のワードで、職場を標準で埋めていけるという願望の元に、パプリックな議論を避け続けることを希望しているのだろうか?
その対応はかつては有効だったかもしれない。しかし今は、ソーシャルメディアやブログの時代であり、隠れ場所はない。ISO29119 関連の情報を検索する者ならばだれであっても、説得力のあるISO29119への反対意見を容易に見つけるだろう。一方で、標準を強く支持する主張は同じようには見つけられないだろう。
これはISOの選んだ選択のようだ。

29119

(訳注:このページは、ISO/IEC JTC1/SC7/WG26のWebサイト(http://softwaretestingstandard.org/)に掲載されている"Response to Stop 29119 Petition“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書はWG26に公式に認められています。翻訳はASTER(ソフトウェアテスト技術振興協会)として、にしが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、Yasuharu.Nishi@uec.ac.jpまでお知らせ下さい。)

ISO 29119 Background / ISO 29119 の背景

Up until last year there was no comprehensive set of international software testing standards. There are standards that touch upon software testing, but many of these standards overlap and contain what appear to be contradictory requirements with conflicts in definitions, processes
and procedures. There are some useful IEEE testing standards (e.g. IEEE 829, IEEE 1028) and national standards (e.g. BS 7925-1/-2) but there were large gaps in the standards relating to
software testing, such as organizational-level testing, test management and non-functional testing, where no useful standards existed at all. This means that consumers of software testing services (and testers themselves) had no single source of information on good testing practice.

昨年まで、ソフトウェアテストに関する包括的な国際標準はありませんでした。ソフトウェアテストに触れている標準はいくつかありますが、多くは重複しており、また定義やプロセス、手順に一貫していないところがあり矛盾した要求を含んでいるようです。IEEE(米国電気電子学会)の標準(IEEE829、IEEE1028など)や国家標準(BS 7925-1/02など)といったテストに関する有用な標準もありますが、組織レベルのテスト、テストマネジメント、非機能テストなどに大きなギャップがあるため、本当に有用な標準とは言えませんでした。これはテストサービスを活用する顧客(そしてテスト技術者自身)にとって、よいテストに関する情報をまとめて提供してくれるものが無い、ということを意味しています。

Given these conflicts and gaps, developing an integrated set of international software testing standards that provide far wider coverage of the testing discipline provided a pragmatic solution to help organizations and testers. And ideally this initiative would not re-
invent the wheel, but build upon the best of the available standards;
thus the motivation for the ISO/IEC/IEEE 29119 set of standards.

こういった矛盾やギャップを考慮すると、テストのdisciplineをとても広くカバーするまとまった国際標準を作成することが、テストを行う組織や技術者の助けとなる実践的な解を提供することになるわけです。理想を言えばこの活動は車輪の再発明になるべきではないでしょうが、実際のところこれまでの標準の優れたところを踏まえて作成することになるでしょう。これが、ISO/IEC/IEEE 29119シリーズの国際標準を作成する動機です。

In May 2007 ISO formed a working group to develop new standards on software testing – a new area for ISO. The scope of this initial work (ISO/IEC/IEEE 29119 parts 1, 2, 3 & 4) was largely defined by the existing IEEE and BSI standards (which they would replace), although it was clear from the onset that a completely new 'Test Processes’ standard would be required, in particular to ensure that agile life cycles and exploratory testing were considered, as well as more traditional approaches to software projects and to testing. Subsequently, work on a 'Test Assessment’ standard (ISO/IEC 33063) based on the 'Test Processes’ standard started. Much later (in 2012) a standard on Keyword-Driven Testing (ISO/IEC/IEEE 29119-5) was begun, and a proposal for a standard on 'Work Product Reviews’ is currently under ballot.

2007年5月にISO(国際標準化機構)は、これまで手がけてこなかったソフトウェアテストの分野で新しい標準を作成するWG(ワーキンググループ)を設立しました。初期の成果物(ISO/IEC/IEEE 29119 part 1~4)の範囲は(後にISO 29119シリーズに置き換えられることになる)IEEEやBSI(英国規格協会)の標準で既に広く定義されているものでしたが、テストプロセスに関する全く新しい標準を手がけること、特に、伝統的なソフトウェア開発やテストだけでなく、アジャイル開発や探索的テストも考慮にいれることが必要なのは明白でした。続いて、テストプロセスに関する標準を基にして、テストアセスメントに関する標準(ISO/IEC 33063)の作成も開始されました。さらにその後(2012年)、キーワード駆動テスト(ISO/IEC/IEEE 29119-5)に関する標準の作成が開始されました。ワークプロダクトレビューに関する新規作成の提案も現在投票中です。

The current set of standards handled by WG26, the joint ISO/IEC/IEEE working group on software testing, is shown below:

  • Concepts and Definitions (ISO/IEC/IEEE 29119-1) – published August 2013
  • Test Processes (ISO/IEC/IEEE 29119-2) – published August 2013
  • Test Documentation (ISO/IEC/IEEE 29119-3) – published August 2013
  • Test Techniques (ISO/IEC/IEEE 29119-4) – due for publication in 2014
  • Keyword-Driven Testing (ISO/IEC/IEEE 29119-5) – due for publication in 2015
  • Test Assessment (ISO/IEC 33063) – due for publication in 2014/2015
  • Work Product Reviews (awaiting approval – working draft available)

以下に、現在WG26が取り扱っている標準を示します(訳注:2015年1月時点の情報で翻訳しています):

  • コンセプトと定義(ISO/IEC/IEEE 29119-1) – 2013年8月発行
  • テストプロセス(ISO/IEC/IEEE 29119-2) – 2013年8月発行
  • テスト文書(ISO/IEC/IEEE 29119-3) – 2013年8月発行
  • テスト技法(ISO/IEC/IEEE 29119-4) – 2015年発行予定
  • キーワード駆動テスト(ISO/IEC/IEEE 29119-5) – 2015年発行予定
  • テストアセスメント(ISO/IEC 33063) – 2015年発行予定
  • ワークプロダクトレビュー(ISO/IEC 20246) – ワーキングドラフト準備中

The first three of these standards were published over a year ago, and were available as drafts for several years prior to that. Both the IEEE and BSI contributed existing standards, which were themselves developed by consensus over many years, as source documents to the project (these
standards will be retired as the new standards are published).

始めの3つの標準は1年以上前に正式に発行されており、ドラフトとしてはその数年前から入手可能になっています。IEEEとBSIはそれ以前に何年もかけてコンセンサスを確保しながら標準を作成していたのですが、それらがこのプロジェクトのソース文書となっています(IEEEとBSIの標準は、29119シリーズに統合されます)。

The availability of these international testing standards provides a
number of potential benefits:

  • Improved communication – through a common terminology.
  • Definition of good practice in the testing industry – a guideline for testing professionals, a benchmark for those buying testing services and a basis for future improvements to testing practices. Note that we do not claim that these standards define 'best practice’, which will change based on the specific context.
  • A baseline for the testing discipline – for instance, the standard on test techniques and measures provides an ideal baseline for comparison of the effectiveness of test design techniques (for instance, by academics performing research) and a means of ensuring consistency of test coverage measurement (which is useful for tool developers).
  • A starting point – for any organization that is looking to define their testing processes, templates, techniques or concepts for the first time.

29119シリーズが入手できることによって、以下のような効果が期待できます:

  • コミュニケーションの改善 – 用語の共通化を通して可能になります。
  • テスト業界における優れた取り組みの明確化 – テストのプロフェッショナルのためのガイドラインにも、テストサービスを依頼する顧客のためのベンチマークにも、優れた取り組みに向かう改善の基盤としても役立ちます。ただし私たちは、29119シリーズが「ベストプラクティス」だと主張するつもりはありません。何がベストなのか、は状況によって異なるからです。
  • テストのdisciplineに対するベースライン – 例えばテスト技法の標準は、テスト設計技法の効果の比較のベースラインを提供します。これは学術的な実証研究などで可能になります。またテストの測定の標準は、テストカバレッジの測定の一貫性を保証する手段を提供します。これはツールベンダにとって有用です。
  • きっかけ – 自分たちのプロセスやテンプレート、技法、コンセプトを最初に定義するために何かいいものを探している組織に有用でしょう。

Petition and Response /
29119シリーズに対する反対請願(Petition)とそれに対する回答

In August 2014 the following online petition was created and the
following is the response from the convenor of ISO Software Testing
Working Group (WG26), Dr Stuart Reid.

2014年8月に、以下のようなオンラインの反対請願が始められました。またそれらに対し、ISOのソフトウェアテストのワーキンググループWG26のコンビーナ(訳注:ワーキンググループのリーダのこと)であるStuart Reid博士が回答を以下のように行っています。

“To the President of the International Organization for Standardisation, We, the undersigned, hereby petition the International Organization for Standardisation to suspend publication of ISO/IEC/IEEE 29119-4 and ISO/ IEC/IEEE 29119-5, and to withdraw ISO/IEC/IEEE 29119-1, ISO/IEC/IEEE 29119-2 and ISO/IEC/IEEE 29119-3. It is our view that significant disagreement and sustained opposition
exists amongst professional testers as to the validity of these standards, and that there is no consensus (per definition 1.7 of ISO/IEC Guide 2:2004) as to their content."

「国際標準化機構(ISO: the International Organization for Standardisation)会長(President)宛: 我々この反対請願に署名する者は、ISO/IEC/IEEE29119-4, 5の発行の延期と、ISO/IEC/IEEE29119-1, 2, 3の廃止を請願します。我々は、これらの標準の妥当性についてプロフェッショナルのテスト技術者の間でかなりの反対(significant disagreement)と継続的な異議(sustained opposition)が存在し、内容についてコンセンサス(ISO/IEC Guide 2:2004のdefinition1.7に書かれています)が存在しないという見方をしています。」

Members of the ISO Software Testing Working Group (WG26) are well-versed in the definition of consensus. The six years spent in gaining consensus on the published testing standards provided us all with plenty of experience in the discussion, negotiation and resolution of technical disagreements – if nothing else, we are now experts at compromise and reaching consensus.

ISOのソフトウェアテストのワーキンググループ(WG26)のメンバは、コンセンサスの定義についてよく理解しています。29119シリーズに対するコンセンサスを得るために、6年の年月を経てきました。その間、技術的な反対に対して議論し、交渉し、解決するという多くの経験を積み重ねてきました。他のことはともかく、歩み寄りとコンセンサスに関して私たちは今のところ専門家になりました。

However, as a Working Group (WG) we can only gain consensus when those with substantial objections raise them via the ISO/IEC or IEEE processes. The petition talks of sustained opposition. A petition initiated a year after the publication of the first three standards (after over 6 years’ development) represents input to the standards after the fact and inputs can now only be included in futursussse maintenance versions of the standards as they evolve.

私たちにできることは、ISO/IECやIEEEのプロセスを通して提出された重要な異議に対して、ISOのワーキンググループ(WG)としてコンセンサスを得ることだけです。この反対請願は、継続的な異議について論じられています。最初の3つの標準は6年以上に及ぶ執筆編集の後に出版されましたが、ある反対請願はその1年後に始められました。現在のところ、反対請願は出版後になされたものであり、29119シリーズが将来進化する際の改訂にのみ含まれうる材料(input)になります。

It is unclear if 'significant disagreement’ reflects the number of professional testers who don’t like these standards or their level of dissatisfaction with their content, however the petition comments raise a number of issues which deserve a considered response:

「かなりの反対(significant disagreement)」が、29119シリーズを好まないプロフェッショナルのテスト技術者の数、もしくは内容に対する不満足さを反映しているかどうかは定かではありません。とはいえ、熟慮を要する回答を行うべき論点(issues)は増えてきています。

“The standards are not free." /
「標準なのに有償だ」

Most ISO/IEC/IEEE standards cost money (ISO is partially funded by the sale of standards), and the testing standards are no different in this respect. Personally, I would prefer all standards to be made freely-available, but I am not in a position to make this change – and do not know where the costs of development would come from. I can see that the charge made for the standards has forced a large proportion of those commenting on them to base their commentary on
second-hand descriptions of the standards – and with fuller access and better information I expect many of these people would have refrained from 'signing’ the petition and making incorrect statements about the standards.

多くのISO/IEC/IEEEの標準は有償です(ISOの活動の原資は標準の売上げによるものでもあります)。29119シリーズも例外ではありません。個人的には全ての標準は無償で入手できるべきだと思いますが、私はISOの仕組みを変える立場にありませんし、もしそうできたとしても標準を作成する原資をどこから得ればいいのかは分かりません。標準が有償であるため、標準にコメントしたい方々のかなりの割合が2次記述(訳注:標準そのものではなく標準について書かれた記事など)に対してしかコメントできないのは理解しています。もし標準が自由に入手でき、より良い情報に触れることができれば、反対請願に“署名した”方々の多くが署名しなかったでしょうし、標準に対する誤った意見表明もしなかったでしょう。

“The standards 'movement’ is politicized and driven by big business to the exclusion of others." /
「標準化“活動”は、巨額の利益を生むビジネスを自分たちで囲い込むための政治的な運動だ」

A large proportion of the members of WG26 are listed at our About WG26 page along with their employers. This list does not support the assertion in the petition. The seven editors (who do the
majority of the work) are from a government department, a charity, two small testing consultancies, a mid-size testing consultancy, a university and one is semi-retired. All WG members give their time
freely and many use their own money to attend meetings. As all received comments have their resolution fully documented anyone who submits a comment on a draft standard can easily see how their suggested change was handled – thus even those who cannot afford the time to come to WG meetings can easily influence the content of the standards. IEEE balloting also extends the consensus. For example, the IEEE balloting group for ISO/IEC/IEEE 29119-4 contains 76 people: 5 identify themselves as academic; 11 consultants; 9 government and/or military; 5 process management; 7 software producers; 5 project managers; 12 software product users/acquirers, and 21 with general interest.

WG26のWebページには、WG26のメンバのリストが所属と共に掲載されています。このリストを見れば、この反対請願の主張が支持されないことが分かります。7人のエディタ(かなりの執筆作業を行ってくれました)の所属は、政府機関、ボランティア、2つの小さなテストコンサルティング企業、中規模のテストコンサルティング企業、大学、そしてセミリタイア(訳注:長年勤めていた大きな企業を早期退職し独立して個人でコンサルタントを務めている)です。WGのメンバは全員自分の時間をたくさん費やし、その多くは自費で標準化の会議に参加しています。会議に提出された全てのコメントは、きちんと解決(resolution、訳注:コメントに従って標準案が修正されたり、コメントに従わないことを提出国が納得し同意すること)され文書化されますので、標準案に対してコメントを提出した人は誰でも簡単にコメントの結果を確認することができます。すなわち、WG会議に来る時間が無い人でも、自分が標準の内容にどのように影響を与えたかを簡単に確認することができるわけです。IEEEはそうしたコンセンサスを基に、さらに投票を行ってもいます。例えば、29119-4に対する投票グループは76名います。内訳は、5人は学術機関、11人はコンサルタント、9人は政府機関や防衛関連、5人はプロセスマネジメント、7人はソフトウェア開発者、5人はプロジェクトマネジャー、12人はソフトウェア製品を利用・購入する顧客、その他が21人です。

“The methods advocated haven’t been tried and the standards do not emerge from practice." /
「この標準で提案されている方法は十分に適用されているわけではなく、またこの標準は現場の実践から生み出されたものではない」

The number of years’ and range of testing experience on the Working Group (and the number of countries represented) shows that a wide range of experiences have been drawn on to create the standards. Early drafts were widely distributed and many organizations started (and continue) to use the standards – and so provided important feedback on their use to allow improvements to be made. At least one academic study at PhD level has been performed on the use of these early drafts within 14 different software organizations by Jussi Kasurinen of Lappeenranta University of Technology. Three of the main contributions of the thesis were described as: The concepts presented in the ISO/IEC 29119 test process model enable better end-product quality. The ISO/IEC 29119 test standard is a feasible process model for a practical organization with some limitations. The ISO/IEC 29119 test standard is a feasible foundation for a test process development framework.

WGに集まった何ヶ国もの代表の経験を基に何年もかけて議論したことは、29119シリーズをつくるために幅広い経験が引き出されたことを示しています。初期の標準案は広く配布され、多くの組織が適用し始めました(そして使い続けています)。そして重要なフィードバックが得られ、改善につながりました。ラッペーンランタ大学(Lappeenranta University of Technology)のJussi Kasurinenは、14の異なるソフトウェア組織に対して初期の標準案を適用するという博士号レベルの研究を行っています。この論文の3つの主要な結論は、以下の通りです:29119シリーズのテストプロセスモデルで提示されているコンセプトは、最終製品の品質をより高くできます。いくつかの制約はありますが、実際の組織で実現可能なプロセスモデルです。テストプロセスを構築するフレームワークの実現可能な基礎になります。

“The standards represent an old-fashioned view and do not address testing on agile projects." /
「この標準はアジャイルプロジェクトに対して論じておらず、時代遅れの代表である」

The standards were being continually updated until 2013 and so are inclusive of most development life cycles, including agile. As an example, the test documentation standard (ISO/IEC/IEEE 29119-3) is largely made up of example test documentation and for each defined document type example documentation for both traditional and agile projects is provided. The standards will be regularly reviewed and changes based on feedback from use have already been documented for the next versions.

29119シリーズは2013年から継続的に改訂されており、アジャイルを含むほとんどの開発ライフサイクルを含んでいます。例えば、29119-3(テスト文書)の大半はテスト文書の事例から構成されており、各文書に対して非アジャイルととアジャイルの両方の例を掲載しています。29119シリーズは、現在の版を利用した方々からのフィードバックを基に、次版に向けて定期的にレビューされ改訂されています。

“The standards require users to create too much documentation." /
「この標準は利用者に膨大な文書化を求める」

Unlike the IEEE 829 standard, which it replaces, the test documentation standard, ISO/IEC/IEEE 29119-3, does not require documentation to follow specific naming conventions nor does it require a specific set of documents – so users can decide how many documents to create and what to call them. The standard is information-based and simply requires the necessary test information to be recorded somewhere (e.g. on a Wiki). As stated above, it is fully aligned with agile development approaches and so users taking a lean approach to documentation can be fully compliant with the standard.

テスト文書に関する(29119シリーズに統合された)IEEE829標準とは異なり、29119-3は特定の文書名も文書のセットも要求しません。利用者がどの文書をどう呼んでどう利用するかを決められるのです。29119-3は、文書に記載される必要のある内容について求めています。別にWikiに書いても構いません。上で述べたように、アジャイル開発アプローチにも沿っていますので、リーンな文書化のアプローチを採用している方々にも29119-3は十分適合します。

“The existence of these standards forces testers to start using them." /
「標準が存在すると、テスト技術者がそれに従うことを強制される」

According to ISO, standards are “Guideline documentation that reflects agreements on products, practices, or operations by nationally or internationally recognized industrial, professional, trade associations or governmental bodies".

ISOによると、標準は「国内もしくは国際的に認められた企業団体や技術者団体、業界団体、政府機関による合意を反映した製品、方法、操作のガイドライン文書」です。

They are guideline documents therefore they are not compulsory unless mandated by an individual or an organization – it is up to the organization (or individual) as to whether or not following the
standards is required, either in part or in their entirety. However, if specified in a contract then they can define requirements on the testing, but as with all contracts this depends on the signatories. Because the standards includes the ability to apply its requirements in a range of
lifecycles, including agile, if a company is required to use the standards it will not prevent an agile approach.

標準はガイドライン文書ですから、特定の個人や組織によって義務として求められない限り、強制ではありません。標準の一部を義務として求めるのか、それとも全部なのか、も同様です。契約に記載されればテストに対する要求事項を明示しなくてはなりませんが、その契約にサインするかどうかは当事者の問題です。例えば、29119シリーズはアジャイルを含む開発ライフサイクルにおいて契約の要求事項を実現する能力を提供しますので、もしある企業が標準を使うことを要求しても、アジャイルアプローチを採ることを妨げません。

My view of the testing standards is that they will be of most use to testers who want to see a definition of good practice and see how close (or far) they are away from it. They can then decide if they wish to change their practices and if they wish to adopt the standard then they
are free to tailor it to suit their needs. One of the most common uses I make of the testing standards is to use them as checklists – I then have more confidence that I haven’t accidentally ignored an important aspect of the testing.

私見ですが、テストの標準は、よい取り組みの定義と、自分たちがどれくらいそれに近い(遠い)のかを知りたいテスト技術者にとても有用です。自分たちの取り組みを改善したいと望めば始められますし、標準を採用したいと望んだとしても自由に自分たちのやり方に合わせることができます。私が行っているこの標準の一般的な使い方は、チェックリストです。何か重要な側面をたまたま見逃していないかどうかの確信が持ちやすいですから。

“The Testing Standards are simply another way of making money through certification." /
「この標準は単に認証を通してカネを生むための新たな手段である」

There is currently no certification scheme associated with the testing standards, and I am not aware of one being developed. There is also no link between the ISO/IEC/IEEE Testing Standards and the ISTQB tester certification scheme. The ISTQB scheme could align with the body of knowledge represented by the ISO/IEC/IEEE testing standards, but that is a decision for those who run ISTQB.

現在のところ29119シリーズに関する認証制度はありませんし、そうした動きを私は知りません。同様に、ISTQBの技術者認定制度との関係もありません。ISTQBの制度が29119シリーズに示された知識体系に従う可能性はありますが、それはISTQBを運営している人たちが決めることです。

“The Testing Standards do not allow exploratory testing to be used." /
「この標準は探索的テストを許容していない」

Exploratory testing is explicitly included as a valid approach to testing in the standards. The following is a quote from part 1:"When deciding whether to use scripted testing, unscripted testing or a hybrid of both, the primary consideration is the risk profile of the test item. For example, a hybrid practice might use scripted testing to test high risk test items and unscripted testing to test low risk test items on the same project."

探索的テストは、価値の高いアプローチだと29119シリーズで明記されています。以下の引用は29119-1からのものです: “記述的なテストを行うか非記述的なテストを行うか、もしくは両者を混合して行うかを決める際には、テスト対象のリスクプロファイルを考えるのが第一です。例えば同じプロジェクトで両者を混合して行う場合、リスクの高いテストは記述的なテストを行い、リスクの低いテストは非記述的なテストを行う、といった方法がありえるかもしれません。”

If using exploratory testing (and also wanting to show compliance with the standard) then a simple rationale for not documenting tests in advance would be required. The standard also does not require the tests executed during an exploratory testing session to be documented – it does require they be “recorded", but this could be with a screen reader or as notes in a session sheet, and even this requirement can be tailored out if an organization deemed such recording as unnecessary.

(29119シリーズに適合する形で)探索的テストを行う場合、事前に文書を作成しないテストでよいという点について、簡単な理由が必要になります。同様に29119シリーズは、探索的テストのセッションで実行されたテストを文書化せよという要求もしていません。“記録”の形で十分ですし、何ならスクリーンリーダーを使っても、セッションシートへのメモでも構いません。その組織が不必要だとみなすのであれば、記録は不要だというようにテーラリングすることもできます。

“No-one knew about the standards and the Working Group worked in isolation." /
「この標準やワーキンググループが密室で決められていることを誰も知らない」

From the outset the development of the testing standards has been well-publicised worldwide by members of the Working Group at conferences, in magazine articles and on the web. Early in the
development, in 2008, workshops were run at both the IEEE International Conference in Software Testing and the EuroSTAR conference where the content and structure of the set of standards were discussed and improved. The working group also went to great lengths to invite the broader testing community to comment on the standard and to voice their opinions at meetings of our software testing standards working group, by placing information on the softwaretestingstandard.org website on how individuals can get involved in the development of the standard (see our How to Get Involved page). Since then I have lost count of the number of testing conferences where the standards were presented on and discussed. At every one of my presentations on the standards I have invited the audience to become involved in their development. Of course, I am not the only person who has spoken about the standards – experts from many countries have spoken about the standards and invited participation.

29119シリーズの作成は、WGのメンバによって講演されたり雑誌やWebの記事として執筆されて、始めから広く公表されています。作成初期の2008年には、ICSTというIEEEのテストの国際学会やEuroSTARというカンファレンスの両方でワークショップが開催され、29119シリーズの内容や構造が議論され改善されました。WGとしても、私たちのWGの会議の場で29119シリーズにコメントや意見を頂くべく、幅広いテストのコミュニティをお呼びするために色々尽力しました。個人として29119シリーズの作成に参加するための情報も、私たちのWebサイト(softwaretestingstandard.org)に載せています。2008年以後は、覚えきれないほどの数のカンファレンスに出席し、29119シリーズについて紹介し議論してきています。私はその都度、29119シリーズの作成に参加してもらうよう聴衆に呼びかけてきました。もちろん、私だけが29119シリーズについて話すわけではりません。多くの国のエキスパートが29119シリーズについて講演の依頼を受けています。

Testing experts from around the world were invited to take part in the development of the standards – these included a number of prominent members of the AST who were personally approached and asked to contribute to the standards early in their development, but they declined to take part. Other members of the AST have provided input, such as Jon Hagar, who is the IEEE-appointed Project Editor – and he has presented on the standards at the CAST conference.

29119シリーズの作成には、世界中からテストのエキスパートが参加しています。その中には、作成初期に個人的にアプローチし貢献したいと問い合わせてこられたAST(訳注:Association for Software Testing。この反対請願の原動力となっている団体)の著名なメンバもいます。その後辞退されましたが。また、29119シリーズに貢献しているASTのメンバもいます。IEEEから参加しているプロジェクトエディタのJon Hager氏です。CASTカンファレンス(訳注:ASTの年次カンファレンス)で29119シリーズについて発表も行っています。

“No-one outside the Working Group is allowed to participate." /
「WG以外からの参加は許されない」

There are a number of options for those interested in contributing to the standards – and these are all still open. The Working Group (WG) meets twice a year for 6 days – and is made up of experts acting in a personal capacity, appointed by national standards bodies, such as ANSI, or liaising organizations (e.g. IEEE). Most experts at Working Group meetings are supported by a 'mirror panel’ in their home country who act as reviewers and submit comments on the drafts. Many of these mirror panel members represent specific industry areas (e.g. financial testing), testing roles (e.g. independent consultant) or testing interest groups. These comments are then collated and moderated by the mirror panel to remove duplicates and contradictory suggestions before being submitted to the WG. The Working Group also accepts comments directly from any individual with an interest in software testing. Each comment is individually handled and the response to the comment is agreed by the WG and is fully documented. As an example, the WG itself resolved well over 3000 comments on the 'Test Processes’ standard. All comment resolution files are then circulated back to each country’s mirror panels, so that individual contributors can see how their comments were handled by the WG. This makes it a very transparent process that is accessible to any tester, anywhere.

29119シリーズに貢献する選択肢はいくつかあり、どれも有効です。WGは年に2回の会議を開催しています。会議は参加するエキスパートの個人的な尽力によって支えられており、またANSI(訳注:米国国家規格協会)のような国内標準化団体やIEEEのようなリエゾン組織とで日程調整がなされています。WG会議に出席するエキスパートのほとんどは、標準案をレビューしコメントを作成する自国の「ミラー組織」の窓口として出席しています。ミラー組織のメンバーは、金融分野のテストといった産業分野や独立コンサルタントといった職種、テスト関連の団体を代表しています。作成されたコメントは、重複したコメントや矛盾したコメントが無いよう、WGに提出される前に照合されてミラー組織によって整理されます。WGは、ソフトウェアテストに関心のある人なら誰からでも直接コメントを受け付けます。それぞれのコメントは、コメントごとに検討され、WGでの合意のもとに対応案が作成され、きちんと文書化されます。例えば、29119-2(テストプロセス)では3000をはるかに超えるコメントがWGで対応(resolve)されました。コメントに対する全ての対応が入ったファイルは各国のミラー組織に送付されますので、個人として貢献した方々は自分のコメントがどう対応されたかを見ることができます。これは、どこに住んでいるどんなテスト技術者にとっても、非常に透明なプロセスです。

“Context-Driven Testing isn’t covered by the standards." /
「29119シリーズでは、コンテキスト駆動テスト(Context-Driven Testing)はカバーされていない」

I fully agree with the seven basic principles of the 'Context-Driven School’ at http://context-driven-testing.com. To me most of them are truisms, and I can see that to those new to software testing they are a useful starting point. I also have no problem with context-driven testers declaring themselves as a 'school’, however I am unhappy when they assign other testers to other deprecated 'schools’ of their own making.

私は、http://context-driven-testing.comに載っている「コンテキスト駆動学派(Context-Driven School)」の7つの基本原則は全く正しいと思います。私にとってほとんどは自明のことですが、ソフトウェアテストを始めたばかりの技術者には有用なきっかけになるという点も理解しています。コンテキスト駆動の立場を取る技術者が自分たちを「学派(school)」と宣言するのは別に構いませんが、そうでない技術者を「反対派」のように扱うのは残念ですね。

Jon Hagar, the Project Editor for the ISO/IEC/IEEE 29119 set of standards, is a supporter of the context-driven school and he, along with the rest of the Working Group, ensured that that many of the context-driven perspectives were considered. For instance, the following statement is early in part 1: “Software testing is performed as a context-managed process."

29119シリーズのプロジェクトエディタであるJon Hagerはコンテキスト駆動学派の支持者ですが、WGの他のメンバと同様に、29119シリーズにはコンテキスト駆動の考え方が考慮されていると考えています。例えば、29119-1の最初の方には「ソフトウェアテストは、コンテキストをきちんと考えたプロセス(context-managed process)で行われるものである」と書いてあります。

The standards do, however, also mandate that a risk-based approach is used, as can be seen in the following quote (also from part 1): “A key premise of this standard is the idea of performing the optimal testing within the given constraints and context using a risk-based approach." I see no problem in following both risk-based and context-driven approaches simultaneously as I believe the context and the risk-profile to be part of the same big picture which I would use to determine my
approach to the testing.

とはいえ29119シリーズでは、リスクベースのアプローチを用いることを求めています。29119-1には「リスクベースのアプローチを用いて与えられた制約やコンテキストを満たしながら最適なテストを行うという考え方は、29119シリーズの重要な前提である」と書いてあることが分かります。私自身は、リスクベースのアプローチとコンテキスト駆動のアプローチを同時に追求することは問題無いと思いますし、コンテキストとリスクプロファイルは両方とも、私がテストのアプローチを決める時に考慮する全体像の一部だと信じています。

Dr Stuart Reid
Convenor, WG26
8th September 2014

2014年9月8日

WG26コンビーナ Stuart Reid博士