VSTePを語る夕べ

はじめに

このエントリーは、鈴木三紀夫さんが主催している『語る夕べシリーズ』コミュニティ？で2019年1月10日に語る内容の前半部分です。前半といっても『この内容が伝わればいいやというお気持ち』です。

いまは、10日の11時で、プレゼン資料はできているものの語る内容は未定です。私は、普段、プレゼンの原稿は作りません。また、練習も一切しません。どちらも良くないことと思っています。（プレゼンの練習は大切なことです）

でも、今回は、多数の申し込みをいただき、定員オーバーで参加されない方がいらっしゃるようなので、文字起こししてみました。ご興味のある方は、プレゼン資料と合わせてお読みいただければと思います。

ただし、この通り話すかどうかはわかりません。会場からの質問や、三紀夫さんらの突っ込みを受ければ、そちらの話題になることでしょう。

動機

connpassのイベント説明には、『秋山さんがVSTePについて語ります』とあります。私がVSTePについて語りたいと思ったのは、VSTePがすばらしい技術だからです。

でも、それだけの動機なら私よりも、にしさんや三紀夫さんが語ったほうがよいと思っています。では私のモチベーションは何か？　動機について少し書きます。

VSTePは2009年1月29日のJaSST東京のクロージングパネルで、提唱者のにしさんが発表したものが最初と思います。「テスト技法からテストメソドロジへの進化を目指して」と題したクロージングパネルには私も登壇し、HAYST法について発表しました。

あれから10年も経つのに、いまもVSTePやHAYST法が使われているなんて！　当時はまったく思っていませんでした。

さて、この10年の間にVSTePについて、私はにしさんのプレゼンを何度も聴きました。さらに一方的にプレゼンを聴くだけではなく智美塾という研究会で質問をしたり、メールやTwitterなどで、『テスト観点についてわかりません』と不躾な質問をし、回答をいただくこともありました。

また、にしさんも私のHAYST法のプレゼンを何度も聞いてくださったかもしれません。（直近では、JaSST 2018東北にいらしてくれました）。

でも、二人ともどんどん分かりにくい発表になっていると思うのです。ひとつには、手法の改善・進化によって伝えるべきことが増えて、相対的に内容が薄くなっているということがあるとます。さらに、私の場合は、“そのときに興味のあることに時間をかけてプレゼンしてしまう”という悪い癖があり、そこに大きな問題があると自覚しています。

でも、会場に見知った人の顔を見つけると、その人も退屈しない話をしたいなあ、この話は以前したので『また同じ話かー』と思われるだろうなあ、それは嫌だなあ、、、といった邪念が生じ、分かりにくい発表になってしまうのです。

そこで、VSTePの提唱者ではなく、横からイチ・ファンとして勉強させていただいてきたVSTePウォッチャーである私が話すのも面白いのでは？と思いました。
VSTePについては何度も使った実践経験もありますし。

さらに付け加えれば、『良くできた手法の完成形は、当たり前に見える法則』（いま、適当に考えました）がありますので、昔のことを知っている人が“その当時に、みんなが困っていたこと”とセットにして語ると、VSTePを構成する各要素が何をしたいのかが伝わるかなあと思い、それなら当時の状況を知っている私が語るのも一興かなあと、、、それが動機です。

テスト観点

VSTePのVはVewpointのVです。Vewpointはテスト観点のことです。

「テストで不具合を見逃すのは“テスト観点”が漏れていたからだ」という人がいます。そして、その意見は、「識者を集めて、“テスト観点”をたくさん見つけたので、次からは大丈夫」とか「識者がいないのでよい“テスト観点”をください」といった対策につながります。

そして、対策を始めると、“テスト観点”ってなんだろう？　JSTQBのテスト条件とは違うのかな？　テストケースを抽象化したものが“テスト観点”って本当かな？　ググッてサンプルを見つけたのでとりあえず使ってみるか、、、などなど誤った方向に進みがちです。

かくいう私も、“抜け漏れのない標準テスト観点リスト”を追い求めた時期がありました。三紀夫さんから、既存のテストケースから抽出したという“テスト観点”を見せていただいて、『すごいなあ』と思ったのは、2011年くらいのことでしたでしょうか。

あまりに上手くいかないので「テストで不具合を見逃すのは“テスト観点”が漏れていたからだ」はずるいロジックだ！（なぜなら、どんな場合でも当てはまるから、“よいものを良いと定義する”と同じ構図で、つまりは、なにも言っていないのと同じだ！）
などと、まるでイソップ童話の酸っぱい葡萄のキツネのようなことを思っていました。

いまなら“抜け漏れのない標準テスト観点リスト”を追い求めるというアプローチが間違っていたのだということが分かりますが、当時はそんな風に思っていました。

10年、20年前の日本のテスト業界の状況を思い出してみますと、当時は『テスト技法のセミナー』が花盛りでした。「テストをしても、バグを取り切れずにリリース後、市場不具合をだしてしまうのは、下手なテストをしているからだ。テスト技法を学ぼう」というわけです。

