Zenn
💡

WACATE24夏に参加しました

2024/06/24に公開
Test
QAエンジニア
ソフトウェアテスト
QA
テスト設計
tech

こんにちはHR-techブロダクトでQAエンジニアを担当しているますやまゆうきです。
詳細は後述しますが、WACATEネームはまっす〜です。
ソフトウェアテストの合宿形式のワークショップ「WACATE」に初参加しましたので、詳細についてブログで書かせていただこうと思います。

対象読者

  • WACATEに興味はあるけど参加したことがない方
  • WACATE参加経験者
  • 未来の自分(次回参加時の事前準備短縮用)

イベントの詳細

  • WACATEとは

    • Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ

  • 主催

    • WACATE実行委員会

  • 開催日

    • 2024年6月22日(土)～6月23日(日)

  • 参加費

    • 35歳以下　￥25,000
    • 36歳以上　￥28,000

  • 参加人数

参加した動機、モチベーションなど

  • 社外でQAの仲間を増やしたい
  • グループワークで自分を試したい
  • 知的好奇心
    • 土日にこんなニッチなイベントに集まるような変わった人達の観察

そもそも私ってどんな人

まずは書いてる人についてですが

  • バックボーン
    • R&BのDJ、作曲家、イベント制作、カメラマン、WEBメディアのライター
      • QAになる前は、いわゆるハイパー何ちゃらクリエイターみたいなことを生業としてました。
  • QAエンジニア歴
    • 約6〜7年目
      • 第三者検証会社数社
      • 事業会社でのQAは2年目に突入
  • 普段の業務
    • 品質文化の醸成
    • スクラムチーム内でのQAプロセス&開発プロセスの構築、改善、運用
    • 自動テストの導入・運用・保守(MagicPod導入)
    • アジャイルQAコーチング
    • WACATEを通してQMOの視点で組織を見ていることに気づいた
  • テストの知識・資格
    • 資格なし
    • 独学だけどソフトウェア工学好き
    • JSTQB第4版の内容はぼんやり
    • アジャイルなQAにこだわり過ぎて、テスト項目はもう3年くらい書いてない探索的テスター

事前準備

  1. 会社名を出して参加するので、まず上司に話しを通す
  2. 申し込む
  3. ポジションペーパーの作成・提出
  4. 実行委員との追加のメールやり取り
  5. 当日は現金を準備して会場へ向かう
    ※予習をしていった人もいると思いますが、私は全くのノー準備

持っていったもの

  • 基本的なお泊まりグッズ(洋服や日用品)
  • 充電器など
  • 移動と空き時間に読む積読本
  • 筆記用具
  • MacBook air
    • WACATEはグループで手書きの付箋を貼っていくようなワークショップが基本なので、ワークの中でPCは使いません。メモはMacのメモアプリに残す派です。

イベントの詳細

<1日目>

前段階が長くなりましたが、ここからイベントについて話します

オープニングセッション

運営側の挨拶やアナウンス、参加者用の名札の準備、1組6人で構成される班のメンバーとの顔合わせなど。
班は全部で8つ生まれました。

複数回参加している方も各班に配置されていたので、初参加同士で何したら良いか分からず、見合ってしまうようなことはなかったです。

ポジションペーパーセッション

これからワークを共にするグループ内で自己紹介です。ポジションペーパーは一冊の本のようになっていて読み応えたっぷり。

ポジションペーパーの中から何を抜き出して、どんな順番で紹介するのか考え、実際に自己紹介を行う時間が分けられていました。タイムマネジメントや、情報の伝え方について考え続ける二日間の始まりです。

班のガイドライン作り

これから2日間一緒にワークを行うメンバーで以下を決めました

  • 班の雰囲気
  • そのための行動

参考までに私たちはこんな感じです。

  • 班の雰囲気
    • ワンチーム(ワイワイ、楽しくバリバリ)
  • そのための行動
    • 話しを遮らない、WACATEネームをつける

WACATEネーム(その場限定でのあだ名)をつけるの大正解でした。
複数回参加の方からの案ですが、これによって心理的安全性が高まり、議論も円滑に進んだ感があります。やっぱりちょっと言いにくいこと言い合わなきといけない瞬間もありますが、あだ名のおかげでなんか許容し合えるんですよね。業務でも使いたいな。

BPPセッション

前回WACATEのベストポジションペーパー賞の方が担当するセッションです。今回は「LeadingQuality」のMarkさんこと河原田さんのでした。なんと豪華な。

