なにもかもがわからなくて…2020冬

あらすじ

「あなたの知らないQAチーム、QAエンジニアの世界」を聞いて良かったなーと思ったが
ふとイベントの目的に立ち返り「QAではない私がQAチーム、QAエンジニアのことを知ることができたか？」
を胸に手を置いて考えてみたらノーだった。

私はQAではないです。
QAがどんな仕事なのかなー、はWeb検索すると出てくるので、何となく分かります。
それを見たうえでも私はQAではないので
私がテストで知ったような話をしたときに「QAっぽいですねー」なんて言われると
「えっQAではないです・・・」と思うこともしばしばです。

「QAを対象にした話は、QAじゃない人も対象で聞いていいのかな？」
これは良く思う疑問です。私はこの話の対象じゃないのでは？と。
今の仕事の範囲だけで関連の話を狭めるのは了見を狭めることになるので
自分が対象かどうかは気にしないふりをしていますが、どことなく自分は対象外なのでは？感はずっと抜けません。

傍から見ればこの拘りはとても下らないことだと思う。
肩書が何であろうが、品質を上げることに邁進できるならなんでもいい。
・・・品質とは？
・・・品質を上げる、とは？

有名な本の定義を持ち出してもいいけれども、これも私はよく分かっていません。
「定義された要件だけ満たすことを確認すればいい」
「バグをひたすら見つけて減らせればいい」
こういうことではない、という意味は分かります。
そのソフトを使う人が困らない、使いやすくなる方法で開発が気づいていないところを気づくように促す？
私は第三者検証の人なので、第一の依頼者は開発している側です。
最終的に使用するユーザーが不利益にならないように想像を膨らませはします。
ただその想像を膨らませすぎて依頼者の利益を損なうようなことにはならないようにとは常に考えます。
飛び越えて暴走してはいけないと。
私は品質のバランサーではなくあくまでフィードバックをみえるようにする側なんだろうな、と思っています。

ところで、品質を考えるのはQAだけなのでしょうか？
多分違います。開発も考えてると思いますし、いわずもがなPMやPO、私のようなテスト実行者も
はっきりと「品質 is 何」を言えないまでもそれを意識しないということはあまりないでしょう。

テストをするのはQAだけなのでしょうか？これも違うと思います。
テストに興味を持つ層を見ればQAだけではないことは分かります。

「QAのみを対象にしてテストや品質を語るのが良くない」と言っているわけではないです。
（そもそもQAのみを対象とかにはしている何かはそうそう無さそう）
QAの仕事は会社によって曖昧で、時には会社内、採用でその認識が分かれていて
それに苦労している人がいるわけで、そんなQAな人々を導くのに
「QA」という対象をメインに話をするのは有効であると自分は考えます。

でも、品質を「考える」か「考えていないか」で、QAとそれ以外をもし分けることがあったりするのならば
その分け方はちょっと悲しいかな、とは思います。
特に自分がテスト実行者だから、品質を考える考えてないで区分けされるのが悲しいと思うのかもしれません。
区分けしている意図はないかもしれないです。
結構感情論です。

うまくまとめられない。ぐえええ
なんだろな。何が言いたかったんだろう。
QAの世界はとても盛り上がっていると思う。
大変かつ定義が曖昧な仕事なのでQA内で情報を交換することは大切なことだと思う。
でもQAの内側からではなく外側からみた「QAとは？」があまり見えてこない。
開発から見た「QA」とは？テスターからみた「QA」とは？
QAの中から開発に働きかけて「テストだけじゃなく包括的に品質をみていくよ！」という話は見るのに
開発側から見た「QAはこんなことをしているよ」が見えてこないのがもどかしい。
私は、プロダクトの開発の中にいるQAを、QA以外の視点から「こんな感じだよー」という話を見たいのかもしれない。
（私は恐ろしく情報収集力が低いので、私が知らないだけの可能性も高い）

びっくりするほどまとまらなかった。
しかも最後（QA以外から見たQAの話し）はありそう。

で、最初の「QAは何をする人かわかったか」がノーなのは
うーん私がテスト以外のどんなことがQAの仕事かがいまいちよくわかっていないからかもですね。
そして、会社によってめっちゃ分かれそうなのでこの「何するか」も一概には言えないのかもですね・・・
良いお年を・・・

このまとまらない記事をまとめると

・私はQAではない。しがないテスト実行者さ…
・品質もよく分からない。
・QA以外も品質については考えてるよね？
・QA以外からみたQAを知りたい！

あなたの知らないQAチーム、QAエンジニアの世界を聞いた話

あらすじ

いまから2か月ほど前に掲題のオンラインイベントを聴講しました。
内容は多分「色々なQAチーム、QAエンジニアのことを知るきっかけになれば！」的な感じだったと思います。
（意訳なので違っていたらすみません）

イベント本番より、その準備の工程のほうが「おおーがんばってるなー」感があって
ワクワクとハラハラを交えた気持ちで経緯を見ていました。

ざっくりした感想

