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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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