wacate 2019夏 ～納期半端ないって～
6/15,6/16に三浦海岸のマホロバ・マインズ三浦にてwacateの研修に参加してきました。
wacateって？
テストエンジニア向けの研修合宿。その名の通り、若手向け。
ただ聞くだけでなく、ワークを通して皆で成長できるような研修内容となっている。
1日目の振り返り
10:00~10:20 オープニングセッション
今回久々に60名達成！
初回参加の人が多数とのこと。
wacateのテーマは「加速」。今回の合宿を通して皆で加速して成長して行きましょう！と熱い思いを語っていただきました。
10:20~11:35 ポジションペーパーセッション
申し込み時に記入したポジションぺーパー（自己紹介シート）を元に各テーブル（1グループ6人）で1人3分ずつでポジションペーパーを元に自己紹介を行う。最初のグループでの自己紹介が終わると、席替えをしてグループワークのチームで再度自己紹介を行う。
まさかポジションペーパーが冊子になっているとは… もっとちゃんと書いておけば良かったと後悔。全員のポジションペーパーを読み明日のお昼までに1人1票投票を実施。
11:35~12:05 BPPセッション -開発者から見るテスト-
前回Best Position Paper賞を受賞した人による発表。
今回の発表者はテスターやQAという立場の人ではなく、開発の人による発表でした。
発表資料は下記より見ることが出来ます。
https://speakerdeck.com/kariad/wacate2019-summer-bpp
Unitテストに注目した発表となっていました。開発者がUnitテストをやらない理由一番の理由は「やり方がわからない」。テストを書くためには多くの知識が必要で、テストを書けるようになるまで時間がかかり、敷居が高いことが原因だろう（まさに私も今その状態）。
また、既存のコードでテストコードを書こうとすると、やたら長いコードやコメントが多いコード（コメントを書かないと、コードが読めない複雑なコード）があり、テストを書くことがより難しくなっているのが現状。発表者の方はこれを解決するには「コードの声を聴く」ことだと言っていました。複雑なコードにも必ず痕跡があり、このコードは何をしたいのかその声を聴くことが大事と仰っていました。
コードの声が聴けるようになるにはある程度スキルと経験を積まなければ難しい気もする。
12:05~13:05 昼食
海鮮丼！
13:05~14:05 セッション１ -テストの組み立て方-
wacate実行委員による発表
発表資料は以下より見ることができます。
https://www.slideshare.net/kauji0522/ss-149792193
JSTQBのシラバスの内容に沿った発表が多いイメージでした。この発表の中で一番活用したいと思ったテストの組み立て方の方法が「テストレベル」を横軸に「テストタイプ」を縦軸にて分割し、どこのテストがmustがwantかを分けていく方法です。
スライドにも記載がありますが、イメージは以下です。
jstqbのシラバスにも記載がありますが「全数テストは不可能」（時間や金銭での制限があるため）なので、テストの必要・不必要の切り分けにこの表を使うと整理がしやすいように感じる。
14:05~17:00 ワーク１
電話のコールから始まり一体何が始まるのかと皆注目。
「悪いお知らせと悪いお願いがあります。」
「今日から徹夜で実装を行い、明日のお昼に納品。明日の10時には実装を完了するので、そこから30分でテスト実行して、バグを修正して納品します。」
テスト計画・テスト設計 2時間（今日のワークの時間）
テスト実行 30分（明日のワークで実施）
のスケジュール。今回の合宿タイトル通り
「納期半端ないって」
テストを行うものは「動画再生数チェッカー」
簡単にまとめると以下となる（他にも情報はあるが割愛します）
背景
- 発注者はワカテミュージックの子レーベル所属
- プロモーションの手段としてyoutubeを使用
- youtubeにアップロードした動画を分析したい
前提
- 分析を行うためにCSVでデータをダウンロードできるようにする
機能要件
- 一般利用者：動画の再生数推移を参照、ダウンロードできる
- システム管理者：一般利用者の権限に加え、アーティストや動画の管理ができる
- 管理者はアカウントを発行するのではなく、特定のパスワードを知っているかどうかで判断する簡易的な仕組み
機能
・管理者権限で利用可
アーティスト追加／変更／削除
動画追加／削除、再生数集計無効化／有効化
・一般利用者。システム管理者両方で利用可
動画検索
再生数更新（1日1回バッチがはしる仕様だが、今回のテストでは手動で更新）
再生数推移確認
再生数推移ダウンロード
管理者ログイン（ログイン画面は一般利用者でも開くことができる）
仕様の説明が終わると、グループでテスト計画、設計を開始。
ワークの感想は最後にまとめて記載します。
19:10~20:50 ディナーセッション
ご飯を食べながら、申し込み時に記載したアンケートを紹介していったり、プレゼント抽選会があったり、勉強会等の宣伝タイムがありました。
21:20~23:00 夜の分科会
いつくかのテーマがあり、興味があるテーマのところに行き皆で語らう時間です。
私は同じ部屋の人とテストについて話しました。
2日目の振り返り
9:00~9:30 SeleniumConf Tokyo 2019 参加レポート
毎年世界のどこかで（アメリカとかの実施が多い）開催されているSeleniumConf。
今年初めてアジア圏内でSeleniumConfが実施された。
英語での発表は日本語で通訳があり、日本人でも理解できる内容になっていたとのこと。
youtubeにも今回の内容がアップされている。
9:30~10:30 ワーク２
昨日のテスト計画・テスト設計を元に30分でテスト実行を行った。
10:40~11:40 ワーク３
ワーク結果の分析を行い、発表準備を行う時間。
11:40~12:40 昼食
3種のカレーのバイキング。毎回恒例らしい。
そして毎回3種のカレーでカバレッジ100にするにはどうするかという議論がでるらしい。
ご飯とナン、カレーが3種。
カバレッジ100にするには簡単では？と思ったら食べているうちにカレーが混ざる。より複雑に…
これ100になるように食べるとお腹いっぱいで午後のセッションが…
12:40~13:45 ワーク発表・講評
各班3分発表・2分質疑応答にて進行。
その後、招待講演を行う中野様より講評を行っていただく。
私の班の発表時に中野さんがちょうど歯を磨いていたらしく講評聞けず（笑）
114:20~ 15:50 招待講演 -テストの組み立て方-
株式会社 LIFULLの中野直樹様による招待講演。
中野様は「ソフトウェアテスト教科書 JSTQB Foundation 第3版」の共著者でもあります。
発表スライドは以下。
https://www.slideshare.net/naokinakano737/wacate2019-150142179
この講演を聞くだけでも今回の合宿に参加した意義があった。
とくに注目したのが7ルール。
1.テスト計画の可能性を疑わない
テスト計画は必要なのか、いらないのではないかと言う人が必ずいるらしい。
そういう人は役に立たないテスト計画を作っているだけ。役に立つテスト計画を作らないと意味がない。
2.みんなのためにテスト計画をつくる
3.最速で作り共有する
1番の理想は仕様を聞きながら、テスト計画を作ること。最速で作って共有することによって、認識のズレやもっとこうしたほうがいいのではという意見を取り入れ、さらに良いテスト計画を作れるようになる
4.戦略やアプローチにこだわる
5.包み隠さず全部かく
このテスト必要？と思うことほどとにかく書くことが大事。その書いたことによって重大なバグを見つけ出すことができることもある
6.無理だとわかったらなおす
想定していたバグの数よりより多くのバグができたりしたら一度立ち止まることが大事。
そのまま進めてもリリース後にトラブルがおこるだけ。
7.誰よりもコミットメントをもつ
これだけでも覚えておくと役立つ時がきそう。
16:00〜16:30 クロージングセッション
ポジションペーパーの賞の発表。
実行委員が選んだ1名、
招待講演の中野様が選んだ1名、
全員の票によって選ばれた1名
が表彰される。
中野様に私のポジションペーパーを選んでいただき、副賞として本を2冊いただきました。
ワークの振り返り
私の班もそうですが、他の班も皆軸としていたことは「お客様の1番の要望は何か」
今回の1番の要望は動画再生数が分析できること。
そのためには受け入れテストの機能テストをmustでしないといけない。
分析できるようにするためにはcsvデータがダウンロードできる→正確なデータをダウンロードするためにはバッチが動くこととどこをテストするか掘り下げていきました(知らない間にマインドマップを使っていた気がする)
機能を１つずつだした後に２人1組になり、テストケースを作成しお互いにペアレビューができたことは良かったなと思います。
反省点として、お客様の1番の要望を軸にしたにも関わらず、そこに関わるテストの掘り下げが少なかったこと。
機能ごとにグループわけしたことによって、全体的に広く浅くになってしまいました。
テストケースに落とす前にもっと重視するところ、しないところを確認する必要があった。
今回初めて、計画→設計→実行の一通りの業務を経験し、流れを理解できたのは大きな収穫でした。
全体を通して
まずは「楽しかった！」
合宿に行く前はテストの研修だし、皆黙々と静かに行うのかなと思っていましたが、どのセッションも必ず笑いがあり、実行委員の方々が楽しませそう！としていることがとても伝わって来ました。
もう一つはQAの方々と初めて関わりを持てた。
自社サービスを扱っているQA、第三者検証の会社の方、開発をしていてテストも行なっている人、、、等色んな人と関わりを持てたことが良かった。
次回も興味があるテーマだったら行きたいと思える合宿でした。