I read a medium post recently that referenced something @friendlytester said at RTC:
It sparked a lot of ideas for me. This or a variation of this is something I see come up often
How do you stay positive testing when you feel like youâre mostly bringing bad news?
The author of the above post admits to being one of these people, struggling to find the positivity. Some answers to this may seem very obvious but when youâre in that negative headspace, it can be very difficult to see the good.
So my request for you: how would you advise people to bring positivity into their testing? I appreciate there is no one size fits all model but some suggestions for people to try would be an awesome start.
I really do like the idea that Iâm a copy editor. Iâm not telling devs bad news, Iâm making them look good.
Other than that, it can get really hard. I find it really hard sometimes when Iâm the one asking the hard questions and pointing out things that can go wrong, so I try and communicate with my team outside of those things so thatâs not my entire work persona. I also make sure to compliment people on work well done.
Iâm already a very positive person and I have always looked at bugs as opportunities to learn something new. Mistakes are incredibly valuable as a resource to teach others on things to avoid. Reframing is key here its easy to make a problem bigger than it is and its better to just reflect there will be more bugs in the future.
Iâve always felt it was part of my job to be a quality advocate so Iâve never really been negative in my feedback. I actually did a talk at Leeds Tester gathering about a situation back in 2005 where both testers and developers were measured on bugs recorded. Everything became an argument so I dropped âbugsâ and started talking about behaviour and whether it was desirable or not.
Changing the language helped a lot and now itâs habit for me to use expressions like;
Can I confirm my understanding?
This isnât quite what I expected?
Perhaps we could tryâŚ
Could I suggest an alternative?
It may be simpler / easier if we
In all cases they are suggestions of âusâ to do something. I had a conversation this morning about bugs and my dislike with another tester and framed it like this. If the software is under development and therefore unfinished, how can you tell someone its wrong? If you see a building with the roof still to go on itâs unfinished. You wouldnât say thereâs a bug in the house would you?
Maybe not the best analogy but hopefully you get the idea.
One of the things that I try to do is give feedback about the good as well as the bad. For example, âI love the extra feature you added,â or âThis does exactly what I want it toâ (Without following with a âbutâŚâ then the positive loses its positivity).
I get better feedback when my feedback includes questions. For example, the questions in @adrian.stokes post. (I especially like âCan I confirm my understanding?â)
I learned these techniques from a psycologist who encouraged me to use coaching techniques in my every day activities. I mention positives to lift the mood in the conversation, so that the less positive points, âby the way, thereâs a bugâ are dulled. I ask questions to let the recipients of your feedback feel that you are interested in what they are doing.
A great response from @ardesco on Slack:
you arenât giving people bad news, you are helping make sure that when a product goes live everybody who uses it says âWow this is awesome, they must have amazing developersâ Remember if something doesnât work the general public wonât say âWho tested this?â They will say âWho wrote this sh**???â
Really like your phraseology suggestions as those first few opening words are critical to the overall tone your conversation is going to take.
The first one is my favourite because I am not 100% sure what I have found is a bug as it could be built in business logic not documented or my own misunderstandings of the acceptance criteria.
If it is a bug then we (the developer & I) sort it quickly and without too much fuss which is a way I find to bring a positive note to my involvement.
I consciously choose to be a positive tester. Iâm the bearer of the bad news most of the time so taking that role might not seem easy.
Pretty straight forward thing to do is to actually give praise when thing contain few or no bugs. Also quick and nice bug fixes or releases deserve praise.
One of the main things I do is talk to developers as if they were human. I know this sounds strange, but bear with me. Say âGood morningâ and âGood eveningâ. Ask how they are and if you can help them in any way.
These easy things, make you a positive person they like to work with. The work you do, doesnât define you as a person. Decouple the negative work from the positive person.
Another thing is getting involved. Solve an issue âtogetherâ. Demo the problem, think along, help them find a solution. You might not know the in and outs of a programming language, trying is everything. In the same line I talk in the âWeâ-form.
âIf we resolve this and this issue, I think the quality is pretty okayâ. Even when you didnât do anything but point out the issue, you still helped.
These things didnât come naturally to me. But I faked it till it became natural to me and now I do it all the time, with positive results!
This is very interesting topic and here is my thoughts:
If someone asks about the job description of a tester, then most of the people gives a common reply that job of a tester is to find bugs. Nobody would like if someone always find bugs in a decently build product and feel delighted in it.
Anyone can criticize a testing profile. If we analyze the testing process profoundly by keeping apart such likes and dislikes, then we will get to distinguish that such negative opinions are not true always. We, as a tester, are adding positivity into the product development in various manner.
In software testing companies; software testers, QA, QCs are performing the testing tasks & assignments very well and alongside providing assistance to other techies also. It could be module knowledge sharing, technical session, query resolution, for other teams and so on.
Most of the time dev team gets stuck while trying to reproduce issues then testers are there to assist them for example, to setup instances, reproduce issue and verify the fix they have provided.
Team co-ordination also add positivity to the whole organization and prove you as a better resource who always think positively about the organizationâs growth.
If a tester tests the fix whichever is provided and does not go through in around scenarios to find if build is working fine and later-on it proves to be a fatal reason in production that the build is failed. Hence by testing regression areas and making it quality oriented, tester is actually making the product look good.
We should comprehend the negative aspects of testing with a positive prospect, only then we understand that it is mandatory to avoid re-occurrence of future error.
A software tester got negative knockers for finding major to minor glitches while ad-hoc testing. But, it is always good to find bugs prior to production. A bug in production might be the reason for project loss also.
Finding bugs is actually helping dev to polish their build before it is released to client. Hence its a win - win situation for both tester as well as developer.
Our priority should be a positive testing by making negative aspects interesting too.
QA team should use decent terminology while raising issues with dev team (e.g, rather than saying âThis is wrongâ they can say âfew features do not seems to be working exactly as they shouldâ, or while saying âYou missed thisâ they can say that âwe should also include thisâ. This way they can build a positive environment within the organization.