The role of a tester in a team is surrounded by many myths. One of them is that it is the most problematic role in a team. The second is that his/her work delays handing the finished product over to the customer. Someone who repeats this kind of stereotypes may not realize what QA (Quality Assurance) work consists in. Nor do they see that testing activities bring more good than bad. In the long term, we balance out two scenarios: postponing the submission of works or... losing the customer. So I decided to analyze what software testing is really all about. And who can become a tester, even before acquiring hard skills.
Software tester: what does this job consist in?
What is a software tester’s work like at Inwedo?
- Application testing step by step
- The role of asking questions and compliance with the customer's concept
- Software testing and quality
Good tester, meaning who?
Communication between the QA team and developers
It is a hurtful myth that the work of a manual tester is based on clicking on applications, so it’s a job for everyone. I mean, how hard can it be?
Contrary to appearances, testing applications is not based on mindless clicking on individual boxes or buttons for errors. It’s a thoughtful effort to eliminate as many errors as possible while preserving the business value of the project.
In terms of the way tests are carried out, we can distinguish between two basic types of software testing: manual testing and automated testing. In my text, I focus on manual testing, which I also interchangeably call QA. It’s a subject much closer to my heart and I’m more passionate about it. I consciously don’t describe the second kind of software testing, because it’s the topic for my next text. To facilitate the understanding of my role, I give examples closely related to the specificity and approach we have at Inwedo.
At Inwedo, we attach great importance to the quality and testing of the products we manufacture. Each project has its own tester, and in our case – a girl-tester, because our team is currently made up of girls only. Each of us makes sure that the effects of our actions both meet the customer’s expectations and retain our quality standard. At Inwedo, the tester is involved in the project already at the stage of Discovery workshops (initiating the project), which helps avoid setbacks. In addition, the presence of the tester in meetings with the customer allows for a good planning of the testing process right from the start.
It’s not about which view is better or worse. It’s simply different – seeing threats, asking difficult questions (has anyone ever counted how many times the question “What if …?” was asked during a meeting?), paying attention to the impact of the task on other system elements. In fact, the first organizational meetings already show the first test scenarios that can help programmers estimate their work and turn their attention to critical spots.
The work of the tester in the project is carried out simultaneously with the work of programmers. Thanks to this, it’s possible to quickly catch a bug and thus save our customers’ time and money.
At the initial stage, when the application does not yet exist physically, preliminary test scenarios are created based on technical documentation, AC (acceptance criteria) for individual tasks, or we implement a new tool to support work. Developing scenarios or AC at this stage allows you to maintain relative peace of mind when real testing tasks appear. Acceptance criteria also help programmers to accomplish individual tasks, as they indicate places or operation of individual elements in the system, which we must bear in mind during works.
Once the application is physically ready for testing, it’s the software tester’s job to verify that the application works correctly. Also in terms of business compliance. Don’t be frightened by this – if you are not sure if something works as intended, contact your Product Owner. And as a last resort – the customer.
At Inwedo, it’s the tester who selects testing tools and methods. It is she who knows best what methods will work in a particular project, which will allow to eliminate as many defects as possible.
When does testing end? Never really. You can always find something that can be improved or changed. But after all, testing cannot go on forever! For me, the moment when I can say that the software is ready to be handed over to the client is when it meets the AC (acceptance criteria) of all the tasks assigned to the given iteration.
There are many myths about testing, testers and the IT industry. One of the biggest and often very hurtful is that a software tester is a simple “clicker”, possibly a “destroyer” of all development work (or a saboteur, but this is a story for another article ;)).
Personally, I disagree with that. So who can be called a good tester then? Does such a person have a “special” set of distinctive characteristics? Or is it the contrary? Anyone can test and it’s not a big deal? I would like to present my subjective assessment of who can become a tester and what qualities come in handy in this job.
For a layperson, testing can actually look like simple “clicking” or breaking what seems unbreakable. In fact, the person who verifies the application for the correctness of the task performance has a responsible task to tackle:
- Undoubtedly, the most important quality in a tester is perceptiveness as it often happens that the first tasks are of frontend kind. Therefore, the ability to catch irregularities is very useful. A good exercise to develop this quality is playing all kinds of games of “find 10 differences in the picture” type, noting changes in the neighborhood, memory, etc. It may seem funny, but through this kind of brain exercise we become more perceptive. After just a few rounds of such amusement, we realize that we start noting changes and differences faster.
- Another quality is inquisitiveness. A really good software tester must ask a lot of insightful questions and, above all, not be afraid of asking them. Sometimes it is better to ask one more “What if…?” than to skip some aspect of the system operation. Looking at objects like a small child would is also worthwhile, as children rarely use things for their intended purpose. It’s about being inspired by this approach and testing the software in a non-obvious way.
- I believe knowing how to make compromises is just as important as hard skills. I think it’s useful in virtually any teamwork. Sometimes, it’s ok to turn a blind eye on this one pixel too many (of course, if the customer allows such deviations) or eliminate some fancy stuff from the functionality in favor of a holistic look at the project.
- Compromise in inextricably linked with the ability to collaborate. Just as the striker won’t win the match all by himself, the developer or tester will not finish the project alone. This should be taken into account every time there is a stressful moment and the tension in the project begins to rise. Only by working together can the tasks be carried out well.
- Assertiveness is a useful skill in a tester’s work, especially when all the deadlines of the world fall on the same moment in time. A software tester must know how to refuse, and it’s not about being malicious or blocking the project. Assessing own strength realistically and bearing in mind own well-being is important. A tired tester is a bad tester and it’s something to remember.
In my opinion, the above set of soft skills is vital in the work of a tester. In addition to them, technical skills such as programming, writing SQL queries or API testing using Postman are useful. But this is already a topic for the second part 😉 If there is someone here who is considering changing the industry to IT, despite the lack of education in the field, I recommend looking for portals and communities that help in making a professional change. A great example is the community that helps women enter the IT industry, centered around the Dare IT mentoring program.
Sometimes my friends outside the IT world ask me what my job is all about. This usually boils down to the question: “So you point out errors to people?” After I confirm that, another question arises: “How do you get along with the developers? You probably have a never-ending beef with them, because few people like it when you point out their mistakes?” Well, no.
At Inwedo, our work supports the work of others. We know how to communicate with each other, which is especially valuable in the era of pandemic and remote work.
As we have found out on multiple occasions, only together can we achieve the goal, which is to provide the customer with a good quality product. Thus, we can count on mutual support in our actions. In tense moments, we are all looking for a compromise that will be as profitable as possible for the customer.
And when emotions run high and stress takes over, we exchange some old jokes or memes – this is how we release the tension and return to the search for a reasonable solution. For our own needs, we call this approach “Empower others” and it has often helped us mitigate potential conflicts right at the outset.
In the process of making software, a tester is just as important as a programmer. By working together, we are able to create a project that will benefit our customers and make them happy.
If you are interested in working as a tester at Inwedo, perfect timing – we’re looking for a new person for the team! Check out our Careers tab for more: