あらすじ
wacate2020冬オンライン（wacateの説明は省略します）の分科会（説明省略します）で
参加してくれた人々が「分からない点」やそれに対する「こうすればいい」を
出してくれたので、それを共有します。
これから勉強する方の参考になれば…！
解決案の色の見方
緑：自己完結で出来る
茶：他者と一緒に頑張る・他者の力を借りる
青：私の謎コメント
黒：分類なし
注意
・多少文章の言い回しを変えているところはあります
・全部は載せていないかも！
1章.テストの基礎
開発がどんなテストしているのかわからない
＜解決案＞
・開発者とランチいって聞いてみる（当事者に聞く）
・自分でも書いて体験してみる。cyber-dojoってのがあるらしい（自分で体験してみる）
・周りに仲間を見つけてみんなで解く（周囲を巻き込んで体験してみる）
＜謎コメント＞
開発がどんなテストしているかは、会社によって異なりそうです。
強いて言えばソフトの中の細かい「XXする」の単位（関数）とかが実現するかは開発で実施することが多いのではないでしょうか。
書いていて思ったのですが、「慣れていないときに、ソフトの中の話をどう話したら分かりやすいか？」を
分科会で聞けば良かったと思いました。
最初のうちの「用語に慣れない」という視点はとても貴重なのです。
JSTQBの勉強で「開発がどんなテストしているか分からない」は
「デバッグが分からない」か「ホワイトボックステストが分からない」に繋がっているのかな？と思います。
図を描きますのでもし参考になれば。
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
なにもかもが、、わからない！（※意訳です）
＜解決案＞
・がんばる
＜謎コメント＞
まず最初はみんななにもかもがわからないです！そこは安心してください（は？
そして近道はあまりない気もします。
実務で覚えるにせよ、本で読むにせよ、毎日の少しづつの積み重ねが
何もかも分からない！から
ほんの少しだけ分かる！に進めるのだと思います。
今、分からないことに絶望しないでくださいー！
・全体に対しての意見
＜解決案＞
・確かに勉強したことを社内で発表してみることで自分自身の足らないことや今わかっていることがわかるのかも？（周囲を巻き込んで体験してみる）
＜謎コメント＞
この解決案、間違いないです。社内発表までいかなくても言葉にするといいです。
「言葉にすること」が「分からないことを分かる」第一歩なので。
さいごに
分科会に参加してくださった方…このページを見てくださった方…試験、応援しています！！！
