More than 5 years have passed since last update.

リリカルにVSTePを語る夕べというイベントに参加しました

Last updated at 2019-07-22Posted at 2019-07-22

はじめに

半年以上前ですが（現在2019/07/23）、リリカルにVSTePを語る夕べというイベントに参加しました。
開催日時：2018/12/26(水) 19:00 〜 21:00

VSTeP(Viewpoint-based Software Test Engineering Process) とは、電気通信大学の西康晴さんが提唱しているテスト技法のひとつです。
このイベントはVSTePの解説をする場ではなく、VSTePをある程度知っている人（リリカルさんとイベント参加者）に対して、当イベントの主催者（みっきーさん）がVSTePを語る会。
VSTePについて体系立った情報が欲しい人は「関連資料」にある資料を見て下さい。
この記事は、それらの資料を見た後に読むともしかしたらためになるところがあるかもしれない。。。という記事です。

本題

イベントに参加した時の私のメモです。

（VSTeP以外の代表的なテスト技法との比較）
HAYST法は手順がちゃんとしてるはっきり決まっている。
ゆもつよメソッド（※）はゆもつよマトリクスといういいカンジの表をつくる（全体を網羅出来てる感じがある）。
※ゆもつよメソッドについては以前こんな記事を書いているのでよければご参照ください。

VSTePには2つの使い方がある。
プラットフォームとして
　→各種方法論のメリットデメリットを比較するため。
テスト開発方法論として
　→私はテストをこう考えると発言するとき

VSTePの特徴
テスト要求分析こそが！(リリカルさん)
テストアーキテクチャ設計こそが！(みっきーさん)

どういうSTEPを踏んでテストケースに落とすか

資料より抜粋

テストアーキテクチャ設計は、まだまだ定着していない考え方。
テスト好きな皆さんは知っている、当り前の作業。
四角と矢印や線を使ったモデリングを行う。
テスト要求分析のアウトプットとテストアーキテクチャ設計のアウトプットは別
『テスト観点』という部品で構成される、という点では一緒

テスト要求分析

ソフトウェア要求分析があるようにテストにもテスト要求分析がある。
テスト要求の源泉…ミスると観点が抜け落ちる。
あなたがもらった要求の源泉となる文書は完璧なものですか？
要求の源泉となるモノに対して吟味したことがないことを恥じる必要はない。
足りないじゃんとか不足してるじゃんという見方を伝えたらみんな理解できる。

１．テスト要求モデリング

テスト要求をモデリングする。
モデリングの２つのアプローチ

トップダウン型

資料より抜粋

テスト観点は、ボトムアップとトップダウン両方から一気に書く。どれかを選ぶと何かが落ちるので、書き直すことが必要になる。
⇒西さんの回答「反復的にモデリングしますよ」

資料より抜粋

トップダウンだと、メインブランチをきっちり決めておきたがる人が多いが、無理です。
対策として、品質特性とかユーザ特性などで気にするところを書く。
ただし、取捨選択すると何かがおちる。
最初からがっちりは作れないので、行きつ戻りつする。

品質特性だったり会社で持っている観点にしたり、「この立場の人だったらこういう観点を見たいはずだ・・・」という人もいるが、無理です。推測にしかならない。
立場：ユーザー、システム管理者、開発者、発注者

通常、「要求」と言えば、やりたいこと。イメージ付きやすい。
「テスト要求」と言われると、何？よくわからん。ってなる。
⇒テストしたいなと思うことをテスト要求という。
VSTePのテスト観点がテスト要求。

・エンジニアリング要求
テストケースに直接結び付くもの
・マネジメント要求
テストケースを導かないもの。制約となるもの。
制約は極力排除して後方で取り込む
VSTePではアーキテクチャ設計まで終わらないと計画が出てこない。
「テストをいくらでやりたい」はテスト要求？
　⇒それはマネジメント要求。制約事項に当たる。

