1 開催概要
2017年9月17日 NaITE#24を以下のように開催しました。
https://nagasaki-it-engineers.connpass.com/event/63088/
開催日時 | 2017/9/17(日)10:15 ~16:30 | ||
開催場所 | ミューザ川崎シンフォニーホール 会議室2 | ||
メインテーマ | テストカタマリーワークショップ&解説 | ||
キーワード・タグ | ソフトウェアテスト カタマリー モデリング RDRA | ||
プログラム | 10:15〜10:25
|
オープニング「開会のご挨拶」
|
NaITE 運営スタッフ
|
10:25〜12:30
|
セッション1「テストカタマリーワーク1部:テストカタマリーでテストを表現してみよう!」 | みずのり氏 | |
12:30〜13:30
|
休憩 | ― | |
13:30〜15:20
|
セッション2「テストカタマリーワーク2部:自分たちのテストを描いてみよう!」 | みずのり氏 | |
15:20〜15:50
|
ふりかえり&フィードバック 実施したワークのふりかえり! |
みずのり氏 | |
15:50〜16:20
|
セッション3 「Relation with Nagasaki And Agile」 |
Toshie氏 | |
16:20〜16:30
|
クロージング | NaITE運営スタッフ |
1 勉強会の様子
今回は「テストカタマリー ワークショップ&解説」というタイトルで勉強会を行いました。
テストカタマリーの提唱者であるみずのり氏、中岫氏(テクニカルアドバイザー)に解説とワークショップを実施していただきました。
「テストカタマリー」と呼ぶ謎の記法を用いたソフトウェアのテスト設計における整理・表記方法についてのワークショップ開催となりました。テストケースの「塊」サイズの表現を上手に用いることで、全体的に「塊」で抜けがないコトを確認しつつ、それぞれの詳細を検討することができると考え、このテストケースの塊を「テストカタマリー」と命名したそうです。 この「テストカタマリー」の名前を適切に設定(画面名や機能で分けるなど)し整理することで、プロダクトのテスト設計結果を類似プロダクトのテストへ流用することができます。
本勉強会用に準備したテスト対象に対して、テストカタマリーを用いたテストの表現を行うワークをいくつか行い、理解を深めました。
また、NaITEの新しいスタッフである長崎在住のtoshie氏に、「Relation with Nagasaki And Agile」というタイトルで自己紹介を兼ねた発表をして頂きました。
1.1 オープニング
オープニングではNaITEスタッフから本イベントの注意事項、NaITEについての紹介、当日のプログラムについて説明をいたしました。その他現在活動中のSIG、2/2に開催が決定した長崎QDGについての案内も実施いたしました。
1.2 セッション1「テストカタマリーワーク1部:テストカタマリーでテストを表現してみよう!」
みずのり氏、中岫氏から「テストカタマリーとは?」の解説を行った後、ワークショップを行って頂きました。
本モデリングを試す際には、以下のような経験があるとよいとされていました。
<
<推奨>
- テスト技法でテストケースをつくったことがあること
⇒同値分割、境界値分析が実施できて、デシジョンテーブルを活用したテストケースがつくれる程度ならよいです。 ワークショップ内では時間の関係上、テスト技法の説明は行いません。 - おすすめ:VSTeP、ゆもつよメソッドといった名前を多少は知っていること
⇒こちらは推奨。特に、VSTePワークを受けていると、本勉強会の「カタマリー」とVSTEPで作られるコンテナの関係性をイメージできるのでオモシロいです。
<テストカタマリーの解説>
近年のシステムは複雑になってきており、多人数での開発、設計書が散在するといったことが起きてきています。特に、多人数での開発の点では、人それぞれのスキル・ドメイン知識などにより、テスト設計、テストケースにばらつきが出てしまい、テストケース等を再利用することも困難となってくる傾向があると説明されました。
仕様変更、機能追加…こんな複雑な状況が近年の派生開発ではありがちであり、様々なところ(人の頭の中、個人のローカルPC内、仕様調整の資料など)に設計情報・仕様情報が分散していきます。そんな状況下ではドキュメントレビューで仕様の漏れも見つかりにくくなります。そこで、モデリングすることできれいに整理して表現できるのではないか?と思い表現してみたとのことです。
このカタマリーができるまでに、ゆもつよメソッド、VSTePを試してみたとのことでした。
テストカタマリーの記法には、UTP、UML、JSTQB,テスト技法、RDRAなどなどが情報としてインプットにあるとのことです。
テストカタマリーとは、テストの塊のことを示します。テストの領域から、テストスコープを分割し、スコープの一部を詳細に落としていきます。この分割されたスコープの一部を、テストカタマリーと呼んでいます。カタマリー全体図、テストカタマリー、ロジカルテストケースの順に階層化されています。クラス表現が主体とした記法となっており、最下層は、DFDのようなものになっているとのことです。
<ワークショップ1>
一つ目のワークショップ(10分間):カンファレンスへの申し込みシステム
チケット種別、購入部分のテストケースがすでに出来上がっている前提で、そのテストケースをリバースして、カタマリーを作成してみるというワークでした。テストケース一覧がすでに塊になっていたため、このワークショップは参加者も取り組みやすかったようでした。
<キガカリーの解説>
キガカリーとは、テストカタマリーに対する”気がかり”な事項を表現したものです。
テストカタマリー = ロジカルテストケース+キガカリー
キガカリーは「ゆもつよメソッド」におけるテストカテゴリ相当にあたるとのことです。詳細は以下を参照ください。
https://www.slideshare.net/NoriyukiMizuno/jasst17-kansai
また、カタマリーのクラス図の中には技法選択のヒントを記載してもよいかもしれないとみずのり氏より解説がありました。
例:「結果網羅」、デシジョンテーブル、ALL-PAIR など。
<ワークショップ2>
二つ目のワークショップ(10分間):キガカリーをかいてみよう!ワーク
気がかりなことをどう表現していくのかに戸惑いながらワークに取り組んでいる参加者が多かったようです。
<ワークショップ3>
三つ目のワークショップ(10分間):ワークショップ2でやったところへ、ロジカルテストケース+キガカリーを足していこう!
ロジカルテストケースのカタマリーの中にキガカリーを書いていきました。キガカリーをモデリングし、テストケースにマッピングしていくのは非常に難しい印象でした。テストの粒度とキガカリーの内容が合わなかったり、キガカリーのモデリングはこれでいいのか?という疑問が浮かんだり、どういう形で抽象化するか悩む参加者が多いようでした。
<ワークショップ4>
四つ目のワークショップ(10分間):キガカリーをまとめてみよう
キガカリーをグループで話し合い、モデリングしていくというワークでした。
最初にモデリングする時と、その後のテスト詳細設計時にもキガカリーがたくさん出てくるので、キガカリーはある程度の数が出てからまとめるほうがよいとアドバイスがありました。また、モデリングしたクラス図の中に入るテスト技法は、UTPのuseを使って表示すると良い、とアドバイスもありました。
1.3 セッション2「テストカタマリーワーク2部:自分たちのテストを描いてみよう!」
4つのワークを振り返り、どうするとうまくいくか?という疑問が参加者の多くに沸いていたようです。そこで、その疑問に対するみずのり氏、中岫氏の経験からくるアドバイスをいただきました。その内容は、以下のようなものです。
- カタマリーの子カタマリーは、has-aで持たせるとよい。
- クラス図はなるべく大きくなりすぎないようにする
- カタマリーは、何らかの仕様書をベースにしたほうが、トレーサビリティを取りやすい。キガカリーは、出していく過程でダブりがあってもよい。むしろ重複を気にし過ぎないほうがたくさん出てくるかもしれない。
<ワークショップ5>
五つ目のワークショップ(15分間):カタマリーとキガカリーをマッピング、モデリングする
講師の方々にいただいたアドバイスをもとに、参加者たちはグループで議論しながら付箋紙に文字を書き、貼り付け、剥がし、を繰り返してモデリングをしていきました。なかなか思うようにモデリングできず、何度も詳細化と抽象化を繰り返しているグループもありました。
実際のプロジェクトにおいても、設計時にはモデリングを何度も見直します。このグループワークでも同じ体験ができ、ディスカッションを行いながらのワークショップは非常に盛り上がっている様子でした。
1.4 ふりかえり
最後に、今回の勉強会で実施したワークショップの振り返りを行いました。
以下に、みずのり氏がまとめてくださっていたものをご紹介します。
振り返りの中で参加者の多くがうなずいていたのは、「キガカリーのスターターキットがあるとよさそう」というものでした。キガカリーのモデリングで、多くの参加者が悩んでいたので、このスターターキットを各組織で持っていれば、担当者ごとの経験や知識差から生じる方向性・観点の違いをある程度は吸収し、完成度の高いものができるともいわれていました。
1.5 セッション3「Relation with Nagasaki And Agile」
今回より新しくNaITEのスタッフに参画したToshie氏より、自己紹介と長崎の紹介、自己とAgileの関わりについての紹介がありました。
長崎は、観光面/食の面、いろいろな面で恵まれたところであることが紹介されていました。
Toshie氏は、現在の業務でアジャイル開発を取り入れているところで、プラクティスを経験し始めているが、いくつか躓き・疑問等が生じているとのことでした。その部分に対し、参加者から意見やアドバイスをもらいながら、活発な議論が交わされました。
2 参考情報・リンク等
当日の発表資料等は以下をご参照ください。
・OP資料
https://www.slideshare.net/NaITE_Official/na-ite-24op
・テストカタマリーワークショップ
https://www.slideshare.net/NoriyukiMizuno/ss-80257236
・Relation with Nagasaki And Agile
https://www.slideshare.net/naototeshima/relation-with-nagasaki-and-agile
3 次回の予定等
次回は11/11(土) NaITE #25「欠陥モデリングワークショップ&解説」と題して開催いたします。ぜひ参加をご検討ください。
以上
ーーーーーーーーーー
2017年10月7日 作成
報告者:岡野 麻子(NaITE)