Avoiding Blunders that will Hamper Your Testing Efforts

Member Submitted

The author has compiled testing blunders that can undermine a company's testing efforts. This article offers insights and recommendations for avoiding many of these testing problems. He focuses on seemingly trivial issues such as naming conventions or collection of testing metrics, as well as on identification and classification of testing data. You can use these insights to avoid planting the seeds of major problems.

Missing Naming Conventions–Nomenclature
I recall a project that had automated over 1000 test scripts from various testing releases but did not have any structured naming conventions for the automated test scripts, or for naming the test folders where the automated test scripts were saved within the test management tool. This project had difficulty finding automated test scripts from one release to the next within the automated test management tool, and often times the testers within this project re-develop automated test scripts that already existed since the existing automated test scripts were difficult to find within the automated test tool. One of the objectives of having automated test scripts is to be able to re-use them as much as possible from one software release to the next and this project was forfeiting this benefit since the testers could not find the previously automated test scripts.

A test management tool serves as a repository for storing test scripts and test cases, but its utility will be greatly diminished if the QA team does not enforce a rigorous and logical approach for naming the test scripts and the naming of folders where the test scripts are saved. A viable approach for naming test scripts would be after the business processes that they represent or requirement identifiers that they represent. Below I describe an example for naming test scripts and test folders based on business processes related to human resources tasks. Regardless, of the approach that a project uses to name test scripts and test folders the naming standards should be robust, rigorous, consistent, resonate with the testing team and be widely accepted by testers and process teams.

If one is testing a human resource application one could create folders representing the various business processes associated with human resources such as recruiting, payroll, benefits, performance appraisal, training, organizational development, etc. Once the folders names are created and named the subfolders are created that have names that demonstrate more specific granularity for a particular human resources business process. As an example under the recruiting folder one could have subfolders for reimbursements, resumes, status of applicant, interviews, etc. Within the subfolders the test scripts are saved and stored with proper sequencing, release name, and identifiers as part of the naming conventions (i.e. HR_Recruit_Status_Rejected_releasename_001, where "rejected" represents a candidate who was not hired).

The business process teams and testers should thoroughly understand the naming standards and the naming standards should be enforced as part of the QA standards and procedures. Any saved test script that does not follow the project's naming standards should be removed from the test management tool, or renamed until it is compliant with the project’s naming conventions. Naming standards help to ensure that test scripts can be tracked, maintained, and reused once stored within a test management test tool.

Inconsistent terminology
I have been in projects where testers and test managers have problems communicating with one another because each party is either using the same terminology to describe different testing artifacts or different terminology to describe the same testing artifacts. As an example, in one project that I consulted for the term "mega testing" meant the same as the term "integration testing" and some testers within this project used the term mega testing to describe integration testing while other testers were not acquainted with the term mega test and only used the term integration test .

Test managers and tester should have consistent definitions and terminology for referring to the same test artifacts for instance a test script is not the same as a test set, and a test case is not the


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.