small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

In today's technological world, where user expectations and design requirements are constantly changing, the role of a QA tester becomes crucial. I recently had the opportunity to participate in an exciting project with a German client, where I was responsible for manual testing and overall product quality assurance. This project was a demanding challenge but provided many valuable lessons I would like to share with you today.

#### The beginning of the adventure with the project

I joined the team as a QA tester when the SPLINT Feedback project was underway.

At this stage, the most crucial task was actually to get to know the project and plan further work:
- The first step was to get to see the documentation, application architecture and functional requirements;
- I had to take into account that the analysis of requirements, design and planning was still ongoing;
- the project was not yet stable enough to introduce automated tests;
- However, the already created BE and FE allow manual testing.

Organizing the work helped me better understand the project and plan an effective test strategy. My experience working on the SPLINT application, of which SPLINT Feedback is a sub-product, proved helpful.


#### Tests, tests, tests..!

Testing was an integral part of the application development process. We focused on the highest-priority tasks, which were accepted and sent to test environments. This allowed us to examine the functionalities closely, analyse their usability, and make the final changes by end users' expectations. How did it look in this case?
- The entire testing process was based on unit tests (performed by the development team) and manual tests for which I was responsible;
- The application consisted of two modules: SPLINT Feedback for Teachers (part of the web application) and SPLINTY—PWA for students. When planning the tests, I took into account not only the needs of both groups but also the need to broaden the scope to include tests on physical mobile devices.
- Our main goal was to enable students and teachers to jointly develop annual goals and cooperate on achieving them through self-assessment and feedback processes. To ensure that everything works as it should, we, the dev team, often assume the role of end users.
- During the testing stage, a solution did not fulfill its intended role, and we had to modify it. In such situations, the tests' conclusions allowed us to create a new, more adapted solution.
- From the application development perspective, pre-release and post-release testing were very important. The test environment, a copy of the production environment, significantly accelerated the smooth release of the latest changes and allowed me to work independently and engage the team.
- To ensure the app was “production ready” at the project's end, we ran acceptance tests with external testers. This allowed us to confirm our previous choices and catch any discrepancies.

Our approach, based on iterative testing and adaptability, was crucial to success.

#### Communication is key

Even the best tests are useless if there is no communication within the project team. Direct contact with developers, product owners (POs), and customers, as well as using tools such as Jira, allowed me to constantly update my priorities and adjust the testing process to the project's needs. Transparency and shared responsibility for the product's quality helped create a strong team and allowed for agile change implementation.

#### Summary 

The SPLINT Feedback project developed quickly and with great flexibility. Thanks to a small, closely related team and constant communication, we could focus on critical aspects of testing. Getting a good grip on the project at an early stage allowed for early detection and prevention of defects, which directly contributed to shortening the development time, reducing costs and improving product quality. Working in an agile environment allowed for quick modification of tasks and improving solutions that the tests indicated were worth refining. Communication was vital, and thanks to the shared responsibility for the quality of the product, our small group had the freedom to make decisions. We analysed the test results, identified errors and adapted the application to users' needs. Most importantly, the conclusions from this project will be valuable to us in future endeavours, and the knowledge and experience gained will have a lasting impact on our team.

large_blog-Inclusion Digital Saga part. 5_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 5_cover_high.jpg

small_blog-Inclusion Digital Saga part. 5_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 5_cover_high.jpg

blog-Inclusion Digital Saga part. 5_cover_high.jpg

From the QA diary: experiences from developing applications for teachers and students - the Inklusion Digital Saga part 5

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

#### 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.

![ ](\uploads\Blog_artykul_MaciejG_02_36fF6FFYmWLmXlV5tpPaPj.jpg)
#### 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.

![ ](\uploads\Blog_artykul_MaciejG_03_6rJxZiROBODJASqnA80CxV.jpg)
#### 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.



small_Blog_artykul_MaciejG_cover_high.png

thumbnail_Blog_artykul_MaciejG_cover_high.png

Blog_artykul_MaciejG_cover_high.png

How to Become a QA Engineer?

From the QA diary: experiences from developing applications for teachers and students - the Inklusion Digital Saga part 5

Piotr

How to Become a QA Engineer?

Maciej

GET IN TOUCH