アラカルト的で面白かった。
話を聞く人の対比がちょうどよかったかな？と。
少しリクルート的な雰囲気は感じた。これはこのイベントに限らず
会社の名前を背負ってお仕事の話に触れる界隈は仕方ないのかもしれない。
あと、質問を結構拾ってくれていたのでYoutubeライブなのに双方向感が強かった。

以下は覚えてる限りの感想走り書きです。
（ちょっと時間が経ってしまっているので）

QAチームがある程度出来上がっている組織の話

エムスリー株式会社さんの話はある意味QA的な人々の理想形なんじゃないかなーと思った。
バグの数が指標ではないところや、、比較的早い工程からQAが関わっていくところ
組織としてフラットなところ‥勉強会が業務時間内にできるところ
り、理想形のたまてばこやー！みたいな。
ふと裏を返すと何が理想じゃないんだろう？
・バグの数が指標
・開発が終わってからQAが関わる
・組織としてフラットじゃない
・勉強会が業務時間内にできない
…そ、そういうことか！これは、、！理想形を見てダメを洗い出す！！
（全然感想になってなくてすみません。素晴らしい会社だと思ったのは確かです）
私がこんな会社で働きたいか？と思ったかというと、、うーん？？？？？
烏滸がましい感じがしますね。
まだこの「一緒に成長して一緒に頑張ろう」マインドまで至っていないというか。
それか私は自分の天井を低く設定しすぎているのかもしれない。

QAチームを立ち上げ段階、または一人目QAを募集している組織の話

モノグサ株式会社さんはスタートアップライフサイクル（？？？）でいうと
若い会社なんだろうなあと思った。
職種横断で全員で開発を考えるお話がよかったかな・・
話がすごく飛びますが、今年2月のデブサミにいったときに
「QAいないんですよーほしいんですよねー」とおっしゃっている会社があって
（その会社の方に話を伺ったときに自分たちがテストの人だよと名乗っただからそんな話になったっぽい）
その時にふと「この会社はどのような目的を達成したくてQAが欲しいのかなあ？」と思ったのですが
モノグサさんの話は同じことを思ったかもしれない。
まだ解決課題がふわふわして形がはっきりみえていない段階というか、そこからなのかな？と。
急に困っているところは無いけど品質は大事だなーという漠然とした概念がふわーんとしている感じ。
この「ふわーん」が魅力的か当たり前かとかでも変わってきそうというか、「ふわーん」を
ロクロから焼き物を形作るかのごとく明解にしていくのもQAなのかもしれないですね！！！！（無理やりなまとめ
しかし良いものを作りたいという熱意は感じました。
きっとその良いものを構成する一部に品質が含まれているに違いない。

QAエンジニアのキャリアの話

マークさんの半生の話が涙あり笑いあり、紆余曲折経てQAで花開く感あって面白かった（小学生なみの感想）
80社落ちた後からお仕事で苦労された後の話から色々繋がってQAで生き生きしていくのが物語みありました。
聞いていて思ったのはQAはなんの知識あっても損が無いなーということと
生き生きできる場所をみつけるのは大事だなーということ、ですかね。
なんて陳腐な感想なんだ・・
マークさんのように生き生きプレイスを見つけたいというか、生き生き境界線を越えてみたいなーは思いました。
、、、駄文過ぎて消えたい。

QAエンジニアのキャリアの話（語る人枠）

フリーランスなQAのふるいちさんの話。
ふるいちさんも経験をフルにどんどん繋げていくイメージが強かったです。
全力のときのバイタリティがすごい！と思いましたが、もしかしたら語りたかったことは
全力と気のゆるみ、いつも万全ではなかった（けれど全力を尽くす時は尽くした）という話だったのかな？と
（ちがったらすみません）

最後まで聴いたあとに…

聴いて良かったなーと終わった後思った。
熱意に満ちていて、QAを盛り上げたい！がよく伝わってきた。

しばらく経って、自分の中に疑問が湧いて来た。
私は、このイベントを聴講して、良かったーと思ったけれど
その気持ちの中に「QAとはこういうものなんだ、やってみたいな！」はあったのかな？と。
こたえは、、ノーでした。私は、、QAじゃない！ぶわー（以下怒涛の「私はQAじゃない」編へ続く）

wacate2020冬の2日目でやっていた「cyber-dojoで始めるプログラミング勉強」が面白かった

あらすじ

wacate2020冬の2日目のモーニングセッションで
cyber-dojoを使ったプログラミング勉強（TDDを体験してみる）を
やっていたのですが、それが結構面白かったので
メモを残しておこうと思います。

私は英語がプー＆プログラミングもだいぶ中途半端というひどい状態ですが
テストに関わっていてずっとTDDを見ないふりしているのはよくない気がするので
下記の走り書きを読んで練習したいときにしてみようと思います。

cyber-dojoで始めるプログラミング勉強

・プログラミング勉強は大事だけどつらい

・つらいの中身→プログラミング以外のつらみがいっぱい
環境構築とか環境構築とか環境構築とか

・そんな「プログラミングの勉強以外のつらみにはまらない」方法が知りたい人へ…
→cyber-dojo！！
（プログラミング練習ができるよ
（TDDができるよ
（モブプロもできるよ

