D E V M A T E

Loading

Freepik vectorjuice Illustration - Software Testing
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:
 

1. Most people don’t care about testing.

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.
 

2. No-one cares about testers.

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)?
 

3. Many people don’t care about specifying requirements.

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.
 

4. You can’t write test cases if you don’t have proper requirements.

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!
 
written by Daniel Lehner

Leave a Comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.

Privacy Settings saved!
Privacy Settings

When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.

GetResponse, Google Analytics

We use Google Analytics for marketing purposes. You can disable these cookies.
  • __utmz
  • __utma
  • _ga
  • _gat

We use GetResponse for marketing purposes. This service cannot be disabled, otherwise the website functions will be limited.

Decline all Services
Accept all Services
Get Free Access Now to
9 eBooks!
All about Automated Software Testing
Proven experts
Learn to save up to 75% of your test efforts
Get Free Access Now!
Get Access Now! & Save 50%
Personal Trainer FREE Nutrition Custom Workout App
Get Access Now!
eBook Download
Enter your details to get your free ebook!
All about Automated Software Testing
Download Free Ebook
SUBSCRIBE
MY WEB
NEWSLETTERS
Lorem ipsum dolor sit amet, consectetur adipiscing