Updated: November 11, 2025 for clarity, modern tone, and expanded personal insights from my journey to QA leadership

Welcome back to the “Tester to Lead” series! If you caught the previous post, you’ve already seen why QA became my career foundation and what the core basics, test plans, bug tracking, and foundational practices look like in the real world.

Today, I want to shift gears and talk about something that rarely gets enough attention in QA: the people side of testing. The mindsets, soft skills, and expectations that separated those who thrived from those who struggled in every QA team I’ve been part of.

Looking back at my early days as a tester, I realize the technical skills were actually the easy part. What really challenged me and what ultimately shaped my path to leadership were the human elements. How I communicated. How I collaborated. How I thought about quality beyond just “finding bugs.”

Whether you’re about to start your first QA job or you’re a year in and still finding your footing, these are the lessons I wish someone had shared with me on Day 1.

The Mindset Shifts That Changed Everything

From Checklist Executor to Curious Explorer

My early mistake: I thought QA was about executing test cases perfectly. Check the boxes. Follow the script. Report what I found.

The shift: Quality Assurance isn’t a checklist job, it’s detective work.

I remember the moment this clicked. I was testing a simple form submission feature. My test case said “verify form submits successfully.” I checked it and it worked. Done, right?

Then, out of curiosity, I tried submitting it twice rapidly. The system created duplicate records. That bug wasn’t in any test case. It was found because I stopped following scripts and started exploring.

What this means for you:

Test cases are your starting point, not your finish line
Ask “what else could go wrong here?” after completing scripted tests
Break things intentionally, it’s literally your job
The best bugs are often found in the scenarios nobody wrote down

From Feature Tester to User Advocate

My early mistake: I tested features in isolation, focusing on whether they “worked” technically.

The shift: I started asking “but would a real user actually understand this?”

There was a project where we built a perfectly functional feature it met every requirement in the spec. But when I tested it thinking like an actual user, I realized the workflow was confusing. The buttons weren’t labeled clearly. The error messages were technical jargon.

The developers weren’t wrong they built exactly what was specified. But someone needed to advocate for the person who’d actually use this. That’s when I understood: QA is the user’s voice in the room.

What this means for you:

Test with empathy—put yourself in the user’s shoes
Question whether features are usable, not just functional
Speak up when something works but doesn’t make sense
Remember: you’re often the first “real user” to touch this feature

From Fixed Skillset to Growth Mindset

My early mistake: I thought I could “finish” learning QA. Master the basics, then just apply them.

The reality: The tech world moves too fast for that approach.

In my first two years, I saw automation frameworks change, new testing tools emerge, and entire methodologies (like shift-left testing) become standard practice. The testers who thrived weren’t necessarily the most experienced they were the most adaptable.

What this means for you:

Treat every project as a learning opportunity
Subscribe to QA blogs and communities (Ministry of Testing, Test Automation University)
Don’t be intimidated by new tools or approaches everyone was a beginner once
The moment you think you know everything about QA is the moment you stop growing

The Soft Skills That Actually Mattered

Communication: Your Most Important Tool

The hard truth: You can find the most critical bug in the system, but if you can’t communicate it effectively, it might not get fixed.

I learned this the hard way. Early in my career, I filed a bug report that said “Payment doesn’t work.” That’s it. No steps, no context, no impact assessment.

The developer closed it as “Cannot Reproduce.”

I was frustrated—it WAS broken! But looking back, I gave them nothing to work with. No reproduction steps, no environment details, no error logs. I expected them to read my mind.

What changed:

I started writing bug reports as if I was teaching someone to see what I saw
I included screenshots, logs, and exact steps even when it felt obvious
I explained the user impact, not just the technical failure
I learned that clear communication prevents 90% of QA-dev conflicts

Your takeaway: Strong communication isn’t about being eloquent, it’s about being clear. Every bug report, every status update, every conversation with stakeholders is a chance to build trust through clarity.

Collaboration: You Can’t Test in a Silo

The reality I faced: In my first few months, I sat at my desk, ran my tests, filed my bugs, and rarely talked to anyone unless I had to.

I thought I was being efficient. Actually, I was being ineffective.

The turning point: A developer once told me, “I wish you’d talked to me before filing this. I could’ve explained why it works that way and saved us both time.”

He was right. I’d wasted time testing an edge case that was intentionally designed that way. A 5-minute conversation would have clarified everything.

What I learned:

Loop in developers early when you find something confusing
Attend design discussions understanding requirements before they’re coded prevents misunderstandings later
Build relationships with your team when people trust you, they collaborate better
Ask questions freely “stupid questions” prevent stupid bugs

Your takeaway: The best QA professionals aren’t lone wolves. They’re team players who make everyone around them better.

Diplomacy: How to Give Feedback Without Making Enemies

The uncomfortable truth: Finding bugs is easy. Reporting them without damaging relationships is an art.

There were times I filed bugs that felt like accusations: “Feature X is broken. Developer didn’t test this.” Even when I was technically right, my tone created unnecessary friction.

The approach that worked:

