In IT we hear constantly that you have to keep growing. New tools, new frameworks, new approaches, new market expectations. For some this is motivating. For others exhausting. Especially in QA, where the breadth of competencies can be enormous: manual testing, automation, API, CI/CD, cloud, security, performance, business analysis, communication, processes. The question is: is continuous growth a real gain, or just pressure that never ends?

This is the final article in the “Mature QA in practice” series. Earlier: skipping QA, automation, evolving QA, experience, individual growth.

Where does the pressure come from?

It didn’t come from nowhere. Real sources:

  • Dynamic IT market. Every quarter brings something new - a framework, a tool, AI, a paradigm.
  • Job postings with very long lists of requirements. “Junior with 5 years in 12 technologies.”
  • Comparing yourself to others. LinkedIn shows 200 people who just finished a course you’ve never heard of.
  • Success culture on social media. “Second certificate this year, another side project, I’m on a roll!” Looks like the norm. It isn’t.
  • Fast tool churn. Selenium → Cypress → Playwright → something new. Three years is a chasm.
  • Fear of falling behind. Even if you’re a strong tester today, the brain says: “what about three years from now?”
  • Employer expectations. Some make continuous learning a condition for any pay growth.
  • Your own ambition. A real desire to be better, sometimes hard to tell apart from external pressure.

Each source in isolation is bearable. Together they can create the feeling that we never know enough.

Why growth can be a gain

Despite all the traps - growth genuinely pays off, when it’s deliberate.

Concrete benefits:

  • more confidence - in technical conversations, refinements, release decisions,
  • more autonomy - less dependence on developers, devops, business,
  • better testing decisions - when to automate, when to leave manual, when not to test at all,
  • more influence on the project - your opinions are heard because they’re backed by competence,
  • better career options - easier moves, promotions, role-by-choice,
  • less fear of switching jobs - you know you’ll cope in a different context,
  • more flexibility - when the project changes you don’t lose your footing,
  • easier communication with developers and business - because you understand both worlds.

These are measurable effects, not marketing slogans. A tester with SQL + API + automation basics has materially different prospects than a purely manual tester - and it shows in offers, pay and freedom.

When growth becomes a curse

When it’s chaotic and goalless.

Symptoms worth recognising:

  • you start many courses and finish none,
  • you learn things you don’t use at work or in any realistic move,
  • you constantly compare yourself to others - especially those with different backgrounds,
  • you feel you know nothing, even though you’re doing your job well,
  • you jump between tools - a new framework every quarter, none mastered,
  • you don’t see the effects of growth in your daily work,
  • growth drains all your evening energy at the cost of personal life,
  • you learn out of fear, not out of need.

These don’t mean you should stop growing. They mean you should change the method. Without a goal, awareness and rest, growth becomes self-destructive.

You don’t have to know everything

This is the most important reassuring part.

QA is a wide field. Not everyone has to be an expert at:

  • UI automation,
  • API testing,
  • performance,
  • security,
  • cloud,
  • DevOps,
  • accessibility,
  • mobile testing,
  • databases,
  • architecture,
  • business analysis.

A person trying to know everything usually knows everything shallowly and nothing deeply. That’s a worse position than a solid core + one or two deep specialisations.

A practical question to yourself:

What can I say about myself with full conviction that I genuinely know well?

If the answer is “nothing”, it’s not a competence problem. It’s a scatter problem.

Vertical and horizontal growth

Two sensible directions.

Vertical

Deepening a single specialisation. You become an expert in a narrow area where few people are truly strong.

Examples:

  • automation (from basics to framework architecture),
  • performance (from first k6 script to designing load scenarios),
  • security (from OWASP Top 10 to penetration testing),
  • test architecture (org-wide strategy),
  • quality management (QA Lead, Quality Coach).

Plus: you become hard to replace. Minus: if the market shifts elsewhere, you’re more exposed.

Horizontal

Broadening perspective. You learn what borders your role.

Examples:

  • backend basics - to understand what’s behind the API,
  • frontend basics - to understand why a UI test breaks,
  • business domain - to understand what the system does,
  • communication - to influence decisions more effectively,
  • requirements analysis - to find gaps before implementation,
  • working with risk - to prioritise consciously.

