5 Tips for QA Testers
5 Tips for QA Testers
QA testing is crucial in development. By making your work as thorough and efficient as possible, you might make some developers mad, but your customers will be happier.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Our jobs as QA engineers is to test features before they are released in order to keep the product up to the highest standards. Last time we discussed QA testers’ jobs, we humoristically detailed 6 developer phrases that QA engineers love to hate.
This time, we will go over five tips for QA testing to make your work better, faster, and easier.
1. Make a Replica of Your Production Environment
If you want to find out the real problems of the system you are testing, you need to test it in an environment as similar as possible to the one it will be working on. That sounds basic, but many times, testers use environments with different CPUs or load balancing abilities, or they use dockers.
So, if you want to find errors and bugs that might arise during migrations or version changes and want to prevent a situation in which you jam the system’s database and clients can’t work, create a twin environment. It should have the same servers, data structure, architecture, etc.
We also recommend you secure the replica to protect your system and make sure you don’t expose users so that the real ones don’t receive notifications while you are running tests.
2. Determine Your Test Cases
QA testers need to know the product like the back of their hand. They should be familiar with all of its features, including old features, as well the different use cases their customers have. This knowledge enables them to determine what they are testing and how to test it in the most thorough way.
Take the time to learn the system and plan the different test cases in detail to ensure all important use cases are covered and run the tests. If needed, use monitoring systems that analyze the most popular user actions. This will help you prioritize and focus.
3. Decide on the Pass/Fail Criteria for Your Tests
You are now ready to run your tests, but how do you know which results are satisfactory and which aren’t? The pass/fail criteria for each feature, otherwise known as the acceptance criteria, is determined by the Product Manager. As a QA engineer, you should transform those requirements into pass/fail criteria for each test you run. If you’re not sure about the measurements you are setting, go talk to the Product Manager.
4. Monitor Your App Performance
When running tests for different features, you examine components like CPU, memory, throughput, network, and different servers. Each of these system components has their own KPIs.
There are a few application monitoring tools that can assist you in examining these KPIs and discovering bottlenecks. Examples include CA APM, New Relic, AppDynamics, and Dynatrace. Using them will shorten and improve your testing and help you alert about issues faster.
5. Prioritize and Categorize Your Tasks
The era of CI and CD means ongoing releases and updates, which means we don’t have enough time for in-depth testing of every new feature and fix. Therefore, sometimes you need to give up on end-to-end testing.
The best way to deal with this situation and reduce risks is to prioritize and categorize. First, determine the importance of each feature, i.e., its business value. If you’re not sure, speak to the Product Manager. Second, evaluate how complex the testing of each feature will be, i.e., how many resources it will take from you and your team. Then, you can intelligently decide which types of tests to do and when to do them. These decisions can then be reflected onto the development teams and to PM, who can plan their own work accordingly. This will also reduce your own stress levels.
Published at DZone with permission of Jason Silberman . See the original article here.
Opinions expressed by DZone contributors are their own.