テスト仕様書、テストケース仕様書の作成方法はどのようにして身につけるのか

IPAの資料を見るのが手堅いかと思います。
・教科書的
組込みソフトウェア開発における品質向上の勧め［テスト編～事例集～］
https://www.ipa.go.jp/archive/files/000005149.pdf

・実例ベース入り(こちらのほうがとっつきやすいかも)
高信頼化ソフトウェアのための開発手法ガイドブック
https://www.ipa.go.jp/archive/publish/qv6pgp0000000zlp-att/000005144.pdf

テストとは仕様書の機能、諸元の性能、品質を確認すること。

と誰が言っていました。by 糸村聡　（遺留捜査）

過去のケースの範囲内なら、ChatGTPに仕様書通りのコーディングもテストも任せれば良いことです。（恐らく、すぐそこ）一方、人間は見当違いな発想からブレークスルーする可能性も秘めています。だから、仕様書を超えた視点で提案することが人間である証明と考えています。

設計書が存在しない テストですか？
人間は間違う生き物です。テストは人間の間違いを指摘し、顧客に与える損害を事前に除外する作業でしょうか？

さて、網羅的な試験はコストと時間を要します。設計書が存在しないをブレークスルーするヒントは私はテストの定義にあると考えます。

私はテストは
ビジネスを継続する上で、出来上がるソフトウェアが莫大な損害をもたらすのではないか？その不安を解消するために行うと考えています。不安の主体は、ステースクホルダーと貴方です。だから、テスト計画書やテスト体制図、スケジュールでステースクホルダーに実現可能性を認識させる必要があり、進捗報告でビジネスを継続するために、ステースクホルダーと貴方は呉越同舟となる必要があります。

網羅的テストとは別に過去のバグのケースから、ビジネス目的の視点、ビジネス損害の視点、ＤＢチューニングの視点、フェールオーバーの視点、過剰な売れ行きにシステムのその先の体制まで、思いつくテストケースを記載し、ステースクホルダーと順位つけして、ｐｍと相談してプランニングする以外ないと思います。

設計書が存在しない　探せばあると思いますよ？別の形で！

設計書が存在しない(開発指揮者の口頭指示ベース)で開発を進めています。

言った言わないの話でトラブルになるので、指示で決まった仕様は文書に残しましょう。設計書はなくとも、決まった事をメモっておく事くらいは出来るでしょう。おかしい・曖昧と思う部分があったら、その場できちんと決まるまで突っ込みましょう。

私の認識として、一般的には事前に仕様書のテンプレートがあり、それに合わせた形でテスト仕様書を作成している会社が多いように思います。
実際は、テスト仕様書の作成スキルは、どのようにして身につけていくのでしょうか？

会社ごとに形式は違えど、テストは、基本的には実装した仕様の確認になるので、仕様がはっきりしているなら自ずとテストで確認すべき事も判るはずです。決まった事を文書に残す、というのはそういう事です。
画面（機能）単位で列挙し、仕様を満たしているかを確認していけばよいでしょう。（＋αで入力データ異常、通信異常等のイレギュラー対応など）

以下は一例ですが、
画面ならボタンを押した場合の動作、入力桁数・文字制限、コントロールのタブ移動順、
印刷物ならフォント・出力すべき項目、項目の最大桁数、項目のフォーマット、寸法が重要なら寸法も図る、
といった感じです。