You can’t test everything.
Had a case, that reminded me of this today and wanted to share this “tidbit of wisdom”.
It’s not a suggestion to not test, because you can’t test everything, no. Testing is your friend, whether it’s a code, an assumption during a tech investigation, or some crazy idea for a startup. But similar as I preach It’s ok to not know something
to tech supporters, I would preach You can’t test everything
to testers. Let me explain why this thought is important.
I have a library, called HTMLCut. It cuts the HTML text, so that you can have some “text preview”. You can see it live on this very website, where I use it on main page to show previews of the posts, I’ve made. I created it, because when dealing with HTML you can’t just substr() or do anything similar. If you do, you will risk corrupting HTML, and at the least, that can make your text look weird or even corrupt the layout of the whole website.
I did test it long ago when I initially created it. When I reintegrated it into my current website, I also made some minor adjustments, but I thought, that otherwise it was working fine. Until I made a post today. Somehow, it got cut to an empty string, which was not expected.
I won’t lie, I am still not entirely sure I understand what exactly was causing this issue for this particular piece of HTML, but not for anything else, but I did find a flaw in my code and implemented a fix for it. But that’s not the point of this post.
The point is, that in some “business environments”, if something like this would pop-up and affect a business process, the “Blaming Game” would begin. Blame can fall either on business testers, tech testers or devs, but it will go something like this: You have not tested enough!!!!!!111!!!!oneone!1!
. Hence the mantra: “You can’t test everything”.
Your manager or some business unit, hell, even CEO of the company may say whatever they want in this case, but it is important for you to know, that this is not your fault. Well, unless, it was a very obvious test case, that you did not include in your test plan. In this case, it may be your fault. To an extent, at least.
But even if it is, for the sake of your own sanity, you need to accept, that you can’t predict everything. Yes, a good test plan will include edge cases, but as mentioned above, - obvious ones. Sometimes you just can’t know about an edge case, until it actually happens. Or it may not be an edge case, but a complex combination of several conditions, and the more complex the system – the easier it is to miss something, which may result in an issue some time down the line.
If you start blaming yourself and tearing out the hair from your head every time this happens – you will go bald pretty fast. Thus: You can’t test everything
. You are only human, you were not able to predict this combination of conditions, it happened, you learnt about it – add it to test plan, if possible, and move on. Unless you do want to go bald, but I believe there are better ways for that.
