Go to content|Go to the main menu|Go to search

edhouse-CookieGdpr-Policy-s
8753657
2
/en/gdpr/
875650B6A

Back to Blog

SQA

What Should I know as a Tester?

14.9.2022Martin Blažek

Soft skills

Communication

As a Software Quality Engineer (SQE), you'll find yourself positioned between programmers and management. Each side prefers a different type of communication. While management is interested in the product's status, current issues, or the release schedule, programmers are more concerned with technical specifications. They need to know how the product should behave, how it should not behave under any circumstances, where changes should manifest, and under what conditions. In the case of a bug, they need to know when and how it occurred.

It's important for an SQE to be able to filter/translate information for each team member so that it can be used as effectively as possible. An SQE should know as much as possible about the product they are testing. However, they often won't receive all the information upfront and must not be afraid to ask questions multiple times, even if phrased differently each time.

Responsibility

Every member of the team should be accountable, no one should rely solely on the tester. However, the tester is often the last person to work with a feature or make the biggest changes. Testers need to be aware that they have a major influence on the direction the development will take and how it may affect the customer. Testers face a lot of pressure at the end of the normal development cycle (sprint, release). Sometimes they have to prolong the development or oppose the whole team in order to achieve product quality. They should have a rather critical or pessimistic mindset. To summarize, a tester must be sure that, he or she has done his best to ensure the highest possible test coverage. Alternatively, he or she has communicated all threats during development before it starts.

Curiosity

As a tester, curiosity is one of the most important qualities you can possess. If a particular functionality works correctly, it's essential to remember that it may not work the same way in any other configuration. Let me give you an example. Imagine we have an e-shop where we can order goods. After we confirm our order via email, we go through the normal order process. Just because we didn't encounter any error doesn't mean there can't be a bug! The tester should be interested in what happens if he doesn't fill in the address, enters unauthorised characters in the name, makes the whole purchase on a different browser or device. Every tester should be curious and ask questions or try things out. Thanks to his curiosity, it is possible that a problem will be discovered before the start of the work on the product!

Presenting

From the previous characteristics, it's clear that the tester will need to present their idea in the best way possible. They often find themselves in opposition to the team, but if they want to get their point across, they have to present it correctly. The point must be clear to each team member and why they should be concerned with it. But sometimes this is not enough! The tester always faces outnumbered in the team, so they have to make their point forcefully or engagingly.

Share article

Author

Martin Blažek

Edhouse newsletter

Get the latest updates from the world of Edhouse – news, events, and current software and hardware trends.

By signing up, you agree to our Privacy Policy.

Thank you for your interest in subscribing to our newsletter! To complete your registration you need to confirm your subscription. We have just sent you a confirmation link to the email address you provided. Please click on this link to complete your registration. If you do not find the email, please check your spam or "Promotions" folder.