・cyber-dojo is 何？
テスト駆動開発(TDD)の練習ができる（数少ない）プログラミング練習サイト

・TDD is 何？
1.最初に失敗するテスト（要件に基づいたテスト）を書く
2.テストが通るようにコードを書く
3.テストが通る状態を保ちつつコードの重複などを排除（いわゆるリファクタリング）
以下1に戻ってループ

・TDDは何がうれしいか？
1.次の作業のための受け入れ基準が明確になる！
2.テストが「コードが何をしているか？」の説明になる
3.自動テストを書くことができるコンポーネント状態が保たれる
4.（テストコードを書く）サイクルを細かく回していくと
コードが動かなくなったときに、前にテストが通っていたときの状態に
すぐ戻れる
→（＾o＾）安心

TDDについて詳しくは本を…参照！
・テスト駆動開発
・実践テスト駆動開発

テスト駆動開発の勉強には、開発環境の構築と
ユニットテスト環境の構築が必要
（つまりテストコードを書く環境とテストするコードを書く環境？
↓
PCの環境が…汚れていく…

・プログラミング練習サイト少ない
↓
・そこでCyber-dojoを使おう！

＊＊＊ここから動画で説明＊＊＊＊

補足：この動画の説明が楽しかったのですが
通信速度？の関係で接続がラグっていて勿体無かったので動画（ワーク共有資料）を
見られるうちに概要メモしておきます。
動画に合わせて手を動かしてみると分かりやすかったです。

www.cyber-dojo.org

1.
モブプロやりたいなら右の「we're…」
一人で練習するなら左「i'm on my…」を押す
・今回は一人で練習

2.次の画面で
上：create a new…：新しい環境を作りますか
下：enter an existing…：昔の環境を引っ張り出しますか
・今回は上を選ぶ

3.次の画面は問題選択（choose a problem）
プログラミング練習のお題を選ぶことができる
自分でも任意の例題を作ったりもできる
・例題を選択or自分で作った例題を使う場合は何も選択せず[next]

4.次の画面は言語とテストフレームワークを選ぼう（choose a langage & test-framework）
ここで言語を選択し[next]

5.環境これでいいですか？の確認がでるので[confirm]

6.IDが振られる。このIDをメモっておく
※中断したときにこの番号を指定してあげると途中から始めることができる。
[enter the exercise]を押して開始

7.環境の説明が表示される
赤：テストは失敗している
黄色：テストは走っていない（コンパイルエラーなど）
緑：テストが全部通ったよ
「×」説明で閉じるともう環境が出来ている（おめでたい！）

Hiker.拡張子：テストされる対象（普通にプログラムを書くためのファイル）
Hiker_Test（またはtest_hiker）.拡張子：テストコード（テストを書くためのファイル
[+]で任意のファイルを追加できる

最初は
・Hikerの方に「6*9」が書いてある
・Hiker_Testの方に「42」が書いてある
このままの状態で[test]を押すと（太極図がぐるぐるする）
テストコードの期待結果「42」に対して、プログラムの出力が「54」
なので「失敗してるよ」的なログが出る。
[test]の上あたりに赤い●が出る。
プログラムの方を（6*7)に修正して
[test]を押すと成功したっぽいログが出る。
[test]の上あたりに緑の●が出る。
（この「失敗しているテストを、プログラムを直して通す」が1サイクル）

流れは
1.テストコードを書く（まだプログラムコードは実装しない）
2.テストする→失敗する
3.プログラムコードを実装する
4.テストする→成功する
これを1つの仕様ずつで繰り返していく。
（いっぺんに複数の仕様のテストを書かず、あくまで1つ1つやっていく、この1つ1つクリアがTDD）

TDDの場合は失敗したテストに基づき「最低限の」コードを実装する
詳しくは書籍でお楽しみください…

→書籍を読みながら上記の最低限説明を読んでFizzBuzzでも
やってみるといいかもしれない！

感想

テスト対象に対して結果を書いてテスト、は以前Pythonの試験に向けて勉強していたときに
ほんの少しやっていたので知っていたのですが
TDDの「テストを先に書く」→「失敗する」→「実装する」→「テストを通す」というのを
具体的に見たのは今回が初めてでした。（不勉強にもほどがある
文で読むのと実際を見るのって結構違うので、こういうことを言っていたのか
という腹落ち感がありました。

どこからとっかかれば良いか分からない、に対して
実際の動作を見てみる、は結構有効なんだなというのと
文だけじゃあまり分かっていなかったというのが自覚できて良かったです。

なので、プログラムに対するトラウマの一つの解消法として
・実際に操作しているところを見せてみる
・あわよくばそれに習って手を動かす
は有効なのかもしれないですね。

JSTQB FLの勉強方法（分科会でみんなが考えてくれた内容＋α）

あらすじ

wacate2020冬オンライン（wacateの説明は省略します）の分科会（説明省略します）で
参加してくれた人々が「分からない点」やそれに対する「こうすればいい」を
出してくれたので、それを共有します。
これから勉強する方の参考になれば…！

分科会のイメージ

解決案の色の見方

