「Workshop for Accelerating CApable Testing Engineers」、通称WACATEに参加してきました。神奈川県・三浦海岸にテストバカが集まって夜通しテストの話をする勉強会です。
WACATE2016 夏 ～走りきるテスト設計～ 開催概要 - WACATE （ソフトウェアテストワークショップ）
以下、前回の参加レポートです。
toshimana.hatenablog.com
…2015夏も参加しているはずなのですが、レポート書いていなかったですね。
概要
タイトルに"走りきる"と書いてある通り、「テスト分析」から「テスト設計」、「テストケース実装」までの一連を行うことが今回のメインテーマとなっています。
「テスト分析」「テスト設計」「テストケース実装」を全て行うワークショップは、JaSST'16東北の企画当初に想定し、最終的に断念したテーマでもあります。
ワークそのものにも興味がありますが、どんな運営、ワークをするのかに凄く興味を持って参加しました。
BPPセッション 近美さん
ASTER-テスト設計コンテスト'14の優勝チームの一員である近美さんの発表は、まさに今回のテーマにうってつけだと言えます。「テストエンジニアはどうあるべきか」の話だったり「テスト技術があると何が嬉しい」といった話があり、上流から下流までの様々な話題の詰まった満足度の高い発表でした。特に印象に残ったものを書き出します。
「始めるのは危機感、続けるのは楽しさ」
普段は意識しないけど、言われると納得する一言。「炎上駆動改善」のように、普段動かない人を動かすには危機感を煽るのが有効。だけど、それではどこかでガス欠になってしまう。なので、楽しさを体感できる仕組みも必要。ゲーミフィケーションがフィットする？この一言は自分の成長サイクルを見直す一環にもなる。
テスト活動も「段階的」戦略で構造設計が必要
良い(と自分が信じている)ものでも、周りは正しく(=自分が期待する通りに)理解してくれない。他人に伝えるためにはどう伝えるかを考える必要があるし、伝える言葉によって、伝わり方が変わることもある。他人を変えることはできなくて、自分が変わる事しかできない。なので、他人を最適化するためには、自分がどう振る舞えば良いかは良く考える必要がある。
ゲストセッション 秋山さん
www.slideshare.net
テスト分析手法「HAYST法」考案者である秋山さんの講義。テスト要求分析で基本となる「分解」について、どのように考えればよいかを説明いただいた。十分に洗い出せているかを確認するための分解フレームワークの紹介や、どのように分解できていると良いのかの例示など。60分という時間ながら、濃厚かつ分かりやすい内容。テスト分析のチートシートとしてスライドを持ち歩きたい内容でした。
ワーク「走りきるテスト設計」
1チーム6人で、二日間を使ってテスト分析ーテスト設計ーテストケース実装を体験する大ボリュームのメインワーク。WACATE実行委員から「WACATEへの参加登録システムのテストケースを用意してほしい」という依頼に応える体のお題でした。お題の説明資料が来た時は、「こんな大ボリュームが二日間で終わるのか！(いや、無理だろう)」と思ったのですが、チームメンバーが上手く協力できてなんとか走りきることができました。
テスト分析
顧客要求や対象のシステムから何をテストしなければならないかを分析する。
- テスト要求分析：システムの目的の洗い出し
- 誰が何の目的でこのシステムを使うのか
- テスト対象分析：画面項目や入力項目の洗い出し
- 画面A、画面Bなどの画面の種類の洗い出し
- 氏名、メールアドレスなど入力項目の洗い出し
雑な言い方をすると、テスト要求分析はトップダウン、テスト対象分析はボトムアップな洗い出しになりやすい。理想としては、ボトムアップとトップダウンが繋がるのだけれど、時間の都合で今回はそこまではいかなかった。
感想
仕様書に引っ張られた印象がある。テストエンジニアは仕様書に書かれていない所を含めて不具合を見つけることが求められるが、仕様書以外のテストすべきことについては十分な議論ができなかったことが反省点として挙げられる。
テスト設計
テスト分析で出てきた項目に対して、テスト設計技法を用いてテストケースを作る準備をする。何をテストするかをモデルを書いて整理することで、テストケースが十分であることを担保する。今回はテスト設計技法として、以下のモノを利用しました。
感想
技法ありきのモデリングとなった印象がある。テスト設計技法を使うことが網羅を担保することにはならないはず。何を保証したいのかを整理した上で、それぞれの保証したい内容をテスト設計技法で整理する方が望ましい。技法を使えることに満足してはいけない。
テストケース実装
テスト設計で作成したモデルに基づき、テストケースを生成する。テスト分析のワークショップではテストケース導出までやることはほとんどないので、テスト分析、テスト設計したものでテストケースを出してみるのは楽しかった。最後の報告で、モデルとテストケースを照らし合わせて「我々はこれでテストの網羅性を担保しています」とドヤ顔でいうのも楽しかった。
まとめ
運営側の目線でワークショップの内容についても考えていました。本ワークショップオリジナルのテスト対象なのに、仕様書が良く作り込まれており、運営側の力の入り具合が感じられました。ワークショップとしてとても楽しい二日間でした。欲を言えばJaSST東北実行委員として、WACATE実行委員と運営やワークの内容について色々意見交換したいと感じました。*1
*1:だから、WACATE実行委員は7/2(土)のJaSST'16東北おかわり会に来ればいいと思う。 tohoku-dev.jp
