I started my professional career in September 2011. My first job was as a QC Engineer, but I soon switched to test automation and software development. As of 2021, I worked in different companies - from banking and finance to gaming with various technology stacks.
I am not a fan of regrets. So in this blog post, I want to tell more about lessons learned than just simple regrets.
Personal development inside the company
During my first years in university and my first years in a full-time job, I hoped that somebody would "magically" create a strict development path for me.
"Just learn this and that, practice this, and you will become a middle/senior/lead test/automation engineer."
Unfortunately, it did not happen in university, so I needed to learn a lot by myself. So it did not occur at work.
What I learned is that the only person responsible for your personal development - is you. It is not your lead, manager, CTO, or career advisor. It is YOU.
You need to think about what you want from your current and future career: whether it will be testing, development, automation, leading people, or starting your own company.
You need to think about which companies do you want to work with in the future.
You need to create a personal development plan for yourself. Analyze which skills do you need to have. Which frameworks or programming languages do you need to master.
Think about it as an RPG game. Create a mind map with skills that you have, and want to have. It can be a path for the upcoming 3-6 months or a couple of years.
Set goals and start to learn new things. Learn from books, courses, videos, blogs. Learn for colleagues.
You can discuss your plan with your manager. Ask him/her whether you can apply new skills in your current project. Ask about future opportunities within a company. If you see that a company can't (or don't want) to support you in your development - consider changing your job.
Take responsibility for your own career "story," and you won't regret it.
Test engineering is considered as non-technical
In many work environments where I worked, testers or automation engineers are considered "not-so-technical" engineers. It is a huge regret for the whole industry.
Testers are just clicking buttons and file bugs. Testers just sent a message "Something is not working" without attaching any logs, environment information. Testers do not provide clear steps to reproduce the issues. Testers can't even give initial thoughts on the root cause of the bugs.
I also thought in such a way for some time.
The root cause of such a problem is because most QA courses do not provide a solid technical background on how systems work. The primary purpose of such classes is to teach you how to follow predefined test cases and file bugs. The most "technical" thing is firing a few HTTP calls manually or writing simple WebDriver tests for the Login page. And after all, what the heck do you want to learn from scratch after 1-2 month courses?
As a result, most testers want to move to the development roles as soon as possible. It can be software development, managing positions, business analysts, etc.
If you stay in testing for more than ten years, you feel like a "stranger" person.
All of this is why testers themselves do not know or feel that their work can be technical.
But magic can happen.
If you invest in developing your technical skills, you, as a tester, can see that the overall picture is changing.
It changes when you go to the developer with an initial investigation of the root cause. Or with possible solutions along with the trade-offs.
It changes when you describe a possible "what if" scenario during a discussion of future deployment strategies.
It changes when you highlight possible issues with scalability or reliability when you talk with architects.
And after all, it changes when you clearly show the risks to managers and stakeholders, supplying it with business metrics and data - not just words.
Developing technical skills is challenging. It requires time and dedication. But it pays off.
Testers are engineers. They can perform academic researches. They can apply programming to create the tools which benefit the team. They can do a complex analysis of the system to find "weak points."
That's what engineers can and should do.
Credits: Photo by Brett Jordan on Unsplash
Previously published on GitHub.