Published on 11 Oct 2022
Switching from Java to Node.js as a senior developer - Tomasz’s story
Tomasz
Backend Developer
How One Man Went From Teaching English to Becoming a QA Tester.
There is no single path to becoming a quality assurance engineer. Whatever your background, you'll make it as a QA engineer with persistence, communication, and attention to detail.
Maciej, one of our QA engineers, embodies these qualities. His career journey took him from restaurant manager to car parts salesman to English teacher. He did all this while living in a country foreign to him: Cambodia.
Since then, he's settled in as a QA engineer. On his last project, he worked with a unicorn startup valued at around 2 billion dollars. Want to find out how he did it? Read on to learn about Maciej's journey.
Q: Maciej, tell us what you did before becoming a QA Engineer.
When I was younger, I was never the technical type. Rather, I spent much of my time chasing experiences. In my home country, Poland, I worked at a paragliding school. I also volunteered to organize large-scale events, such as the OldTown Festival.
I had a penchant for travel. Therefore, I moved to Cambodia where I started out working as a manager at a vegan restaurant. Later, I moved on to become a car parts salesman, and finally an English teacher. I am quite versatile.
Unfortunately, none of those positions were quite enough to pay the bills. I struggled to make ends meet. One day, I had a heart-to-heart conversation with a good friend of mine. During this conversation, he mentioned I would make a good QA engineer. He said I had all the necessary skills. After all, as a salesman, I had to learn about different car parts. I was quite adept at learning about new technology.
Bursting with confidence from that conversation, I heeded my friend's advice. I was going to become a QA engineer.
Q: Why did you decide to become a QA Engineer?
As you can tell from my previous answer, money was one of the factors. Unlike many of my previous forays, QA engineers make some decent money. Especially compared to what the average vegan restaurant manager makes in south-east Asia. Here's a hint: it's not much.
Not to mention, I just felt it was time for a career change. I researched the IT industry a bit and figured that I would make a good project manager. After all, I had already assumed a leadership role when teaching paragliding and English and as well when I organized events and managed that vegan restaurant.
In the end, I decided to follow my friend's advice to the letter and become a QA engineer. I researched the types of things that QA engineers do and found that it wasn't as technical as I once thought.
Q: Did you have any doubts about your career move?
One of the most common misconceptions people have about QA engineers is that we all have technical backgrounds. After all, doesn't the name "engineer" sound technical to you?
I got nervous, I thought that it was mandatory for everyone in IT to have a degree in computer science. However, I was wrong. Most quality assurance engineers don’t have a comp sci degree. Like me, they come from all sorts of backgrounds.
Q: Did your fears materialize?
Without a doubt, IT is extremely technical. I was intimidated at first, I didn't have any formal IT education. Fortunately, my employer gave me time to learn, time to make mistakes, and time to improve. You don't need to be an expert on day one.
It was a shaky start, but over time, my skills improved. I was in the perfect environment for growth. I'm grateful that people in the IT industry are so willing to share their knowledge. Without their assistance, I wouldn't be here today.
Q: Let's talk about your first steps in your career as a QA Engineer.
The very first step I took was to complete an ISTQB course. ISTQB stands for International Software Testing Qualifications Board. The point of those courses is to ensure that everyone follows a common standard in quality assurance. I learned the principles and terminology associated with QA so that I could collaborate and communicate with everyone. Communication is the key to being a QA engineer.
If you don't know where to start on your journey as a QA engineer, I would look at completing the test first. Nowadays, I think you can easily complete it online. Once I passed the test, I received an ISTQB certificate.
Armed with those credentials, I rapidly fired off my resume to several companies. Not long after, I interviewed with Bitnoise and got the job. They were the first company that wanted to hire me. I was ecstatic.
Q: Did the recruiters mind that you had no experience?
Luckily for me, they didn't mind too much. When the recruiters asked about my experience I was honest. I told them that my experience was minimal.
The recruiters saw my potential. They told me that I had the right attitude for learning and that my new colleagues would teach me everything I needed to know. As I said earlier, I was given every opportunity to grow.
Q: What were your first impressions when you joined Bitnoise as a QA Engineer?
I was stunned by how great the team was. Everyone at Bitnoise is so friendly and helpful. I had never encountered a company with such an awesome culture. For the first time in my life, I was working with people whose presence I enjoyed both inside at outside of work.
In such an open environment, I flourished. You can probably tell, that communication is one of my biggest talents. I met people quickly. They also moved me around to different projects quite often. This exposed me to as many people, ideas, and experiences as possible.
Q: Did you like the fact that you changed projects on regular basis?
When you're in a new setting, you try to stick to what you know. I was pretty hesitant at first because I still wasn't confident in my abilities as a QA engineer. But my mindset quickly changed when I realized that the more projects I'm involved in, the more I'll learn.
You know, I was right. Moving from project to project helped me learn new approaches and new methods in quality assurance. I've done this for two years now, and I'm quite grateful for all these opportunities to learn.
Q: What are the responsibilities of a QA Engineer?
I could go into great detail, but I'll keep my answer brief. My responsibility is to check the quality of the software. Alongside my peers, I use a whole range of methods and techniques to identify bugs and other issues.
Another aspect of my role is to make sure that the documentation for each software product is coherent. It's challenging to update software with crappy documentation. My job is to make sure our developers aren't spending all day asking questions on Stack Overflow.
Part of gauging coherence is to ensure that the user experience is comfortable, along with the software performance. I check those things using a variety of tests. We have a whole set of criteria that we must adhere to.
Q: What are the testing types, methods, and techniques in software development?
That's quite a complex question. I'll go over each type of testing to give you a better understanding of each of them. It will help you understand my role better.
Exploratory Testing
My favorite form of testing is exploratory testing, so I'll go over that one first. People used to call it ad-hoc testing because you create tests for the software on the fly. Essentially, you think of a bunch of different situations without any preparation, unlike the other tests which we plan ahead of time. This is a very creative way to discover any bugs in the software.
Regression Testing
The next one is regression testing. When you change a piece of code, it's possible that another part of code relied on the part you changed. Regression testing ensures that the code still works after you change it. Poorly written code is when you create functions or clauses that unexpectedly rely on code that should be completely unrelated. You want to avoid this.
Sometimes, this process is manual. But at other times, it's automated.
Sanity & Smoke Testing
Before I try any other type of test, I usually conduct sanity tests and smoke tests. These are simple tests that you should conduct first to avoid wasting time on complex testing.
We conduct sanity tests after a change occurs to check for bugs and ensure that the new functionality works. This isn't a deep dive. As the name suggests, it's just another test to make sure that things work before going into more detail.
Smoke tests serve a similar purpose. But we use them to verify only the most critical functionality. For example, I might run a smoke test to ensure that the app starts successfully and that the GUI is responsive.
Destructive Testing
Destructive testing can be pretty fun too. In this test, we design a set of scripts ahead in an attempt to make the software fail. Once the software fails, and it will, I examine exactly which components of the software caused it to fail. This helps me understand the weak points that need to be fixed. Not to mention, it's a great way to account for unpredictable user behavior.
Compliance Testing
When you create software, you generate a bunch of standards first. I run compliance tests to ensure that we meet those standards. This happens at every stage of our development process because it's absolutely critical that we are consistent. Plus, there would be too many issues to go back and fix after the fact.
During compliance testing, I also examine the documentation to ensure that it's complete and follows our standards. Useful documentation is a top priority.
You might wonder how I juggle between so many different types of tests. Some QA engineers specialize only in a certain kind. Personally, I've grown to enjoy running a variety of tests myself.
Q: What are the benefits of being a software tester?
The great thing about being a software tester, and working in IT in general, is that the number one priority is getting the job done. Once the job is done, I'm free to do anything I want. Few industries offer this kind of flexibility. I prioritize independence quite a bit, so being a software tester is perfect for me.
Of course, you have to be comfortable with the industry. Jobs in IT are quite stable compared to those in other industries. So, I don’t feel like job security is an issue. As long as I'm performing well, I'll always have someplace to work.
That brings me to the next benefit. Since most QA work is merit-based, managers and clients leave me alone because they know I can deliver results. I've proven myself enough times and that allows me to once again maintain independence.
Finally, I find that working as a QA engineer is extremely rewarding. With every project that I work on, I take full ownership and give the client everything I've got. I’ll take in user feedback with pleasure to shape the software into the best version it can be. Most of all, I'm proud to watch each software grow into its own ecosystem, its own universe that people use and interact with every day.
Q: What do you like the most about your job?
I'm a people person, I love teamwork and collaboration. Throughout my day as a software engineer, I'm talking to all sorts of people. These can include project managers, product owners, developers, and designers. Each of those people has their own unique role and their own unique character. Synergizing with these people to release software gives you such a fantastic feeling of accomplishment.
And even though I get to hear everyone's input. Decisions are still mine. I have a fair degree of freedom when it comes to my approach to testing as well as my daily tasks.
Q: Why is the work of a QA engineer important?
I mean, why is the work of any engineer important? Engineers keep structures safe. They find flaws in the design long before anyone walks across that bridge. As a QA engineer, the stakes are a bit lower. But the software market is competitive, it's essential to find any bugs or other issues with it before users do. Otherwise, you're putting out a garbage product.
In the long run, software users appreciate everything we do, even though they might not be aware we exist. One of the main goals of quality assurance is to improve the user experience.
Our clients appreciate us as well. That's because we reduce costs all-around. The more mistakes we find earlier rather than later, the cheaper it is to fix them. Every time you neglect an issue you end up putting layers upon layers of code on top of it. It's best to identify problems right away.
Q: How do you educate yourself? What are your resources?
Everybody must start somewhere. I know that I did. As I mentioned earlier, I had to rely quite a bit on my colleagues in the beginning. For some of the more jaded vets around me, I’m sure that my constant newbie calls became irritating. That said, they never showed that they were annoyed. They always made me aware that they were only a phone call away. I’m incredibly grateful for the wealth of knowledge that they lent to me – it was quite empowering.
Aside from consulting your friends and colleagues, you also have the option of asking your burning questions on social media. Google and YouTube can be helpful. However, Reddit is by far my favorite avenue to look for help, specifically, r/qualityassurance.
Here's one example of a post I saw recently. Someone on there wanted to automate localization testing, but they weren't sure how to achieve this. If you're not familiar, it's a way to test how an app handles settings in various locations. For instance, the settings in Germany might not work the same as they do in India. Shortly after the question was asked, someone else replied and recommended a tool called Playwright.
That goes to show that the community is pretty helpful. When you have a question, first try searching for it in the search bar on the right. If you can’t find an answer there, then you should ask the question yourself. You'll probably get a good answer.
You could also ask a more general question. Another one I saw asked why it was important to have a separate environment for development and QA. It's a rather novice question, but it still got plenty of helpful responses.
Q: What is the salary of a QA engineer?
I'm guessing you asked this question because you want to know how much I make. While I can't give you any exact figures, I should mention that the starting salary is fairly low. Although, it was still more than what I made as a used car parts salesman in Cambodia, which is not saying much.
To see a salary increase right away, you need to be hardworking and ambitious. I'd like to think I possess both of those qualities. And now, after two years of working as a QA engineer, I am both satisfied and secure given how much money I'm pulling in each month.
Q: Any advice for junior testers?
Naturally, I'm basing all my advice on personal experience. So, if you want to follow in my footsteps, then start by making as many friends as possible. If people take a liking to you, they will be quite eager to help you with any professional challenges you’re facing. These connections will become major assets down the road.
You have a bit of a grace period as a newbie, but you should try to provide value to everyone from the get-go. On day one, that might mean bringing everyone coffee. Soon after, you should be capable of communicating valuable information to everyone the same way I do. I always say that being a QA engineer just boils down to being an "information broker". You should always initiate conversations, and always ask people questions.
Given enough time and interaction, you’ll start to build coalitions. You'll get familiar with your colleagues and you'll understand people’s strengths and weaknesses. That will help you select the go-to people when you need advice for a certain project.
Thank you, Maciej, for giving such thoughtful answers. It's been a pleasure.
Likewise. I'm always happy to share my knowledge.
Wrapping Up
That was quite an enlightening interview. As Maciej showed us, the key to becoming a QA engineer lies not in your technical background, but in your willingness to learn. Furthermore, he benefited from a huge support network to answer his questions. This is what you need to become a QA engineer.
