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

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

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

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

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

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

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

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

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