small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

#### **Though, there was a problem...**
Some time ago, while working on one of the tasks in the project, I got to the stage where I had to write a test. I am aware that someone now could say that I should start with tests at the beginning. Why didn't I? Because some parts of the code already existed (and were not tested), and I wanted to be sure that my changes would not mess with what I found. This decision was ultimately aimed at overall improvement of the quality and testability of this part of the application.

The application remained uncooperative and did not want to perform, despite the fact that in my subjective opinion the quality of the found code was not so bad. Of course, I would find a few things that I would like to refactor, but despite the lack of testing, the code seemed *testable*. And I was not mistaken. After about 40 minutes I had a very decent *test suite* written, that covered a few existing and new cases. As an engineer, I was satisfied, but still something was bothering me. So I took two steps back and looked at my work again. I was troubled by a few questions. Why was the code so reluctant to be tested, despite its apparent testability? Did I spend enough time on these tests?  What's more, I started to wonder if what I tested actually gives me enough feedback in the case of subsequent changes to the system? It was definitely a topic worth exploring a bit more!


#### **Application Architecture On Her Testesty's (Secret) Service**
For the sake of simplicity, let's assume that the code architecture is primarily the way a code is organized. Of course, this does not only apply to the folders structure, but above all, what responsibilities are met by its individual parts. In the case with my project, we talk about striving to meet the demands of Clean Architecture, also known as Hexagonal, Ports and Adapters or even as Onion, although the latter name has not really caught on. Within this architecture, we distinguish three layers:

1. Infrastructure level - where we communicate with the outside world and use external dependencies (e.g. attached libraries and packages),

2. Application level - where the operational part of our application should be happening,

3. Domain level - where key decisions should be made, e.g. about changing the state of the application.


An interesting property that we should look for in such architecture is the range of visibility of each of these layers. The domain only sees itself and cannot access other layers. The application level has knowledge of the domain and itself. Infrastructure, in turn, sees everything - both from above and below. This mindset forces the developer to always include dependencies from the infrastructure layer to the application layer. We can say that we insert the dependencies from the bottom or, as in the case of the visualization characteristic of this architecture - from the outside to the inside.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_02_1r3nE0JHqmRUOI6znpMU7u.jpg)
##### Graph 1. Visualization of Clean Architecture, own diagram (Domain, App/application, Infrastructure)
We also aim for such architecture when we try to design our application according to DDD (Domain Driven Design) methodology. The system I was working with was definitely heading in DDD direction, although there were still a lot of things to do. That is why ideas derived from DDD appeared in the code, such as entities, value objects, or repositories. This blog-post is not intended to explain what DDD is and what concepts it consists of, but for a further understanding of the whole context, let's adopt such simplified definitions for a few of the terms that I used:

- Entity - it is an object with an identity that represents some model. For example, a user that we can uniquely identify. This model, however, unlike the typical approach containing mainly anemic entities, apart from data, also has methods that allow you to perform some action on this object.

- Value object  - this is an object that has no identity. A perfect example is the representation of money. However, unlike a simple data structure, it may also have some logic, e.g. related to validation, different representation or comparison.

- Repository - it is an object that allows us to perform database operations. However, it should provide a high-level API to not reveal implementation details.


It seems Uncle Bob would have accepted that. However, how could such architecture help us in any way in testing? What layer should we test the most? What should such tests look like? Unfortunately, it seems that the very concept of this architecture does not answer those questions. So let's try to ask a slightly different one. What makes a test easy to write, and what makes it difficult or even impossible?

#### **White or black?**
One popular pattern for writing unit tests is the 3xA rule:

- Arrange - prepare the application so that it can be tested,

- Act - perform an action,

- Assert - check and test if the result of the action is consistent with your predictions.


After analyzing the tests I wrote for the project I noticed that the Arrange stage, i.e. test preparation, was the most time consuming part. The very implementation of the action and test usually came down to one or two lines of code, but preparation took even a dozen or so. Besides, I had a strong feeling that I needed to go too deep into the implementation to know how to test a given piece of code.

Let's look at the following code snippet:

``Code 1: Implementation of the Calculator class``



Now let's try to test this code:

``Code 2: Tests for the Calculator class``



