SaPID+とVSTePの共通点
今回のJaSST東北実行委員会ブログを担当します、リリカルこと@mhlycです。
JaSST東北実行委員会では「VSTePチュートリアル」というコンテンツを提供しています。
VSTePとは、質の高いテストを行うためのテスト開発方法論です。詳しくは以下のページに資料が掲載されています。
私もVSTePについては個人的に勉強しているところです。
SaPID+ bootcampに参加してきました
ところで私は、先月2月25日〜26日に神奈川 三浦海岸にて開催されたSaPID+ bootcampというイベントに参加してきました。
SaPIDとは自律型プロセス改善手法であり、SaPID+にはさらにSaPIDを拡張した内容も含まれています。
SaPID+ bootcampは、温泉リゾートに泊まり込み、SaPID+ の「STEP0：テーマ共有～STEP3：問題分析・構造化＋α」に集中して”がっつり”取り組むという、内容盛りだくさんの合宿形式のワークショップです。充実した内容で、とても勉強になりました。
さて、SaPID+ bootcampに参加してみて私は「SaPID+とVSTePにはいくつかの共通点がある」と感じました。ここでは、私が思うSaPID+とVSTePの共通点を紹介してみようと思います。（私見ですので、誤りを含んでいるかもしれません）
私の思うSaPID+とVSTePの共通点
- メンバー同士の対話を大事にする。言葉で共通認識を作ることにこだわる。
- 成果物（VSTePで言えばテスト観点図、SaPID+で言えば問題構造図）を作ることが目的ではない。本当の目的は、成果物を作る過程で議論して頭を使うこと(後述します)。また、そのような場を作ること。
- 外から成果物だけを持ってくることを良しとしない。成果物の押し付けでは自分たちの"納得感"や"所有感"がなくなってしまうため、自分たちで作ることを大事にする。
議論して頭を使い、成果物を作る
「普段の業務においても、頭を使って成果物を作るだろう」と思われるかもしれません。VSTePに関していえば、実際の現場においてVSTePそのものはやったことがなくても、テスト計画や方針を話し合う場などで議論をする場は設けられていることもあります。
VSTePやSaPID+で「議論して頭を使う」という部分を強調しているのは、そのプロセス（何をテストしたいのか？／自分たちは何に困っているのか？ を深く考えて議論する）というプロセスをもっと増やしたい／もっと効果的にやりたいからです。そういった意味で、成果物を作るということ自体が目的なのではなく、しっかり頭を突き合わせて議論すること、テスト観点や問題についてもっと深く考えてみる（＝頭を使う）こと、その場を作ることを目的としています。
方法論と聞くと普段の業務でやっていることと離れていると思われるかもしれませんが、議論などの活動の形態が異なっているだけで、似たようなことをしている現場はあると思っています。ただそれを体系立てて進めたり、成果が出やすい進め方にするための工夫がVSTePやSaPID+ には盛り込まれています。
VSTePがテスト開発方法論なのに対し、SaPID+は自律的プロセス改善手法です。また、成果物を構成する要素が「テスト観点（テストしたいこと）」なのか「問題（困っていること）」なのかという点でも違いがあります。それでも、根本的なところで大事にしているポイントは似通っているように感じました。
色々な手法が提案され使われている昨今ですが、それぞれの手法の使い方や利点、使い所などを比較して考えてみるのも、手法を理解して有効に活用するための手がかりになるかもしれないと思いました。
仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜
2017年1月28日に「仙台ソフトウェアテスト勉強会?エンジニアのためのQA研修?」として境野さんにお越し頂き勉強会を開催しました。
勉強会では株式会社ガイアックスにて新人エンジニア向けに実施している「QAレクチャー」を再演頂く形で進行し、ソフトウェアテストの基礎を解説いただきながら『QAって何やってるのか』、『品質が高いものを作るために何を考えればいいか』といったことを中心にお話いただきました。
■第一章：イントロダクション
品質、品質保証、テストって？
当たり前品質、魅力的品質のお話から
ガイアックスでは当たり前品質を確保する為に作った人と別の人がテストする
テストしている内容はどんなことかお話いただきました。
品質保証＝テストではなく手段の一つ
テスト以外に品質をあげる手法はある
テストはなにやっているのか。
・仕様理解し必要なテストをイメージ
・テストケース作成
・テストを実施
・バグトラッキング
■第二章：テストをやってみよう
テスト実施ワーク、バグって？
実際にガイアックスさんの研修で使用している、研修用のイベント登録システムを使っての
テストのワークを行いました。
まずは仕様書を見ないでテストを行い、その後仕様書を見てからのテストを行うことによって
開発者視点としては以下が大事だと言う話をしていただきました。
・作るものを正しくQAに伝えることが大切
・ドキュメント化が基本だが、全ては表現できない
そして、密なコミュニケーションをとり意図や熱意を共有することが大事
【バグとは】
■一般的には
プログラムの誤り
プログラム開発者が行ったミス
■ガイアックスでは
仕様と異なる動き
通常有すべき性質を備えていない
テストはバグを見つけて終わりじゃない
バグの一生
開発者が修正でおわらない
QAが確認してCLOSEする
修正確認、リグレッションテストまでやって終わり
実際の業務では「仕様書の抜け盛れをどれだけ実装前に指摘できるか」が重要
バグは後工程で見つかるほど修正コストが上がる
仕様書レビューのポイント
①こんなときはどうなるの？
②こっちのほうがいいんじゃないの指摘
をどれだけあげられるか
①については全体像がなにで、抜け漏れはないのかが大事
【テストすべきポイント】
その機能、画面でどんなテストするか
フォーム
操作
システムのないようによって代わる
create/read/update/delete
仕様を考える人も、コードを書く人もDが抜ける。
例えば SNSアカウント削除したら投稿、他人へのコメント、友達関係どうする
投稿がシェアされてたら、イベント会社医者だったら
削除後、同じアカウントで再登録できるか
■第三章：QA/テストについて知ろう
ソフトウェアテストの７原則、ソフトウェアテストの分類、テスト技法など
組み込み vs web
①プロジェクトあたりの、コスト 人数 期間がちがう
■求められる品質
【組み込み】
設計段階から、失敗が許されない
【web】
すぐなおせる
個人情報については重点を置く
小機能・短期間で公開してシェアをとる
QA×開発
開発者とQAは対等な立場
組み込みでは品質保証部のほうが権限が大きい場合もある
QAと開発は向かい合って対立しているのでなく、
同じ方向をむいているもの。
いいものを世の中に出そうという想いは同じ
デジカメで学んだこと
人が増えるとプロセス強い
メリット
誰がやっても一定以上の成果。
工業製品の量産とか得意。
デメリット
変化に弱い プロセスを守るが正義となってしまう
組織の硬直化
境野さんとしてはプロセス重視の世界から WEBの世界に来て自由すぎて驚いたとのこと
■所感
新人研修の内容を基にしていただいていた為、基本から丁寧に話をしていただいた結果
最後の質疑応答も質問しやすく盛り上がりさまざまな質問が飛び交いよい勉強会でした。
私個人、組み込みのテストから入り、現在ウェブの検証をやっており似たような境遇であるある話があったり、開発経験がなく、検証していく上で開発知識はどこまで必要かということを最近考えていたところに境野さんの開発修行の話、開発するテストとQAのテスト違いなどを話していただけ大変有意義な勉強会となりました。
【講師プロフィール】
境野 高義 氏
株式会社ガイアックス技術開発部に所属。
組み込み系(デジカメ)のソフトウェアテストを7年経験。
2009年、ガイアックスに入社し、QAチームの立ち上げ、運営を行う。
直近はグループ会社であるアディッシュ株式会社にて業務改善や運用改善を行っている。
過去の発表資料
「WebのQAを5年間運営してみた」
http://www.slideshare.net/takayoshisakaino/ques5-gx
■最後に
JaSSTTohokuでは5月に「育成」をテーマとしたシンポジウムを開催いたします。
ぜひ参加ください！
（菅野）
JaSST'17 TokyoでVSTePチュートリアルを行いました。
@ToshiManaPlus1です。
2017/2/3,4にJaSST'17 Tokyoが開催されました。
JaSSTは全国各地で行われていて、その中でも東京は規模が大きく、数多くのセッションが行われています。
なんと今年は「VSTePのファーストステップ～JaSST'16東北出張おかわり会～」と題して、JaSST東北実行委員から6名を送り出し、テスト開発技法であるVSTePのチュートリアルを行いました。
JaSSTソフトウェアテストシンポジウム-JaSST'17 Tokyo セッション概要
内容はタイトルの通り、JaSST'16 Tohokuの再演となります。とはいえ、当時と同じ時間は取れないので、構成を練り直し4時間バージョンとして作り直しています。(我々のチュートリアル時間を可能な限り本会に近づけるために、タイムテーブル調整してくださったスタッフの皆様には感謝です。)
長い時間のチュートリアルということもあり、最初は人が十分に集まるかで不安でいっぱいでした。実際にはこちらで設定した参加者上限が埋まり、早々に募集制限がかかるほど募集いただいたようです。嬉しいと同時にそれに見合うチュートリアルができるかでまた不安になりました。
VSTePチュートリアルはJaSST'17 Tokyoの二日目である2/4(日)の9:00～13:00で行いました。会場時間も他の同時刻帯のセッションに比べて早く、対応してくださったスタッフの方には本当に頭が上がりません。
チュートリアルは最初の40分で説明が終わると、約3時間ぶっ続けで頭を使ってVSTePによるテスト開発(テスト観点図／テストコンテナ作成)を体験していただく内容になっています。参加者同士の話し合いがとても重要なワークであり、参加者の皆様には頭をフル回転していただきました。頭が疲れた時の栄養源としておやつを用意しましたが、数に限りがあったため参加者の皆様はおやつマネジメントの重要性を体感していたようです。
来れない予定だったVSTeP考案者のにしさんが登場して美味しいところを持っていくサプライズもありましたが、チュートリアル自体はトラブルなく、終了することができました。参加者の皆様から疲れたけど楽しかったなど嬉しい感想も頂いて、我々としてもJaSST Tokyoの大舞台をやり切って満足の一日でした。
VSTePチュートリアルの感想をブログにまとめてくださった参加者もいらっしゃいます。そちらも見てみてください。
JaSST Tokyo '17に参加してきました - shiro庵
JaSST'17 Tokyoは無事に終わりましたが、JaSST東北実行委員ではその振り返りも行い、次は更に上手くワークを体験していただけるように磨き続けています。VSTePチュートリアルを体験したい、などありましたら是非JaSST東北実行委員にご相談ください。
また、JaSST'17 Tohokuの準備も着々と進めています。5/26(金)に開催しますので、皆様奮ってご参加ください。
JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku
やりきったぞー！
言葉を使ったモデリングの話
こんにちは nemorineです。
JaSST東北実行委員のメンバーは昨年のJaSST東北をきっかけにVSTePについて継続的に勉強してますが、その場でいつも思うことがあります。
それは「言葉を使ったモデリング」です。
VSTePのテスト観点図の作成のとき、それぞれのメンバーがどういうテストをしたいのか、もしくはテスト観点そのものを出していきます。それに関して分からないことがあれば、別のメンバーからツッコミが入り、意図を説明したり表現を変えたりします。その作業を繰り返し、構造化して観点図を作ります。
テスト観点図 イメージ
VSTePの初心者(？)はこの観点図が成果物であり、重要だと考えます。
しかし、違うのです！！
真に重要なのはこの観点図を作成するプロセスです。
「あっ 確かに検索条件を解除したときのテストは必要だね。自分の考えからスッポリ抜けてたわ。」
とか
「Aさんのパフォーマンスっていうのは、画面の更新で表示が固まることを気にしてたんだね。」
とかいう気付きがあって、それがチームの中で共有される、そのこと自体が重要なんです。会話の中で曖昧な情報を具体化し、不要な情報をそぎ落とし、概念にピッタリする言葉を探していくっていうのはまさにモデリングだなぁと思います。そしてこのプロセスをチームで経験することでモデルというシンプルな状態でチームメンバーの頭の中に残る！ここがポイントです。
西さんが「納得感が大事！」と言っているのはこのことだと実感するようになりました。
この特性からVSTePはチームの中で情報を共有しながら進めるチーム開発に向いていると言えるでしょう。テストのときだけやるものだと思っている人がいますが、開発の上流（要件定義中や要件定義後）で実施してももちろんOKです。
もちろんメンバーの中に開発者が入ってても全く問題ありません。開発者に「画面が固まらないようにしないと」って思ってもらえばしめたものです。それが心に楔（クサビ）のように刺さりこんでいるので、普通の感覚を持つ開発者だったら気にしながら開発しますよね（笑
実はそんなことを実践している理想のチームがあるんです。
それが栃木の関さん、美和さんチームです。
いやー すごいですねぇ。
最後に言いたいのは、こんな体験がJaSST'17東京でできるということです。
各チームには東北のVSTePモデレータがつきますよ！
JaSST'17東京のお申し込みはこちらから。
ソフトウェアテスト勉強会〜テスターと創る開発現場〜
10月29日（土）に「ソフトウェアテスト勉強会～テスターと創る開発現場～」として、@miwa719さんをお呼びして、テスターやチームについてお話しいただきました。
今回は、組込みシステムの開発チームで一緒にお仕事をされている、dRubyで有名な@m_sekiさんにも
お越しいただき、豪華二本立となりました。
参加人数は16人で、仙台以外からの外部参加者がとても多く、また、テスターが多いという勉強会となりました。
最初は@m_sekiさんのお話で、チームに新しく新人とテスターがやってきた場合、テスターの方が、バグが多様化したというお話をしていただきました。
この、新しく来たテスターが@miwa719さんということで、ここから@miwa719さんのお話が始まりました。
@miwa719さんがいるチームは、以下のようなチームらしいのですが、未だにそんなチームが存在するのか半信半疑です。
@miwa719さんがいるチーム・・・
開発とテスターが分かれておらず、開発者もこんなにテストするのかというようなチームであり、常に、雑談レベルでも、対象の製品についての話が行われ、誰かが困っていたら、すぐに声を掛け合うような状態のようです。
課題や問題を担当者だけのものとせず、自分ならどうするか、現在どうあるべきか自分の問題としてその課題等に向き合う風土ができているとのこと。
どうしたら、このようなチームが出来上がるのかとの質問には、チーム創設当時、問題意識を持ったチーム員が多くいたこと、問題解決のために専任を設ける体制が組めたことがあげられるとのことで、それなりの環境があったことが伺えました。
その後、@miwa719さんがどうテストしているかのお話が続きました。
基本はチケットにて管理しているそうです。
チケットにはテストケースがあり、それを元にテストを行うようです。
チケットに記載している内容が、わかりづらかったり、やたら長かったりと記載内容から、あやしい匂いがわかるらしいです。
担当者の顔色だったり、声のトーンも気にしているようです。
その他、仕様の変更が多かったり、揉めていたのに急におとなしくなったりと、その時の状況もおかしさを見つけるヒントになるそうです。
テスターにかかれば、どうあってもあやしい匂いをかぎ分けられるとのことでした。
五感どころか六感もフル活用していれば、わかるとか。
ただただ、感心するとともに、「匂い」と表現するところに@miwa719さんのお人柄とテストに関するポジティブさを感じました。
私なら「臭い」と表現したくなりますので、まずはここから気持ちを改めないと、あやしいチケットを見抜けないのではないかと思いました。
より良い製品を作るための、チーム作りについてお話を聞くことができましたが、このようなチーム作りをすぐにするのは難しいと思いますので、まずは、できることから始めたいと思います。
できることは限られているので、私は、例えば、以下の２つぐらいからやれたらよいなと思います。
１．なんでも質問できる会議体を作る
@miwa719さんのところでは、朝会の二次会なるものが存在しており、新人等が朝会で分からなかったところを聞いたりする場を設けているそうです。
なんでも聞くことができる場は、それほどなかったりします。
敢えて、会議体として設定しておけば、何でも聞くことができる雰囲気が出来上がっていくのではないかと思います。
２．製品をよくしたいという目的を共有する
製品をよくするというのは、当たり前のことなのですが、チームが細分化されたりすると、自分のチームの担当部分に注力し、他のチームとの連携に関しては、責任の押し付け合いになったりして、うまくいかなくなることもしばしば・・・。
よく出てくる「３人のレンガ職人」の話のように、目的が違えば、作業のやり方も変わってくるのではないでしょうか。
製品をよりよくしたいという、目的をいつも共有できていれば責任の押し付け合いではなく、うまく連携できた作業ができるのではないかと思います。
ソフトウェアテスト勉強会に参加されているみなさんのお悩みとして、新たなテスト技法をチームに浸透させたいと思っても、チーム内の雰囲気が良くないと、うまくいかないことも多いかと思います。
そんな問題を、今回のお話からヒントを得ることができました。
詳しくは、こちらでご確認ください。
わたしたちの開発現場 // Speaker Deck
@m_sekiさん、@miwa719さん本当にありがとうございました。
（竹内）
テスト設計チュートリアル（U-30版）に参加してきました
JaSSTを主催しているASTERでは、毎年「テスト設計コンテスト」というコンテストを開催しています。
コンテスト開始前には「テスト設計チュートリアル」が開催されていて、テスト設計の考え方を紹介していただけます。JaSST’16 Tohokuでは「テスト設計」をテーマに開催しましたが、このチュートリアルは残念ながら東北では開催されていません。東京会場に行って聞いてきましたので、JaSST’16 Tohokuのワーク内容と紐づけながらレポートしたいと思います。
ASTER-テスト設計コンテスト'17-U30 クラス チュートリアル
テストケース作成を成功させるために
「テストケースを挙げてください」と言ったとき、以下のような状況に陥ることが多々あります。
- 思い付きでテストケースの羅列をする
- 粒度がバラバラ
- よく読まないと分からない
テストケースを作成するとき限りませんが、情報を整理する必要があります。そうすることで、テストすべきことが見えやすくなります。大事なことは、自分が納得して、自分で説明すること。伝えてフィードバックをもらうことで、いいテストができるようになります。
それを実現するために、4つのステップを踏みます。
- テスト観点（テストすべきこと）を整理して、網羅的に挙げよう
ピンポイント型のテスト観点もきちんと挙げよう - テストフレーム（テストケースの構造）を考えよう
- テストコンテナ（テスト観点やテストフレームをまとめたもの）とその間の順序関係を網羅しよう
リスクベース度な優先順位付けをしよう - テスト観点からテスト値（テストケース）を網羅しよう
1.テスト観点（テストすべきこと）を整理して、網羅的に挙げよう【テスト要求分析】
トップダウンとボトムアップを循環させながらテスト観点を網羅していきます。
最終的に、階層型の記法を用いると、様々な抽象度のテスト観点を俯瞰的に整理することができます。同じ階層の粒度は揃えることが大切です。分解については、WACATE2016夏の「分解について」という資料を参考にするとよいでしょう。
【図：テスト観点図の例】*3
ピンポイントの観点も忘れずに
- 起きてほしくないこと
危険事象やハザードなどいろいろ - バグ
絶対に入ってほしくないバグやよく作りこんでしまうバグ - 後工程でバグを引き落としそうな罠や弱点
構造が歪んでいるところや分かりにくいところ
プラットフォームや言語使用に潜む罠や弱点
JaSST’16 Tohokuのワークショップの前半では、テスト観点の洗い出しとテスト観点ツリーの作成を行いました。テスト観点は仕様書を伏せて出して行きました。そうすることで、仕様書に書かれていることに捕らわれず、「自分が使うなら」「自分が開発するなら」「こんなバグに出会ったことがある」といった幅広い観点が出せるようになりました。
チームで行うことで、他の人が持っている観点を共有することもできます。ツリー構造にする時には、粒度や言葉の意味を合わせるのが難しくはありますが、相手に伝え、フィードバックをもらい、納得しあう、というフローは、説明力が求められる「テスト技術」を高める練習にもなるのではないかと思います。
2.テストフレーム（テストケースの構造）を考えよう【テストアーキテクチャ設計（テストフレームモデリング）】
"テストケースの構造"には単純なものから複雑なものまでいろいろあります。テストケースの構造を、テスト観点やテストパラメーターで表したものを「テストフレーム」と呼びます。
【図：単純なテストフレームの例】*4
【図：複雑なテストフレームの例】*5
テストフレームはテストケースのスケルトン（骨格）です。テストフレームの要素を見出しとして表にすると、テストケースになります。テストには様々な観点がありますので、テストフレームは1パターンのみでで表現できるとは限りません。
【図：テストフレームとテストケース表の例】*6
【図：組み合わせのテストフレームとテストケース表の例】*7
テストフレームについては、情報交換会の質疑応答で話題にあがりました。今回はワークの提供ができませんでしたが、その後、勉強会を開催して理解を深めているところです。
3.テストコンテナとその間の順序関係を網羅しよう【テストアーキテクチャ設計（テストコンテナモデリング）】
テストコンテナ（テスト観点やテストフレームをまとめたもの）にまとめる
テスト観点やテストフレームが増えてきたら、「テストコンテナ（テストの箱）」にまとめてあげると見通しがよくなります。テスト設計をする人は、「なぜこれらのテスト観点やテストフレームをまとめて、このテストコンテナにしたのか」きちんと説明できないといけません。社内標準のようなもがあり、それを適用する場合であっても、きちんと説明できる必要があります。もし説明できないのであれば、理解が浅いか、その社内標準とテストがマッチしていない証拠です。
＜テストコンテナの例＞
- テストレベル
- テストタイプ
- テストサイクル
【図：テストコンテナの例】*8
テストコンテナ間の順序関係（テストアーキテクチャ）を考える
後工程や後プロジェクトでテストしやすいようにテスコンテナをまとめ、前後関係や並列関係を考える必要があります。テストコンテナを適切に配置しないと、開発がやり直しになるような不具合が出荷間際に見つかったりする羽目になります。
テストコンテナを用いてテストアーキテクチャを設計すると、テストの全体像が俯瞰しやすくなり、チームで共有しやすくなるというメリットもあります。
【図：テストコンテナの例】*9
テストコンテナ間の結合度を低め凝集度を高めるようにしつつ、テストアーキテクチャ設計の品質特性を高めていくのが王道…ということですが、これがテスト設計の腕の見せどころでもあります。テスト設計コンテストでも特に重要視されており、出場経験のある私としては、ここが一番難しく、評価を分ける部分だと感じています。
※リスクベースドな優先付けをしよう
リスクベースドテストとは、「もしこのテストケースを実施しなかったらどのくらい困ってしまうのか？」と推測し、困ってしまう程度（品質リスク）の高い順に優先順位をつける方法です。テスト担当者はリスクを明らかにした上で、後回しにできる品質リスクを顧客や開発側と相談し、合意を取ります。テストアーキテクチャ設計では、品質リスクに合わせて厚みやバランスを決めていきます。リスクの高さによっては網羅基準を変えることもあるでしょう。
テスト詳細設計では、品質リスクの高い順にテストケースを実施するとよいです。
JaSST’16 Tohokuでは、テストコンテナの作成と並び替えのワークも行いました。私が担当したグループでは実際の業務を意識し、「この不具合はいつの時点で見つかってほしいのか」という視点でコンテナを並び替えました。例えば、「ユーザビリティの観点については、テストの最終段階（リリースの直前）になってから言われても直しようがないので、実装をするもっと前、設計レビューで指摘されたい」といった感じです。テストは実行に目が行きがちですが、レビューも大事なテストの一つ。テストコンテナを作成し並び替えることで、レビューの観点ができあがったのは大きな発見でした。
4.テスト観点からテスト値（テストケース）を網羅しよう【テスト詳細設計】
テストケースの導出までは、以下の流れで行っていきます。
【図：テスト値の導出】*10
青の四角に書かれたものをインプットとし、丸の中に書かれたことを行います。オレンジの四角に書かれているものがアウトプットです。次のインプットにもなっていますね。丸に書かれていることを、1つずつ見ていきましょう。
1.モデルの特定
モデルには以下の4種類があります。
【図：モデルの種類】*11
①範囲：連続性があるもの
②一覧表：因子水準表など
③マトリクス：組み合わせを表現する
④グラフ：画面遷移図や状態遷移図など
グラフは全体を俯瞰しやすい一方で表現するための技術が必要であったり、マトリクスは簡単に作れる一方で巨大化しやすいという難点があったりします。どれを使うのが正解、というわけではなく、その時に整理したい内容や好みに合わせて活用していくのがよさそうです。
2.詳細化する
これ以上細かくならないところまで細かくします。洗い出してしまえば理由を付けてテストの量を減らすことはできますが、洗い出しが不十分な場合、テストが漏れてしまいます。
3.基準を決める
テストの厚みや幅を調整するための基準を決めます。このとき必要になる情報としては以下の2つです。
- カバレッジ基準：説明材料として必要なもの
- 状況、条件、制約：現場や案件の現状に合わせた形にするために必要な情報
これらはプロジェクトやテストの計画時に用意されていることもありますが、ない場合は、様々なテストベースから導き出す必要があります。 リスクベースの考え方を用いてみましょう。
4.基準に沿ったテスト値を導出する
テスト値を作成します。テスト値には、直接テスト手順の一部（テストデータ）として実施できるものと、テスト値からさらにテストデータを導く必要があるものに分かれます。前者の場合、そのままでテスト実行できるかもしれませんが、後者の場合はテストデータの抽出が必要になってきます。
このように、テストケースを作成するときには、詳細化やモデリングを行います。闇雲にテストケースを作成したのでは、このテストが十分かどうかの説明もできませんし、効果的なテストに間引くこともできません。最後まで、自分が納得して自分で説明することを意識するとよいでしょう。
テスト観点図やテストコンテナの作成も、詳細化とモデリングという作業を行っていました。これがテスト設計の肝なのだろうなと感じています。
まとめ
東京で開催されたテスト設計チュートリアル（U-30版）のレポートをお届けしました。テスト設計チュートリアルは全国各地で開催されています。東北のみなさんから「テスト設計やりたい！」というたくさんの声が届けば、来年は東北でも開催されるかもしれません。JaSST東北の実行委員と一緒に、勉強していきましょう！！
お知らせ
10月29日（土）に仙台にて、「ソフトウェアテスト勉強会～テスターと創る開発現場～」が開催されます。JaSST'14 Tohokuで講演いただいた@miwa719さんにお越しいただき、テスターやチームについて語り合います。参加費はお菓子＋会場費として300円のみとなっていますので、ぜひみなさん、ご参加ください！
記：めい
JaSST東北おかわり会(07/02)を開催した話
【JaSST東北おかわり会開催】
7/2(土)にJaSST東北おかわり会ということで
丸1日参加者のみなさんとVSTeP漬けになりました。
仙台で土曜開催にもかかわらず、
仙台の人だけでなく、新潟や愛知の人にも参加していただき、
開始早々プレッシャー高まるおかわり会となりました。
【おかわり会午前の部】
午前の部は、VSTePの紹介を行いました。
JaSST東北本会のにしさんのようにはできないので
にしさんに感謝しつつ
にしさん講演資料ベースにスライドの順番を入替えたり、
今回対象範囲にしない記載を抜いたり、
補足や途中のまとめを入れたり等させていただき
VSTePの概念や大事にしたいポイントをお伝えすることにしました。
（にしさんにはTwitterで質問のフォローをしていただき、本当に感謝してます。）
私には、聞いてるだけだと実際どうやるのか理解しにくいという思いがあります。
どこまで、どの粒度で、はVSTePをやる際、みなさんの悩みどころだと思っています。
JaSST東北本会でも、グループによっては
「詳細に出したまま議論しすぎてしまったため、まとめるのが大変苦労した」、
「粒度がまちまちになってしまい、もやもやした」、
ような話を聞きました。
そのため、午前の部の時点で無茶振りですが、
ざっくり考えてテスト観点出しをするワークや、
そこからテストコンテナを作成するというワークをすることにしました。
ワークでは詳細すぎる観点ではなく、
ざっくりした観点を考えてもらいやすく促そうとしてみたり
VSTePで大事にしたいプロセスをないがしろにした場合に陥る問題の体感をしていただきました。
まずは、自分が気になるところを大事にするといい、ということや
どうなると、「もやもや」するのか？
どの部分の理解が「もやもや」していてのか？
など、早く「もやもや」していただけるようにしてみました。
午前のワーク時間は超短時間ということもあり、
結果はそれなりに狙い通りになった気がしますが、
実際参加者目線ではどうだったのか気になるところです。
無茶振り以外でも何物でもないので、本当に大変だったと思います・・・。
無茶振りにも関わらず、みなさんのアウトプットはいい塩梅で
本当に助けられたと思いました。
参加されたみなさん、ありがとうございました（＞＜）
【午後の部】
午後の部は、JaSST東北本会と全く同じ流れで実施しました。
午前の「もやもや」が晴れて、次なる「もやもや」が生じたようです。
次なる「もやもや」も、まぁそうですよね。と思いつつ、
私たちがよくわからず迷いながらも着実に歩んだ道を
参加者のみなさんは理解しつつ、私たちと違って早足で歩いていただいてるようで、
やってよかったんだろうなぁと実感しました。
「もやもや」が残る方もいる中でそれでも最後に、参加者の人たちから
「楽しかった」、「来てよかった」っていわれる勉強会になって
ほんとによかったです。
【次なる「もやもや」のために】
私たちは最後まで残った次なる「もやもや」に立ち向かおうと思います。
おかわり会のおかわり会を開くことにしました。
しかし、現状のまま自分たちが変わらないと
「もやもや」は減らないままであることも認識していました。
そのため、少しでも自分たちのレベルアップを図ろうと
JaSST東北実行委員は、いろんな「もやもや」解決のため
少しでも期待に応えられるようVSTePの勉強会を独自に開催(7/23)しました。
勉強会の主旨は、分析から、テストケース作成まで一連した流れの体験です。
・詳細設計するために必要なレベルの分析ってどこまでやればいいのだろう？
・コンテナから詳細設計へのつながりってどうやるのだろう？
そんな疑問点が少し晴れる勉強会になりました。
おかわり会のおかわり会では、きっと
若干レベルアップした（かもしれない）実行委員に会えることでしょう。
【年中おかわり会！？】
おかわり会のおかわり会があるなら、
そのおかわり会も・・・・とすると
１年中おかわり会になるんじゃないの！？、
っていう話もありますが、私はあまり気にしていません。
VSTePはテスト開発方法論の１つですが
VSTePが大事にしたいポイントって、テストに限らず
開発、評価問わず業務全般に生かせると思っているので
それが少しでも広まるんであれば、それはそれでいいんじゃないの、と思っています。
私含めて、いろんな人の
「楽しい開発」、「楽しいテスト」に
少しでも生かせるならいいですよね。
【最後に】
みんなでうんうん唸りながら、手を動かしながら楽しんで勉強できるよう
8/27(土)におかわり会のおかわり会を開きます！
http://tohoku-dev.jp/modules/eguide/event.php?eid=317
おかわり会のおかわり会では、
今回の結果を次回に反映したいと思ってますし、
次回は、異なる「お題」で開催してみようと思っています。
VSTePを知らない方はもちろん、
JaSST東北本会やおかわり会に参加された方の中で
異なるお題でやってみたい方はぜひいらしてください。
みなさんと一緒に楽しんで勉強できるのを
JaSST東北実行委員会一同、心よりお待ちしています♪
記：うめつ
