Tacta Academy: How I started coding & finding myself as Quality Assurance Engineer
This is a story of how I started coding and kept on learning and growing as a Quality Assurance Engineer in Tacta. Learning to code is tough, it can take a long time and I’m hoping my confession might help others find motivation, so let’s dig into it!
The first coding experience
The first time I tried to learn coding was in Java and it was in 2014. Back then (being a smarty pants) I thought I could learn coding with little effort since it was generally always easy for me to pick up new things. I had no idea at the time that learning to code takes a lot of time, practice, dedication and commitment – hacking away at it constantly is much more important than just being smart.
Specializing in QA & test automation in Java
After doing web development for some time, I fell in love with testing or QA. It was when I realized that testers can also code and that manual testing is there to complement the automation testing – they go hand in hand, to do automation the right way you need to understand the business logic.
At my previous company I was a Junior QA (Quality Assurance) and I was just getting acquainted with test automation in a real world project – prior to that I was doing only manual testing in my first company. There were online resources at the time, but a lot of them were either outdated, not using all the tooling I was supposed to be using at work and the Test Automation University didn’t exist at the time.
I wanted to focus more on doing automation in Java, but what was working against me was the fact that I was working on several projects at the same time (three to four projects usually, as I was a bench consultant) which made focusing on the project with Java automation more difficult.
I thought I had to learn everything at once putting too much pressure on myself, instead of learning incrementally in small manageable chunks.
Yet another obstacle was the fact that I was preparing for automation with C# NUnint, Visual Studio, etc. – as the company was mostly using Microsoft technologies for everything, with the sole exception of the small Java project I got assigned to. Seeing a finished test automation framework which was made by people with 5-10 years of experience was also pretty daunting, I knew the basics but, to me, the framework seemed scary and overengineered – now when I look back the “scary” framework makes perfect sense, it was built using SOLID principles and the tests were following the DAMP paradigme.
Additionally, I thought I had to learn everything at once putting too much pressure on myself, instead of learning incrementally in small manageable chunks.
QA in Java at its best in Tacta
When I truly matured as QA and rediscovered my love for Java was in Tacta.
I was assigned to do testing automation on an API-based product, and the backend product was being made using the Spring framework, built in Java language.
After several years of experience in testing automation, I was ready to do it in Java. Having previously worked with a similar object oriented language (C#) helped a lot – this time Java was making perfect sense. I was pretty comfortable using Postman and since I had a pretty good grasp of the HTTP protocol this time there was no panic. I was creating an API test automation framework and I realized there is nothing better for that than Java.
I had several reasons behind this Solomonic Solution: the first and most important one is that Tacta has many great and experienced Java developers who were practicing Test Driven Development and Pair Programming, meaning that I could learn from them and use their knowledge and support.
Being within a Java ecosystem, it made perfect sense to utilise the tools built in Java and for Java, such as IntelliJ IDE, JUnit, TestNG, Maven, Jenkins, etc. These are well established tools, highly customizable and a lot of them are Open Source!
With my colleagues’ support and experience, I stopped looking at a language from an emotional perspective and I took a gander at it from a more pragmatic point of view – which really paid off.
My takeaway for people who are learning to code and want to become Quality Assurance Engineers:
My main takeaways would be the following:
- Before learning any specific frameworks, learn the fundamentals of the language it’s built upon, that way you will not be using the framework as a crutch – you will know what’s going on beneath the hood and your code will be better for it.
- For test automation, learn design patterns as these will help you organize your code a lot better making it easier to maintain – it also won’t be brittle when making changes
- Use courses only to get the general sense of the technology you’re trying to learn – relying on courses and tutorials for tool long will give you a false sense of security, the instructor will be holding your hand along the way and you won’t face any real challenges – that is where we actually learn the most! So, start working on real project as soon as you can, either at your job or on personal projects
- Don’t try to learn everything at once, focus on one thing at a time, make long-term learning goals and plan your learning (don’t be that tutorial-butterfly that just jumps from one topic to the next one). This way you will break large and complex topics into a much smaller one, which will make it easier to absorb knowledge which will in turn result in frequent and satisfying small wins, as suggested in the Dopamine-Driven Development.
- Also, don’t be a fanatical supporter of any language or technology stack, even your favourite one(s) since ultimately these are just tools of our trade which we use to get the job done – solve a problem for a customer so everyone involved can reap the benefits.
- Use your colleagues experience and knowledge to learn how do to work smarter not harder
I hope this post might help people who are learning to code to (re)gain some of their much needed motivation – I know in my case articles like this one meant a lot, they still do! Thanks for reading!
Author: Mirza Sisic