昨年、WACATE 2016夏に参加してきました。
今回は1つの題材を元に、テスト分析・テスト設計を行おうという趣旨のものでした。
WACATE2016のワークで行ったことを共有したいと思います。
テスト分析
最初に仕様書、設計書が配布されたところで、
- 個人ワーク
- ワーク結果をマージ（基準にできそうな人のワーク結果を土台にグループとしての分析結果を出す）
- 各テスト条件に対して、利用できそうなテスト設計技法を選ぶ
という計画を示されました。
私の班が行ったこと
自分達の班は、個人ワークおよびマージした後、
- 「本当にお客さんが要望していることってなんだろう？」
- 「新業務がきちんと行うことができることではないか？」
という結論になり、業務を回すために必要なことは何かということを中心にもう一度個人ワークをすることになりました。
個人的な想い
上記の議論の際、「業務を回すこと」ではなく「一つ一つのチェックがしっかりできること」という結論に持っていくことも可能であり、そちらを取ったほうが色々なテスト技法に触れられるのでは？と思っていました。
しかし、班としての結論・納得は「業務を回すこと」であり、私自身もそちらで納得できたので、この方向で進めました。
ただ、正直、今回のワークとして成功できるのか、そして初参加の方に満足してもらってWACATEを終わらせることができるのか、この時点ではすごい不安でした。
秋山先生の講演
2日目の朝は、秋山先生の講演がありました。
その中で、分解という部分に注目し、前日に出てきた内容についてグループ化を行うことにしました。
発表スライド
www.slideshare.net
個人的な感想
分解、そしてセミラティスの話とか、JaSST'16 Tohokuでの話と似ているなと感じました。
実際、グループ化の作業は正にJaSST'16 Tohokuと同じようなワークになりました。
テスト設計技法の実践＆テストケースの作成
私達の班では、以下の4つを利用することに。
特に、「業務を回すこと」を第一に考えることにしたので、ユースケーステストの作成に3人を投入し、残りの部分に、1人ずつ分担して作成することに。
結果的に、この方針が良かった（気がする）。
ユースケーステストはベテラン1人が若手2人をサポート。
同値分割の人はすぐに終わったので、状態遷移を作っている初参加の人をサポート。
同値分割＆デシジョンテーブル担当は黙々と実施。
そんな形で行いました。
ただし、テストケースについては、時間切れで最後まで完成できず･･･。
そこまで考慮した時間配分にできればもっと良かったかなと。
個人的な想い
ユースケーステストは、他のテスト技法に比べても、作成者の差が顕著に出やすいものになると思っています。
今回も作成した3人で差が出ました。
ただし、今回はベテランではない人のテスト設計結果を採用しました。
これは2つの狙いがありました。
今の自分達チームの結果をきちんと示したい（ベテランの内容をそのまま使ってしまうと、「自分のチームの成果」という意義が薄れてしまう）
テスト設計結果の抜け漏れの部分を、他の設計したもので補完できていることを示したい。
特に2つ目の狙いは、ユースケーステストで書ききれなかったケースを、状態遷移側で上手く補完できました。
成果物
以下の写真のようになりました。
全体の進め方
業務フロー
テスト分析結果
ユースケーステスト
ユースケーステストから作成したテストケース
状態遷移
同値分割・境界値分析
デシジョンテーブル
デシジョンテーブルを元にしたテストケース
はっきり言って、成果物は他の班よりも綺麗ではありません。
しかし、班の人全員が納得できるものになったのではないかと感じています。
最後に
2017年夏のWACATEは6/17・18開催予定です！
wacate.jp
