Don’t Let “Try It Now” Impede Your Test Initiative
Software issues are typically resolved through a well-organized, well-documented process by entering them into a defect-tracking database.
However, sometimes environmentally based issues arise that impede your ability to access or test the software. Rather than addressing the problem methodically, as with defects, testers often attempt to solve the problem on their own, initiating an investigation by contacting various people, notifying them of the issue, and waiting for the appropriate person to determine the issue’s cause and apply its remedy.
This will inevitably result in chaos and being told repeatedly to “try it now.”
However, from a long-term perspective, the objective is not getting the problem resolved, but rather not having the problem occur in the first place.
These types of environmental issues can be due to procedural inadequacies or any number of infrastructural problems, and they may appear after software deployments, hotfixes, or patches. You may see these kinds issues after server caches not being cleared or refreshed, proper software components not being deployed, servers not being restarted, log files becoming too large, permissions and load balancers not being properly configured, authentication issues, database scripts not being executed, memory issues, enterprise application platforms not being restarted or being in an inoperable state, and database changes not being deployed.
The bottom line is that your testing is impeded—you’re unable to begin or continue testing, and you may even need to start over once the problem is resolved.
There is a finite amount of time allotted for testing, and if that time is lost due to software inaccessibility, it could result in other test activities being compromised. Therefore, software inaccessibility issues should be reported and handled just like any other software-related defect.
This means logging the issue into the defect-tracking database. Enter the problem as a defect each time it happens, under a category separate unto itself, and include all relevant information. Identify the problem, as well as any other pertinent information, such as how much time was lost due to its occurrence, how much time was needed for the issue to get fixed, resolution date, and how much time was needed for reinitiating the tests.
By entering this information into the defect-tracking database, it will be well-documented and easier to follow up on. It will also give the rest of the team a clear picture of the situation. Allowing everyone to see that testing is being delayed due to inaccessibility problems beyond the tester’s control can help facilitate the most appropriate course of action for resolution. Also, showing a clear accumulation of the lost time will shed light on the issue, raising the awareness level about the costs incurred, in both time and money, by these types of problems.
Treating software inaccessibility issues the same way as any other defect, and entering them into the defect-tracking database, is a more efficient way to solve these problems and prevent them from happening in the future. The next time you are told to “try it now,” take a different approach that won’t impede your test initiative.
