5 Most Common Ways to Screw up Test Management
Test management is a difficult task that requires a certain type of individual. More than that, though, it requires someone well versed not only in...
Test management is a difficult task that requires a certain type of individual. More than that, though, it requires someone well versed not only in best practices associated with testing, but also in worst practices- what doesn’t work, in addition to what does. Since this component is easy to overlook, we’ve outlined what we consider the five most common ways to mess up the test management process, and how they can be avoided.
Improper test management has far-reaching consequences: difficulty for testers, confusing results, and complicated or useless test cases, to name a few. While it takes many characteristics to make a good test manager, it’s important to also consider what makes a bad one; often, they’re someone who is careless or neglectful about avoiding the above aspects of the test management process.
- Not sorting/naming consistently. When a test case or execution is complete, it must be stored so that testers and developers can go back later and make use of the information it contains. A necessary part of the storage process is naming and sorting the test cases, making it possible to go back and reference it later in the cycle or in future cycles. Skipping this vital step means that test cases just end up in an unusable clump; without organization, it’s impossible to use the data you’re creating, rendering it totally useless.
- Neglecting traceability. In software development, traceability refers to “the ability to link product requirements back to stakeholders’ rationales and forward to corresponding design artifacts, code, and test cases.” If you want to see which requirements are satisfied, traceability is vital. Similarly, not assigning defect reports to their proper test cases will also negatively effect traceability, as well as inaccurate.
- Decentralization. The left hand isn’t doing what the right hand is. In fact, the left hand has no idea what the right is doing, or what they’re working on together, or if they’re actually working together, or really if the right hand’s even there at all. The right hand is a thing of myth and mystery to the left.
That’s what a decentralized system is like for testers. No one person can figure out what’s happening to the system as a whole; the big picture is totally invisible to them. A decentralized system can cause redundancy and overcomplication of tracking down border issues. Which leads us to…
- …overcomplicating the fields in defect reports. This can be through the use of non-standardized defect reports which confuse the testers as well as the developers. If there are too few options, the data is unclear; if there are too many, the data will still be vague (maybe because the testers is unsure which information goes where, or just because our minds tend to shut down when we have too many options).
- Not adding new test cases by cycle, just referencing them afterward in the test repository. When a test case begins, it must be added to the test repository before any of the executions start. This can be organized in a plethora of ways, such as by test case, functionality, etc. However you decide to organize them, it’s important that they are all stored where they will be searched for; storing test cases in a remote location requires a wild goose chase of link-clicking through reference after reference to access the information.
The first downside here is that it’s ridiculously inconvenient. Secondly, this can sometimes create a central script repository which is simply an amalgamation of other test cases, instead of information which may actually be more relevant; as it stands, it’s difficult for putting test cycles together and finding necessary test cases, both of which are pointlessly lengthy and confusing for everyone involved.
Improper test management has far-reaching consequences: difficulty for testers, confusing results, and complicated or useless test cases, to name a few. While it takes many characteristics to make a good test manager, it’s important to also consider what makes a bad one; often, they’re someone who is careless or neglectful about avoiding the above aspects of the test management process. Keeping these common screw-ups in mind results in fewer errors, added ease, and less confusion both during the test cycle itself and afterward.