秋山さんがVSTePを語る夕べ
２０１９年１月１０日（木）１９時に開催しました「秋山さんがVSTePを語る夕べ」のメモです。
１．はじめに
■語る夕べシリーズについて
喫茶店や居酒屋などで話されている事柄をオープンの場で話します。登壇している２人（今回は１人ですが）の私的な会話に、皆さんを巻き込む感じです。セミナー講師が受講生に向かって理解させるというスタイルではなく、登壇者が勝手に喋りますので、ぐたぐた過ぎて、参加者の方が消化不良になることもあります。
登壇者の話に割り込んできても構いません。どんどん話に入ってきてください。
基本はツイッターで呟いていただいてかまいませんが、僕が呟かないで欲しいと言った内容については止めてください。ハッシュタグはこちらになります。
皆さんの判断でこれは「問題になりそうだな」というのがあれば、そちらも控えていただけると有り難いです。
「ツイッター班がいるので、呟かなくていいや」と思っている方もいるかもしれませんが、僕が寂しいので可能であればツイートしてください。
■本日の進め方
秋山さんにVSTePを語っていただきます。資料は事前に配布済みです。
では、よろしくお願いいたします。
２．秋山さんの講演
始めたいと思います。
資料はアップされていますし、今日話す内容は先ほどアップしました。
https://speakerdeck.com/kouichiakiyama/vstep-number-yu-ruxi-be
https://qiita.com/akiyama924/items/8bf5b9e0300ec95c5d5b
２－１．はじめに
VSTePは、にしさんが提唱しているテスト方法論です。本日使う資料は、にしさんの許可をもらって（にしさんの資料から）コピペしています。
資料に書きましたように、今日話すことは４つあります。
１．テスト観点
２．NGT
３．VSTeP
４．NGT/VSTeP
テスト観点
テスト観点という言葉。私はよく分からないので、にしさんにしつこく絡みました。なぜ分からないかというと、テスト観点が漏れたからテストが失敗したと言われます。では、テスト観点が揃っていればテストは失敗しないのか。
これが当初の悩みでした。
私なりにテスト観点という考え方が生まれた理由というのを考えてみました。どこからきたかというと、おそらくテスト技法の選択が難しいというのが発端でしょう。
2000年の頃って、ソフトウェアテストのセミナーに行くとテスト技法のセミナーしかありませんでした。１日のセミナーの中で、テスト技法の話は１時間ぐらいしかありません。そして１０個ぐらいのテスト技法を教えてくれます。１個１０分、カタログの紹介ぐらいです・
ですから、会社に戻っても、どのテスト技法も使えません。私の周辺の人たちの感想はそういうものでした。「テスト技法って使っていないよね」という話がたくさんありました。
にしさんもVSTePを教えるまでは、テスト技法を教えていたそうです。
そして、せっかく教えたのに使ってくれる人が少ない。なぜだろうと思っていたそうです。
テスト技法が難しいのではありません。何をテストしたいのかを見つけるのが難しいのです。何かをテストするという決まってからテスト技法を使います。年齢をテストしたい、というのが分かってから、じゃぁ同値分割を使おう。
テスト技法は後です。
この「何かをテストしたい」というのを見つける方法を誰も教えてくれません。テスト技法は既にあります。ですから、「これをテストしたい」というのを見つけたい。これをテスト観点という言葉でまとまられたのかなと。
一応、この資料はにしさんのチェックを受けていますが、にしさんは忙しい人なので、全部は見ていないと思います。もしかすると、にしさんの考えとは異なったことを語っているかもしれません。
NGT
何かをテストする。この何かを見つけつくす。
新元号のテストするとしましょう。
・新元号の当日、前日は確認したい。
・レイアウトが崩れるかもしれない。
こういうテストで確認したいことがバラバラと出てくる、そのような状態です。いくつか挙げられますが、テストしたいと思うことを見つけつくしたかどうかが確認できません。
確認するためには、NGTを作る。木構造で作る。
にしさんは、このようなことをしたいのかなと。
私は（大項目）機能があって、（中項目）画面があって、（小項目）条件があって、このようなテストケースの一覧表を作っていました。
この表記では、機能の下に画面があって、画面の下に条件があって、という構造です。この書き方は画面遷移のときとか書き難いんです。
こういう不便さの解消のために、木構造のNGTができたのだろうと思っています。
VSTeP：エンジニアリング・プロセス
10年ぐらい前ですが、携帯電話のテストは数百人集めて、数か月バグを取る、テストする、こんなスタイルでテストしました。でもって、いくら人を増やしてもバグがでつくせない。
これをどうにかするには、ちゃんとテスト設計しなくちゃいけない。
設計する前には分析が必要だよね。
じゃあ、粗い設計のことをアーキテクチャって言おうか。
設計と実装は分けたほうがいいよね。
このようにフェーズに分けてテストをやっていこう。
小さな犬小屋を作るなら、すぐに作り始めてもいいけれども、家を作るときには不安ですよね。家を作るには設計は必要です。
テストもエンジニアリング・プロセスなんです。
そもそも、79年にマイヤーズが「ソフトウェア・テストの技法」を書いたとき、テストに技法があるんだなぁと皆が思ったんですね。そのあと何十年もテスト技法の時代がありました。で、そこからVSTePが作られた。
NGT/VSTeP
NGTとVSTeP、二つを合わせた方法論です。NGT/VSTePというと、にしさんが決めた考え方に沿ったものと思われがちですが、NGT/VSTePには、NGT/VSTeP以外の知識、モデリングの知識とかが必要になります。
２－２．テスト観点（テストの意図・狙い）とは、
テスト観点をベースにしてテストへの要求を分析したい、というのがそもそもの狙いです。
にしさんが、よく説明で使っている三角形問題。このプログラムのテストが分かりやすかったのでそのまま紹介します。
三角形をテストする成立すること、成立しないことをテストしたい。
三角形には正三角形、二等辺三角形、不等辺三角形がありますから、これをテストしたい。
このようにテストしたいということを描いていきます。テスト観点の下にたくさんつけていきます。
段階的に詳細化していくと抜け漏れがなくなります。
きわどいところをテストするのではなく、こういうところをテストしたいというのがテスト観点になります。
テスト観点というのは、何をテストするのかを端的に表現したものです。文章では書きません。単語レベルで短く書いていきます。これが観点です。
よくテスト観点図を書いてもらうと、長く書く人がいるんですけど、この条件のキーとなる言葉を書いていきましょう。
似た言葉にテストケースがあります。テストケースは、テスト観点＋網羅基準になります。網羅基準はカバレッジ基準と網羅率が入っています。
カバレッジ基準として境界値をすべてテストする、網羅率１００％にします。このような感じです。正常境界値を基準にして、網羅率１００％ということになるかもしれません。
テスト観点は「正三角形」。正三角形をテストしたいということは分かりますが、このままではテストケースになりません。
同値分割で網羅しようでもいいですし、境界値で網羅したいでもいいですし、今回は正常境界値を１００％テストしたいでもいいです。基準を設定してテストケースに落としていきます。
テストケースはこれ以上分解できないという性質を持っています。一番細かいものです。
テストスクリプトが一番細かいのではないかと疑問に思うかもしれません。
テストスクリプトはテストケースの書き直しですから、別に細かくなっていません。
テスト実行する人に必要な情報を添付したものが、テストスクリプトです。またはツールが実行するのに必要な情報を付けます。
テスト観点は何をテストするかを決めています。何をと言いましても、何を出せばいいのか分かりません。
ですので、昔のにしさんの資料には、例を挙げて説明していました。
・グレードの違いをテストしたい。
・北米とかヨーロッパの違いをテストしたい。
・外部環境、固定的な環境、設置場所とか、変わる環境、温度とかをテストしたい。
・過去に発生した不具合をテストしたい。
こんなことをテストしたいよ、というのがテスト観点ですという説明でした。
最近は、CIBFWというのを言い始めています。トップの分割モデルがCIBFWです。それぞれ頭文字です。
CIBFWモデル
- Condition（条件）
- Item（テスト対象）
- Behavior（振る舞い）
- things Faulty or hazardous（嫌なこと全般。例えば、欠陥（バグ）/不具合（現象）、ハザード/心配事や懸念点等）
- World（その他、Customer of Customer、競合）
振る舞いは結果です。
FはFailureと最初書いたんですけど、間違いだとにしさんに指摘されました。FaultのFです。
Fは嫌なこと全般。嫌なことをFの下に書いていきます。
最後はW。その他。今までに入らないものを入れておきます。
お客様とか競合の情報とか、こういうのを書いていきます。
にしさんはこのようなフレームワークを使っています。
２－２．NGT
四角の記号がテスト観点です。角丸四角はテスト対象です。にしさんの最近の資料をみますと、テスト対象が角丸になっていないケースがありますので、別にこだわっていないようです。
一段階ずつ、丁寧に落としていきます。飛ばしません。ちゃんと分けて書いていく。これが重要です。
スライドの右に書いてあるのが表記方法ですが、これも適当でいいかな。にしさんも適当のようですし。にしさんの書いている資料を見ると、見るたびに違っているし、白い三角形をにしさんが書いているところをみたことがないですし。
でも、ある程度記法をそろえておかないと見にくいですよ。
ステレオタイプ、線の意味を言葉に書いています。線の上に文字を書いておけば、このような意味があるんだと分かります。記号を増やさずに情報量を増やしています。
この線、関係線、これとこれが関係しているよというのが関係線です。この関係線が気に入っています。テストケースを表でかくと、これとこれが関連するというのが書きにくい。NGTなら書けます。これがお気に入りです。関連線が好きだということで、例を挙げておきます。にしさんの資料にあったものです。
「新元号対応」をCIBFWで分割してみましょう。
Cで異常系、切替日はテストしたいですよね。2019年5月1日はしたいですよね。前日と翌日もやってみたい。
Cの条件は、入力なんですよね。入力というと、OCR、識別率をテストしたいなと。手入力であれば、入力チェックがありますね。こういうところをテストしたいなと。
Bの振る舞いであれば、画面をテストしたいとか。帳票をテストしたいとか。
帳票の中には文字化けみたいなのをテストしたいですし。
今までの明治・大正・昭和・平成・ｘｘとテストしたい。
このように文字を書いていきますが、漏れなく考えるために、文字化けとレイアウト以外に何かあるかなと考えます。
平成３５年をテストしたいと思ったとします。これは何を確認したいのか。
保険の満期日が確認したいのか、何を確認したいのかを書きます。
先ほど挙げた、機能と画面と条件・・・。大きな機能には複数の画面があるので、このようなカテゴリで分けるのも意味があるのですが、網羅しているかどうかを確認するのは大変です。
派生品のテストをするとき、最初の製品のテストで使ったテストケースを見ても何をしたいのか分からない。
リファインの例です。スライドにはA～Fの６個の観点があります。ここからデシジョンテーブルを作るとはしないでください。
この図をよく見ると、Bが中心になります。関連線の中心はBになります。
Bを軸にして２つに分けます。
「A, B, C, D」の組合せテストと「B, E, F」の組合せテストの２つに分けます。
関連線が複数繋がっていますが、これを２つに分けられると見破る。このように２つに分けると、テストしやすいと。
テスト観点図を綺麗にすることをリファインするといいます。育てる。きれいにする。納得する。みんなが共感する。皆がすっきりする。これをリファインと言います。
やり方は、スライドに書いてあります。にしさんは文章として書いていますが、私の方でリスト化しました。
（１）リファインするとき、手作業でテスト観点を入れ替えるのは大変なので、パソコンで作業します。
（２）次にやることは、テスト観点に複数の意図が含まれていないことを確認します。結構見直すと、複数の意図が入っていることもありますので、ひとつにしてください。分割するか、余計なことを省くか。
（３）言葉を見直します。何をテストするのか、三角形をテストするのか、図形とか、意図が分かるように、名前を変えていきます。名前を変えることでテスト観点図が読みやすくなります。帳票で本当にいいのか、プリントアウト結果がいいのか。
（４）全体の構造を見直します。似たような構造がいろいろとぶら下がっていますので、抽象化して書き直したりします。
（５）ここまでで全体の観点の構造をしっかり掴んだうえで、テスト観点が抜けているところを追加します。綺麗な構造を作ってから、ツリーを増やしていきます。
（６）最後に汎化していきます。もう一段抽象化すれば、コピーのテストがプリンターのテストでも使えるようになります。最後までやれば、テストケースが資産になります。
２－３．VSTeP
いきなりテストを始めません。順番にテストを定義します。
TRA：テスト要求分析
TAD：アーキテクチャー設計
TDD：詳細設計
TI：実装
この順番でやっていきます
TRA：テスト要求分析
テスト観点を段階的に詳細化していきます。テストするものを挙げます。どんな条件でテストするのかをぶら下げていく。テスト観点図を作った後にリファインします。リファインを繰り返します。
一人でつくることはないので、チームでみんなで観点図を見ながら議論ができます。議論しながら、完成させて、みんなこのテストをしたらいい製品になるよなと納得します。
１００％完璧なものを作ろうというわけではありません。
このチームで何をテストしようとしているのか、どのような結果が得たいのか、自分が持っている知見を全部反映して、納得できたら祝杯を挙げる。このようなために書きます。
なお、テスト観点図はモデルなので、簡易的なキーワードだけで書きます。
TAD：アーキテクチャー設計
テストアーキテクチャ設計は、大規模テスト時だけでよいと書いてありました。小さい規模のものはテストアーキテクチャは無いかもしれませんが、仕事はたいてい大規模ですので、仕事でテストをするときは、テストアーキテクチャ設計をするのかもしれません。
テスト観点をグルーピングして、テストコンテナを作ります。テストケースは一番小さいものですから、入れ子にできません。テストコンテナは入れ子になります。コンテナの中にコンテナを入れる。
どのような順番でテストするのか、このようなことを決めるのがテストアーキテクチャ設計になります。こうすれば上手くいくというテストの全体像を示します。
ここでも納得と共感が大切なんです。
TDD：詳細設計
詳細設計は、テスト観点からテストケースを作ります。網羅基準をどこまでにするのか。網羅基準を先に決めてから、テストケースを作っていきます。最終的にはテストデータになります。実際の値まで入れていく。具体値を作ることまでがTDDです。
TI：実装
最後は実装なので、テスト自動化スクリプトを作っていきます。
２－４．テストコンテナとテストフレーム
テストコンテナという言葉とテストフレームという言葉が耳慣れないので、説明しています。
テストコンテナ
スライドを見てください
ユニットテストの中には、構造テストと再発防止テストが入っています。
構造テストは、制御フロー、データフローというふうに分けることもできます。
統合テストでは、・・・・
システムテストでは、・・・・
このように観点をバラバラにして分けますと、開発者がやりやすいとかが分かってきます。
昔はテストレベルとかテストタイプとか呼んでいたのですが、テストコンテナになっています。分かりやすく例を挙げますと、テストコンテナはリングファイルのようなものです。
テストフレーム
テストフレームというのは、テストケースを抽象化したものです。条件と対象と振る舞いを組み合わせたものになります。
自分がテストケースを書いていると、このようなパターンになったりします。
契約数 × バックアップ機能 × 処理が終わるか
条件と対象を組み合わせを考えるのですが、細かい、テスト観点単位で考えるのではなく、よくあるテストケースのパターンで考えています。単独の観点からではなく、いくつかの観点からテストケースを作ります。
関係しているものをパターン化してあれげれば、いろんなところで作れます。
以上で講義は終わります。
次から質疑応答に移ります。
質疑応答につきましては、togetterをご確認ください。
この記事が気に入ったらサポートをしてみませんか？