よもやま。テストを誰でも出来る簡単な仕事とテストを疎かにして、発覚から十数年以上隠蔽や適切に対応せず、国際的な巨額な損害賠償や外交問題にまで発展してる会社もある。 検証しとけば簡単に気づくシステムバグが原因でシステムが不正な計算を繰り返し、そこにいた人が解雇されまくってね。

5.3。テストコントロールやモニタリングのカギを握るのは結局、開発担当者。納期もそうだけどね🧐パソコンだけ見て、ユーザーさんはおろか、直接関係してるステークホルダーすら見ようとしてないから、自分の力量不足を棚に上げる自称さん多過ぎ🤣ま、だから一生、自称さんで終わるんだが。

5.1。ここも用語が沢山😆まあ、書いてることは非常に大事な観点詰め合わせ👀💦て感じやから、ここもじっくり読んで理解しよ🕺２冊目の黒い本との合わせ技で説明が理解しやすいとか見比べながらが良いかも。2周目入る前に黒い本を読んでどっちをメインにやり込むか決めよ。一長一短ありそうだな🧐

4.5。3つのCとINVEST。スコープ。ATDD

4.4。人もテスト手法もひとつに絞るのではなく、組み合わせやね👀💦

1.4。ここは用語集で20ページくらいあるけど分かりやすい例（富士登山ルートとか「デグレしてるかもだから、リグレッションテストやろ」など）を使ってるからサクサク読めるね👀どうせ一回で覚えられないし、覚えたところで実践できないと意味はないから、１周したら何回も見直す 👉至高のフロー

気になる人は、 Horizon (ITシステム) でWikipedia検索。 被害者700人以上のあまりにも有名な事件。 「イギリス史上最大の冤罪事件」 「郵便局長らとその家族の人生に壊滅的な影響を与えたことをおわびする」 システムの杜撰な対応が誰かの人生を台無しにする教訓事例🧐

5.4。残り３節てとこまで読んで、黒い本はまだだけど、青い本は、読み物として読むのに最適だねえ🧐解説とか概念の説明なんかが詳しい。 おそらく、 ・黒い本の方が薄いから試験対策メイン ・黒い本の説明が薄いところを青い本で補充かな💦 シラバスに従って章立て一致してるから探すの楽🕺

4.4。こーやって言われたら、「そんなことは言われなくても出来ていて当たり前」と思う人が多いのだが💦 自分が普段作ってる資料を全く知らない人になって見返してみ👀 資料やドキュメント、手順書、テストケースは、分かってる前提で書かない、端折らない、解釈が分かれないよう具体的に書く😛

5.4。CMのトレーサビリティは大事だねえ🧐スクラッチ開発かパッケージ開発かによっても違うし、保守・改修ならば、チケット管理で良いかな💦👀トレーサビリティマトリクスだけ最初に作って更新されない現場も過去にあったな。トレーサビリティ＝証跡を追うのに最初に作るだけ😆

JSTQB 軽くよもやま よし、これで黒い本も１周目読了。 年明けから、青い本２周目😆 次は練習問題解きながら、復習しながら記憶整理と定着メインやな🕺 最終的に ・黒い本：メイン ・青い本：辞書がわり は変わらない。 青い本の練習問題の該当箇所は、黒い本にもマーク付けとこ。

1.5。ここ結構、一番重要じゃね👀💦がてんこ盛り。 短いけど、 ①テストエンジニア個人に必要なスキル ②チーム構成（クロスファンクショナルか否か） ③プロジェクト内での位置付け（独立性があるか） ④それぞれのメリット・デメリット 👉特に②、③を勘違いしてる組織は多かった😛

1.2。何で間違えたかの方が大事🧐復習やな🕺紛らわしい用語が多いから違いをしっかり

5.5。リスクマネジメント＝計画。欠陥マネジメント＝実際の作業結果＝成果物なイメージ。 まあ、開発者とテストが分かれてることが今は普通👉開発者の作業負担を減らし、開発遅延回避。 なので、BTSで証跡を残した、不正か欠陥かは開発側で判断するのが今は主流かなと🧐開発者の判断に委ねる

3.2。自分が行き着く部署は必ず事前にテストケースのレビューでカバレッジ漏れがないかとか、事後にエビデンスのダブルチェックをやるとこばかりだったから、やらずにテストケースの誤字脱字すらテストエンジニアから指摘される光景を見ると「部署のガバナンスやこの子のキャリア大丈夫⁉️」とは思う

