In this article we’ll discuss the different tips and trick a QA Engineer could use to make the work simpler, these tips and tricks won’t be of a technical type because what works best in a testing framework or a particular language won’t work on another framework. The tips and tricks that will be mentioned are more of logic and concept and they are to help you in any project.
Tips:
- Quality Assurance and Development teams are allies: Frequently inside the organizations there is some type of rivalry or competition between the Development and QA teams, this doesn’t have to be like this. Start by understanding that the work of a QA Engineer is complementary to the work of the Development team, the QA team collaborates with the Development team to deliver a better product for their customer.
- Think on your role as an editor not as a judge: The work of the QA analyst is to find defects in a system, however the reach is no more than finding such bug, document it and in few occasions fix it. Sometimes the analyst is more like a private investigator finding the responsible party of the defect but just to inform that person about the problem, the QA analyst isn’t a police officer that is looking to capture that person and definitely the analyst isn’t a judge that will determine if that person is guilty or not. Think in the role of the QA analyst as an editor that will help the book’s author, in our case the programmer writing the source code, looking for the problems on it, documenting them and also suggesting a possible solution. You don’t need to make the QA analyst a vigilante.
- Get involved on the project as soon as possible: Sometimes the belief is that the QA team work starts when the source code is being written, and sometimes it’s worse the QA get’s involved after the source code is written. This couldn’t be more wrong, it’s really complicated for the whole team to modify the source code or application logic when everything is already in place. That’s why you should get involved as soon as possible, if you can get involved from the beginning. The reasons to do so are: it’s easier to understand the business logic directly from the client or from the business analyst than to do it with the developer, also it’s possible that you find problems or possible risks on the systems logic on the planning phase and then fix it from their origin instead of finding them when everything is already defined and the source code has been written. In this case the QA analyst is like constructor’s supervisor , it’s easier for everyone if the supervisor oversees the whole construction process from the beginning instead of having the supervisor requesting changes when the building’s construction has finished.
- Understand the applications architecture, not just the requirements: Software development methodologies have evolved and programmers now make the source code in modules for them to reuse the source code, and it’s also easier to maintain and it has easier scalability. Therefore it’s essential to understand not just the requirements logic but also the applications architecture in that way we can deduce if a bug is produced due to this source code reutilization or due to a conflict between modules or between application layers. As far as your understanding of the application grows it will be easier for you to write your test cases, test data and to better execute them.
- Apply the Testing pyramid approach: it’s really useful to know how to distribute testing throughout a project. A good testing planning and distribution makes the work simpler and enhances efficiency. A good practice is to divide test cases like this:
The focus is to have the smallest and simplest tests in large numbers, then integration tests come in place, they check combined functionality between 2 or more modules they are a smaller amount, at the top we have UI tests which test only specific scenarios where you need to validate the interface or to validate the specific controls.
Tricks:
- Don’t be afraid to speak up: In several occasions the people in charge of gathering requirements or even the clients themselves have difficulty expressing clearly what the system needs to do. If you consider the definition is confusing or that it’s really shallow it’s better for you to speak up. Don’t remain quiet. It’s better to express your thoughts and work together clarifying the requirements on time that to do all the work and afterwards the team realizes that the job done doesn’t fulfill with what the client requested. Please make sure that this opinions need to be done always in a polite, educated manner with no intent to offend anyone.
- There’s no dumb question: Frequently you rather stay quiet not to embarrass yourself or because you are worried of other persons opinions about you or because you think you should already know the answer to that question, remember that usually if you’re in doubt is because the answer you’re seeking will be something new or different of what you originally thought, other times, we need clarification on the concepts we’ve just learnt occasionally when we ask for that clarification the emitter realizes the message was confusing and they gladly explain it better. This is the main reason we should always ask when something is unclear to avoid having to retest because something was misunderstood or worse that we are reporting a defect that is our fault for misunderstanding the requirement or even worse that a bug is filtered into production because the tests were validating something wrong. It’s always better to be safe than sorry.
- Make common sense your best ally: Our expertise as QA Engineers make us test the application as educated users, this means that we know how the application is built, which are its vulnerabilities and weak spots, and that’s great. However, it is also important to place yourself as a user that is experiencing the system for the first time without any knowledge about it or even without any technology experience. This is done to test how user experience is valued on the application and how simple or complex user experience is. When you perform user experience testing use your common sense don’t think technical, think like someone who is using the system, the computer, or mobile device for the first time.
- An image is worth a thousand words: Documenting test results in a detailed precise way helps a lot when you are a QA Engineer, however, words aren’t the only tool you can use. You can add images to your test results that back up the test execution whether the result was a success or not, when the test is complex a small video detailing the process that has been followed is really useful. Use these tools frequently and constantly for your tests to be the best.
- There’s not just one flavor: QA testing doesn’t involve just functional testing, functional testing isn’t the only way QA can add value to a project. There are also performance, network, security and reliability tests among others, it is important to get used to these types of testing and also with the tools used to perform them. This will add value to your work and the test results will be better. However, you can’t always perform all the types of testing in every project, as the QA Engineer you must know which tests will add more value to your project and use them accordingly.