緑：自己完結で出来る
茶：他者と一緒に頑張る・他者の力を借りる
青：私の謎コメント
黒：分類なし

注意

・多少文章の言い回しを変えているところはあります
・全部は載せていないかも！

1章.テストの基礎

開発がどんなテストしているのかわからない

＜解決案＞
・開発者とランチいって聞いてみる（当事者に聞く）
・自分でも書いて体験してみる。cyber-dojoってのがあるらしい（自分で体験してみる）
・周りに仲間を見つけてみんなで解く（周囲を巻き込んで体験してみる）
＜謎コメント＞
開発がどんなテストしているかは、会社によって異なりそうです。
強いて言えばソフトの中の細かい「XXする」の単位（関数）とかが実現するかは開発で実施することが多いのではないでしょうか。
書いていて思ったのですが、「慣れていないときに、ソフトの中の話をどう話したら分かりやすいか？」を
分科会で聞けば良かったと思いました。
最初のうちの「用語に慣れない」という視点はとても貴重なのです。
JSTQBの勉強で「開発がどんなテストしているか分からない」は
「デバッグが分からない」か「ホワイトボックステストが分からない」に繋がっているのかな？と思います。
図を描きますのでもし参考になれば。

ブラックボックステスト（中は気にせず結果に着目）

ホワイトボックステスト（中に着目）

※デバッグは青本P11や21の図のがわかりやすいかも

2章.ソフトウェア開発ライフサイクル

たくさんの開発ライフサイクル（がわからない）

＜解決案＞
・他社の人や、他社から転職してきた人に話を聞いてみる（経験者に聞く）
・勉強している側がJSTQBFL（の内容）をまとめて、それを先輩に確認してもらう（周囲を巻き込んで自己理解確認）
＜謎コメント＞
開発ライフサイクルの話は、JSTQB以外にも情報系の試験だと良く出てきます。
全体を知る前に勉強で知る人の方が多そうです。
「経験者に聞く」が有効そうですが少し違う意見を。
ーーーーーーーーーーーーーーーーーーーーーーーーーー
仕事で自分が担当している工程の前後を考えてみます。
　1. 製品の構想をしている段階があって
　2. 自分がテストに携わって
　3. テストが終わって問題なさそうになると世の中にテストしている製品が出ていく。
その「構想をする」と「製品が出ていく」が開発ライフサイクルの始まりと終わりなのです。
自分が開発の流れの中の一部分にいるんだよー、から少しずつ考えていくのかな、と思います。
会社に入ってから間もないと、テストしているものが世の中に出ていく、までの流れを経験していないこともあるでしょうが
しばらくいると「始まり」があって「テスト」が関わって「終わり（世の中にでていく）」という一連の流れが見えてくるかもしれません。

3章.静的テスト

レビューの形式多すぎ

＜解決案＞
・経験に落とし込まないと理解がすすまないので、わかる人を交えてロールプレイングしてみる（周囲を巻き込んで体験してみる）
・周りの人に聞く（経験者に聞く）
＜謎コメント＞
自分は実務の想像を諦め、「レビューは誰が主催するか」「目的」などを表にして覚えたかもです。
テクニカルレビューとインセプションについては今も実物を完全には分かっていない。
正式なレビューほど経験者に遭うことは少なそうなので
ここはググった資料をおいておきます。
＜テクニカルレビュー＞
はじめよう！レビューのいろは
↑wacateの資料ですね
（インセプションは見つけられませんでした；；無力ですみません）

4章.テスト技法

技法がいっぱいあって紐づけがむずかしい

＜解決案＞
・技法を覚える（技法練習帳をやろう）（自分で体験してみる）
・ワークショップで覚える（周囲を巻き込んで体験してみる）
（今のところ技法のワークショップは過去にwacateで何回か有ったと思います。connpassで情報チェックですかね）

＜謎コメント＞
分科会のときも目一杯同意しましたが本当に同意しかありません。
これは自分のテストしているものにも大きく依存しそうです＜技法の紐づけのイメージ
WEBだと状態遷移と画面遷移がごっちゃになりそうです。技法練習帳は有効かも。
入力欄・選択するものがいっぱいあるとかだと、自分は頭の中にデシジョンテーブルが浮かびます。
組み込みだと電源OFFだONだがあるので状態遷移もちょっとイメージしやすいです（スイッチおしてONとOFFの状態を行き来とか）
すみません。勉強方法ではなくなってしまいました。
周囲を巻き込めるなら技法練習帳を一緒にやってみるといいかもしれません。

経験ベースのテストってなに？

＜解決案＞
・__rina__さんのテストライブに参加する（勉強会参加）
動画もあがっていました。すげい↓
人類よ！これが探索的テストだ！テスト実況生中継で学びを深めよう！ - Zoom

＜謎コメント＞
経験ベースというと探索的テストの話がよく出ますが
過去の経験（例えば前に同じようなソフトで起きた不具合とか）を根拠にテストすることですかね...
入力欄に何も入れないで決定を押して変なことが前にあったなー＞今回もやってみよ！とか。
これを過去の経験が少ない人が腹落ちするいい言い方があればいいのですが。
ゲームでいえば、あるブロックを叩くとコインが出てくることがある＞ブロックを叩いてみよう、とか
とにかく、自分の経験に基づいてテストすることを決める何かですね。

