開発業界に転職するために独学する人にとって、一番興味があることはおそらくこれだと思います。
だから、参考書やプログラミング教室で勉強しても、やっていけるか不安が大きいままなのではないかと。
業務フローによって細かいところは変わったりしますが、大まかには下記の9つを繰り返しているだけです。

1. 企画提案
2. 仕様策定
3. 設計製造
4. 評価試験
5. バグ修正
6. 納品
7. 検収
8. 事故対応
9. 品質向上施策

このうち、プログラミングが必要になるところは、3～5と8～9です。
現場によっては2もプログラミングを含むことがありますが、プログラミング言語の選定が必要なければ、含みません。
プログラミングが必要になるところの詳細を次のボックス以降で見ていきましょう。

ここを任された場合、必要な技術は下記の9つです。

1. 安全性・品質・コストの観点を設計する技術
2. ゴンベルツ曲線などの評価ツール応用技術
3. 品質評価報告書作成技術
4. 作業分解技術
5. 手順解読技術
6. 見落とさない技術
7. 手順効率化技術
8. レビューのMC技術
9. 他作業者の補助技術

これくらいできれば、評価試験実施者およびサブリーダーくらいは担当できるんじゃないでしょうか。

上記リストには記載しませんでしたが、「神の手」があると、それだけで重宝されます。
「神の手」というのは、他の人がどれだけパターンやタイミングを変えて試験しても発生しない不具合を試験だけで引き当ててしまう異能力です。
ただ、この「神の手」は誰もが持っているものではありませんので、地道に上記リストの項目をマスターしていくのが良いと思います。

通常のバグ対応と異なるものです。
リリース後に客先で発生したバグ対応がこれにあたります。
何が違うかというと、報告手順が変わってきます。
また、報告内容の言葉尻だとか、ブランドに影響しないかとか、政治的な観点も加味して報告する必要が出てきます。
自分が作りこんだバグならいざ知らず、たいていの場合は昔の人が作りこんだバグが突然（悪い意味での）日の目を浴びることによって出現するイベントとなります。
昔の人の代わりに怒られることもしばしばです。
筆者もけっこうな数対応しました。
机をたたかれることもあれば、大声で怒鳴られることもありました。
そんな時は「せやかて工藤・・・」というスルースキルで対応していたりしました。
ということで、ここを任された人には下記のスキルが必要となります。

• 怒鳴られても機械的に対応するスルースキル
• 怒鳴る人さえも味方に取り込むコミュニケーションスキル
• データやエビデンスから根本原因と対策方法を政治的に正しくまとめるスキル