4 things ISTQB doesn’t tell you

ISTQB (I don’t want to bother you with the full name – you know what I mean anyways) offers a wide range of standardized education in software quality, and software testing in particular, for everyone.

In other words, you can learn pretty much everything there is to know about testing from them. At least in theory.

In practice, you still have to face the reality of software quality and testing in actual software development projects.

Here are my top 4 reality checks I had to face as both a C# Test Automation Expert and Test Manager:

 

In theory, there are very nice process descriptions that show you how to most efficiently integrate software testing into your development projects. In practice, it is even hard to include software testing into projects at all. Although most people (including project managers) understand why testing is such a crucial aspect when you explain it to them, most people (especially project managers) succeed at ignoring this fact when it comes to the implementation of software testing in actual projects. In the beginning of a project, writing some tests might even be considered. But after some time, requirements change, no-one updates test cases, and in the face of approaching release dates, everyone is too busy finishing implementation, marketing, etc. to care about failing tests, anyways.

 

An even harder truth to learn after doing ISTQB training is that in practice, testers are often seen rather as a burden than actual help. I’ve written about that in detail in the first three parts of this ebook series if you are interested. In its essence, the problem is that the setting in most software projects makes it very hard for testers (including test automation experts, by the way) to do their job. Most of the time, this leads to testers discovering the blind spots in the implementation process of a project that everyone tries to ignore as long as possible. So, why pay people to tell you what you don’t want to know? Especially if you don’t care about testing, anyways (see previous reality check)?

 

In ISTQB trainings, you learn that for each test case, you have to define execution steps, as well as an expected response (expected result) from the tested system. Therefore, you need to have reliable information about expected behavior of the system in particular situations, i.e. requirements specifications. In practice, however, this information is not easily available. Clients, who would have the domain expertise to tell you what is true, usually don’t bother telling you – and can get pretty annoyed if you keep asking them about it. They simply want to have the job done – not caring about you needing information on what the job actually is. And in general, people (in my experience) simply lack the expertise for properly defining requirements. And even if they do, they do it at the start of a project, but don’t bother adapting requirements if they have changed. So as a tester, you can NEVER rely on information, simply because you found it somewhere stored as “requirement” – there might be two other “requirements” contradicting this information – and these requirements might be just in the head of some developer, but never actually been written down.

 

Why is the above point so relevant for software testing in practice? Because you can’t write tests unless you have a proper specification you can base your test cases upon. Otherwise, what is it you can derive if you tests fails? Or if it doesn’t fail? You don’t know whether this is the case because (i) the system works/does not work as expected, or (ii) you have a different understanding of the requirements than the developer. And in the second case, you also can’t easily verify whose understanding is correct. In other words: is the tested functionality a feature or a bug (the developer will most probably try to convince you that it’s obviously a feature). So, what is the point of testing in that case, anyways?

 

Do you agree with these reality checks?

Do you have something else to add from your personal experience?

Let me know in the comments section below!