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…

VSTeP

Twitterで2013/6/14で@akiyama924さんからご質問頂いたものをまとめておきますね。回答もTwitterで行ったので、140字ずつになっていますから、少し読みにくいかもしれませんが、ご容赦下さい。

にしさんには、テスト観点でない観点を何故それはテスト観点ではないのかといった理由とともに教えてほしいです。「意地悪漢字はテスト観点ではない」「同値はテスト観点ではない」等々の理由。その辺がもやっとしています。

 まず、同値はテスト観点ではない、というのは正確ではありません。同値クラスは(末端の)テスト観点ですが、境界値はテスト観点ではありません。境界値は、あるテスト観点のカバレッジ基準、もしくは選ばれた値そのものに過ぎないからです。全値、代表値、境界値などは全て同様です。

で、この説明を聞くとモヤモヤ感が高まると思います。

実はテスト設計における境界値というのは、2つの意味があるからです。1つは、同値クラスの主要な代表値としての意味。もう1つは、バグを如実に叩き出す武器としての意味。

テスト技法のセミナーを想像してみましょう。私の基礎コースもそうですが、同値分割の後に境界値分析を扱い、両者は関連があると教えることが多いですね。

しかしよく考えてみましょう。同値クラスというのは全て同じふるまいをする入力値集合です。しかし境界値とは、同じ同値クラスに属する他の値よりもバグを検出する確率が高いのです。ならば、境界値とそれ以外の値は、同じ同値クラスには属しません。なぜなら、ふるまいが異なると予想されるからです。

ここから論理的に帰結されるのは、実は境界値分析は同値分割と「意味的に」つながっていないということです。手順的につながっているだけです。言い換えると、境界値分析というのは同値分割に新たなテスト観点を加えているわけです。

もう少し正確に表現しましょう。同値分割は、入力条件網羅を行うためのテスト要求分析の技法です。境界値分析は、入力条件網羅のテスト詳細設計の技法です。これが一つの位置づけ。この位置づけを元に、NGTでは「境界値はテスト観点ではない」と取り扱います。

もう一つの解釈をすると、境界値分析はif文の比較演算子のミスや配列の境界越えのようなバグのパターンを示唆するテスト観点に基づき、テスト要求分析からテスト詳細設計までを統合した技法です。

この解釈を取るのであれば、境界値という曖昧なテスト観点よりも、むしろ「比較演算子のミス」をテスト観点として挙げた方が、モデリングが分かりやすくなります。ですのでNGTでは「境界値はテスト観点じゃないよ」という教え方をしています。

エキスパートの皆さんがモヤモヤしないように正確に表現するならば「境界値そのものじゃなくて、境界値で狙っているバグのパターンを直接テスト観点として挙げましょう。何のバグを狙ってもいない境界値は、単なる同値クラスのカバレッジ基準ないし値ですから、テスト観点ではありません」となります。

意地悪漢字も同様です。意地悪漢字が狙っているバグのパターンを直接テスト観点として挙げる方が、モデリングとして分かりやすくなります。

ただそれが難しいことも多々あるので、最終的にテスト観点に残さない前提で、他のテスト観点と組み合わせて考えるヒントとして、境界値や意地悪漢字が初期のテスト観点図に出てくる方がモデリングしやすい、ということであれば、別に構わないと思います。私もそうすることがあります。

あ、まだ疑問があったか、テスト技法はテスト観点じゃない、というやつね。

NGTでは、テスト技法はテスト観点じゃないという説明をしています。それは、テスト技法というのが何を意味しているか、に依存した説明です。より正確に言うと、一般的にテスト技法という用語が含んでいるものは、単純にテスト観点になるわけじゃないよ、という意味です。ヒントにはなります。

一般にテスト技法というのは、2つの工程をいっしょに行います。テスト要求分析すなわちテスト観点の特定と、テスト詳細設計すなわちテストデータの特定です。ただ面倒なのは、片方しかやらないテスト技法もある点です。

例えば境界値分析は両方やりますし、同値分割はテスト要求分析が主です。制御パステストはテスト詳細設計が主です。

テスト観点を挙げる時にヒントとなるのは、制御パステストのようにテスト詳細設計を主に行う技法です。なぜなら、テスト詳細設計を行うためにテスト観点を特定しているからです。テスト技法をテスト観点にすると、そのテスト技法で特定しているテスト観点を挙げていることになります。

ただall-pair法のように、テスト詳細設計を主に行うのにテスト観点を特定していないテスト技法もありますから、そう一筋縄ではいきません。ですのでNGTでは、テスト技法はテスト観点を挙げる際のヒントにはなるけれど、直接テスト観点にすべきではない、と説明しています。

一般に、NGTを教わるテストのモデラーはここまでテスト技法について考察しているわけではありませんので、ここまで詳しく説明するとかえって混乱を招くと予想されます。

要するに「テスト技法」という用語は、テスト要求分析とテスト詳細設計が分離されてなかった時代につくられた用語なので、テスト観点の特定とテストデータの導出の切り分けが難しい用語なのです。それが本件の原因。これは29119-4でテスト条件の粒度がずいぶん変わることからも分かります。

VSTeP

 2012/4/3に行われたWARAI(関西テスト勉強会)の受講者の方から頂いた質問です。

NGTはUMLのクラス図によく似た記述形式ですが、UML同様、関連に方向性があったりするのでしょうか?それともテスト観点に、依存関係の方向などなく、すべてフラットに抽出すべきでしょうか?(あるテスト観点と「その前提となるテスト観点」などは依存関係が存在しそうにも思えます。。。)

 ご質問ありがとうございます。まずお答えを先に申し上げてしまうと、関連に方向性をつけるかどうかはモデリングを行うテスト設計者が決めて構いません。

 ちょっと分かりにくいですね。NGTという記法としては、順序依存性を持つ関連に対して開き矢印で方向性を表します。一方、組み合わせテストの必要性のように方向性を持たない関連に対しては、矢印の無い直線で表します。また、関連の表す意味についてはステレオタイプで表します。WARAIではその辺りを詳しく説明する時間がありませんでしたね。申し訳ありませんでした。

 ところで、ご質問で気になるのが「前提となるテスト観点」という言い回しです。この「前提」とは、どういう意味でしょうか。もしこれが、回帰テストのように、Aというテスト観点から導出されるテストスクリプトを実施した後でBというテスト観点から導出されるテストスクリプトを実施する、という実施順序しか意味していないのであれば、その関連Xをテスト要求モデルに記述すべきではありません。その関連Xはテスト要求を満たすことに何も寄与しないからです。例えば、Bのテスト観点の必要性がAのテスト結果によって変化する(Aのテスト結果によってはBのテストをしなくてもよくなる、など)のであれば、テスト要求モデルに記述すべきです。もし、実施順序をそう定めることで実施効率を向上したいという意図があるのであれば、テストアーキテクチャ設計モデルに記述すべきです。これは記法の問題ではなく、モデリング技術の問題ですね。

 NGTの説明を聞くと記法に気を取られてしまいがちですが、モデリング技術も重要です。NGTはステレオタイプなど自由度の高い記法を指向していますので、皆さんがモデリングしたい構造を把握していればきちんと記述できます。ですので記法の限界を気にするよりも、記述しようとしている構造はどういう意味でどういう位置づけなのか、を考えることに時間を割くようにして下さい。そうすれば実り多いテスト開発が可能になると思います。頑張ってくださいね。