The code shows a very simple implementation of a calculator with two methods for dividing and adding. Very often, such samples are used to show an example of testing an application.



In each test case, I started with a comment of the part of the Arrange, Act and Assert sections. You will notice that these sections are very short and concise. Each test consists of 3 lines, one for each section. However, I would like to highlight one important thing that seems to be overlooked or not sufficiently resonant in such examples. These tests are very simple and quick to write. You could say that we are testing a very simple sample class, but actually such cases rarely occur in the real world. One could even say that these tests are detached from reality. But let's consider what, apart from this uncomplicated example, makes these tests so simple:

- explicitly defined contract in the form of the *CalculatorInterface* interface,

- the *Calculator* class has no dependencies,

- methods have all the information to be able to perform the requested action,

- there is a constant relationship between the input parameters and the return value.



It can be clearly stated that by looking at the methods of this class, we are able to say what their behavior is and what results we can expect. Thanks to this, knowledge of the internal implementation is not required and we could actually write tests based only on the methods specified in the *CalculatorInterface* interface. Tests with these properties are called *blackbox tests*. The black box test is the simplest type of test that makes it much easier to check your application. However, we rarely test simple calculators in our lives. So let's try to discuss a slightly more complex case.

``Code 3: Currency exchange service``



The purpose of this class is to convert the value of one currency to another. It has a dependency in the form of a repository returning the current exchange rate. The specific implementation of this repository, as part of our Clean Architecture, should be placed at the infrastructure level. In our case, this type of service belongs to the application layer. In the domain layer, in turn, there will be concepts presented as value objects, such as *Currency*, *Money* or *ExchangeRate*. Let's try to add tests for this class.



``Code 4: Tests for the CurrencyExchangeService class``



You can see at first sight that this test is much more complicated. What’s more, the number of lines of the test is bigger than the test code itself! This one test took me a lot more time than the 3 previous ones for the Calculator class combined. The test itself is not complicated, although some intellectual effort was required to have it prepared. It's worth noting that the *Arrange* section contains the most lines of code. As the *CurrencyExchangeService* class has an external dependency, it had to be replaced with an object of the class pretending to be a real repository. Such an object is called *Test Double* (the name refers to the term *Stunt Double*, i.e. a stuntman who replaces an actor in dangerous scenes of the movie). It is supposed to replace the original object on which it will be possible to call the necessary methods and return the previously prepared data. This is to ensure the repeatability of the test execution and to cut off the true dependencies in order to be able to test the code in isolation. In this particular case, I used a *Mock-type* test double, which allows you to verify whether a given method was used during the test. It also allows you to define what parameters the method should expect and the value to be returned.


In comparison to the previous example, in order to call and test the *exchange* method, I needed to know the internal implementation of the *CurrencyExchangeService* class. I needed to know that this method would call the *getExchangeRate* method inside and what value this method would give in return. Creating a test double complicated the process of writing the test. It is also not as transparent as the tests for the *Calculator* class. Tests where implementation knowledge is required are called *whitebox* tests. What is more interesting, almost all the tests I wrote and were dedicated to the problem described at the beginning of this article were *white box tests*. The tested classes had a large number of dependencies, so the *Arrange* stage first included the instance of many test doubles, which made the whole testing process difficult. I will also mention that the preparation of these test double files was extremely boring and required a thorough code review (as these tests were written in the form of TAD - *Test After Development*) in search of a specific use of them. It can be clearly stated that the white-box tests are much more difficult to write, although at the moment it seems that they are still much more “real life-like” than the black-box tests. Ideally, we should only be able to test the functionality with black-box testing. Then the question arises how to do it and how would our application architecture help us? Let's look at one more example and try to transform it to answer these questions.

#### **A classic. Testing the cart**
``Code 5: The CartService class``




