このブログは私のチラシの裏であって（略）
■Quesに初めていってきた（オフラインで）
昨日も書いた通り思い立ってQuesというQA専門のイベントにQAではないけど行ってきました。
普段あまり外出しないので世の中が花金（死語）で飲みに行っているんだなあと知れたのはよかったかもしれません。
全然イベントの感想になってないがな。
オフラインで行ってみて何をしたわけでもないのですがなんとなく見てみて良かったかなあとは思います。
Zoomでもいいんですが話している人の熱量というか、空気感が分かるのが。
シフトレフトがお題でしたが、話していた内容は
特にアジャイルや短期間リリースにおいてはテストに使える時間は限られているので、
目的を定めて厳選してテストしていくよ！といった内容が多かったかなと、、違うかもしれません。
■ぱいんさんの話で印象に残ったこと
ぱいんさんのお話はザク―っというと
リリース頻度を早くするためのブロッカーを取り除きたい
→そのブロッカーがテストフェーズで差し戻しが出ている
→実行が早くても仕様がずれていると手戻りが減らないので
その手戻りを減らすにはどう改善したらいい？というその改善の取り組みの話でした。
その対策の中で、レビューを工夫するというのがありました。
ちょっとうろ覚えですが
「レビューの用意に時間かかりすぎて開発のさまたげにならないようにする」
というのがあって、確かに効率化しようとしてるのにプロセスが重くてボトルネックになったら本末転倒だよなあと思いました。
あとはリグレッションテストを減らすことで
目的に沿ってテストを取捨選択する話もうなづけたかもしれません。
どちらも、目的という軸がないとダメなことだなあと。
自分がテストを取捨選択したりするときに何を軸にして考えているかは立ち戻りたいかもしれないです。その目的が途中（例えばカバレッジ満たしたいだけとか）で止まってないかとか。
■Summyさんの話で印象に残ったこと
シナリオテスト（ユースケーステスト）を結構早い段階で書いて
PdMや開発な人とわちゃわちゃしていくことで
リリースの直前でジャッジしてやりたいことができてないよを防ぐよ、的な話だったとおもいます
（全然違いそうなのでちゃんと資料をみたほうがいいです）
シナリオを早い段階で色んな人を巻き込んでテスト実装していくことは
・ユーザが使いうる範囲のところがあとでダメだーとならない
・シナリオ（ユースケース？）が具体的に合意できる
このへんの点でよさそうですよね（意地悪観点じゃなくいわゆる普通に使う観点を担保できるみたいな）
印象に残ったことは「抽象度をあげた確認ポイント」の話でした。
いわゆる「ここは重点的にみたほうがいいよね」のポイントで
・作るときに議論が活発だったり、仕様が途中で変わったりした箇所
・プロダクトに関わる法律（やレギュレーション）が変化した箇所
・ロジックが複雑な箇所
これらを挙げられていましたが、これはおそらく汎用的に使えるポイントなのだろうなと思いました。
私が今日聞いたことを今すぐ生かせるかって言えばそんなに自信ないですが
取捨選択する、そのために目的に立ち戻るは常にやりたいなとおもいつつねますや
