Testing

November 17, 2014

These are the bugs that haunt every tester’s nightmares

A software testing professional’s worst nightmare

There are several extreme testing situations in which testers find themselves breaking into a cold sweat either because they’re badly under-resourced or because crucial elements in the testing process simply fail to come together. In this article, I list 10 nightmarish testing scenarios which every tester hopes they’ll never encounter in their work.

10 nightmarish testing scenarios:

1) The bug can only be replicated under very particular circumstances

Like any scientist worth his/her salt, a tester will repeatedly test a buggy program under a variety of conditions in order to narrow down the range of possible causes of the problem and eventually pinpoint a specific one. Unfortunately, some bugs can baffle even the most zealous testers when they are triggered only under extremely particular production conditions that cannot be recreated in the test environment. A bug report that can’t be reproduced is seldom going to be fixed by the developer.

2) The odds of the bug occurring are low, but if it does the consequences are serious

Some bugs strike fear in testers’ hearts not because they occur frequently but because they are so rarely encountered that it’s is difficult to accurately classify and describe them. It’s even worse when these ‘unknown’ wildcards can have catastrophic results on the finished product and the users’ experience when they do eventually show up. Like in the first testing scenario mentioned, testers have to rack their brains in order to come up with different and creative approaches to reproduce the bug and pin it down in their reports.

3) The bug is a logical error that happens at a very late stage

Some bugs lie hidden in your software only to rear their ugly head well into the running time and force you to retrace every step that led up to their occurrence. These situations will test your patience as even the most simple bug will require the team to plough through layers of code before finding the offending part. Bugs found late are associated with a much higher risk for failure. This is exactly why it is so important to start testing at an early stage.

4) Working on an unrealistic schedule

All too often, the problem lies not in the software but in the people the tester has to satisfy. Having to work to unrealistic schedules to please a client is not only a stress-inducing experience for the tester which impact the quality his or her work, but also a lack of appreciation of the effort that goes into bug reporting and testing. We’ve already talked about how to estimate the time that should be spent on testing software. In an agile context the team takes responsibility for testing as well as for coding.

5) Having to deal with untrained resources

Another people problem that most testers will encounter during their career is having to deal with untrained personnel. These can take the form of an intern who’s still wet behind the ears or colleagues who, though knowledgeable in their area expertise, did not receive adequate training in the systems use by the organisation, as well as it’s core values. Both will take up your time as you find yourself stopping every so often to explain how something should be done or, even worse, step in and do it yourself. When new people are added to the team, take the time to go through the test management tool. When it comes to ReQtest the tool is pretty much self-explanatory, but you might have to go through how bug reports are to be written and how to make best use of test cases, checklists and test runs. This is a small investment that makes for large value later on.

6) Not having a good test management tool

Sometimes you are expected to do testing with no tools at all, or to be precise, just Word, Excel and Outlook. This is like handling accounting in Excel. Nowadays tools are inexpensive and will provide a huge benefit. A tool such as ReQtest helps you manage testing, regardless of whether the team sits together in the same office or is distributed across offices over the world. The build-in agile board facilitates communications between the team and other stakeholders such as the customer, management and other teams.

EXTRA: Check out ReQtest, our very own bug reporting and testing solution to find out more about the benefits and features that specialised software offers to testers and their teams.

7) Bad management

Testers are increasingly being called upon to take on a leadership role in their organisations, particularly those that embrace Agile principles. However, testers still have to report to someone, as well as coordinate their efforts with their colleagues in other departments. Bad management means that this complex web of human interactions cannot be sustained for long enough to see the product finished, or if it does get that far, the final outcome is subpar. Bad management decisions generally arise when people don’t understand the needs of the team members and testers are forced to work in the shadow of someone else’s ego.

8) Lack of or ambiguous requirements

Another spine-chilling scenario for testers is when they are presented with no pre-defined software requirements, thus either having to work them out by themselves with hindsight alone, or else go straight to the product owner or scrum master and ask them to clarify their goals for the software being developed. Having to carry out testing based on ambiguous requirements is probably an even more terrifying scenario as you may end up actually spending time doing work which could ultimately be useless.

9) Important stakeholders not present

One of the key factors in good teamwork is the presence and input of the stakeholders at every stage of the development process. This needn’t happen physically; keeping open channels of communication between stakeholders virtually will also be enough in most situations to sort out any issues as they arise. When key people are out of touch with the project, mistakes that could have been avoided or resolved early on can transform into deep-seated problems which will simply burden testers with extra work.

10) Poor communication

Tying in neatly with the above, it is pointless to have open communication channels if the quality of the communication between people is poor. We’ve discussed the importance of good communication practices before, as well as methods to resolve conflicts more effectively by adopting less hostile and judgemental communication patterns.

Conclusion

If just one of these tough testing situations is a big enough challenge to test the mettle of even the most experienced professional, can you imagine the horror of coming across a situation where you have to deal with two or more of the problems listed above at once? The very thought makes me shudder!

Do you have any testing-related horror stories? Were you unlucky enough to have experience one or more of the situations in the article? Share your experiences of dealing with tough bugs in impossible circumstances in the comments section below.

Share article