VSTePを用いた場合でも、全体テスト計画を考える中で、テスト戦略的な要素が入る。
制約・束縛・前提条件をテストアーキテクチャの中に入れて、順序を変更するということはやっても良いと理解している。
例：セキュリティテストは、自社で実施できないので外注する。

日立の河野さんという方の資料がある。
テスト設計コンテストの2年連続チャンピオンの方。
これを見れば、テスト要求が何かがわかるかもしれない。
・テスト設計コンテスト'13 優勝チームの成果物

ボトムアップ型

資料より抜粋

２．テスト観点図

資料より抜粋

テスト観点：テストしたいなと思うもの、こと、など「テストしたい何か」をテスト観点と呼んでいる。
VSTePでは”テスト観点”という言葉を明確に定義していない（それぞれの会社の方言とかとぶつからないように包含する）。

マネジメント的要求は、テスト観点には(ほぼ)入ってこない。極力排除する。
これはテスト計画に入ってくるもの。

テスト観点図をつくるときにはオブジェクト指向の見方を取り入れると良い考え方ができる。
テスト観点　⇒　クラス図で表現できそうな書き方になっている。

広義のオブジェクト指向の話。
理解の三つの秘訣
私たちが物事を認知し，それを伝達するために，どんな戦術を用いているかを分析的に考察してみよう。ある物を説明する際に，
(1)　これが何からできているのか
(2)　これと似たようなものがあるか
(3)　これでどんなことができるのか
などを述べる。

３．モデルの構築と納得

資料より抜粋

テスト観点図を書くと書きすぎることが多くある。
⇒剪定しましょう。
その後確認しましょう。
関係者と合意しましょう。

VSTePは、関係者間の合意を重視している。なぜ合意が必要か？
テスト観点図の末端はテストケースに結び付くものだが、剪定する。
つまりはテストケース数のボリュームを減らす。
剪定で刈り取りすぎるとテスト観点が足りなくなる。テストケース数が減る。
関係者集めてどこまでやりますか？を、図を見て意見し、合意する。
テスト観点は図で書いているので専門家でなくてもわかる。開発者じゃなくても意見が言いやすい。

一方、HAYST法では、関係者との合意がない。
⇒VSTePとHAYST法で違うところ。
ゆもつよメソッドも合意を取りに行く。
図を書いて合意を取るのがVSTePの特徴。
HAYST法：関係者集めて合意は取らない
VSTeP：剪定して確定、関係者集めて合意を重視

テストアーキテクチャ設計

巨大なソフトウェアをつくるとき、構造物としてモノを見る。ソフトウェアの巨大化に伴いテストケースも膨大なものになる。
膨大なテストケースも構造物としてみようよ。
　⇒テストアーキテクチャ設計が必要

資料より抜粋

実務では組織にあるテストアーキテクチャのストックを使っているし、あるのに「テストアーキテクチャの設計をしよう」とはならないことが多い。

計画とテストアーキテクチャ設計は分ける。
VSTePでは分けようとしている。分けようと努力している。

テストアーキテクチャが決まらないとテスト全体計画を作れない。・・・というのが西さん（VSTePの考案者）の考え方。
VSTePでは、テスト要求分析→テストアーキテクチャ設計→全体テスト計画の順序で進める

ある会社の場合、テスト要求分析を実施したあとで、全体テスト計画を作る。
全体テスト計画は、テスト戦略とテスト実行計画で構成される。
テスト戦略は、自組織で持っている場合がある。
テスト戦略の例：「システムテストでは、性能テストやシナリオテストをやる」

自組織で持っているものを使う場合でも、「同じような開発である」という前提がある。
プロジェクトに応じて、必要なテストタイプを選ぶ。
↓
IoTをクラウドで作るとした例。
IoT：組み込み
クラウド：エンプラ寄り。組み込みのノウハウしか持っていないような会社が、クラウドでIoTを作るとなったら、テストアーキテクチャ設計からやらないといけない。
社内のプロセスに合わせて適切なものを選ぶ。テーラリングする。
プロジェクトの状況に合わせてこれをやる／やらないを選んでいた。

