WACATE2021冬の2日目に行ってきました

結構時間が経ってしまいましたが、WACATE2021冬2日目に参加してきたので、
その内容を報告したいと思います。(記事の内容は適宜更新します。)
1日目の内容は[この記事](https://qiita.com/Toru-ymgc/items/9f8f04798b745b078649)に書いています。

#2日目のセッション一覧

|日時|セッション名|
|:--:|:--:|
|9:30-9:50|オープニングセッション|
|9:50-10:20|モーニングセッション|
|10:35-12:35|探索的テスト|
|13:50-14:55|昼の分科会|
|15:10-16:40|みんなどんな書式でテストケース書いているの？|
|16:55-18:25|招待講演|
|18:40-19:20|クロージングセッション|

#各セッションの概要と所感
※オープニングセッションとクロージングセッションは除きます。

##モーニングセッション(継続的テストモデルにおける具体的な施策を学ぶ)
### 概要
[A Practical Guide to Testing in DevOps Japanese Edition](https://leanpub.com/testingindevops-japanese-edition)に記載している内容を中心にお話していただきました。

- 継続的テストモデルのops部分に着目したお話
- デプロイ先とトグル(フラグ)によって、リリース戦略がさまざま
- 全体の戦略やリリース戦略まで踏まえたテストを考えよう
- 今回のセッションで紹介した施策は以下の通り
    - 開発を手助けする施策
        - ダークローンチ
        - A/Bテスト
    - 一般的に行うテストの後に実施できる施策
        - バグバッシュ
        - ドッグフィーディング
    - 新機能の利用者を徐々に広げる施策
        - βテスト
        - カナリアリリース
- 参考資料
    - [ABテスト,カナリアリリース,ブルー・グリーンデプロイの違い](https://qiita.com/ozota/items/4126d85073175f66cb41)

### 所感
いままで組み込み系の検証をしていたこともあり、初めましての用語が多かった。
次のPRJで上記の施策を使っているところになるかもしれないので、事前に学習できてよかった。
全体の戦略やリリース戦略まで踏まえたテストを考えるのは、テスト自動化を導入する時にも考えないといけない部分だなと思い、共通しているなと感じた。
モーニングセッションにしては、内容を詰め込んでいるなと。。(という感想です。)

## 探索的テスト
### 概要
webサイトを使って、テストチャーターを使った探索的テストをグループで行った。
最初に探索的テストについての説明があったが、事前に[テスターちゃん](https://www.youtube.com/channel/UCM0H2AtNPbSNUg5wCyFsVGw)を見ていたため、理解しやすかった。
事前学習以外で学んだことは以下の通り。

- 探索的テストが使われる場面は以下のパターンが多い
    - システムテストが探索的テストのみ
    - UIは探索的テスト、APIはスクリプトテスト
    - テスト初期
        - スクリプトテストがそもそもできる品質かどうか確認する
    - テストの終わり
        - スクリプトテストが終わった後、仕様などにとらわれないで探索する
        - スクリプトテストの補完としてテストする

- 探索的テストの学習/観察フェーズでよく注目する部分
    - カウントできるものに注目
        - ゼロ/単体/複数
    - CRUD
        - 登録/読み込み/更新/削除
    - フロー
        - 画面遷移/状態遷移
    - 細かい動作
        - 画面のちらつき
        - URLのクエリ
        - コンピューターのCPU音
       
- 探索的テストをうまくできるようなるには、実際にやってみるしかないとのこと。

### 感想
探索的テストできる人に憧れるマンだったので、実際に探索的テストを体験できてとても楽しかった。
いろんな方の探索的テストを見ると、着目していることがバラバラだったので、チームで探索的テストをするときは、チャーターなどの方向性は必要だなと感じた。
また、自分はまだまだいろんな知識が足りないなと実感したとともに、知識を身に着ければこんな楽しいことできるんだと思った。

## 昼の分科会
### 概要
- wacate参加者の皆さんが主体となり、各テーマを持ち寄って議論する会
- 今回は昼に開催されました。
- インプットをテーマとした分科会のオーナーとして初参加
    - 内容はまた別の機会に書きます。

### 感想
初オーナーはとてもしんどかった。(もう勘弁（笑）)
その分、いろいろ反省点と気づきが多かった。

- 情報共有系は議論に発展しにくい
    - 勉強法とかインプットの方法とかはあてはまるかも
    - 情報共有したら、終わってしまう
- テストケースのメンテナンス方法や品質の測定方法の方が議論になったかもと。。
- 全体に話を振るよりかは、指名した方が話してくれそう。

でも、参加していただいたみなさんが結構インプット書いてくれたので、あとで参考にします。

## みんなどんな書式でテストケース書いているの？
### 概要
- グループワークメインのセッション
- どんな書式でテストケースを書いているか共有する
    - 現場の工夫や困っている点を共有することで、他の方の参考にしてもらう。
    - 新たな知見から改善の機会を探す

### 感想
グループワークや全体共有を通して、様々なテストケースの書式がありました。

- 記載の粒度
    - ハイレベル/ローレベルのテストケース
    - 実行する人を考慮したテスト手順
- テストケースの管理方法
    - スプレッドシート/クラウド(TestRail等)/マインドマップ

自分たちの班の共通の悩みだったのが、「テストケースのメンテナンスが一番楽な方法って何なの？」でした。
結局、答えは出ずPRJによって、管理しやすいテストケース書式は違う(銀の弾丸はない)という結論になりましたが、なんかすっきりせずという感じです。。
こういう時は、テストケースのメンテンナンスに関するアンチパターンを集めた方がよさそうだなと感じました。(もう一回班内でやってみたいなとふと。。)

## 招待講演(レビューが教えてくれたこと~私のレビューふりかえり)
今回は安達さんが「レビューがおしえてくれたこと~私のレビューふりかえり)講演してくださいました。
詳細は以下の資料に記載しているので、ぜひ見てください。

- [講演資料](https://speakerdeck.com/kitanosirokuma/rebiyugajiao-etekuretakoto-for-wacate2021winter)

### 概要
- レビューを10数年以上実施してきた安達さんが実際に遭遇したことをもとにどんな気づきを得られたかを話していただきました。
- 今回紹介したケースは8個あるが、私が特に刺さったものを紹介する

#### ケース1：大量の指摘が繰り返される
- 本来指摘したいことではない部分で時間が取られる
    - こういう時は、開始基準などを設けるのがベター
- 論理は感情に勝てない。
    - 相手の受け取りに配慮し、出来るだけ気持ちよくする
    - 主語は私に、断定ではなく推測
- 一度のレビューですべてを指摘できない(見つけれない)ことをなかなか理解してもらえない
- 一気に指摘を増やさないために、3段階レビューやレビュー開始基準を設けると良い

#### ケース3：不備、不整合指摘が多い
- 原因は顧客の要求をすべて対応していたことが原因だった
    - 目的を確認することが大事
        - 要求の背景とか
    - PRJのコンセプトを考えて、要求の承認/却下をする
    - レビューをするときは、以下の流れでレビューの注力すべき部分を決めるべし
        - 兆候察知⇒仮説設定⇒行動選択

#### ケース8：ひとりビジネスのふりかえり
- まわりの協力がないと仕事できない。
- 熱狂は危険
    - 盲目になる
    - 常に疑問を持つことが大事
        - 異なる見方、意見から学び、自ら既存知識と併せて新しい物事の捉え方、考え方に更新し、より適切な思考・行動へと統合する
- 気づきを得るには、やはりふりかえりが有効


### 感想
初っ端のケース1から、自分に該当するところだったのでそこから刺さりまくりな講演でした。
ただ、いきなりすべて実行するのは困難なので、ふりかえりをしながら、自分のペースでカイゼンしていきたいと思います。
とりあえず、レビュー前のセルフチェックは必ずやります。(今までごめんなさい)

## おわりに
今回のWACATEも楽しかったです。
WACATE実行委員会の皆様もお忙しい中、楽しいセッションを用意していただきありがとうございました。
今回学んだことを、現場に活かしていきたいと思います。

また今回は本をいただいたので、積読にならないように気を付けます。