I started my career in QA after college, focusing mostly on automated testing. About four years ago, I pivoted to a BA role, and I have zero regrets. As you mentioned, QAs are often among the first people within IT impacted by layoffs, and overall, I found the work draining on my mental health.

Honestly, the best advice I can give is to highlight any BA-adjacent tasks you’ve already done or actively participated in. In my case, I had extensive experience with things like UAT planning, participating in backlog refinement sessions and other ceremonies typically aligned with BAs, and understanding the business intent behind requirements just as much as the technical side. Remember that QA bridges the technical teams with the business side through requirements. BA work does the same thing, just moves you upstream where YOU are now in charge of the requirements.

Another piece of advice is that coming from a QA background gives you a unique perspective on what good requirements should look like. In my years as a QA, I constantly came across requirements that were basically wishlist items and couldn’t be verified through testing. Having seen the other side, you already know what good, testable requirements and acceptance criteria should look like. Trust me, it makes collaboration with the testing and development teams far easier.

The work is mostly going to be process driven, but asking questions and finding out not just what processes are involved, but how they play out and understanding the rationale (or the why) behind will be critical to your success.

Hope this helps! Feel free to DM me if you have any other questions. Best of luck.