Job descriptions are written by committees. They list fifteen requirements, half of which are aspirational, and one or two of which are actually deal-breakers. Learning to read between the lines — and knowing which skills genuinely matter — is itself a marketable skill.
This lesson gives you the real map: the competencies that experienced QA and BA professionals consistently identify as most important, not just the keywords recruiters paste into job postings.
Learning Objectives
By the end of this lesson you will be able to:
- List the core skills shared by both QA Tester and Business Analyst roles
- Identify the skills that are specific to QA and those specific to BA
- Apply the T-shaped professional model to your own skill development
- Assess where your existing experience already meets market expectations
The Foundation: Skills Both Roles Share
Before you specialise, you need the foundation. These are the skills that no hiring manager will overlook, regardless of which role you're applying for.
Clear Written and Verbal Communication
Testing produces bug reports. Analysis produces requirements documents. Both must be read and acted on by people who weren't in the room when the work was done. If your writing is ambiguous, your work is ambiguous.
This isn't about elegant prose — it's about precision. Can you describe a defect so that a developer can reproduce it in two minutes? Can you write a requirement so that no two engineers will interpret it differently? That's the standard.
Analytical Thinking
Both QA and BA roles require you to break complex situations into parts, identify what's missing, and reason about cause and effect. In QA, this means designing test cases that actually cover the important scenarios. In BA, it means identifying requirements gaps before they become defects.
Stakeholder Collaboration
Neither role works in isolation. QA testers work with developers, product owners, and release managers. BAs work with business stakeholders, developers, and UX designers. The ability to listen, ask good questions, and influence without authority is non-negotiable.
Attention to Detail
This one is genuinely required, not just a resume cliché. In QA, missing a test case means a bug reaches production. In BA, missing a requirement means the wrong feature gets built. The professionals who last in these roles have a natural intolerance for imprecision.
QA-Specific Skills
If QA is your path, these are the skills that will define your ceiling.
| Skill | Why It Matters |
|---|---|
| Test case design | The core deliverable of a QA role — the ability to translate requirements into structured, repeatable test scenarios |
| Defect reporting | Clear, reproducible bug reports save developer time and build your credibility as a tester |
| Exploratory testing | The ability to go beyond scripted tests and find the bugs that no one thought to specify |
| Understanding of SDLC | Knowing where QA fits in the Software Development Life Cycle, and how to influence quality at each stage |
| Basic SQL | Useful for verifying database state during testing — widely requested in job postings |
| API testing basics | REST API testing (Postman or similar) is increasingly expected even in manual QA roles |
BA-Specific Skills
If BA is your path, these are the skills that matter most.
| Skill | Why It Matters |
|---|---|
| Requirements elicitation | The ability to draw out what stakeholders actually need, not just what they say they want |
| User story writing | Translating requirements into Agile-ready stories (As a…, I want…, So that…) |
| Process modelling | BPMN diagrams, flowcharts, and wireframe annotations that make workflows visible |
| Stakeholder management | Managing conflicting priorities and keeping different audiences aligned |
| Acceptance criteria | Defining the conditions under which a feature is considered "done" |
| Domain knowledge | Understanding the business context well enough to challenge requirements that don't make sense |
The T-Shaped Professional
The most hireable professionals in QA and BA are what practitioners call "T-shaped": broad foundational knowledge across the full software lifecycle, with one or two areas of genuine depth.
Broad knowledge (the horizontal bar of the T):
Agile, communication, SDLC, collaboration, documentation
Deep expertise (the vertical bar of the T):
e.g., test automation —OR— requirements management —OR— API testing
When you're starting out, building the horizontal bar is your priority. The depth comes with experience. But knowing which vertical you're heading toward helps you make better choices about what to learn next.
Mapping Your Existing Experience
Don't assume you're starting from zero. Skills transfer in ways that aren't obvious on the surface.
| If you've done this... | You likely already have... |
|---|---|
| Customer service or support | Stakeholder communication, defect reproduction from user reports |
| Teaching or training | Written communication, breaking down complex processes |
| Manual or repetitive work | Attention to detail, tolerance for systematic checking |
| Project coordination | Stakeholder management, requirement gathering |
| Any technical writing | Documentation, precision in language |
Pro Tips
Don't let a skills gap stop you from applying. Job descriptions list what the ideal candidate has; your job is to demonstrate you can close the gap quickly. Show willingness and evidence of learning.
Pick one technical skill to learn next. For QA: try Postman for API testing. For BA: try drawing a BPMN diagram of a process you know well. Focused learning beats scattered upskilling.
Soft skills are the hard ones to hire for. Communication, analytical thinking, and collaboration are harder to teach than SQL. If you have them, make them visible in your resume and interviews.
Summary
QA and BA roles share a foundation of communication, analytical thinking, stakeholder collaboration, and attention to detail. Beyond that foundation, the paths diverge: QA leans into test case design, defect reporting, and technical verification; BA leans into requirements elicitation, stakeholder management, and process modelling. The T-shaped professional model gives you a framework for building your skills deliberately — broad first, then deep. And your existing experience almost certainly covers more of this map than you think.