プログラム言語がトラウマ。
ホワイトボックステストアレルギー

＜解決案？＞
・ブラックボックス：結果だけ見る、ホワイトボックス：分岐を考える（概念の答え）
・中の動きを考えながらのテストがホワイトボックス（概念の答え）
＜謎コメント＞
このトラウマの克服方法を今も考えています。
プログラムの苦手意識を無くすには入口のハードルを極限まで下げることです。
Online PHP/Java/C++... editor and compiler | paiza.IO
にアクセスする
　1.左上の言語「Python3」を選ぶ
　2.黒いウインドウ欄に「print("hello world")書く
　3.実行する
→下の白い枠に「hello world」が表示される
このへんからとっかかっていく（まずは「できない！」という意識を緩和する）のが手かなと思います。

5章.テストマネジメント

マネージャー≒リーダー？

＜解決案＞
・他の人の経験談（ブログ、発表等）を開いてイマジネーションを膨らませる（他者の経験を見る自己完結）
＜謎コメント＞
マネージャー、リーダーなどがいるかどうか、それぞれの役目は組織の数だけ違いがあることは大前提として…
JSTQBの教科書を読んでいる感じではマネージャーは管理職めいた感じですよね。
マネージャー：マネジメントをする人
テスト担当者：テストを作ったり実行したりする人（この中からリーダーを指名することもあるって教科書に書いてありますね）
教科書の256ページにテストリーダーという言葉がでてくるんですね。
何となく下記のようなピラミッド構造を示している気がします。

テストマネージャーとテストリーダーとテスト実行者

マネジメント未経験からの分からなさ

＜解決案＞
・一読して全体概要を把握、マネージャーの普段の立ち回りを思い出す→マネージャーの行動と書籍の内容を紐づける→具体化され解像度があがるので理解が脳に定着する（他者の経験を見る自己完結）
＜謎コメント＞
安心してください！私も分かりません。（えー
解決案に記載してくださった内容を自分もやっていました‥
どの職場でも、テストという単位だけじゃなくて大きく見渡せばマネジメントをしている人が居ると思うんです。
例えばプロジェクトマネージャとか。
その人たちが何をしているかに思いを馳せていく感じですかね。

6章.テスト支援ツール

ツール多くない？

会社環境によってツールを使わないのでイメージしづらい

