JaSST 東北 2016 おかわり会ツイートまとめ

リリカル @mhlyc

ツリーを作っていくにはボトムアップのやり方とトップダウンのやり方とがあって、ボトムアップは比較的やりやすいです。テストパラメータなどは具体的な値が出てきますし、よりテスト実施レベルに近いのでイメージもわきます。 #sendaitest

リリカル @mhlyc

対してトップダウンでのツリー作成は、ある程度そのドメインにおける完成形とか経験的にこんな構造だと良さそうだよね、みたいな認識が持てていないと難しいです。項目が全然出てきません。 #sendaitest

リリカル @mhlyc

なのでボトムアップとトップダウン両方の視点が必要です。トップダウンだとそもそも項目があまり出てきませんし、ボトムアップでは詳細な項目を検討しすぎてしまって分類に四苦八苦しがちです。 #sendaitest

リリカル @mhlyc

実際にやってみた感覚では、よほど意識しなければボトムアップからの観点出しになってしまい分類で力つきるパターンになります。ボトムアップだと観点出しやすいので、あたかも順調に進んでる感があるのです。 #sendaitest

リリカル @mhlyc

なので、折を見て「そもそもどんなソフトウェアが必要なんだっけ？ 」とか「お客さんの要求にはどんなものがあったかな？」みたいな質問をメンバーに投げかけたりして、要件ベースとか品質特性ベースとかより抽象的な視点で既存の観点を捉え直したりするのが大事です。 #sendaitest

リリカル @mhlyc

あまりに抽象的な項目ばかり出てくるのも「何テストしたいんだよ」となるので考えものですが、ある程度は抽象的な視点で整理ができていないと、全体から詳細への観点の落とし込みにならないのですよね。#sendaitest

リリカル @mhlyc

いきなり詳細な項目が検討されているので、洗い出されている量が多いわりには「これでほんとに網羅してるんだっけ？」という問いにはうまく答えられない。 #sendaitest

リリカル @mhlyc

なので、うまく発散と収束の考え方を使い分けながらMECEでレベル感の揃ったツリーを作成していくのが達成したい事柄になります。しかし発散にはそこまで訓練は必要なさそうだけど収束にはかなり訓練が必要そうだな。というのが私が今日やってみた感想です。 #sendaitest

リリカル @mhlyc

さて、次はこうして作られた漏れやダブりのない（はずの）ツリーをもとにして、いよいよテストコンテナの作成に移っていきます。 #sendaitest

リリカル @mhlyc

テスト観点図（ツリー）を作っていく段階で、漏れがないかとかは色々検討されているわけですから、これをもとに作成するテストコンテナの要素は、自然と必要なテストを網羅したものになります。 #sendaitest

リリカル @mhlyc

なのでテストコンテナを作成するうえで考えることはツリーを整理するときとはまた別で、「どの順番でテストするか（できるか）」「どのテストが並行して実施できるか」といったことになります。 #sendaitest

リリカル @mhlyc

テストコンテナを作成することは、言い換えるとテストの依存関係や優先度に基づいてテストの集合を定義し直すということです。 #sendaitest

リリカル @mhlyc

テストの依存関係を考える時は、「このテストが失敗することでブロックされるテストは何か？」というのを考えるとやりやすいです。#sendaitest

リリカル @mhlyc

例えば、基本機能がそもそも動いていないのに異常系や境界系のテストは行えませんよね。 なのでこの場合は基本機能のテスト→異常系・境界系のテスト　という依存関係が導かれます。#sendaitest

リリカル @mhlyc

依存関係がある程度洗い出されたら次は優先度をつけていきます。これを行うのは、すべてのテストを実施するのに必要な工数が用意されるとは限らないからです。 優先度は修正コストの大きさ、見逃し時のリスクの大きさなどで決めることができます。 #sendaitest

リリカル @mhlyc

顧客と「基本機能から順次納品していく」みたいな契約をしているならば基本的な機能をサブ的な機能よりも基本的に優先するということもありますが、状況やプロダクト、ドメインによって変わります。 このコンテナの分け方がテスト設計の勘所であり、腕の見せ所でもあります。#sendaitest

リリカル @mhlyc

テストコンテナは、ツリー作成の時とは打って変わり「テスト実施者」としての観点を考慮することができます。この機能は先にやっておけるといいよね、この確認項目はこのテストの時に一緒に確認出来るね、など。観点モデリングを行う際に大切なのは、現実に沿っていることです。#sendaitest

リリカル @mhlyc

テストコンテナ作成まで行くと実務上のメリットがありありとわかってきます。 実施のしやすさでテストを整理できるのですから。 さらに、こうした意図がテストコンテナに反映されれば再利用性も上がり、第三者への説明もしやすくなります。#sendaitest

リリカル @mhlyc

少し話が逸れますが、何をテストするのかを事前に開発者に伝えるのは大事です。 テストする側が何を気にしているのか分かれば、開発者からしてもどこを念入りに確認したらいいのかがわかるからです。 こうしたコミュニケーションツールとしても、観点モデルは有効です。#sendaitest

リリカル @mhlyc

まとめです。 にしさんの一貫したメッセージは、「仕様書通りに作られていることを確認することだけが、テストエンジニアの仕事ではないよね」ということです。 #sendaitest

リリカル @mhlyc

VSTePを試してみることで、自分のモデリングの実力やテストの実力が如実に分かります。なぜなら、意図的に仕様ベースという考え方からは離れているからです。（少なくとも、おかわり会のワークではそうだった）#sendaitest

リリカル @mhlyc

CPM法でテストケースを量産するのは誰だってできますが、それを禁じられた状況では自分／組織がこれまで培ってきた知恵や経験がないと有効なテストを導くことができません。ただそこであきらめるのではなくて、どうしたらテストを改善できるか皆で考えていくのが大事です。 #sendaitest

Yasuharu NISHI @YasuharuNishi

ユーザの種類とか競合サービスのようなテスト対象以外のものがWですね RT @chimayu CIBFWモデル Condition/Item/Behaviour/Fault/World 非機能テストなどは”World”に入る。 #sendaitest

リリカル @mhlyc

私の得た大きな収穫のひとつが「VSTePはただの方法論ではなく、考え方の基盤のようなもの」とわかったこと。 根本にある考え方はそもそもエンジニアリングを行ううえで大事にすべきことであり、その考え方を実践することはテストに限らず様々な分野で大切なことです。#sendaitest

リリカル @mhlyc

仙台ソフトウェアテスト勉強会のモデレータの方にも感謝。 「VSTePについては相当勉強した」という自信が、ありありと伝わってきました。 モデレータってテクニック云々以前に自信持ってできるかがとても大事ですよね。価値あるワークにしていただき感謝です。 #sendaitest