JaSST Tohoku実行委員ブログ

JaSST Tohoku実行委員のあれこれを載せていきます、たぶん、きっと。

仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜

2017年1月28日に「仙台ソフトウェアテスト勉強会?エンジニアのためのQA研修?」として境野さんにお越し頂き勉強会を開催しました。

勉強会では株式会社ガイアックスにて新人エンジニア向けに実施している「QAレクチャー」を再演頂く形で進行し、ソフトウェアテストの基礎を解説いただきながら『QAって何やってるのか』、『品質が高いものを作るために何を考えればいいか』といったことを中心にお話いただきました。

 

■第一章:イントロダクション

品質、品質保証、テストって?


当たり前品質、魅力的品質のお話から
ガイアックスでは当たり前品質を確保する為に作った人と別の人がテストする
テストしている内容はどんなことかお話いただきました。

 

品質保証=テストではなく手段の一つ

テスト以外に品質をあげる手法はある

テストはなにやっているのか。
・仕様理解し必要なテストをイメージ
・テストケース作成
・テストを実施
・バグトラッキング

 

■第二章:テストをやってみよう

テスト実施ワーク、バグって? 
実際にガイアックスさんの研修で使用している、研修用のイベント登録システムを使っての
テストのワークを行いました。

まずは仕様書を見ないでテストを行い、その後仕様書を見てからのテストを行うことによって
開発者視点としては以下が大事だと言う話をしていただきました。

・作るものを正しくQAに伝えることが大切
・ドキュメント化が基本だが、全ては表現できない
そして、密なコミュニケーションをとり意図や熱意を共有することが大事


【バグとは】
■一般的には

プログラムの誤り
プログラム開発者が行ったミス


ガイアックスでは
仕様と異なる動き
通常有すべき性質を備えていない


テストはバグを見つけて終わりじゃない
バグの一生
開発者が修正でおわらない
QAが確認してCLOSEする
修正確認、リグレッションテストまでやって終わり

実際の業務では「仕様書の抜け盛れをどれだけ実装前に指摘できるか」が重要
バグは後工程で見つかるほど修正コストが上がる

仕様書レビューのポイント
①こんなときはどうなるの?
②こっちのほうがいいんじゃないの指摘
をどれだけあげられるか

①については全体像がなにで、抜け漏れはないのかが大事


【テストすべきポイント】
その機能、画面でどんなテストするか

フォーム

操作

システムのないようによって代わる

CRUD

create/read/update/delete

仕様を考える人も、コードを書く人もDが抜ける。

例えば SNSアカウント削除したら投稿、他人へのコメント、友達関係どうする
投稿がシェアされてたら、イベント会社医者だったら
削除後、同じアカウントで再登録できるか


■第三章:QA/テストについて知ろう

ソフトウェアテストの7原則、ソフトウェアテストの分類、テスト技法など

組み込み 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によるテスト開発(テスト観点図/テストコンテナ作成)を体験していただく内容になっています。参加者同士の話し合いがとても重要なワークであり、参加者の皆様には頭をフル回転していただきました。頭が疲れた時の栄養源としておやつを用意しましたが、数に限りがあったため参加者の皆様はおやつマネジメントの重要性を体感していたようです。

 

f:id:jasst_tohoku:20170219150335j:plain

 

来れない予定だったVSTeP考案者のにしさんが登場して美味しいところを持っていくサプライズもありましたが、チュートリアル自体はトラブルなく、終了することができました。参加者の皆様から疲れたけど楽しかったなど嬉しい感想も頂いて、我々としてもJaSST Tokyoの大舞台をやり切って満足の一日でした。
VSTePチュートリアルの感想をブログにまとめてくださった参加者もいらっしゃいます。そちらも見てみてください。

JaSST Tokyo '17に参加してきました - shiro庵

kabe-aa.hatenablog.com


JaSST'17 Tokyoは無事に終わりましたが、JaSST東北実行委員ではその振り返りも行い、次は更に上手くワークを体験していただけるように磨き続けています。VSTePチュートリアルを体験したい、などありましたら是非JaSST東北実行委員にご相談ください。
また、JaSST'17 Tohokuの準備も着々と進めています。5/26(金)に開催しますので、皆様奮ってご参加ください。

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku

 

やりきったぞー!

f:id:jasst_tohoku:20170219150350j:plain

言葉を使ったモデリングの話

こんにちは nemorineです。

JaSST東北実行委員のメンバーは昨年のJaSST東北をきっかけにVSTePについて継続的に勉強してますが、その場でいつも思うことがあります。

それは「言葉を使ったモデリングです。


VSTePのテスト観点図の作成のとき、それぞれのメンバーがどういうテストをしたいのか、もしくはテスト観点そのものを出していきます。それに関して分からないことがあれば、別のメンバーからツッコミが入り、意図を説明したり表現を変えたりします。その作業を繰り返し、構造化して観点図を作ります。

f:id:jasst_tohoku:20170113161243p:plain

テスト観点図 イメージ

 

VSTePの初心者(?)はこの観点図が成果物であり、重要だと考えます。

しかし、違うのです!!
真に重要なのはこの観点図を作成するプロセスです。

「あっ 確かに検索条件を解除したときのテストは必要だね。自分の考えからスッポリ抜けてたわ。」
 とか
「Aさんのパフォーマンスっていうのは、画面の更新で表示が固まることを気にしてたんだね。」
 とかいう気付きがあって、それがチームの中で共有される、そのこと自体が重要なんです。会話の中で曖昧な情報を具体化し、不要な情報をそぎ落とし、概念にピッタリする言葉を探していくっていうのはまさにモデリングだなぁと思います。そしてこのプロセスをチームで経験することでモデルというシンプルな状態でチームメンバーの頭の中に残る!ここがポイントです。