よくできた虚の空間であるWACATEに参加すると、現実である職場に戻った時にギャップで憂鬱となってしまう現象のことがWACATEハイと呼ばれています。要するに、WACATEでモチベーションがめっちゃ上がるけど、それを会社に持って帰った時に周囲と熱量が明らかに違ってしまい、孤独や無力感を感じてしまう現象のことですね。

そうならないために何をしたらか良いのかということで、Markさんが提案をしてくれました。
それは、WACATEを持ち帰って、現実の職場のメンバーも巻き込むことで、虚実を曖昧にしてギャップを無くしちゃおうというお話しです。

このセッションのおかげで、これが終わったら誰にいつ何を伝えるか、そんな目的意識を持ちながら参加するスイッチが入りました。

Markさんのお題の選び方、発表の仕方、表現がとても勉強になりました！オフライン参加ならではの学びですね。

僕はWACATEハイ、JaSSTハイ、JSTQBカンファレンスハイ、ゆもつよさんハイ、ブロッコリーさんハイなんかによくなります。

仕様変更によるテストケース修正のワーク & 仕様変更のためのモデリングとテスト設計技法の説明 ※資料公開後に添付します

ここからいよいよ、メインのワークへ入っていきますが、2日間手を動かす前の背景のようなセッションが続きました。

メモってたのは以下。

テスト実装の成果物からテスト設計の成果物を導出し、テスト設計の意図を考えられるようになろう

ここは個人とグループで思いっきり手を動かす時間でした。一旦事前の説明。

メモってたのは以下

ここでのワークは、ブロッコリーさん扮する、メテオフォール気味な社長が登場して以下のような流れでおこないました。

  1. 個人で以下資料の読み解きから始まります
  • テスト実装後のローレベルなテストケース(約13項目くらい)
  • アプリの画面遷移図
  • 仕様書

2.グループで、テストケースから設計者の意図を読み解き、ローレベルテストケースから一つ前のテスト設計段階まで戻ってモデリングを行います。（リバースモデリング）

ここの成果物はデシジョンテーブルやユースケースの図などで表しました

3.ここで社長からの仕様変更が降ってきます。チームでどこのテストケースを変更するのか議論し、テスト設計の成果物の変更を行います

  • リバースモデリングにより、ディシジョンテーブルやユースケース図化をしているので、変更箇所の洗い出し&テストケースの変更も容易になっていることを体感して、一日目がおわりました。

班のガイドラインのふりかえり

最後に班で一日を振り返って最初に設定したガイドライン通りになっていたのか振り返りました。うちのチームは「あだ名をつける」という行動指針が「呼べ」に変更されました。
これで一日のワークは終わり

分科会

夕食と自由時間後は分科会が開催されました。正直参加前から1番楽しみなのこれでした。
運営側でテーマがいくつか用意されているので、自分が気になるところに行って自由にディスカスするというもの。

私は「テスト観点について」というテーマの中に飛び込みました。
テスト観点一つでも属する組織や必要とする場面によって全然違うし、答えがないようなものでした。

興味深いのは、誰でも出来るように再現性の高い成果物が必要なテストベンダー寄りな仕事をされてる方か、事業会社のチーム開発の中で活動するQAエンジニアでも、意見が分かれてそうだなという印象でした。

私自身は、手動テストは探索的テストのみで出来るように、バックログを細かく小さく開発してもらっているし、エンジニアにテストをお願いすることもあるので、抽象的なハイレベルテストケースを箇条書きで書いてます。
そして、これをテスト観点と定義付けていました。恐らく、学術的な定義とはズレてますが、必要な人に適切に意図を届けることが目的なので、既存に捉われずといった感じです。

<2日目>

モーニングセッションで派生開発のお話しなどありますが、一旦メインセッションまで割愛します。

テスト分析レベルまでリバースモデリングして、テストの意図を探ってみよう

1日目のワークの続きとなります。グループで以下を行いました

  1. 前日のテスト設計成果物のモデルを作った状態から、さらにテスト分析の意図を読み取って段階までリバースモデリングを行います
  2. そこにブロッコリー社長が再度登場し、さらに仕様変更が発生します。
  3. テスト分析成果物のモデルから変更箇所を洗い出し、テスト設計成果物のモデル、テスト実装成果物のテスト項目書をそれぞれ修正や追加します

設計から分析段階までのリバースモデリングじたいが難しいのと、人によってテスト分析の考え方が全然違うので、とても難易度高いものでした。

発表

2日間で作成した成果物の発表の時間です。
3分で発表し、2分で質疑応答という事で、ここでもタイムマネジメントや情報整理が求められました。
我が班では、発表を社会人1年目や2年目の若手にお願いしましたが、すごく立派にやってくれてとても感心しました。