Frame bugs as observations, not judgments: “I noticed…” instead of “You broke…”
Focus on the issue, not the person: “This behavior differs from the spec” instead of “You implemented this wrong”
Acknowledge complexity: “I know this was a challenging feature…”
Celebrate fixes: Thank developers when bugs get resolved quickly

What this means for you:

Everyone on the team wants the product to succeed, including developers
Bugs aren’t personal attacks, and reporting them shouldn’t feel like one
A respectful tone in bug reports keeps the focus on improvement, not blame
The teams that ship the best quality are the ones that collaborate without ego

Time Management: Juggling Chaos Gracefully

The reality: Some days you’ll wait hours for a build. Other days you’ll have 3 features to test with a same-day release deadline.

I struggled with this. I’d spend too much time on low-priority features while critical paths went untested. Or I’d get so focused on exploratory testing that I’d miss scripted test execution deadlines.

What helped:

Prioritize based on risk and user impact, not what’s interesting to test
Communicate blockers early don’t wait until deadline day to say you couldn’t test
Use waiting time productively update test cases, automate repetitive tests, review documentation
Know when to say “I need more time” vs “here’s what I can realistically cover”

Your takeaway: Time management in QA isn’t about working faster, it’s about working smarter and communicating honestly about capacity.

Setting Realistic Expectations

Some Days Are Slow, Others Are Chaos

What I didn’t expect: The rhythm of QA work is wildly inconsistent.

Some days I’d finish testing early and have nothing to do. On days near releases, I’d barely have time to breathe.

How I adapted:

I stopped feeling guilty during slow periods, I used that time to learn automation, improve test documentation, or explore the product more deeply
During crunch times, I focused ruthlessly on critical paths and communicated risks clearly
I learned to roll with the pace instead of fighting it

Your expectation: Flexibility is part of the job. Embrace the slow days for growth, and stay focused during the chaos.

Requirements Will Be Vague and that’s Normal

My frustration: I’d often receive requirements that left me with more questions than answers.

“Make the form user-friendly.” “Ensure the feature is fast.” “It should work like the competitor’s app.”

What I learned: Ambiguity isn’t a bug in the process—it’s a feature. Software development is iterative, and requirements evolve.

How I handled it:

I asked clarifying questions early and often: “What does ‘user-friendly’ mean specifically?”
I proposed examples: “Should it work like this, or like this?”
I documented assumptions when I had to test without complete clarity
I didn’t wait for perfect requirements, I tested what I understood and flagged uncertainties

Your expectation: You’ll need to test assumptions sometimes. Don’t be paralyzed by incomplete information—ask questions, document your approach, and move forward.

You Won’t Catch Every Bug And That’s Okay

The hardest lesson: A bug slipped to production. A customer found it. I’d tested that exact area.

I felt like I’d failed. My lead told me something that stuck with me: “QA reduces risk, it doesn’t eliminate it.”

The reality:

You can’t test every possible scenario
Time and resources are always constrained
Sometimes bugs are so obscure they’d take days to find, and that time is better spent elsewhere

What this means for you:

Focus on high-impact, high-risk areas first
Communicate testing coverage and known gaps
Learn from bugs that escape, but don’t let them crush your confidence
Good QA is about intelligent risk management, not perfection

Growth Takes Time and that’s Actually Good

My impatience: I wanted to master everything immediately. Automation, performance testing, security testing, API testing all of it, now.

What I learned: Trying to do everything at once meant I wasn’t doing anything well.

The path that worked:

Master the fundamentals first: test design, bug reporting, communication
Then layer in new skills: basic automation, then API testing, then performance testing
Each skill built on the previous one, rushing skipped the foundation
Years later, I’m still learning new things, and that’s what makes QA exciting

Your expectation: Be patient with yourself. You don’t need to be an expert in everything on Day 1. Build your foundation, then expand deliberately.

Bringing It All Together

If you read the previous post about QA tools and test plans, you now see how everything connects. A bug tracking tool like Jira is only as valuable as the quality of communication in your bug reports. A well-structured test plan only works if you approach it with curiosity and collaboration.

The combination of:

Strong practical skills (tools, test design, bug tracking)
People-oriented skills (mindset, communication, diplomacy)
Realistic expectations (patience, adaptability, risk awareness)

…is what truly sets you apart in QA.

The technical skills will come with practice. But the mindsets and soft skills? Those are what turn good testers into great ones—and eventually, into leaders.

Conclusion

Your first steps in QA are as much about who you become as what you do. The curiosity to explore beyond test cases. The empathy to advocate for users. The communication skills to bridge teams. The patience to grow deliberately.

These are the mindsets that shaped my journey from junior tester to QA lead. And they’re exactly what I look for when building teams today.

Next in the series: We’ll dive into the technical tools and frameworks that accelerate your growth, automation basics, test data management, and the infrastructure that supports modern QA.

Until then, focus on building these foundations. Your future self will thank you.

Jaren Cudilla
QA Overlord | Tester to Lead

I’ve been where you are—debugging my first bug report, overthinking sprint planning, and learning that great QA is as much about people as it is about tests.
This series documents the real lessons from my path to QA leadership at QAJourney.net.
Built test teams, mentored juniors who became leads, and learned that soft skills break or make your career more than automation ever will.

🔗 About My Journey | Support the series