西さんが「納得感が大事!」と言っているのはこのことだと実感するようになりました。

この特性からVSTePはチームの中で情報を共有しながら進めるチーム開発に向いていると言えるでしょう。テストのときだけやるものだと思っている人がいますが、開発の上流(要件定義中や要件定義後)で実施してももちろんOKです。
もちろんメンバーの中に開発者が入ってても全く問題ありません。開発者に「画面が固まらないようにしないと」って思ってもらえばしめたものです。それが心に楔(クサビ)のように刺さりこんでいるので、普通の感覚を持つ開発者だったら気にしながら開発しますよね(笑

実はそんなことを実践している理想のチームがあるんです。
それが栃木の関さん、美和さんチームです。
いやー すごいですねぇ。

miwa719.hatenablog.com

 

最後に言いたいのは、こんな体験がJaSST'17東京でできるということです。
各チームには東北のVSTePモデレータがつきますよ!
JaSST'17東京のお申し込みはこちらから。

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tokyo

ソフトウェアテスト勉強会〜テスターと創る開発現場〜

10月29日(土)に「ソフトウェアテスト勉強会~テスターと創る開発現場~」として、@miwa719さんをお呼びして、テスターやチームについてお話しいただきました。

今回は、組込みシステムの開発チームで一緒にお仕事をされている、dRubyで有名な@m_sekiさんにも
お越しいただき、豪華二本立となりました。

参加人数は16人で、仙台以外からの外部参加者がとても多く、また、テスターが多いという勉強会となりました。

最初は@m_sekiさんのお話で、チームに新しく新人とテスターがやってきた場合、テスターの方が、バグが多様化したというお話をしていただきました。

この、新しく来たテスターが@miwa719さんということで、ここから@miwa719さんのお話が始まりました。

@miwa719さんがいるチームは、以下のようなチームらしいのですが、未だにそんなチームが存在するのか半信半疑です。

@miwa719さんがいるチーム・・・
開発とテスターが分かれておらず、開発者もこんなにテストするのかというようなチームであり、常に、雑談レベルでも、対象の製品についての話が行われ、誰かが困っていたら、すぐに声を掛け合うような状態のようです。
課題や問題を担当者だけのものとせず、自分ならどうするか、現在どうあるべきか自分の問題としてその課題等に向き合う風土ができているとのこと。

どうしたら、このようなチームが出来上がるのかとの質問には、チーム創設当時、問題意識を持ったチーム員が多くいたこと、問題解決のために専任を設ける体制が組めたことがあげられるとのことで、それなりの環境があったことが伺えました。

その後、@miwa719さんがどうテストしているかのお話が続きました。
基本はチケットにて管理しているそうです。
チケットにはテストケースがあり、それを元にテストを行うようです。
チケットに記載している内容が、わかりづらかったり、やたら長かったりと記載内容から、あやしい匂いがわかるらしいです。
担当者の顔色だったり、声のトーンも気にしているようです。
その他、仕様の変更が多かったり、揉めていたのに急におとなしくなったりと、その時の状況もおかしさを見つけるヒントになるそうです。
テスターにかかれば、どうあってもあやしい匂いをかぎ分けられるとのことでした。

五感どころか六感もフル活用していれば、わかるとか。
ただただ、感心するとともに、「匂い」と表現するところに@miwa719さんのお人柄とテストに関するポジティブさを感じました。
私なら「臭い」と表現したくなりますので、まずはここから気持ちを改めないと、あやしいチケットを見抜けないのではないかと思いました。

より良い製品を作るための、チーム作りについてお話を聞くことができましたが、このようなチーム作りをすぐにするのは難しいと思いますので、まずは、できることから始めたいと思います。

できることは限られているので、私は、例えば、以下の2つぐらいからやれたらよいなと思います。

1.なんでも質問できる会議体を作る
 @miwa719さんのところでは、朝会の二次会なるものが存在しており、新人等が朝会で分からなかったところを聞いたりする場を設けているそうです。

 なんでも聞くことができる場は、それほどなかったりします。
 敢えて、会議体として設定しておけば、何でも聞くことができる雰囲気が出来上がっていくのではないかと思います。

2.製品をよくしたいという目的を共有する
 製品をよくするというのは、当たり前のことなのですが、チームが細分化されたりすると、自分のチームの担当部分に注力し、他のチームとの連携に関しては、責任の押し付け合いになったりして、うまくいかなくなることもしばしば・・・。
 
 よく出てくる「3人のレンガ職人」の話のように、目的が違えば、作業のやり方も変わってくるのではないでしょうか。
 製品をよりよくしたいという、目的をいつも共有できていれば責任の押し付け合いではなく、うまく連携できた作業ができるのではないかと思います。


ソフトウェアテスト勉強会に参加されているみなさんのお悩みとして、新たなテスト技法をチームに浸透させたいと思っても、チーム内の雰囲気が良くないと、うまくいかないことも多いかと思います。
そんな問題を、今回のお話からヒントを得ることができました。

詳しくは、こちらでご確認ください。
わたしたちの開発現場 // Speaker Deck




@m_sekiさん、@miwa719さん本当にありがとうございました。

(竹内)

テスト設計チュートリアル(U-30版)に参加してきました

JaSSTを主催しているASTERでは、毎年「テスト設計コンテスト」というコンテストを開催しています。

コンテスト開始前には「テスト設計チュートリアル」が開催されていて、テスト設計の考え方を紹介していただけます。JaSST’16 Tohokuでは「テスト設計」をテーマに開催しましたが、このチュートリアルは残念ながら東北では開催されていません。東京会場に行って聞いてきましたので、JaSST’16 Tohokuのワーク内容と紐づけながらレポートしたいと思います。

ASTER-テスト設計コンテスト'17-U30 クラス チュートリアル

テストケース作成を成功させるために

「テストケースを挙げてください」と言ったとき、以下のような状況に陥ることが多々あります。

  • 思い付きでテストケースの羅列をする
  • 粒度がバラバラ
  • よく読まないと分からない

テストケースを作成するとき限りませんが、情報を整理する必要があります。そうすることで、テストすべきことが見えやすくなります。大事なことは、自分が納得して、自分で説明すること。伝えてフィードバックをもらうことで、いいテストができるようになります。

それを実現するために、4つのステップを踏みます。

  1. テスト観点(テストすべきこと)を整理して、網羅的に挙げよう
    ピンポイント型のテスト観点もきちんと挙げよう
  2. テストフレーム(テストケースの構造)を考えよう
  3. テストコンテナ(テスト観点やテストフレームをまとめたもの)とその間の順序関係を網羅しよう
    リスクベース度な優先順位付けをしよう
  4. テスト観点からテスト値(テストケース)を網羅しよう

1.テスト観点(テストすべきこと)を整理して、網羅的に挙げよう【テスト要求分析】

トップダウンボトムアップを循環させながらテスト観点を網羅していきます。

【図:トップダウンによるテスト観点の整理】*1

f:id:jasst_tohoku:20160928125421p:plain

  • ボトムアップ型:ボトムアップによるテスト観点の整理
    思いつくところからテストケースを具体的に書き、いくつか集まったところで抽象化し、テスト観点を導き出すやり方です。

【図:ボトムアップによるテスト観点の整理】 *2

f:id:jasst_tohoku:20160928125410p:plain

最終的に、階層型の記法を用いると、様々な抽象度のテスト観点を俯瞰的に整理することができます。同じ階層の粒度は揃えることが大切です。分解については、WACATE2016夏の「分解について」という資料を参考にするとよいでしょう。

www.slideshare.net

【図:テスト観点図の例】*3

f:id:jasst_tohoku:20160928132550p:plain

ピンポイントの観点も忘れずに

  • 起きてほしくないこと
    危険事象やハザードなどいろいろ
  • バグ
    絶対に入ってほしくないバグやよく作りこんでしまうバグ
  • 後工程でバグを引き落としそうな罠や弱点
    構造が歪んでいるところや分かりにくいところ
    プラットフォームや言語使用に潜む罠や弱点

JaSST’16 Tohokuのワークショップの前半では、テスト観点の洗い出しとテスト観点ツリーの作成を行いました。テスト観点は仕様書を伏せて出して行きました。そうすることで、仕様書に書かれていることに捕らわれず、「自分が使うなら」「自分が開発するなら」「こんなバグに出会ったことがある」といった幅広い観点が出せるようになりました。

チームで行うことで、他の人が持っている観点を共有することもできます。ツリー構造にする時には、粒度や言葉の意味を合わせるのが難しくはありますが、相手に伝えフィードバックをもらい納得しあう、というフローは、説明力が求められる「テスト技術」を高める練習にもなるのではないかと思います。

2.テストフレーム(テストケースの構造)を考えよう【テストアーキテクチャ設計(テストフレームモデリング)】

"テストケースの構造"には単純なものから複雑なものまでいろいろあります。テストケースの構造を、テスト観点やテストパラメーターで表したものを「テストフレーム」と呼びます。

【図:単純なテストフレームの例】*4

f:id:jasst_tohoku:20160928133703p:plain

【図:複雑なテストフレームの例】*5

f:id:jasst_tohoku:20160928132858p:plain

テストフレームはテストケースのスケルトン(骨格)です。テストフレームの要素を見出しとして表にすると、テストケースになります。テストには様々な観点がありますので、テストフレームは1パターンのみでで表現できるとは限りません。

 【図:テストフレームとテストケース表の例】*6

f:id:jasst_tohoku:20160928133211p:plain

f:id:jasst_tohoku:20160928133129p:plain

 【図:組み合わせのテストフレームとテストケース表の例】*7

f:id:jasst_tohoku:20160928133221p:plain

f:id:jasst_tohoku:20160928133140p:plain

テストフレームについては、情報交換会の質疑応答で話題にあがりました。今回はワークの提供ができませんでしたが、その後、勉強会を開催して理解を深めているところです。

3.テストコンテナとその間の順序関係を網羅しよう【テストアーキテクチャ設計(テストコンテナモデリング)】

テストコンテナ(テスト観点やテストフレームをまとめたもの)にまとめる

テスト観点やテストフレームが増えてきたら、「テストコンテナ(テストの箱)」にまとめてあげると見通しがよくなります。テスト設計をする人は、「なぜこれらのテスト観点やテストフレームをまとめて、このテストコンテナにしたのか」きちんと説明できないといけません。社内標準のようなもがあり、それを適用する場合であっても、きちんと説明できる必要があります。もし説明できないのであれば、理解が浅いか、その社内標準とテストがマッチしていない証拠です。

<テストコンテナの例>

  • テストレベル
  • テストタイプ
  • テストサイクル

 【図:テストコンテナの例】*8

f:id:jasst_tohoku:20160928133716p:plain

テストコンテナ間の順序関係(テストアーキテクチャ)を考える

後工程や後プロジェクトでテストしやすいようにテスコンテナをまとめ、前後関係や並列関係を考える必要があります。テストコンテナを適切に配置しないと、開発がやり直しになるような不具合が出荷間際に見つかったりする羽目になります。

テストコンテナを用いてテストアーキテクチャを設計すると、テストの全体像が俯瞰しやすくなり、チームで共有しやすくなるというメリットもあります。

【図:テストコンテナの例】*9

f:id:jasst_tohoku:20160928133800p:plain

テストコンテナ間の結合度を低め凝集度を高めるようにしつつ、テストアーキテクチャ設計の品質特性を高めていくのが王道…ということですが、これがテスト設計の腕の見せどころでもあります。テスト設計コンテストでも特に重要視されており、出場経験のある私としては、ここが一番難しく、評価を分ける部分だと感じています。

※リスクベースドな優先付けをしよう

リスクベースドテストとは、「もしこのテストケースを実施しなかったらどのくらい困ってしまうのか?」と推測し、困ってしまう程度(品質リスク)の高い順に優先順位をつける方法です。テスト担当者はリスクを明らかにした上で、後回しにできる品質リスクを顧客や開発側と相談し、合意を取ります。テストアーキテクチャ設計では、品質リスクに合わせて厚みやバランスを決めていきます。リスクの高さによっては網羅基準を変えることもあるでしょう。
テスト詳細設計では、品質リスクの高い順にテストケースを実施するとよいです。

JaSST’16 Tohokuでは、テストコンテナの作成と並び替えのワークも行いました。私が担当したグループでは実際の業務を意識し、「この不具合はいつの時点で見つかってほしいのか」という視点でコンテナを並び替えました。例えば、「ユーザビリティの観点については、テストの最終段階(リリースの直前)になってから言われても直しようがないので、実装をするもっと前、設計レビューで指摘されたい」といった感じです。テストは実行に目が行きがちですが、レビューも大事なテストの一つ。テストコンテナを作成し並び替えることで、レビューの観点ができあがったのは大きな発見でした。

4.テスト観点からテスト値(テストケース)を網羅しよう【テスト詳細設計】

テストケースの導出までは、以下の流れで行っていきます。

【図:テスト値の導出】*10

f:id:jasst_tohoku:20160928134022p:plain

青の四角に書かれたものをインプットとし、丸の中に書かれたことを行います。オレンジの四角に書かれているものがアウトプットです。次のインプットにもなっていますね。丸に書かれていることを、1つずつ見ていきましょう。

1.モデルの特定

モデルには以下の4種類があります。

【図:モデルの種類】*11

f:id:jasst_tohoku:20160928134118p:plain

①範囲:連続性があるもの
②一覧表:因子水準表など
③マトリクス:組み合わせを表現する
④グラフ:画面遷移図や状態遷移図など

グラフは全体を俯瞰しやすい一方で表現するための技術が必要であったり、マトリクスは簡単に作れる一方で巨大化しやすいという難点があったりします。どれを使うのが正解、というわけではなく、その時に整理したい内容や好みに合わせて活用していくのがよさそうです。

2.詳細化する

これ以上細かくならないところまで細かくします。洗い出してしまえば理由を付けてテストの量を減らすことはできますが、洗い出しが不十分な場合、テストが漏れてしまいます。

3.基準を決める

テストの厚みや幅を調整するための基準を決めます。このとき必要になる情報としては以下の2つです。

  • カバレッジ基準:説明材料として必要なもの
  • 状況、条件、制約:現場や案件の現状に合わせた形にするために必要な情報

これらはプロジェクトやテストの計画時に用意されていることもありますが、ない場合は、様々なテストベースから導き出す必要があります。 リスクベースの考え方を用いてみましょう。

4.基準に沿ったテスト値を導出する

テストを作成します。テスト値には、直接テスト手順の一部(テストデータ)として実施できるものと、テスト値からさらにテストデータを導く必要があるものに分かれます。前者の場合、そのままでテスト実行できるかもしれませんが、後者の場合はテストデータの抽出が必要になってきます。

 このように、テストケースを作成するときには、詳細化やモデリングを行います。闇雲にテストケースを作成したのでは、このテストが十分かどうかの説明もできませんし、効果的なテストに間引くこともできません。最後まで、自分が納得して自分で説明することを意識するとよいでしょう。

テスト観点図やテストコンテナの作成も、詳細化とモデリングという作業を行っていました。これがテスト設計の肝なのだろうなと感じています。

まとめ

東京で開催されたテスト設計チュートリアル(U-30版)のレポートをお届けしました。テスト設計チュートリアルは全国各地で開催されています。東北のみなさんから「テスト設計やりたい!」というたくさんの声が届けば、来年は東北でも開催されるかもしれません。JaSST東北の実行委員と一緒に、勉強していきましょう!!

お知らせ

10月29日(土)に仙台にて、「ソフトウェアテスト勉強会~テスターと創る開発現場~」が開催されます。JaSST'14 Tohokuで講演いただいた@miwa719さんにお越しいただき、テスターやチームについて語り合います。参加費はお菓子+会場費として300円のみとなっていますので、ぜひみなさん、ご参加ください!

tohoku-dev.jp

記:めい

*1:チュートリアル資料 11P

*2:チュートリアル資料 12P

*3:チュートリアル資料 13P

*4:チュートリアル資料 16P

*5:チュートリアル資料 16P

*6:チュートリアル資料 17P

*7:チュートリアル資料 18P

*8:チュートリアル資料 20P

*9:チュートリアル資料 23P

*10:当日の板書より

*11:当日の板書より

JaSST東北おかわり会(07/02)を開催した話

【JaSST東北おかわり会開催】

7/2(土)にJaSST東北おかわり会ということで
丸1日参加者のみなさんとVSTeP漬けになりました。

仙台で土曜開催にもかかわらず、
仙台の人だけでなく、新潟や愛知の人にも参加していただき、
開始早々プレッシャー高まるおかわり会となりました。

 

【おかわり会午前の部】

午前の部は、VSTePの紹介を行いました。

JaSST東北本会のにしさんのようにはできないので
にしさんに感謝しつつ
にしさん講演資料ベースにスライドの順番を入替えたり、
今回対象範囲にしない記載を抜いたり、
補足や途中のまとめを入れたり等させていただき
VSTePの概念や大事にしたいポイントをお伝えすることにしました。

(にしさんにはTwitterで質問のフォローをしていただき、本当に感謝してます。)

 

私には、聞いてるだけだと実際どうやるのか理解しにくいという思いがあります。
どこまで、どの粒度で、はVSTePをやる際、みなさんの悩みどころだと思っています。

JaSST東北本会でも、グループによっては
「詳細に出したまま議論しすぎてしまったため、まとめるのが大変苦労した」、
「粒度がまちまちになってしまい、もやもやした」、
ような話を聞きました。

そのため、午前の部の時点で無茶振りですが、
ざっくり考えてテスト観点出しをするワークや、
そこからテストコンテナを作成するというワークをすることにしました。

ワークでは詳細すぎる観点ではなく、
ざっくりした観点を考えてもらいやすく促そうとしてみたり
VSTePで大事にしたいプロセスをないがしろにした場合に陥る問題の体感をしていただきました。

 

まずは、自分が気になるところを大事にするといい、ということや
どうなると、「もやもや」するのか?
どの部分の理解が「もやもや」していてのか?
など、早く「もやもや」していただけるようにしてみました。

 

午前のワーク時間は超短時間ということもあり、
結果はそれなりに狙い通りになった気がしますが、
実際参加者目線ではどうだったのか気になるところです。
無茶振り以外でも何物でもないので、本当に大変だったと思います・・・。

無茶振りにも関わらず、みなさんのアウトプットはいい塩梅で
本当に助けられたと思いました。

参加されたみなさん、ありがとうございました(><)

 

【午後の部】

午後の部は、JaSST東北本会と全く同じ流れで実施しました。

午前の「もやもや」が晴れて、次なる「もやもや」が生じたようです。

次なる「もやもや」も、まぁそうですよね。と思いつつ、
私たちがよくわからず迷いながらも着実に歩んだ道を
参加者のみなさんは理解しつつ、私たちと違って早足で歩いていただいてるようで、
やってよかったんだろうなぁと実感しました。

 

「もやもや」が残る方もいる中でそれでも最後に、参加者の人たちから
「楽しかった」、「来てよかった」っていわれる勉強会になって
ほんとによかったです。

 

【次なる「もやもや」のために】

私たちは最後まで残った次なる「もやもや」に立ち向かおうと思います。
おかわり会のおかわり会を開くことにしました。

しかし、現状のまま自分たちが変わらないと
「もやもや」は減らないままであることも認識していました。

 

そのため、少しでも自分たちのレベルアップを図ろうと
JaSST東北実行委員は、いろんな「もやもや」解決のため
少しでも期待に応えられるようVSTePの勉強会を独自に開催(7/23)しました。

勉強会の主旨は、分析から、テストケース作成まで一連した流れの体験です。
・詳細設計するために必要なレベルの分析ってどこまでやればいいのだろう?
・コンテナから詳細設計へのつながりってどうやるのだろう?

そんな疑問点が少し晴れる勉強会になりました。

 

おかわり会のおかわり会では、きっと
若干レベルアップした(かもしれない)実行委員に会えることでしょう。

 

【年中おかわり会!?】

おかわり会のおかわり会があるなら、
そのおかわり会も・・・・とすると
1年中おかわり会になるんじゃないの!?、
っていう話もありますが、私はあまり気にしていません。

 

VSTePはテスト開発方法論の1つですが
VSTePが大事にしたいポイントって、テストに限らず
開発、評価問わず業務全般に生かせると思っているので
それが少しでも広まるんであれば、それはそれでいいんじゃないの、と思っています。

 

私含めて、いろんな人の
「楽しい開発」、「楽しいテスト」に
少しでも生かせるならいいですよね。

 

【最後に】

みんなでうんうん唸りながら、手を動かしながら楽しんで勉強できるよう
8/27(土)におかわり会のおかわり会を開きます!

http://tohoku-dev.jp/modules/eguide/event.php?eid=317

おかわり会のおかわり会では、

今回の結果を次回に反映したいと思ってますし、
次回は、異なる「お題」で開催してみようと思っています。

 

VSTePを知らない方はもちろん、
JaSST東北本会やおかわり会に参加された方の中で
異なるお題でやってみたい方はぜひいらしてください。

 

みなさんと一緒に楽しんで勉強できるのを

JaSST東北実行委員会一同、心よりお待ちしています♪ 

                             記:うめつ

JaSST2016東北でVSTePやってみた!

【はじめに】

JaSST2016東北が終わって約1ヶ月が経ちました。

結果は大成功でした。アンケート結果を見てもべた褒めで、正直、信じられない位の大成功でした。にしさんを始め、安達さん、水野さん、JaSST東北に参加してくれた皆さん、スタッフのみんな、本当にありがとうございました。

JaSST東北で実施した内容については、JaSSTのHPおよびレポートを見て貰えば分かるので、ここではスタッフの裏側と言うか、色々準備したことを記載しておきます。

今後、これだけの熱量(=やる気)が出るか分からないので、記録として残しておくことにしました。

他のJaSSTで同じ様なことを行う人がいるかも知れないので、参考にして下さい。

色々言いたい人もいるでしょうが、やったもん勝ちですwww


【JaSST2016東北の概要】

JaSST東北のHPを見て貰えば分かりますが、今年のJaSST東北は「テスト開発しちゃいなよ」をテーマに、電気通信大学のにしさん(@YasuharuNishi)を招いてVSTePに挑戦しました。
午前中がにしさんによる基調講演。午後が参加者全員によるVSTePワークショップでした。


【今回のコンセプト】

JaSST東北の実行委員長をネモさん(@nemorine)から引継いだ時に、以下の思いから、今回の「一つのテーマに終日取り組む」形にしました。

思い①:にしさんを東北に呼ぶ。

4年前のJaSST東北が立ち上がった頃に、一度にしさんが仙台テスト勉強会に来て、お話ししてくれました。その時の話がとても面白くて、その頃から是非JaSST東北で基調講演をやって欲しいと思っていました。
(確かにしさんと話した時の第一声が「CMMiやってますか?」で、その次が「CMMiやって良くなりましたか?」だったと記憶しています)

思い②:テストアーキテクチャ設計を学びたい。

JaSST2015東京のテスト設計 コンセプト コンテストの総評の時に、にしさんが「テスト要求分析、テストアーキテクチャ設計を行うのは当たり前になって来た。テストアーキテクチャ設計のデキで勝敗が決まった」と解説をしていました。これに僕は衝撃を受けました。「テストアーキテクチャ設計ってそもそもよく分からないし、東北でそんなことを行っているのは、(実行委員を除いて)僕は聞いた事がない。東京に比べると東北のソフトウエアテストは遅れているかもしれない・・・」と考え、東北でテストアーキテクチャ設計を学ぶイベントをやりたいと強く思いました。

思い③:スキルを残したい。

JaSST東北は2015年で3回を数え、毎回楽しいのですが、楽しくて終わってしまって、いまいちスキルとして残らない感じがしていました。昨年、安達さん(@kitanosirokuma)に来ていだだき、レビューに関する講演をしてもらったのですが、参加者から「演習時間が短くて、もっとやりたかった」との意見を聞きました。その時に「これなら一つのテーマで1日かけてもいいんじゃないか?午前に講義して、午後にその演習(ワークショップ)を行う感じで」と考えました。私もそうですが、講演等でいい話を聞くと、すぐその気になるのですが、実際に手を動かさないと身に着かず、すぐ忘れてしまいます。そのため、ワークショップで参加者が手を動かすようにしたいと考え、今回の構成にしました。

思い④:JaSST東京の劣化コピーはやりたくない。

2千人が参加するJaSST東京は規模が大きく色々な内容が「広く・深く」入っています。JaSST2015東京の実行委員の方が「JaSST東京はデパート。何でもある」と話していましたが、その通りだと思います。東北(というか地方)で東京と同じ規模のイベントは出来ないと考えます。同じ事をやろうとしても「中途半端で浅く」なると思います。ならば逆に「狭く・深く」やろうと考えました。JaSST東京の劣化コピーなら、JaSST東京に参加した方がいいので、「JaSST東京と違うこと」をやろうと考えました。


【準備作業】

上に書いたコンセプトは、JaSST2015東北を実施した後の振り返り会でほぼ決めてました。
今思うと1年前ですね。もちろん、にしさんへのお声がけも何もしてないので、本当に実現できるかは分かりませんでした。


会場手配とにしさんの快諾

JaSST東北は会場費の節減のため、仙台市の公的施設を借りて実施しています。会場の手配は6ヶ月前の抽選で決まります。このため、11月頭にならないと会場と開催日程が確定しません。今回は抽選で仙台駅近くの会場が当たったので、良かったです。
会場と開催日程が決まったので、にしさんへ基調講演とワークショップを行いたい旨を伝えたところ快諾をいただきました。
その時に、にしさんから「ワークショップを行いたいなら一度実行委員会でVSTePをやってみて下さい」とのお話をいただき、実施することになりました。
(この時点ではこんな展開になるとは想像もしていませんでした・・・)

12月の失敗

12月27日にスタッフが集まり、東京からメイさん(@hinac0)にも参加してもらい、電気通信大学のにしさんの研究室資料をもとに、VSTePを実施してみました。テスト対象はLhaca(圧縮解凍ソフト)で、まず解凍機能のみやってみました。
結果は大失敗。散々でした。
午後いっぱい作業時間があったのですが、テスト観点図の作成で時間がなくなり、しかもテスト観点図をどこまで作ればいいのか、よく分からなくなって終わりました。

ここで非常に厳しい認識に至りました。
「これはにしさんに教えてもらわないと無理だ」と思い、にしさんに仙台に来てもらえないか、相談することなりました。


2月21日 にしさん打合せ

にしさんに相談した所、何と(!)仙台に来ていただける事になりました。正直、来ていただけるとは思ってなかったので、感謝の上に感謝しても足りません。本当にありがとうございました。
2月21日ににしさんに来ていただきVSTePを実施しました。テスト対象はLhacaよりさらに小さいLhasa(解凍ソフト)で実施しました。
にしさんのアドバイスを受け、全部ではないですが、何とかVSTePを理解できました。テストコンテナを作ることによって、前半の観点図の苦労が報われること等、やっとVSTePが少し見えた気がしました。
この時ににしさんから「50人の規模なので、ワークショップはJaSST東北スタッフがモデレータを務めること」「自分(にしさん)は各島を廻り、各モデレータをサポートする」との話をいただきました。50人のモデレータをにしさん一人ができる訳が無いので、もちろん同意なのですが、問題は「我々が本会までにVSTePのモデレートをできる様になるか」が最大の課題になりました。何せ僕を含めてVSTePもモデレートも未経験だったので。

(余談)
にしさんが参加してくれたVSTeP演習の時に、僕がモデレータ役を務めました。こういう時の中心役は大変で、自分の理解度が足りない場合、にしさんに突っ込まれることになります。なので、大変なのですが、逆に一番勉強できる役とも言えます。モデレータ役をやってにしさんに突っ込まれるより、参加者役になって見ている方が楽なのですが、逆にいうと自分の理解が不完全でも誤解したままでも、そのまま終わってしまいます。他人から指摘されるのは辛いかもしれませんが、教えを乞う時はあえて「地雷を踏みに行く」方がいいと考えモデレータ役を買って出ました。恐らくこの時に一番勉強できたのは僕だと思います。

3月5日 VSTeP復習会

2月21日のにしさん打合せの復習会として、3月5日にT-Pad T-Pod(ミュージックプレイヤー)をテスト対象にVSTePを実施しました。
不思議なもので(当然かもしれませんが)、回数を重ねる毎にVSTePの進め方が上手くなっていくのが分かりました。12月はテスト観点図でタイムアップしましたが、テストコンテナまで作成できました。そこで、次はVSTeP未経験者を入れてやってみることにしました。

3月8、9日(JaSST東京参加)

本会のモデレータ役をJaSST東北スタッフが実施するのはいいのですが、残念ながらJaSST東北スタッフは僕を含めて11名しかいません。スタッフ1人、参加者5人で構成しても最大55人しか参加できません。そこで、JaSST東京に参加した時に、JaSST北海道の安達さん、水野さん(@NoriyukiMizuno)にお声がけして、ワークショップのモデレータやアドバイザー役をお願いしました。突然の無理をお願いしましたが、お二人とも快くお引受けいただきました。本当にありがとうございました。水野さんは前日入りして、我々モデレータ初心者に、モデレートする時の注意点等をアドバイスしてくれることになりました。感謝しております。


3月の失敗と「VSTePワークショップの進め方解説資料」

3月25日にVSTePの未経験者を入れてVSTePを実施してみました。テスト対象はLhacaの解凍機能です。
ここで2つの課題が判明しました。
①未経験者の場合、テスト観点図の成果物イメージがよく分からない。また、テスト観点図の次の作業が分からないので、どこまで観点図を作っていいか分からない(テスト観点図作成の完了基準がわからない)。
②いきなりテスト観点を付箋に書き出す様にすると、参加者は仕様書のコピーを始める。
というものです。 

これを解決するため、
①参加者が完了基準や完成イメージが分かるようにVSTePの成果物サンプルを作る。
②ワークショップの進め方(注意点)をまとめる。

ことにしました。

この二つをまとめた資料「VSTePワークショップの進め方解説資料(=VSTePでテスト開発しちゃいなよ)」を作成しました。この資料によりVSTePを初めて行う参加者でも、ある程度進められる様になったと思います。(「VSTePワークショップの進め方解説資料(=VSTePでテスト開発しちゃいなよ)」は予稿集に入れてあります。また、当日のワークショップ終了後に参加者全員に配布しました)

4月9日 VSTePの練習会

4月9日に北海道のネモさんが参加してVSTePの練習会を行いました。テスト対象はカンバンリスト(Webアプリ)です。この日は普段福島にいるJaSST東北スタッフも参加してのVSTeP練習会でした。本来、参加回数の少ない福島組にモデレートをしてもらう予定でしたが、ついVSTePに夢中になってテスト観点図を完成させちゃいました。今までのなかで一番上手くいったと思います。上手くいった要素としては「回数をこなして慣れた」と「テスト対象が、普段仕事で接しているWebアプリだった」ためだと思います。普段仕事で接しているWebアプリだと、テスト観点やその集約化も割とスムーズにできました。
普段福島にいてもJaSST東北のスタッフですので、今回のモデレータを務めてもらう必要がありました。距離的な問題から、練習にあまり参加できなかった福島組は、自社内の同僚を相手にVSTePの練習をするなど工夫して本会に臨んだそうです。

4月29日 にしさん再打合せと「持ち帰って欲しいもの」

4月29日にも再びにしさんに仙台へ来てもらいました。当初は本会の進め方やワークショップのリハーサルを行う予定だったのですが、にしさんより「VSTePのメリットは様々あるが、わずか半日のワークショップでそれを全て理解して貰うのは無理である。今回のワークショップで参加者に何を持って帰って貰うか(=参加者に理解して欲しい事)を明確にする必要がある。そうしないと各モデレータの説明やモデレートの仕方がバラバラになってしまう」との指摘を受けて、丸一日かけて「持って帰って欲しいもの(=参加者に理解して欲しい事)」を検討しました。
検討した結果、「持って帰って欲しいもの(=参加者に理解して欲しい事)」は以下の様に決めました。
(1)テスト観点図作成:①仕様書に無いテスト観点が出る。②参加者全員の合意を得る。
(2)テストコンテナ作成:テストの保守性が向上する。

それぞれの「持って帰って欲しいもの」に対して、どうモデレートすれば参加者が意識してくれるか、参加者へのアドバイスの仕方などを資料にまとめて、スタッフで共有する様にしました。(スタッフの手持ち資料になりました)

この日もVSTePの未経験者に参加してもらって意見等を貰いました。「テスト観点図とテストコンテナの違いが分からない」との質問を契機に、僕を含めて各スタッフのVSTePの理解度の違いが分かりました。貴重な時間を我々の練習にお付き合いいただき、ありがとうございました。

5月の直前練習とモデレートの注意点。

5月12日と15日に、本会の直前練習(リハーサル)を実施しました。スタッフがモデレート役と参加者役に分かれて、本番の進め方をリハーサルしました。
これは僕がスタッフに無理を言って開催したものですが、やって正解でした。スタッフそれぞれの認識がずれていた事が分かりました。また、ワークショップのタイムスケジュールをあらかじめ定めて、全体で同じ時間で作業する様に見直しました。(それまではワークショップの時間配分は各モデレータの裁量に任せる予定でした)。
リハーサルによって、参加者の議論を活発化するための仕掛けなど、細かい準備を行うことができ、本番に備えることができました。僕の無理を聞いてくれたスタッフに感謝です。

前日の水野さんセミナー

北海道の水野さんが前日入りしてくれて、我々スタッフにモデレータの心得や、本会で「持って帰って欲しいもの」を再確認するセミナーを開催してくれました。お忙しい所、本当にありがとうございました。

【開催当日】

にしさんの基調講演資料について

基調講演資料について、にしさんは今回のワークショップ用にかなり作り変えてくれました。電気通信大学のにしさんの研究室資料を見ると分かりますが、VSTePでテスト観点図を作る時に、テスト観点に「品質リスク」等を記載します。ところが、今回はリスク記載は演習の範囲外なので、説明を全部付録側に移動してありました。
また、予稿集が出来上がった後に、参加者からの事前アンケート結果を送付したところ、作り終わった予稿集に更に質問に対する説明等を加筆してくれました。

にしさんの基調講演について

にしさんは、基調講演資料もそうですが、全90分のうち最初の30分をかけて、ひたすら参加者を煽っていました(現状のままで満足している方は、お金返すから帰ってくれとか・・・)。おそらく午後のワークショップに向けて、参加者のやる気を引き出すことに集中していたんだと思います。本当に有り難いです。ワークショップは我々がいくら準備しても、参加者のやる気がないと上手く行きません。午後のワークショップを成功させるために、にしさんは全力で取り組んでくれたんだと思います。繰り返しになりますが、本当に本当にありがとうございました。


ワークショップについて

午前のにしさんの煽りのお蔭か、驚くほど盛り上がり、大成功でした!
お通夜になるんじゃないかと心配していたのですが、そんな事もなくどのテーブルも盛り上がっていました。
お通夜を避けるために、スタッフが話し合ってWACATE等のテストイベントの常連さんたちを、各島に1人座って貰う様にしました。それも上手く行く要因だったと思います。
スタッフの振り返り会では、スタッフの殆どが準備した「持って帰って欲しいもの」を上手く説明できた(=持ち帰って貰えた)と話していました。
反省点としては、常連さんたちに前もって連絡をしていなかったため、ビックリされた方がいらっしゃると思います。突然、申し訳ありませんでした。

【結果と反省と】

結果としては、大成功でした。こんなに上手く行くとは、スタッフの誰も思っていませんでした。にしさん、安達さん、水野さん、JaSST東北に参加してくれた皆さん、スタッフのみんなにお礼を言いたいです。本当にありがとうございました。
最後の懇親会の挨拶で、泣きそうになりました。それぐらい、嬉しい結果でした。

反省点としては幾つかあります。
・他のIT系のイベントと重なった。
・スタッフがVSTePを習得するのに時間がかかり、JaSST東北本体のイベント準備がバタバタになってしまった。
・スタッフ全員がVSTePのモデレータを出来る様になるため、かなりの時間を拘束した。


【最後に】

当然の事ですが、スキルは苦労しないと身に着きません。
苦労してスキルを身につけるか、苦労せず身につけないかどちらかです。

今回はスキルを身に着けること、東北の人達にテストアーキテクチャ設計を知って貰う(=体感して貰う)ことを目的としてここまでやって来ました。
参加者の1人でも、JaSST東北が終わったあと、自分の会社等でVSTePを試してもらえれば、頑張った甲斐があるというものです。

また、今回はスタッフにかなり無理を言いました。何度も「これはチャレンジだから、失敗してもいい」と話しました。「上手く行かなかったら、上手く行くまでやる。3年連続VSTePでもいい」とまで話しました。(さすがにスタッフに止めてくれと言われましたがw)
スタッフのみんなは、よく頑張ってくれたと思います。僕一人では、こんなことは出来ません。本当に感謝の言葉しかありません。ありがとう!


【ちょっとだけ宣伝】

7月2日(土)にVSTePの復習会をします。一日かけてVSTePのワークショップを行いたいと思います。
JaSST東北に参加できなかった方、何かモヤモヤしてる方、是非、ご参加下さい。
TDCサイトで申込み受付中です。

内容:ソフトウェアテスト勉強会~JaSST'16 Tohokuおかわり会~
開催日:7月2日(土)10:00~18:00
場所:戦災復興記念館 第4会議室

   http://www.hm-sendai.jp/sisetu/sensai/index.html#sisetu-annai

参加費:500円

お待ちしています。

 

以上、長文にお付き合いいただき、ありがとうございました。

 (記)JaSST2016東北 実行委員長 高橋

 

20160624:誤字を修正