ところが、多くのセミナーは、1日で、V字の話と、テスト計画書の書き方と、テストケースを埋める表のフォーマットと、テスト技法を大体こんな時間配分で教えるものでした。

開始時刻	内容	時間
9:00	・イントロダクション ・開発とテスト	1
10:00	・V字モデル ・テスト計画書、計画書作成演習	2
13:00	・テスト技法（同値分割、境界値分析、デシジョンテーブル、業務シナリオテスト、ホワイトボックステスト）	1
14:00	・テスト技法演習	1
15:00	・テスト自動化ツール	1
16:00	・テスト最新情報（標準、コミュニティ、関連セミナー） ・セミナーの理解度確認テスト	1

2日コースの場合は、これに品質の話やプロセス（ISO9000やCMMIなど）の話が増えます。なお、このようなセミナーとは違い、5日間、ガチでテストという仕事についてトレーニングする松尾谷徹さんの『CFD法セミナー』もありましたが、それは特殊な例となります。

そして、上記カリキュラムは『テスト技法』をどこに使えばよいか分からない人を量産し、つまりは、『会社に戻ってもテスト技法を活用できず、なにも変わらない』ことが頻発していました。

事実、セミナーの話題になると「テスト技法習ったけど、仕事じゃ使ってないよ」と苦笑しあうのが常でした。

これについて、技法の教え方が悪いとか、例題が単純すぎるといった批判がでましたが、にしさんは、「そうではない。テスト技法は“テストしたい何か”を上手くテストする方法であり、みなが困っているのは、『何をテストすべきか』について深く考えず、テスト技法を使いさえすれば良いテストが出来ると思っているためではないか？」と考えたようなのです。

この『何をテストすべきか』が“テスト観点”です。このように考えると、テストの7原則の『原則6：テストは条件次第』が教える通り、“抜け漏れのない標準テスト観点リスト”を追い求めることはナンセンスと分かるでしょう。

（組織知として、テスト観点を蓄えて活用することは良いことですが。それは別の話です）

NGT

NGTは先に書いた“テスト観点”を抜け漏れなく挙げるための表記法です。『何をテストすべきか』が“テスト観点”と書きましたが、思いつきでバラバラとテスト観点を挙げていっても抜け漏れが発生するのは明らかでしょう。

これも当時の状況を思い浮かべるとなぜ木構造で段階的詳細化をしようとしたのかが、わかります。

当時（今もこの方法の組織もありそうですが……）、テストの準備というと、Excelを開いて、仕様書を書き写し、こんな感じの表（テストケース一覧表）を作るものでした。

No	機能	画面	条件	確認者	確認日	結果
1	検索	リスト表示	送信者名がXX	秋山	2019/1/10	〇
2	検索	リスト表示	受信者名がYY	秋山	2019/1/10	×
3	検索	メール表示

一見すると悪くないようにも見えますが、ここでは、「機能＞画面＞条件」とテストすべきことを3段階（固定）に分解しています。機能や画面をもっと深く分解したいこともあるでしょうし、逆に、画面を持たない（たとえば自動バックアップ機能）もあるでしょう。本来、様々な分解ができるものを固定3階層に当てはめようとするところに無理があるのです。また、テストケース間に関係があることも表では表現しにくいものです。

そこで、NGTは木構造で段階的詳細化を行なう記法となっています。

VSTeP

VSTePは、テスト観点に基づくエンジニアリング・プロセスのことです。NGTでテスト観点を抜け漏れなく挙げてから（もしくはNGT前に）何をどのような段取りで行なうかのプロセス定義です。

「テスト設計」という言葉が日本で聞かれるようになったのは2007年以降のことと思います。前述のようにテスト技法はその存在は知られていても実務ではほとんど使われていませんでしたし、テストといえば、『仕様通りに動作するかを確認する作業』という認識が多かったように思います。

そこで、開発の仕様書があれば、極端な話、仕様書をマーカーで塗りつぶしながら動作確認すればよく、それ以上のことはテスターに任されていたように思います。したがって、不具合をたくさん見つけられる『神の手を持つテスター』がいました。そして、その神テスターのノウハウは決して組織のノウハウになることはありませんでした。本人でさえ、「この仕様なら、ここを確認するっしょ」と今で言う「探索的テスターが頭の中で考えていることが分からない」のと同じ状況になっていました。

マイヤーズは、1979年の本でソフトウェアテストを『作業ではなくエンジニアリング活動の一つ（＝テストは作業ではなく技術が必要な活動）』と位置づけましたが、VSTePでは、開発の工程に対応したエンジニアリング・プロセスを取っています。テストプロセスを意識させたことは重要なポイントであり、VSTePの貢献の一つと思います。

語る夕べでは、このあとに、テスト観点・NGT・VSTePの中身について語ろうと思っていますが、それは、テクニック的な話なのでにしさんの資料を読めばわかると思います。