Plus: better grasp of the whole. Minus: you’re not an expert in any of those (and don’t need to be).

The strongest long-term strategy: one strong vertical + a broad horizontal. T-shape, as it’s neatly called.

How to choose what to learn

A simple decision model - four questions.

Q1: What will help me on the current project?

The best learning is what you can apply quickly. If you’re learning SQL and tomorrow’s task touches the database - immediate return.

Q2: What will increase my market value?

Not everything has to be needed today. Sometimes it’s worth investing in the future - especially in competencies that grow slowly and are hard to catch up on (risk analysis, mentoring, architecture).

Q3: What genuinely interests me?

Growth driven by pressure alone is hard to sustain. If the topic bores you, you probably won’t finish the course - or you’ll finish it without effect.

Q4: What’s the logical next step?

Someone who doesn’t know API basics doesn’t need to build an advanced automation framework right away. Step by step - fundamentals first, then the rest. Shortcuts usually cost more than they save.

A healthy pace of growth

A practical proposal that works in many teams:

  • One major topic per quarter. Not five. One. That’s enough.
  • Small, regular steps. Half an hour daily > five hours on a single Saturday once a month.
  • Learn through practice. A new technique applied in a real project sticks. A course without practice fades in six months.
  • Project notes. Your own knowledge base - bugs, patterns, decisions. Builds itself if you keep it.
  • Mini-projects. Sometimes worth doing something on the side - small but finished.
  • Conversations with your team. Cheapest and best form of learning - what a colleague did, why, what they ran into.
  • Analysis of your own mistakes. Every missed bug is a lesson.
  • Breaks without guilt. Weeks or months in which you just do your job well and nothing else. Healthy.

Growth at work or after work?

A real-life topic rarely discussed openly.

Professional growth shouldn’t entirely come at the cost of personal life. A good organisation should create space for learning at work, because it benefits from your competencies. Time to read docs, explore a new tool, experiment with the process - that’s an employer’s investment in the product.

On the other hand - some personal growth genuinely requires your own initiative:

  • if you want to change paths (e.g. from manual to automation),
  • if you want to level up faster than the natural pace of the project,
  • if you want to change job to a company with different requirements.

That’s an honest framing: sometimes after-hours learning is your decision, not your duty. And if it’s a decision, it’s fine. If it’s a duty imposed by ambient pressure - stop and ask: who am I doing this for?

How to tell if growth is working?

Not by certificates. Real effects of growth are visible when:

  • you ask better questions - more precise, going to the heart of things,
  • you diagnose problems faster - minutes instead of hours,
  • you understand the system’s architecture better,
  • you depend less on others - narrowing the bug source yourself, creating test data yourself,
  • you can propose improvements to process or test strategy,
  • your tests give more value - catch more, generate less noise,
  • the team asks you about risk more often - because they know you have answers,
  • you feel more confident in technical conversations with developers and business.

Each of those is measurable - if not in numbers, then clearly perceivable. If after a year of growth none of those changed, the direction was wrong.

The anti-trap “I’m always growing, so I’m good”

Merely declaring growth doesn’t make anyone a better tester. You can endlessly listen to podcasts, buy books and book conferences without changing your daily work.

If that’s your situation - ask honestly: which concrete testing decisions did I make differently than a year ago?

If there’s no answer, the growth is declarative, not real.

Summary

Continuous growth is a gain when it’s deliberate. It’s a curse when it becomes an unreflective obligation. The goal isn’t to learn everything. The goal is to grow in a direction that makes sense - for you, your work, your goals.

You don’t have to learn everything at once. Pick one area that gives the biggest return: in the current project, in a future role, or in everyday confidence. That’s enough.

The full series

This closes the “Mature QA in practice” series. The earlier articles:

  1. Why skipping QA almost always costs more than it seems
  2. When to automate tests
  3. Why QA must evolve
  4. Why QA experience matters
  5. Is it worth growing in QA
  6. (this article) Continuous growth in QA - curse or gain