Trish highlighted that sometimes testers can have a bad reputation, and that’s mainly down to the belief that us testers have a negative mindset… This is something that I have experienced before in a previous role – where developers would moan about me “scrutinising their work”, or “trying to break their code”… Both misconceptions that I believe were brought on by their lack of understanding about what the role of a tester actually involves, and what the purpose of testing is on the project.
Trish then made a great point about testers needing to have a negative mindset for certain testing activities. And again, I totally agree – we have to think of as many unruly ways that we can cause the system to fail. Even saying this sentence can come across as being negative, with the use of the word “fail”.
Additionally, we have to have a bit of a pessimistic mentality sometimes, as we know that there are going to be bugs to find in the code that we are delivered… right?
But on the other hand, we don’t just solely look at the software in a negative manner. We might want to perform “happy path testing”, or “sanity testing” where we are not trying to intentionally find defects, but are trying to prove that the system works with basic simple scenarios. We might wish to do this for a number of reasons – perhaps as an initial test to make sure that a release went well before applying our negative testing actions, or even a simple investigation to make sure than a certain function is ready to be demoed to a stakeholder…
Additionally, testing doesn’t break software… the software is already broken before we even set eyes on it. My opinion (as was Trish’s opinion in her talk), is that testing is a service, where we investigate and discover the level of quality that the software pertains and we deliver this information to the business stakeholders in order to help them make a decision on whether the software is in an adequate, shippable state.
This is what I believe needs to be educated to anyone who has that misconception about the role of the tester being so negative.
Trish made a very good point in that, in a sense, “we are all software developers”. This highlights the fact that we are all contributing to the end goal of having a high quality, working, secure software application. We all play our part in that software being developed to that high level of quality.
So with this in mind, where testing activities need to have an air of negativity about them, and the fact that we should have a positive attitude towards the developers as we work collaboratively with them, I got thinking about scenarios that this might be very difficult and might contradict each other – for example when you have a paired developer and tester combination.
This scenario of pairing with a developer might be tricky as you’d need to apply your negative mindset to hunt out and stress the system in order to find bugs, whilst trying to keep on having a positive interaction with the developer.
I posed this question to Trish, and she offered a good response in saying that it’s all about having a balance and the communication skills to be able to handle this situation. I believe it’s also a great opportunity to influence the developer in how(and when it’s applicable) to think like a tester (i.e. having the “negative” mentality to think of difficult situations that the system is most likely not going to handle well).
It’s definitely a conversational topic that I’m sure will have continued into the night with many of the testers that attended last night! And Trish done a great job in presenting that topic!!