When I started my first QA job, I had already spent around twenty years working in mechanical engineering and manufacturing.
I had technical experience. I had programmed CNC machines. I had used Linux for years. I had even studied programming as a kid.
And yet, when I entered software development, I quickly discovered how much I didn't understand.
I remember being confused by things that seem completely normal to me today. DEV, QA, STG, PROD. The way a pull request moved through a team. What happened before testing, what happened after it, and who was responsible for what.
I was lucky to have a patient buddy who helped me through those first months. Eventually, I became the person mentoring a new colleague.
Looking back, there are a few things I wish I had understood earlier.
You don't need to understand the whole system on day one
When you're new, it's easy to look around and assume everyone else understands everything.
Developers discuss architecture. DevOps talks about deployments. QA engineers know the product. Someone mentions a database migration or a production incident, and you feel like you've missed an entire chapter.
The truth is that everyone learned those things somewhere.
You don't need to understand the whole system immediately. You need to start building a mental map of it.
Where does the code live? How does it reach a test environment? Where do the logs go? Who owns the service? What happens when a build fails?
One answer usually leads to another question. That's how the map grows.
Ask the question, even when it feels basic
I was fortunate to have Ventsislav as my buddy at SolarWinds. I still remember his patience.
When you're changing careers, there are moments when you don't even know how to formulate what you don't understand. That can be uncomfortable, especially when you've already spent years being competent in another profession.
But pretending to understand something doesn't make you better at your job.
Asking does.
I would rather ask a basic question and understand the system than stay quiet and make decisions based on an assumption.
And if you're the experienced person in the room, remember what those first months felt like. The way you answer a beginner's question can influence whether they ask the next one.
Learn how the product works, not just how to execute a test
At the beginning, it's tempting to focus on the assigned test case.
Open the application. Follow the steps. Compare the actual result with the expected result. Report a defect if something doesn't match.
That's useful work, but it's only part of QA.
The more you understand the product, the more useful your testing becomes.
What is the user trying to achieve? Which parts of the system depend on this feature? What happens when an API fails? What data is involved? What would make this change risky?
A tester who understands the product can ask questions that aren't written in the test case.
And those questions often matter more than another perfectly executed checklist.
Don't treat developers as the other side
Early in a QA career, it can be easy to fall into a pattern where developers build things and testers find what's wrong with them.
But QA and development aren't opposing teams.
You're working on the same product.
A good bug report helps a developer understand the problem. A good conversation with a developer helps QA understand the implementation and the risks. A good developer can teach you a lot about how the system works, and a good tester can reveal assumptions the developer hadn't considered.
Some of the most useful things I've learned came from asking developers to explain why something behaved the way it did.
Not to prove that I was right.
To understand it better.
Automation isn't a different species of engineering
For a long time, I admired colleagues who worked with automation.
I could change parameters and make smaller adjustments, but writing automated tests myself felt like another level.
Then I took a Python course and started building my own projects.
Gradually, automation stopped being something other people did.
It became code I could understand, debug, and write.
If you're a manual QA engineer who wants to learn automation, you don't need to start by building a complete framework.
Start with a small script. Make an API request. Parse a response. Write one test. Run it. Break it. Fix it.
Then learn why it works.
The important part is not how quickly you can copy a framework from a tutorial. It's whether you can understand and maintain what you've written.
I wish I had looked beyond the test itself earlier.
APIs, databases, logs, Linux, Git, CI/CD, and environment configuration all became increasingly useful as I moved deeper into automation.
You don't need to become an expert in every one of those areas.
But knowing how to inspect an API response, read a log, understand a pipeline failure, or check whether a service is running can save you hours of guessing.
A failed test doesn't always mean an application defect.
Sometimes the environment is broken. Sometimes the test data is wrong. Sometimes a dependency is unavailable. Sometimes the test itself is wrong.
Understanding the surrounding system helps you find the difference.
Quality is bigger than the number of bugs you find
Finding a serious bug before production is satisfying. It can save a team a lot of trouble.
But the number of bugs you report isn't a complete measure of your value as a QA engineer.
Sometimes your most valuable contribution is asking a question before development starts.
Sometimes it's improving a test that everyone has stopped trusting.
Sometimes it's identifying an environment problem that causes repeated false failures.
Sometimes it's helping the team understand a release risk that no individual test can capture.
Over time, I stopped thinking of QA only as finding defects.
I started thinking of it as helping the team understand quality and risk.
That change in perspective has stayed with me.
Your previous career is not wasted
This is something I would tell anyone entering IT later in life.
I spent roughly twenty years in mechanical engineering, working as a designer and technologist and programming CNC machines.
At first, that experience felt separate from my new QA career.
Today I see a lot of connections.
Precision. Processes. Root-cause analysis. Understanding dependencies. Thinking about what happens before and after your part of the work.
Those habits followed me into software engineering.
You may need to learn a new technology stack, but you don't necessarily need to start your professional identity from zero.
Your previous experience can become an advantage once you learn how to apply it.
You will eventually become the person who explains it
One of my favorite memories from my first QA job is becoming a buddy for a new colleague.
I had gone from struggling to understand the environments and processes to helping someone else navigate them.
That didn't happen overnight.
There was no moment when I suddenly knew everything.
It was a gradual accumulation of questions, mistakes, explanations, and experience.
Growth often works like that. You don't notice it while it's happening.
Then one day someone asks you a question, and you realize you're explaining something that once confused you completely.
Keep looking one layer deeper
If I could give my younger QA self one piece of advice, it would be this:
Don't stop at the first answer.
If a test fails, investigate why.
If a deployment fails, try to understand what happened.
If a developer explains a technical decision, ask about the trade-offs.
If a production issue occurs, look at what the team learned from it.
You don't need to become a developer, DevOps engineer, security specialist, and product manager all at once.
But every layer you understand makes you a more capable QA engineer.
My own curiosity eventually took me from manual testing into Python, Robot Framework, Playwright, CI/CD, Linux infrastructure, observability, and release engineering.
I'm still learning.
And I suspect I always will be.
This is the second article in my My QA Journey series.
If you're starting in QA today, what is one thing you wish someone had told you earlier? And if you've been in the industry for a while, what advice would you give your first-year self?