In the presented section of the code, we have the part responsible for using the coupon with a percentage discount on the items added to the shopping cart. The *applyDiscountHandler* method takes a command (that is, an action request) and gets an instance of the current cart and finds the coupon in the database. Then it applies the coupon according to the business rules, saves the changed cart and blocks the coupon so that it cannot be used again. The code structure and dependencies are distributed within Clean Architecture.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_04_3CbAXJz8YLyGPyQgnyXlxZ.jpg)
##### 
Graph 2. Code structure of the Cart module
We can list the characteristic blocks from which we build the application using DDD design. Let us think about how we could test this method. The *CartService* class has 3 dependencies. Two for the repositories for the cart and coupons and one for the service for broadcasting events (event - something important happened in the system). This means that at first we would have to create mocks for these dependencies. Then we should check what methods are used (how many times, with what parameters and what they return) and set them accordingly. The key action we are trying to perform is actually changing the state of the *Cart* object. However, the *CartService* class does not return an instance of this class in any way. Verification of its condition would also have to be done with a *mock*. Definitely,  It would be a white box test. What's more, the code doesn't make it easy for us by returning nothing, which would require workarounds and tricks to make it work. This kind of test would be neither easy to write nor read (and we need to remember that tests are the best documentation!). At this point, we should have a feeling that something is wrong with our code. Let's try to refactor our code to make our tests a little easier to write and a little more readable.  So what is wrong with the code presented?

- The method definitely breaks the SRP (*Single Responsibility Principle*) principle and does too much - so it would be good to separate the operations on the coupon and the cart from each other.

- The business logic of the discount calculation rules leaked from the domain to the application site. The application layer is responsible for the operational part of the program. It should not make business decisions.

- Two different business logic are mixed up here. Logic of coupon management and blocking, and logic of the cart calculation.


First, let's deal with the separation of responsibilities. 

``Code 6: DiscountService class``



We have created a new class that deals only with the validation and coupon usage. On the found coupon, we call the *useDiscount* method, which returns the event informing about the change of the coupon state. Let's take a look at the *Discount* class.

``Code 7: Discount class``



*The Discount* class has no dependencies. All the information required to make the state change decision was provided in the initialization stage. So we have led to a situation where we can test our business logic with a ... black-box test!

``Code 8: Tests for class Discount``



Definitely, the test of our business logic looks much neater than the test of the currency conversion site and it took a lot less time to write it. Thanks to the returned events, we can examine the connections between the input parameters and the output parameters of the method. The use of the concept of events is also not accidental. By events, we mean a change of state that is significant for the system. This is also what happened in this case. Then, within *DiscountService*, we do two things with the event:

- We save the change - depending on the system architecture, we can save this event in our database. The sum of all events (i.e. changes in state) on an object will always give us its current state. On the other hand, in a system where these historical state changes are irrelevant, we can update the state of the object directly. In the latter case, however, it is good to transfer a new, consistent instance of the object being provided inside the event.

- We publish an event - thanks to this, other objects listening to specific events can take their own actions. This is how we make it possible to apply our coupon to the cart.


``Code 9: The CartService class``



The *DiscountCouponUsedEvent* event caused the *applyDiscountHandler* method to be called on a *CartService* object. This event brings the necessary information that we need to apply to our shopping cart. As you can see, there is no need to provide the entire discount object, only information about the discount type (*DiscountType*) and discount percentage (*DiscountPercentage*).

``Code 10: Cart Class`` 




Again, the *Cart* class has all the information required to apply the discount and returns an event as a result of calling the *applyDiscount* method. Then we persist in this event and publish it. This approach creates a cause and effect chain that is very easy to follow and understand. The *Cart* type tests will also be black box tests. However, the question arises, what about the *CartService* and *DiscountService* classes? Both have dependencies, so testing them forces us to do white-box testing. At this point, I would like to highlight the responsibilities of these services. Their task is to:

- preparation of our object (*Cart/Discount*),

- calling the appropriate method with appropriate parameters,

- calling actions aimed at preserving and publishing events.



Isn't that a bit like the *Arrange, Act, Assert* pattern? We have to answer the question, what would we really like to test in these classes? There seems to be no point in testing them, as the essence of their responsibility is actually triggering our business logic. So these would be the same tests we wrote for the *Discount* and *Cart* classes, but wrapped in a complicated structure of stubs and mocks. Therefore, integration tests, not unit tests, would make much more sense here.

#### **So where are these aggregates?**
The title of this article promised the aggregates, and I still haven't mentioned anything about them. This is a deliberate case, as it seems to me that this topic is not fully understood by many programmers. In the given example, all we did is refactor a little and reorganize our code. This allowed us to bring it to a stage where we were able to test it with a much simpler black-box testing method. As a result, our *Cart* and *Discount* classes have acquired some properties that they did not have before, namely:

