Manual QA Engineer testing is defined as manually testing a software or application without any coding automation tools. The purpose of manual testing is to find bugs and defects in a program as early as possible. Every application should be manually tested before it is automated to confirm it is bug-free.
This article will go into detail on these 5 tips
Verbiage versatility
Communicate test coverage
Learn about the product
Bugs/Defects
Prioritize testing order
Photo by Mimi Thian on Unsplash
Verbiage Versatility
This is what will separate you from the crowd as a QA Manual tester, verbiage versatility. If you can communicate in a language that the product owners understand as well as a language that the developers understand, you can be a true glue piece to your team. This will require extra effort, being thoroughly knowledgeable regarding the products you are testing as well as a high-level of the code being implements and being able to communicate what is going on for each adequately.
This versatility will seem strenuous to you at first, but can in fact improve the overall team flow for projects. You can be a universal reference point using knowledge transfer and communicating it appropriately. For example, if you find a bug while manual testing regarding a certain input field not accepting certain characters. If you know enough about the code you can do the debugging yourself to find the problem. That way when you later communicate the defect you can also communicate what in the code you believe is costing it, possibly saving the developers valuable time of trying to find it on their own.
Communicate test coverage
Depending on your team’s structure, as the manual QA tester, you may be responsible for creating the test plan for testing an application. This test plan should at a minimum include everything from the requirements documentation gathered from the product owner. Next, you want to make sure everything documented in the test plan is adequately being tested.
There should be a test case for every possible scenario that the application being tested can possibly experience. You must clearly dictate and document to your team as well as in your software tools what test cases are going to be manually tested by the QA and what test cases are going to be tested by automation. This documentation should be shared and accessible to everyone on the team to avoid any confusion on what parts they are testing.
Learn about the product
The more you know about the product that is being tested the better. Don’t be afraid to ask questions to the developers and product owners and any other resources that are tied to the product.
Ask questions like:
What end-users will be using this application?
On average how many end-users will use it daily?
Do similar products already exist in production?
The end-users are the people who will use the product once it is deployed to production, so it is vital to think like an end-user when you are testing? By asking the above questions you can put yourself in the end-user’s seat and form more adequate test cases.
Bugs/Defects
Usually, no application is 100% perfect after the development phase. Your job is to find all of the bugs and defects as early as possible. Don’t be afraid to break things. If you can find a way to break an application there is a good chance an end-user can do the same. Make sure you track all of the bugs and defects that you find. Make sure you document the process that you took where you found the bug so that other people can reproduce the bug and false see it.
Once the bug or defect is fixed and redeployed make sure you not only test the functionality that was broken but should also retest the other core functionality to confirm that the fix did not have an adverse effect on other parts of the application. Make sure you are comfortable with the fix after testing before getting your approval and sign off.
Prioritize testing order
Depending on the methodology that your team is using, you may have tight deadlines for your testing. Make sure you are able to prioritize the different parts of the application that is being tested. The complete application should have test cases, but if one particular portion will have higher usage, make sure you are spending adequate time thoroughly making sure no bugs exist. Also, once bugs and defects are found you can help prioritize if it would be something that should be fixed immediately or can be fixed after deployment(you must document the defects either way).
This is when knowledge of the application is very important. For example, a new calculator application is being created that offers addition, subtraction, and multiplication capabilities. The target audience is first graders who will use it 99% of the time for addition and subtraction. What features do you think should have the highest importance? Obviously the addition and subtraction features. Scale this simple example to other applications that you may encounter in the future.
Comments