Top Dos and Don'ts for Software Testers

As we all know by the time a software development process approaches the final stage, it needs to go through numerous tests in order to make sure it is free of bugs, able to handle a load and ready for use.

For example, in load testing, simulated demand is put on a software, a website, or an application such that it demonstrates the behaviour in different conditions. Over the past decade, the significance of testing has skyrocketed.

Testing, that was once very simple, like a pre-deployment exercise to ensure whether a web application works properly has now become a vital part of software development and improvement process.

With more advancement in websites and web applications, testing is becoming more challenging every passing day. Though it is conducted since long, mobile and web apps still seem to be overwhelmed with traffic.

So, it is very important for the software tester or test engineer to focus closely and work towards breaking the software or product from the initial to the final stage of the application building process.
This post will concentrate not only on testing a web/mobile app or software but also the tasks associated with testing like spotting defects and configuration management. So let’s get started!

Dos:

• Make sure that the activities involved in testing are in sync with the test plan.
• Recognize technical areas where you might require assistance or training. If required, you need to come up with a plan and arrange for such a training to ensure that the issue is solved.
• Strictly obey the standard testing plans as identified in the testing strategy. Follow the given guidelines as per the test plan documents.
• Must have the documents showing the release notes. This can be availed from the development team. Those documents contain all the details associated with the release that was prepared to QA for testing. This usually contains the following information:

1. Code version for testing.
2. Features of the product that will be a part of the release.
3. Features that will not be a part of the release.
4. New functionalities and features added (if any).
5. Changes made in existing functionalities.
6. Current issues, and so on. 

• They must stick to the entry and exit rules for all the testing abilities. For example, if the criteria for input of a release is sanity tested code from the development team, the tester should ask for sanity test results.
• The tester should update the test results for all the test cases during run time. This should be done as and when it is executed.
• The tester should report the faults found in the tool used for defect tracking outlined in the test plan.
• He must make sure that the codes are version controlled for all the releases.
• He must categorize defects in levels such as P1/P2/P3/P4 or Critical/High/Medium/Low in order to aid the developers fix the defects in priority. 
• Conduct sanity testing right after the release is made from the development team.

Don’ts:

• Don’t update the test cases during execution. The tester needs to track the variations and update according to a written reference (like a SRS or functional specification). It is not the right way to update a test case on the basis of the application’s look and feel. It may also happen that the UI could change with time. So each and every scenario should be documented in accordance with an approved document.
• Do not look for faults in multiple places be it, in the excel sheets or other defect tracking tools. This will probably increase the tracking time. Hence it is better to use one single centralized repository to track the defects/faults.
• Do not waste time concentrating in feature testing which is an exclusion from the current release.
• The testing should not focus on the non-critical parts (the tester needs to think from the customer’s perspective).
• Do not assume anything while attempting to verify the fixed defects. In a case of confusion, you must clarify and close the ticket post clarification.
• Do not jump in to update any test cases without running them on any previous assumptions that worked in a previous release(s).
• Do not concentrate on negative situations only. All it will do is consume your time whereas it is least used by the end user in practice. Although there comes a time when you have to test it at a point of time but you need to prioritize tests at any cost.