___
**they have all the information required to make a business decision**

___
As a result, they can protect data with consistent rules and make state change decisions without having to ask other parts of the system for additional conditions. Let's add to this supplementary conditions that do not result directly from the code:

- *Cart* and *Discount* class objects should always be created in whole extend (all required data should be loaded),

- state changes should be persisted atomically (i.e. always all together),

- only the *Cart* and *Discount* classes can modify their state - no other part of the system can do so.



By adding these few additional conditions, it turns out that our *Cart* and *Discount* classes are technically... aggregates in the sense of the DDD. More precisely, the roots of their aggregates. To illustrate this better, take a look at how I reorganized the directory structure of our component.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_05_5EIfawNNSZ2LZx9zqPsdHr.jpg)
##### Graph 3. Cart module structure containing aggregates
The Domain class contains 3 catalogs: *Commons*, which contains common concepts, and *Cart* and *Discount*, where our aggregates are located. I highlighted their roots in blue, i.e. classes that constitute a public interface for interacting with the aggregate. It seems to me that such a presentation of this concept can be much more accessible, because it not only shows us the benefits of a much better testability of our code, but also one of the ways in which we are able to extract aggregates from our system. Of course, there are much better and more appropriate tools for this (e.g. process and tactical sessions in Event Storming), but even if we do not know these concepts, we can improve our applications in the way presented. 

#### **Who is your boss?**
In conclusion, I would like to present a certain analogy that comes to my mind when I think about the responsibilities of clean architecture. This analogy can be helpful when we are forced to decide how we should organize our application code.

![ ](\uploads\Blog_artykul_TestingAggregates_LukaszD_03_2lCBUwq9BZwf1P03b5469X.jpg)
##### Graph 4. Analogy of Clean Architecture to Organization, own diagram

Imagine your company has three levels:

1. The boss - the decision-maker

2. Middle-level manager

3. Employees


The responsibility of a middle-level manager is to execute the plan provided by the decision-making person. He does not do it by himself, but delegates work to employees. Employees do it physically. Moreover, the manager is responsible for providing the data the boss needs to make specific decisions. The preparation of these data is also delegated to employees, but the manager may also format or organize them differently before handing them over to the boss. In a large organization, the boss very often does not even know his employees. The data is provided to him by the manager, so there is no need to ask and search for data from the lowest-level employees. He is also not interested in the way the assigned tasks are performed.

Our application structure works similarly. The application layer orders the physical download and preparation of data for specific instances in the infrastructure layer, which retrieve it from the database and return our aggregate root. Then the parameters are called and passed to the aggregate method, which makes the decision about the state change already in the domain layer. This decision is returned by event to the application layer, which is then delegated back to the infrastructure layer for persistence and publication.

#### **Try it yourself!**
As part of this article, I also created an implementation of this solution. As you may have noticed, not everything I wrote about has been tested. What's more, the infrastructure layer has not been presented here in any way, which in our case can be completely replaced by tests. If you would like to practice, fork the codebase repository and try to extend the existing tests, modify the *CurrencyExchangeService* class the same way I did with the *CartService* class. Suggest your own solutions and share your implementation with everyone in the comments. I am curious about your opinion on how you understand the presented topic and ideas for implementation.

The blog post was created as a translation of a "Testowanie agregatów, czyli architektura wspierająca testowanie" entry on [**devkick.pl**](http://devkick.pl/testowanie-agregatow-czyli-architektura-wspierajaca-testowanie/)
, written by Łukasz Duraj. 

GitHub - [**lukasz-devkick**](https://github.com/lukasz-devkick)
**/**[**aggregates.testing**](https://github.com/lukasz-devkick/aggregates.testing)




small_Blog_artykul_TestingAggregates_LukaszD_cover_high.png

thumbnail_Blog_artykul_TestingAggregates_LukaszD_cover_high.png

Blog_artykul_TestingAggregates_LukaszD_cover_high.png

Testing Aggregates

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.



Testing Aggregates

Łukasz

How to Become a QA Engineer?

Maciej

GET IN TOUCH