JaSST’23 Kyushu 実行委員会主催の「JaSST’23 Kyushu」に参加してきました | 1部: 基調講演
去る2023年11月2日、JaSST’23 Kyushu 実行委員会及び特定非営利活動法人（NPO法人）ソフトウェアテスト技術振興協会（ASTER）主催の「JaSSTソフトウェアテストシンポジウム-JaSST’23 Kyushu」が開催されました。
本ブログは、福岡で現地参加してきたレポートになります。
そして、講演内容が濃すぎたおかげで、2部作になっています。
- 1部: 基調講演
- 2部: 招待講演
本ブログの範囲は、「1部: 基調講演」になります。
JaSST’23 Kyushuのテーマはテスト未経験やこれからテスト（QA）業界に入る方々、つまり初学者向けでした
JaSST’23 Kyushuのテーマは、「テストの初学者が、テストの基本的なことを得ること」でした。
その背景があるのか、学生も5名ほど参加されていました。
また、JaSST’23 Kyushu実行委員には、学生から続けている方もいます。
そして、今年からも1名学生が入ったそうです。
ですので、JaSST Kyushuは学生の育成も力を入れている印象でした。
参加した私が初学者（経験が浅い）かと言われると、SET（テスト自動化エンジニア）にジョブチェンジしてから2年目なので、問題ないんです。
基調講演: 「わからない？をわかる！に変えよう！- QAエンジニアが実践している基本的な考え方と方法」/ 福田 里奈 氏（メルカリ）
講演はワーク中心で進んでいきました
講演は上記の①~⑥の流れで進んでいきました。
- ①: テストが上手いQAエンジニアを考えることで、自分が持っていないものが分かり、② からのワークで解決します
- ②: 製品を<使う側>の気持ちを考えます
- ③: 製品を<作る側>の気持ちを考えます
- ④: 製品を作るときの課題は、仕様が複雑であると知ります
- ⑤: 課題の解決策は<作る側>が持っています
- ⑥: <作る側>で全員で会話すると、仕様が明確になります
ちなみに①の女の子は福田さんのつもりです。
自分の中の”テストが上手なQAエンジニア像”を考えることで、”足りない考え”や”やるべきこと”が分かります
【①のワーク】テストが上手いQAエンジニアを考えること自分が持っていないものが分かります
最初に、周りにいるすごいテストをする人ってどういう思考・行動をする人？を考えます。
実は、そのすごい人が実践していることは、今、自分に足りていないことです。
なので、自分の中の足りないことを知ったうえで、１つでも解消してほしい！ことが講演のゴールでした。
ちなみに、私のQAがすごい人は、他の人の想定外を想定できる人でした。
次に、そもそも、テストは何のためにやるのか？を考えます。
福田さんは、みんなの役に立ちたい！であり、そしてそれが一番得意とのことでした。
私の仕事への想いは、役に立ちたい！で一緒でした。
さらに、誰に対して役に立ちたいの？を絞るとチーム > お客さまです。
それはなぜかと言うと、喜ぶ顔が想像できるのが近い順なんだろうな〜、と思います。
仕事は、製品を使ってくれるお客さまのためでしょ！と言われそうですが、自分に嘘はつけないです。
お客さまの顔を想像するの難しい…
製品を使う側だけではなく、作る側も考えよう！なぜならQAは作る側の気持ちを知ることが重要だからです
次は、テストをする上での考えかたです。
製品をテストする時には、良く<使う側>（ユーザー目線）でテストすることが重要と言われます。
しかし、テストするときには、<作る側>の気持ちを知ることも重要です。
なぜなら、製品は作ってから使う人に届けますからね。
ここでは、<使う側>と<作る側>の気持ちを知るワークがあり、私は、対象の製品をJaSSTのホームページにしました。
ここに他のサイトを載せちゃうのはどうかな？と思ったのですが、私はJaSST Niigata実行委員だから良いよね。
【②のワーク】製品を<使う側>の気持ちを考えます
私は以下のようになりました。
<使う側>
- Good: 新着情報がトップにあり、一番知りたい情報にアクセスしやすい
- Bad: スポンサーになりたいけど、導線が分からない
【③のワーク】製品を<作る側>の気持ちを考えます
私は以下のようになりました。
<作る側>
- QAエンジニア: リンク切れないかな？
- デザイナー・CS: 使う側はどの情報から見るんだろうな？
- エンジニア: 他の地域も同じような作りだし、使いまわせる所ないかな？
- 社長・営業・広報・企画・運営: スポンサー付くのかな？売上しだいで来年も開催するか決めたいな？
製品を作る役割によって気にするところは異なります
こうみると、QAエンジニアはちゃんと動くのか？（機能性）のところを気にしています。
しかし、他の役割は、別のところを気にしていますね。
このワークは、Six Thinking Hatsに似ているなぁと思いました。
また、経営層は製品を数字で見たい！とのお話がありました。
確かに、経営層はそもそも、その製品は成長させるのか？撤退させるのか？のシビアな判断をします。
シビアな判断には気持ちとかではなく、定量（数字）の事実が必要なんだと思います。
未成年ってどうやってテストするの？そもそもなんで未成年で料金違うの？
【④のワーク】製品を作るときの課題は、仕様が複雑であると知ります
ここからは、テストの技術的な話になります。
ワークでは、未成年かどうか？で料金が違う製品を例にしていました。
未成年かどうか？は、製品を<使う側>の年齢に左右されます。
そうすると、途端にテストは難しくなります。
なぜなら、常に変動する値を条件にしているからです。
（このブログを読んでいる方も、今、年齢を重ねて変動しています。）
私は、以下のようになりました。
- 誕生日とはどこまで厳密な条件にするのか？（誕生月？日？分？ミリ秒？）
- 未成年と判断するタイミングはいつなのか？（製品を申し込む時？製品を使う時？）
- 年齢を未成年とする国の法律は？（日本？海外？）
もう、大変ですね。
なので、条件をきちんと定義できる人が貴重な存在になります。
それが、テストが上手いQAエンジニアです。
もちろん、製品を作るうえでは、仕様書に書いてあるべきです。
ですが、そのようなことは幻想です。
では、どうするのか？
それは、<作る側>のみんなと会話になります。
<作る側>とみんな会話することを、コラボレーションベースのテストアプローチと呼びます
【⑤のセクション】課題の解決策は<作る側>が持っています
ここからはワークではなくセクションになります。
④のワークで、仕様が複雑で分からない！仕様書がない！という課題があることがわかりました。
そして、③のワークで、製品を<作る側>を気持ちを知るワークをしました。
それでは、製品を<作る側>の人たちと会話して一緒に理解して作れば良いじゃない！ が課題の解決策になります。
これが、シフトレフトのコラボレーションベースのアプローチになります。
ちなみに私は、JSTQBにこの用語が追加されたことをここで初めて知りました…。
勉強していないことがバレてしまいました。私は、製品を<作る側>で会話することが、シフトレフトで最初に取るべきアプローチと考えています。
集まって、机囲んで話すだけなので、ハードルは高くないからです。（three amigo の考えに近いです。）
ただし、会話にも準備が必要です。
「この仕様わかりません、教えてください。」
これでは、会話にはなりません。「この機能なのですが、こういう仕様だと思うのですが、認識間違ってますかね？」
このような、仮説を持った会話が必要です。仮説を持つためには、製品を<作る側>を気持ちを知る必要があり、③のワークを最初にしたのかな〜？と思ってます。
製品を<作る側>で会話する時には、ユーザーストーリーや受け入れ基準で話すと認識が合いやすいです
【⑥のセクション】<作る側>で全員で会話すると、仕様が明確になります
ユーザーストーリーや受け入れ基準の書きかたは、講演資料を見ていただいた方が詳しいので省きます。
受け入れ基準を明確にするとQAエンジニアには大きな利点があります。
それは、テストをすることを製品<作る側>の人たち（ステークホルダー）と合意が取れることです。
合意があるだけで、実際のテストフェーズの安心感が違います。
以上が私の基調講演のふりかえりでした
本当は、「テスト技法」や「テストの7原則」のお話などありました。
しかし、1投稿には収まらない文章量になったので、省きました。
それぐらい内容が濃すぎました。
他の人のテストへの想いを聞くと、共通点があると嬉しいですし、逆に、そのテスト観点を深掘りするのか！どうしてだろう？を考えるのも、楽しかったです。
次は、「2部: 招待講演」です！（執筆中）