VSTePではテストタイプのストックあるなしを考慮していない。
あれば使うけど、なくても成り立つようなプロセス、やり方になっているのがVSTeP
つまりVSTePは、自組織に蓄積されたナレッジがない、または流用できない場合でも適用できる。

テストタイプ：負荷テスト、構成テスト（動作環境変更テスト）、セキュリティテストなど。
例えばシステムテストならこのテストとこのテストやる！みたいな雛型。
先輩にシステムテストって？と聞くとでて来たりするやつ。

テストコンテナ

資料より抜粋

テストコンテナモデル
テストコンテナ：便利に色々突っ込める箱。テスト観点を入れる箱。
（よくわからないひとはテスコンチュートリアルの資料で雰囲気を掴むのが大切）
テスコン(OPENクラス)のチュートリアル資料

初心者の方は、この資料を見て雰囲気を掴むのがおすすめ。
同じテスト対象でも、コンテストの参加者(が持つ経験)によって見え方が異なり、様々なレイヤーで表現される。
レイヤー型以外にも、フィルター型など様々なアーキテクチャがある。これらを参考にすると良い。

にしさんが語るテスト設計チュートリアル
https://note.mu/kataruyube/n/ncec3070bffa8
https://scrapbox.io/kataruyube/にしさんのテスコンチュートリアル

性能テスト（コンテナ）
⊢ 長時間テスト
└ 負荷テスト
⇒性能テストコンテナの中に、長時間・負荷テストのコンテナを入れる。

テストコンテナ間の関係
・包含関係
・依存関係（順序とか。品質担保してからじゃないと性能テストできないとか）
・合成関係
『不具合のせいで落ちる』状態で、性能テストを始めることはできない。このように、順序を考慮することもテストコンテナの整理といえる。
これらは、ヒト・モノ・カネは関係ないので、『エンジニアリング的』の範疇

テストフレームモデル

資料より抜粋

テスト詳細設計では頭を使わずに、自動的にやりたい（と西さんは思っているだろう）。
VSTePで言うところのテストケース
パラメータとバリューの組み合わせ＋網羅基準で出来る。と、VSTePでは考えている。

因子×水準
普段、事前条件とか操作とか合格条件を書いている。
事前条件とかがあがる時もあるが、ポイントはそこじゃない。
実務で使うテストケースとはちょっと違うかも。大中小項目とか。
いわゆる『大中小項目』は、テスト観点図で表現しているので、テストケースに表れない。
パラメータとバリューの掛け算をするとテストケース数が膨大になるので、網羅基準を設ける。
網羅基準は、剪定をするときに決めている。値さえ決めれば、テストケースは自動的に生成できる。
そのため、テスト詳細設計はあまり語られない。

QA

会場からの質問「テストコンテナにおいて、矢印の読み方は定義されていますか？(『依存関係』など)」: ・みっきーさんの回答; 「矢印は、『順序』を示していると理解していますが、それが正解かどうかはわかりません。」; ・西さんの回答; 前後依存関係。デフォルトでは。
会場からの質問「テストコンテナの中に網羅基準を書くか？」: ・みっきーさんの回答; 「網羅は考えるが、このタイミングでは網羅基準は考えない(後工程でも良い)」
twitter上での質問
みっきーさんの質問「計画に落とすときには順序になるけど、アーキテクチャ上はあくまでも前後の依存関係として認識するという理解であっていますか？」: 西さんの回答：正しい

イベント内でおすすめされた本

・榊原さんが監修された「ソフトウェアシステムアーキテクチャ構築の原理」もおススメ。
https://www.amazon.co.jp/dp/4798116424
https://www.amazon.co.jp/dp/B00ZF44J0I

・実践ソフトウェアアーキテクチャ
https://www.amazon.co.jp/dp/4526055239
※アーキテクチャを学びたいリリカルさんへの参考図書。ただし、現在はプレミアがついている。

・Software Architecture in Practice
https://www.amazon.co.jp/dp/B009GMUL84
※「実践ソフトウェアアーキテクチャ」の原著。プレ値はついていないが、英語。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up