Software testing is not…

Reading Time: 7 minutes

Software testing is not … part 2.

Software testing is not … part 3.

Software testing is not… finding bugs part 4

Software testing is not … playing. Part 5

Software testing is not … easy to explain. Last part.

This post might be considered  a follow-up to Outdated testing concepts, but with it I’d like to switch the perspective to a bit more general view.

After the above mentioned series were published, I went through a lot of feedback, comments and other non-related articles and they made me think. How do anyone, mostly non-testing professionals feel competent to give opinion on what software testing is? What’s the reason about it? Well, my opinion is that many testers lack the ability to tell a compelling story about their job(and that includes me, in perspective), we often neglect the need to explain what we do in two ways: we either switch to our software testing lingo and get people confused or frustrated or on the opposite, we agree with what other people say software testing is, which is most commonly brought down to – executing test cases, looking for bugs, breaking the product, playing with the product etc.

How do we talk about testing?

This article doesn’t aim to blame anyone, it’s more of a self reflection of the way I was explaining to non-testers about software testing, until now and what I believe many testers say, when they are asked what do they do. So let’s say you meet a friend from school and you haven’t seen each other in 10 years and he happens to be a doctor, for example, and asks you what you do and you say you are a software tester. In the past, in my experience this conversation looked like this:

Friend: Software tester? That sounds cool, what do you do?
Me: Well, it’s kind of like being a programmer, but I am actually testing the code, not writing it.
Friend: But why do you do it, why does it need to be tested?
Me: Because, we are all human, we make mistakes, programmers as well, I need to take a look at their work and  see if the product we create together works as expected.
Friend: How do you know what is expected?
Me: Well, we have requirements created by our clients and we test it against them.
Friend: And what if it doesn’t work as expected?
Me: In this case, we found a defect, we log it in defect management tool, the programmers fix it and we test again,  to see if fix really worked or if didn’t introduce any other defects.
Friend: Ahh, I see… I think I got it.

I know this conversation might look silly, but I did really had this kind of conversations, so this is kind of a compilation of all such talks that I had. The point that I am trying to make here is, we talk about software testing so often by only mentioning only things like: requirements, “kind of like programming”, finding defects etc. and  in the same time we have so many things left off, that are essential to the quality of testing. And who if not us, should be able to build correctly the vision of software testing in other’s eyes and minds. That’s why I am getting really pissed off by people who are often not involved in testing, but trying to school testers what to speak and how to articulate concepts in testing.

Software testing is not…

And this is how I got to this idea. I want to try and figure it out for myself. What software testing is not, what are all these people telling us that is not true and not relevant to testing professionals and most importantly, what software testing is, which will be the topic of the second part of this series. I believe the part of what software is, is the part that gets often omitted and leads to misinterpretation about testing and it’s nature.

So, I made a mind map and I will try to briefly cover what software testing is not, in this chapter. Some of the things, might cover with Outdated testing concepts, so I will run through them quickly.

 

 

Easily performed by anyone.

This is a lie, and I am totally comfortable to call it a lie. In your experience as a tester you will get feedback from non-testers pretending to be “testing” the product. That will be your project manager, your devs, your CEO, designers, anyone will try to make you believe that testing is a task that everyone can do. They are not to blame, more often they are not doing it with bad intent, it’s our job to set the boundaries of what testing is and who can do it.

There’s two sides that have interest in this lie – one is the companies selling pseudo knowledge, that try to make you believe you can become skilled software tester overnight. The other interested side of this lie are the companies that are outsourcing people and threat them as irreplaceable components. They will try to make you believe that talent and expertise don’t matter as long as you write down your tests scripts in the most detailed way, so the next “clicking monkey” could perform everything you did and hopefully get the same success rate as you.

All of this is wrong, and I encourage you to speak up and tell people who believe one of the above claims, that testing is a structured activity that has a purpose and is not a mindless hitting on keys, that there’s way much more than just playing with the product.

In fact, my challenge for you is, every time you are involved in a project, where you and another “pseudo tester” are testing, please, make sure to show non-testing related people the value of true testing. Make them understand the difference between a tester and a non-tester doing testing (still keeping in mind, I don’t consider the latter one “testing”). Make them understand what a skilled professional is capable of by providing the vital information about risk, information of the product on functional and para functional level, provide the better reports, the better test documentation, the better explanation how the product works and most important, learn to sound like an expert, don’t shy out and don’t let people tell you how are you supposed to test, if they are not related to testing directly. There’s one competent person in software testing and that’s you.
Also see:Outdated testing concepts #1 – Anyone can test.

Fixed in a specific time frame.

If you tell this to your management it will probably give them a heart attack, unfortunately it’s true. Let’s try to recall what is testing all about – it is about gathering information and it is about evaluating risk. When your manager or project manager or stake holder comes to you and asks you “Is there any bugs?”, do you think he or she really cares about the bugs? What they are really trying to ask you, in my opinion, is “If we release the product like this tomorrow, is there a risk for our clients? Is it possible for them to reveal a problem that will harm our credibility as a service or product provider?”.

Having that said, we can also repeat again that testing is activity that can only “show the presence of bugs, but not their absence”. Therefore, aiming to release with zero bugs is utopic idea, you will release with bugs, no matter what, so you better know and not lose your fucking mind when that happens. What can we do better is to know what are these bugs and be aware if they are critical for our clients or not.

From everything said up to this point, it seems estimating time for testing is a wild guess and yes it is. Here are a couple of reasons:

• Since exhaustive testing is impossible, we can’t run “all the tests”.
• Do we know what system holds as information, before we start the process of testing? We might have requirements, but are we sure they are up to date, before we run into an inconsistency?
• Do we know how many defects are there in the system, until we actually discover them?
• Do we know each defect’s complexity, until we try to document it?
• Can we anticipate the appearance of regression bugs?
• Can we predict the changes in parts of the system where we don’t expect them, due to the actions of inexperienced developer or bad system architecture (strong coupling between components, lack of unit tests, lack of following recommended development practices) ?

What can we do when we are asked for an estimate, then? It will be a wild guess, but let’s keep it our little secret, ok? People in management and marketing, people working with digits and pie charts, they don’t like uncertainty. What we can do as testers, though is make sure they understand that testing is process on its own, it has different phases and it shouldn’t get mixed with the development process, e.g. the estimated time for the development isn’t the time in which the product is going to be ready to release, we should make the best effort to inform our co-workers that testing takes time and we shouldn’t try to fit in a minimal time frame that was left for us, but rather ask for a dedicated time for testing.

There are ways in which we can try to minimize the uncertainty in our prediction on how long testing would take:

• Experience is one for sure, the more we test, the more capable we are in order to guess the time to test a system, based on its complexity.
• Which brings us to our next point – knowing the system, the more we know about it, the easier it will be for us to guess the time to test it.
• Knowledge of the scope of the change – which is directly related to the two above, we need to have profound knowledge of the system and be aware what part of it will be affected by the change in order to estimate time for testing.
• And of course, knowing our own process – this is important as well and it should be our first concern, we should know how we will approach the changes, how many meetings we will have to attend to, in order to gather our initial data, how much time we need to write our documentation, if we use one, what documentation will we write, etc, etc.

So, this is for now. The topic is complex and the article becomes lengthy, that’s why I will split it in parts and try to provide explanation of another branches of the mind map in couple of days.

Until then, every comment and opinion on the topic is well come. If you liked it, please feel free to share it in social media. Thanks for reading. 🙂