・わかりみの嵐（解決方法よりわかりみがいっぱい書いてあった）
＜謎コメント＞
これは、、、ツールを使ってみてイメージする感じかもしれません！
分かる限りでツールの例を紹介しておきます。。、
静的解析ツール（開発）
いわゆるプログラムをなんやかんやしたときに
この形じゃ実行できないよ！とか出てくる何か。
（実行する前にプログラムのおかしいところを表示してくれる）
Online PHP/Java/C++... editor and compiler | paiza.IO
にアクセスする
　1.左上の言語「Python3」を選ぶ
　2.黒いウインドウ欄に「print("hello)書く
　3.実行する
→下の白い枠に

File "Main.py", line 3
print("hello)
^
SyntaxError: EOL while scanning string literal

と表示される（helloのところの終わり方がおかしいよ！Syntax(文法）エラー
この「実行前にエラーしているところを解析できる」が静的解析ツールのイメージです。

テスト設計ツール
アカウント登録必要ですがGIHOZを使ってみましょう。状態遷移図やデシジョンテーブルが設計できます。
テスト技法ツールGIHOZ｜ソフトウェアテスト・第三者検証のベリサーブ

他も色々ありますが、壮大なツールを使って「うわっツールよくわかんね」などのトラウマになるのなら
単語から覚えるのもありだと思います！

その他全体

テスト用語から、まずちゃんとわかっていない

＜解決案＞
・JSTQBの用語を確認
＜謎コメント＞
だいじょうぶ　さいしょはみんな　わからない（５７５）
結構ギリギリまで区別つかないもんだと思います。
めげずに読んでるところで迷ったら意味調べる…を繰り返していくのがコツです。
試験終わっても分からないこともあります。
分かるか分からないかより、アレ？となったら調べることに立ち戻る姿勢が大事なんじゃないかなーと
「テストタイプ」とかでググるとみんな苦悩している気配がみえますね。。「テストレベル」とかも

公開されている過去問が少ない？？

＜謎コメント＞
JSTQBの「問題用紙は回収し正答は出さない」
そのポリシーは「問題を覚えてそれだけやってほしくない」が影響してそうです。
ググる翻訳で問題を翻訳するという方法でも良いならばISTQBのサイトにありそう。↓
Foundation Level - ISTQB® International Software Testing Qualifications Board

なにもかもが、、わからない！（※意訳です）

＜解決案＞
・がんばる
＜謎コメント＞
まず最初はみんななにもかもがわからないです！そこは安心してください（は？
そして近道はあまりない気もします。
実務で覚えるにせよ、本で読むにせよ、毎日の少しづつの積み重ねが
何もかも分からない！から
ほんの少しだけ分かる！に進めるのだと思います。
今、分からないことに絶望しないでくださいー！

・全体に対しての意見
＜解決案＞
・確かに勉強したことを社内で発表してみることで自分自身の足らないことや今わかっていることがわかるのかも？（周囲を巻き込んで体験してみる）
＜謎コメント＞
この解決案、間違いないです。社内発表までいかなくても言葉にするといいです。
「言葉にすること」が「分からないことを分かる」第一歩なので。

さいごに

分科会に参加してくださった方…このページを見てくださった方…試験、応援しています！！！

wacate2020冬オンライン（2日目）

wacate2020冬に参加した（2日目）

先週の12日にwacate2020冬に参加したという記事を書きましたが
今回は続きが1週間後の土曜日、というわけで今日でした。昨日でした。

例によって今の気持ちを走り書きしておこうと思います。
（技術的なこと以外が多いかも）
あと、前の記事を読んでくれた人が居るのにびっくりしました。
この推敲とは無縁の駄文を、、！恥ずかしい！
この記事が検索に引っ掛からないように色々な方がwacateの参加記事を書いてくれることを
凄く待ってます。待ってます。・・

去年の2日目の謎記事は↓
wacate2日目 - 私は迷いの中にいる

2日目開始～オープニングセッション

1日目のときと同じくZoom、Slackを駆使してやりとり。
Zoomに入ると実行委員さんがいるのでご挨拶。
ブレイクアウトルームも開いていたので入ってみました。
（基本的にブレイクアウトルームが参加者間雑談用になっている）
この時、私は初めて分科会のオーナーをやることでてんぱっていたので
お話してくれた方に勉強会のアドバイスをもらいに泣きつきました。ありがとうありがとう。
Twitterでフォローしてくれた方ともお話した！たのしー
なんというか、みんな初めて参加かもしれないのにwacateの「たどたどしくても許される空気感？」
を持ってお話してくれるのはありがたいやらありがたいやらありがたいやら
for i in range(10000):print("ありがたいやら")
ワークの班の方にも勉強会でどんなことを気を付ければのアドバイスをもらいました。
ありがとうございます。とんねるずじゃないけれどみなさんのおかげです（謎

オープニングは今日の流れと先週何をやったかのふりかえり。
分科会の紹介もやりました。私はオーナーだったので紹介をやりましたが
歴代の分科会オーナーの中で一番噛んだ自信があります。

モーニングセッション

べにちどりさんのセッション。
プログラミングの勉強を始めるのにプログラミング以外（環境構築とか）でくじけるのはつらい
気軽にプログラミング勉強を始めよう！ということで（環境構築なしで使用できる）
Cyber-dojoを使用したTDDの入門な紹介。
私はテスト駆動開発をしたことはないですが、条件1個1個をテストしていく（まとめてではなく）は
確かになと思いました。
（まとめてテストしちゃうとどこがこけているかわからないから、的な話だったと思う、、うろ覚え）
私のプログラミング知識はめちゃくちゃ中途半端なのですが、手になじませる意味なら
継続してCyber-dojo等で勉強するのもいいかもしれないと思えるセッションでした。

BPPセッション

2019wacateのベストポジションペーパー賞を受賞された方のセッション。形式にとらわれないテスト計画やテストレベルの認識合わせの話
そこにしびれる…あこがれる！！！
「すごいなー」という小学生も真っ青の感想しか出てきませんが
きっとテスト計画やレベルを細かく、かつ明確に合意するには並々ならぬ努力があったのだと思います。
いつか認識合わせに悩んだ時に「こんな形の合わせ方もあるんだよ」ということを思い出したいセッションでした。

分科会

別記事参照です。

私にはもう
・分科会参加者への感謝
・参加者のFL試験がうまくいきますようにという気持ち
・参加者の方がいつの日か成長して「こんな分科会も参加したなあ・・分からない日もあった（遠い目）」と懐かしんでくれることを祈る気持ち
しかありません。ありがとうございます（n回目）

お昼休憩

私は何かが終わると大体胸が締め付けられるようなハイな気分になるので乱文を書き殴っていました。
カレーは食べていません。

おまけ

オフラインのwacateは2日目のご飯はカレーです。
カレーが3種類あります。1個普通のカレーが混じっていたのだけ覚えています。普通のカレーは味が普通です。
あと2つはおいしいカレーです（？
あと、ライスが2種類とナンが1種類なのでここで炭水化物とカレーの組み合わせを網羅するのに
テスト技法を使うと覚えておいてください。覚えておかなくても大丈夫です（？？？

セッション6：仕様からのテスト

ブロッコリーさんのセッション。
「Agile Testing Condensed」の翻訳内容をベースに、開発工程のどこでもテストしていこう
（開発が終わった後ではなく）
開発とQAの異なる視点を持ち寄ってテストを考えようというお話だったと思います。（違ったらすみません）
『Agile Testing Condensed』翻訳者による、Agile Testingのエッセンス - DevLOVE | Doorkeeper
のお話に似ていたとは思うのですが、こちらは翻訳内容を焦点にあてていた（と思います）のに対して
今回は、実例マッピングのワークがメインでした。
ただ、大切なのはプラクティスじゃなくて会話する過程だよ、とはおっしゃっていました。
これはプラクティスを使うこと自体が解決をもたらすという期待を知らぬ間にしてしまうかもしれない
ことに対する否定だったのかなーと思います。
実例マッピングのワークは、、意外と難しかった！
例からルールを導きだすことと、これがテストケース例なのかルールなのかの判別が難しかった印象です。
今回は実例マッピングのワークということで実例マッピングを使ってテスト対象の分析を行いましたが
他の方法（思いついた因子から水準を考える）で見ていってももいいんだろうなとは思いました。（班の方の分析力が高かったのでなおさら）

セッション7：あなたのテストは誰のため_後編

ときわさんのセッション。
先週爆散したワーク。（どのように爆散したかというと伝えたい相手を広く考えすぎた）
「伝えたいこと」「伝えたい相手」「何を伝えたいか」を順を追って考えたのが先週の前編。
今週は今一度先週の内容を整理したあと「相手にどんな反応してほしい」「伝える手段」を考えました。
ときわさんのアドバイスで「伝えたい範囲を狭める」ことでだいぶスコープを絞って考えることができました。
伝える手段の考え方がちょっと荒かったかもです（いつも他の人の話をみて気づく）
「伝える目的（Why)」から考えていくのと「伝える相手（Who)」から考えるのを行ったり来たりして具体化していく
という話が出て結構目からうろこでした。
詳しくは書きませんが、一つ実現したら楽しいだろうなあという話がワーク内であったので今後の楽しみに・・・しています！

招待講演：良いテストは良いフィードバック

井芹さんの招待講演。ワークもありました。もっとメモしておけばよかった。。！！
テストだけでは品質は良くならない。（品質を良くするのはプログラミングなどで実現される）
テストは改善と判断のインプットを提供するもの。
テストをフィードバックの一種と考えて、どんなテストが良いフィードバックになるかを考える（逆に悪い例から考えて）
これを「正確」「的確」「適時」「理解容易」「信頼構築」の面から考えて
テストに必要な考え方を理解する。。といった内容。
どれも基本的なことなのですが、もうこの言語化がすごかったです。
モデリングが複雑なことを理解するための手段だよ、だったり
なぜその複雑なことを理解する必要があるかというと、テスト対象を正確に知るためだったり…とにかく
理由のトレーサビリティ（根本の考えがあって枝があっての説明（そしてその枝が適当ではない））が圧巻でこの内容でハンドブックがあればよいなーとも思いました。
日々に追われて「なぜこれをするのか？（例えば伝えやすい関係を気づいたり、仕様を図示して分かりやすくするなど）」を忘れることが私はよくあります。
この講演内容はそんな「そもそもの目的」を見失いそうなときに思い出したいです。

クロージングセッション

並木さんによるクロージングセッション。
同じ班の方がBPPになっていた！おめでたい！！
次のwacateは参加できるかわからないけれど、BPPセッション聞きたい、！！！
表彰状はPDF。
あとは豪華なプレゼントがありました。
まぐろば君ぬいぐるみは欲しいかもしれない。プレゼントは郵送されるそうです。

wacate2020冬オンラインまとめ

どのセッションも良かったのですが一番楽しかったのはブレイクアウトルームの雑談だったかもしれません。
私の話は他の方の貴重な体験たりえたのでしょうか？
私にはどの方の話も貴重なものでした。
自分の持っていない技術の話も、会社で勉強会が盛んな人の話も、私と同じように会社では勉強会などは無い人の話も
思い切って飛び込みでwacateに来た人の話も、分科会で伺った慣れないうちの話（わかりみ天元突破）も全部貴重な体験でした。
オンラインながらこの交流の機会を繋いでくれた実行委員の方に感謝しかありません。
お話してくれた参加者の方々、実行委員の皆様、ありがとうございました！！

謎テスター、wacate分科会オーナーをやる（参加2回目で）

wacateで分科会オーナーやった

というわけで、wacate2020冬オンラインで分科会オーナーをやってきました。
（wacateがなにかの説明は省略します、すみません；；）
これが私の人生初のモデレータ経験であり、勉強会経験です。ぐえー

多分この後100回くらい繰り返してしまいますが
・分科会参加者の方々
・分科会をフォローしてくださったwacate実行委員の方
・勉強会とはどんなものか！をアドバイスくれたwacate参加者の方々
・葛飾の人々

ありがとうございました！

テーマ

JSTQB FLの勉強方法（をみんなで考えよう）

分科会オーナーをやってみようと思った動機

・今回のwacateは初めての人が多く、分科会が分科しなかったら、今回初参加の人が「分科会が何か」が
　よくわからなくなってしまう気がしたから
・FLの勉強法で悩んでいる人を会社でもTwitterでもよく見かけるので、一度勉強方法を（テス友やるとか本読む以外で）考えてみたかった＞それを届けたかった
　（後日まとめます）
・参加2回目でも勉強会の開催経験が未経験でも分科会開催できるよ、をやって、あとに続く人々が
「おっ自分でも分科会できるんじゃないか？やってみようかな！」と思うきっかけになればいいなと思った
・一度やってみたかった

思い立った当日の日記は↓
出来るのか？出来ないのか？！分科会オーナー！ - 私は迷いの中にいる

準備について

・まず勉強会がなんたるか、モデレータがなんたるかがわからないのでそこから勉強
・最初はすごい人数がくる想定で計画をつくっていた（時間をきっかり割ったり）
・次第に時間が経つにつれて少ない人数で～ゆるい方向で～に計画をシフトした
・実施することに悩まないようにJamboardに実施することを書いた

当日

wacate冬2020のの2日目にあたる19日に開催。
朝にブレイクアウトルームで一緒になった参加者の方々に「勉強会初めてなんです」の旨を伝えて泣きつき、
アドバイスをもらいました。（参加者の人々優しい；；）
アドバイスくれたかたありがとうございます；；

最初に分科会のテーマ紹介があるのですが普通に噛みました。
これから分科会やろうと思う人、噛んでも大丈夫ですよ！！！（泣）

分科会本番

・昨日までの心配をよそに4～6人きてくれました、ありがとうございます（n回目）
（以下緊張しすぎて記憶が飛んでるかも）
・自分の自己紹介をした後FLを受けたことがある人、これから受ける人を聞いてみたところ
（この時点で集まってくれた方々は）みんなこれから受ける人だった！おおおーー（語彙力）

分科会の流れ（想定）は以下。
・（JSTQB FLで）分からないところを付箋で書く
↓
みんなでそれについて考えよう
↓
・こうすればいいを思いついたら付箋に書く

分からないところを書いてもらってちょっと感動したのは、自分が当初わからなかったところは
みんなぶち当たっているんだなーと。。例えば用語分からないとか技法当てはめ方分からないとか・・・

私が共感してると解決にならないのですがここは素直に頷きまくりでした。
（ここで頷きまくりすぎて参加者の人を置いてけぼりにしてしまったかもしれない）

反省点は「いきなり何かを書いてみて」は分かり辛かったかな、ということです。
分からないところを特定するのって結構骨が折れることなので
それを「出してね」はやりづらかったかもしれないなと。

あと唐突に自己紹介振ってもみんな応じてくださってありがとうです（n回目）

「こうすればいい」を考えるの難しい！

これは罠でした。（罠でしたじゃない
「分からないところ」を出す以上に「こうすれば」を出すのは難しかったのです。
実行委員のときわさんがフォローしてくれたのがすごい助かりました。

JSTQB FLって、テストについてまだ経験が浅い時に受けることが多いので、それに対して
経験で腹落ちするのってめっちゃ難しいのだと、お話していて思いました。
自分もまた分からないところだらけだからこそ・・・

分からないところの共感

分からないところってみんな一緒なんだなあ、は結構共感できたと思います。
少なくとも私は参加してくれたみんなに共感できました。
この共感が、参加してくれた方のプラスになれば、と思います。試験時の緊張をほぐせれば！

FL受けたことある方ありがたい

途中からFLを受けたことある方も参加してくださっていて「このようにすれば」を
考えてくれました。すごくありがたかったですToT

自分への課題

課題だらけなのですが
・無茶ぶりしない
・場の多くが共感できる話題を読んでいく
・知識、経験差があるときにどうやってより腹落ちをする説明ができるか
・背景の違いを乗り越えて有効な何かを考えるには？
というのが湧きました。

次回やるとしたら

・アクシデントに、強くなる！！
・自分がしゃべり過ぎない

後日譚

後日もなにも今分科会が終わったばかり（昼休憩中）なのですが
wacate実行委員の方の助言もあり、「こうすれば」をwacate参加者全員に募ることにしました。
29人寄れば文殊の知恵！！まとまったらまとめます（日本語崩壊）

お礼

参加してくださった方ほんとにありがとうありがとう（n回目）
2月に試験会場の方向に向かってみんなが受かることを応援しています。
今回受けない方も、いつの日かこの分科会で「これ分からないねー」といったことを
懐かしむくらいに成長していくことを、祈っています！（私も成長しろって話ですが）

その他

みんなも分科会やってみてください！！！みんな優しいのでなんとかなるから！！たぶん！！

泣いても笑ってもあと1日

■wacateぶ、、ぶんしゃかぶぶんぶん

いよいよ明日です。

参加者がいなかったらそれはそれでしゃーない！と自分を守る気持ちがいっぱい。

情けないがこれが自分だ。ぐえ

でも準備はしきったはず。

5日前に比べるとめっちゃガチガチで準備したところから

いや、そんなに人こないだろ→ほんとに参加者いるんかいな→・・・

と思考が動き、いやそもそも分科会ってそんなガチガチにやるもんじゃなくて

お酒とか飲みながらわいわいやるもんじゃなかったっけ？

ガチガチにしてどうするんだ、という方向に舵を切って

今はなるようになーれモードになりました。

うまくいくにしてもいかないにしても、なんにしても

もし誰か参加してくれる人が居たら、その人が参加してよかったなあくらいには

したいかな・・

とりあえず泣いても笑っても明日だ！