純粋に今の若い世代は本当にすごい👍
わたしはアラフォーで伸び代も少ないベテランですが、ちょっと慢心して学習を辞めたり、新しい価値観のキャッチアップを怠ったら直ぐに次世代に抜かれてしまなと、刺激を頂きました。

私たちの班の成果物となります

招待公演 モデリングのそだてかた

水野 昇幸sanによるセッションでした。
https://speakerdeck.com/mizunori/how-to-learn-modeling
外部に出せない情報もあるとのことで、こちらは一旦手元に残したメモを自分が参照するのみに留めておきますが、特に勉強になったことを抜き出すと

モデリングの原則

  • 目的はソフトウェアを構築することで、モデルを作成することではない
  • AsIsの整理、詳細出す必要はない→ToBeを出す

失敗例
* 自分が作ったモデルを他人が使いこなせないなどの可能性もあるので、組織への展開は特に丁寧にやる必要がある。
* そして、うまくいかない場合は使わないことを選択することが大事

そして、モデリングを作成時には考え抜く力が必要となり、一般的である以下の考え方を用いる必要があるとのことでした。
* クリティカルシンキング、ロジカルシンキング、思考プロセス、問題解決思考

構造化や抽象度のコントロールはとても大事だと、グループワークでも感じていたので、みずのりさんの口からも聞けてよかったです！

みずのりさんおすすめの本
https://www.amazon.co.jp/dp/4844376578?ref=cm_sw_r_cp_ud_dp_NK7HS4R09CM44Y3V6W1Y&ref_=cm_sw_r_cp_ud_dp_NK7HS4R09CM44Y3V6W1Y&social_share=cm_sw_r_cp_ud_dp_NK7HS4R09CM44Y3V6W1Y&skipTwisterOG=2

クロージング

  • 個人で振り返りを行い、いつどこの誰に何を伝えたいかを整理して付箋に記入
  • 5分間で班から出て出来るだけ多くの人とペアを組んで発表
  • 運営が用意してくれた景品の当選結果やベストポジションペーパー賞の発表
  • 最後に2日間お世話になった班のメンバーに挨拶して終了
    お疲れ様でした

個人的な感想

  • 参加してとても良かった。めっっっっっちゃ楽しかった！！

    • 普段どこに生息してるのかもわからないQAエンジニアですが、ニッチなイベントに土日を使って集まるなんて、そりゃ熱量の高い人しかいません！ハイにもなります。

    • QAという職種の共同体に属している安心感や、まだ見ぬ世界がどうなってるのか期待感が湧いてきて、とても充実した気持ちになりました。

  • 他社のVPoE、アジャイルコーチクラスのようハイキャリアの方もいたので、交流して実務面での悩んでることなど相談できた。

    • 外に出てフラットに他社のひとと話したことで、自分自身の視座の高さや、自分がどこを向きたがっていて、どんなポジションを取るのが組織にとっての正解なのか、そんな自己分析や思考整理ができました。

  • 初対面の人たちとのグループワークは学びが多すぎた。

    • 特に大変だったのが、前提の共有や抽象度の目線合わせのところ。限られた時間で班のメンバーを知るための情報収集と、ワーク自体の進行の二つが必要だったため、見合ったり遠慮したりすることもできない状況が作られました。
    • うちの班では最初に口を開く人が手段<How>から話し始めては全体が引っ張られてたり、目的<What>と混同して全員が混乱してしまうことが起きがちだったので、自分はいちばん最初に方針を提示し、全体像を伝え、必要あれば方向修正を促す人に徹することにしました。（自社でも時々そんなポジションだったり）

  • グループワークを通して自分の思考の癖なんかも見えてきました。

  • モデリングとリバースモデリングは、推論で使う、帰納法と演繹法のフレームワークことだとおまいます。意図を読み解くのもロジカル。

  • 勉強会自体の構成が本当によくできていて、勉強会運営という観点でもとても勉強になりました。カリキュラムは、前後関係や抽象度のコントロールが上手くされた状態で並べられており、順序を追って無駄なく効率的に理解できるようになってると感じました。

  • しかし、実務の中で使える内容であるかは人によるかなと思いました。私はそもそもアジャイルで不確実な開発、仕様変更も起こりやすい環境に身を置いています。そのため確度の高いドキュメント、テスト項目を用意するよりも、最初から変更容易性を意識したテスト成果物をモデリングしており、急な仕様/要求の変更に簡単に修正できるようにしております。

  • 最後に、班のメンバーが本当に良かった。めぐみん、あてさん、レオレオ、ゆうたん、あゆみん、ありがとう(WACATEネーム)、またいつかどこかで会ったらよろしくね！

記念撮影までしてたのはうちだけだったかな？

Discussion