5.2。もう10年くらい前から、人の生活がモバイルにシフトしたのに伴い、UIは当たり前で、UXが求められる時代になってるのに、日本は未だに、システム＝パソコン中心👉UIで止まったまま。 人の生活よりもお金が動く規模ありきで化石みたいな考え方だからなあ🧐 👉だろう運用

5.1。リスクマネジメントやカバレッジ漏れまで意識したテストマネジメントの各手法でかなり大事だね👀💦 一回で覚えた、理解したとかは無理だから、何回も見返そ🕺 青い本には、名前しか出てなかったプランニングポーカー面白そう😛

4.3。ステートメントテストとブランチテストをいくら繰り返したところで、業務をきちんと理解してないとカバレッジ漏れは起こる 👉あくまでも、ひとつの手法（フレームワーク） ＝それさえやれば、完璧なんてものではない。

4.1。ここは概念だけなんで見開き2ページに、ブラック、ホワイト、経験ベースて概念の紹介だけだが、まあ充分かな🧐青い本も6ページくらいしかないし

3.1。オイラが見てきた現場では未だに、ホワイトボックスで静的テストに時間をかけ過ぎ、過剰な机上デバッグとコードレビューの繰り返しで後のテストが逼迫する現場。 今や静的なプログラミング言語や開発環境で、組んだ瞬間にミスは嫌でも分かる時代だから、静的テストに時間をかけないねえ🧐

6.2。ま、ここに関しては、５年前にいたテスト会社が完全に別部署で沼ってたねえ🧐appium？を使ってCIのテスト自動化ツールの構築なんて掲げてたが👀💦業務自体が生モノなのに、いくら自動化なんて掲げてもツール改修でコストかかるなら、結局、人で手作業で目検でに落ち着くんだよね😛

5.3。各メトリクスの観点と現状や成果を正確に報告するは、基本中の基本やね🧐２年くらい前、進捗ばかり気にして、開発側のスキル不足による遅れで、まだボタンがないのに、テストスケジュールに沿って今日はボタンのテストこなせみたいなプロジェクトあったな🧐ないのにどーやってテストやんの❓

ちょいと年末に向けて、業務が忙しくなってきたのと青い本をひと通り読み終わって、黒い本はしっかり読み込みたくなってきたので、今日はおやすみ‼️ 来週から残業ない日にジムから帰って来て、寝る前か朝活で読むかな。 朝活で黒い本、夜にその日の新聞が良いかも🕺

さてと、これで青い本は、ひと通り、読み終わり🕺明日からは黒い本だが、おそらくこの前ゆーたとおり、 ・黒い本：メイン ・青い本：黒い本の内容薄いところの辞書がわりとか補強教材 完全に資格対策の本だな😛 実務ではこれ丸暗記して取得したから何⁉️🧐て感じ。 使える考え方もなくはないが😆

4.4。開発部署のコーディング遅延などで、画面設計書自体がないか、最新の仕様に更新されておらず、他の情報共有もない状態で、 ・画面が正しく表示されていること ・ユーザーが操作しやすいこと ・ユーザーに見やすいこと てだけ作業者が書かれてどこまでテストすればいいか分かるか？て話😛

3.2。いやあここは深いし長い😛出てきたな、「タイヤのブランコ」や７人の法則。レビュープロセスについて書かれているが、専門用語が多いので、アジャイル用語ばりだね😆丸暗記にならないように、ここはじっくり読んだ方が良い。１周回って忘れた頃に読み返す感じで🕺シフトレフトまじ大事だねえ🧐

2.1。TDDとシフトレフトと非機能要求テスト。言いたいことは分かるが、出来ない組織の根源はいつだって、V字で知識が止まり、単体テストを省こうとしないロートル管理職と、自分の力量を見誤り、完全に尻カッチンな進め方しかしてない自称、プロ。 👉そいつらが知ってるではなく、実践しろよと

【JSTQBの本】 やっと来たー！時間がある時にゆっくり読も🕺 １日１章ずつとか、何ページとかではなく、 じっくりテケトーに読んで、３回くらい回したら、問題解いてみるかな👀💦 今の仕事に直結はしてるが、別に取れとか言われてないし。 こりゃIT業務未経験者にはわからんめぇ🧐な視点で

2.1。業務と技術が理解出来てないと、いくらテスト工程を守っても、省いた方が良いテスト工程が出てくる単体テストと結合テストが似かよるなら、結合テストだけでOKとかね💦 非機能要求テストも同じ。テストスイーツで書き出してみて、整理してホントに必要なテストは何かを検討する方が良い🧐