We’ve all heard the test vs. dev discussion; that developers think that testers only bring bad news, want to break things or that developers just don’t engage with testers. But is there anything that us testers can we do to turn that around and get more engagement?
Let’s use charisma testing to win people over.
What is charisma testing?
Charisma Testing was initially proposed by Rikard Edgren in the Test Eye as a way to test whether a product has the it factor. The idea is that rather than testing to check for functionality or for negatives (bugs) you instead run sessions to explicitly call out the good in a product. By testing for the charisma of a product you can see how it will satisfy and delight its users and make suggestions for improvements to delightfulness.
So why not do the same thing in our day to day exploratory testing? We could be taking the time to look for the good in what we’re testing and share that back to our teams as a way to help build engagement with our teams.
Positive reinforcement is a reward for doing something well. Remember the joy of receiving a gold star or a “good work” from your parents and teachers? That’s positive reinforcement.
Pavlovian Classical Conditioning shows that positive reinforcement works better to motivate behaviour rather than negative reinforcement. So it follows that if we call out what developers have done that’s awesome it’s more likely to have a lasting effect on code than mentioning what’s bad. This is because negative experiences cause people to shut down, distance themselves and protect themselves, people are less likely to internalise negative feedback and so it’s less likely to affect future behaviours. Saying something positive like “this CTA button is really well designed, it draws the eye and really helped me to know where to click” is much more memorable and is probably going to be remembered the next time that person will design a button.
Uses of charisma testing
- Embedding into a new team – We want to show that testers are working with the developers and not against them. We want to show that we can be pragmatic and are pulling in the same direction, rather than being roadblocks or bottlenecks. Using charisma testing to show the good in what we’re building will provide the team with the confidence that you can celebrate the good, not just bring bad news.
- Winning over developers – Let’s say you have someone in the team who doesn’t see the value of testing. Maybe they’ve had a bad experience in the past or have worked with people that weren’t working with the team. Run a charm offensive by using charisma testing to show how awesome that person is and debrief the whole team with that information; hopefully that’ll win that person over.
- Shifting testing left – Shortening feedback loops means we want to test earlier, but testers can be left out of refinement and planning meetings because they’re a bottleneck. By building confidence in our ability to work with teams and show that we can focus on the good, we can be seen as a trusted advisor and be more likely to be invited to these meetings.
- During crunch – Crunch is hard work and can cause burn out. Additional negativity from raising bugs can just be soul destroying for the team as well as us testers. That’s why I like to also share some good in these times via Ramone’s positive reinforcement corner just to spread a little joy.
- Showing the team off – Product demos to the wider product or to the customer can be made even more delightful if you already know what’s awesome about your product to show off. The sales and product team will thank you for being able to showcase exactly how to delight your customers. That’ll really improve how people perceive you (and testing).
How can we do this amazing thing?
The main way that I’ve run charisma testing is as part of exploratory testing. I create a charter for an area of the system that’s focused on the good such as “Explore the charisma of the homepage with maximum positivity and the web browser to discover all the ways that this page delights me” and timebox that. Once I’ve looked at what’s awesome, I’m able to run a debrief and share that information.
Note: This is a good way to get started on exploratory testing if you’re currently in an environment where that’s not used but you’d like to try it out.
In an environment where we are using scripted tests we can also try to do something similar. We can change up our reporting to specifically call out and draw attention to passing tests, and make reference to things we see during our test steps that felt good to use. As we run through a test script, make additional notes where something looked or felt good to use and then drop a note to say “These tests all passed and additionally I really liked how it felt to log in, it was a really smooth process.”
It works! Tales of using charisma testing
I know these sound a bit like those posts on LinkedIn but I promise these really happened to me!
Story 1 – The sceptical developer
I had joined a new team and didn’t quite get along with one of the developers. He was used to testers who only came to him with problems and said that “he didn’t have time for testers as they slow him down”. I took that as a challenge to win him over. For his next ticket I chose to go on a charm offensive and ran some charisma testing over his feature. I created a mind map that showed all the ways that the UI and API calls he’d implemented were awesome, pointing out all of his good work. In the next stand up when we got to his ticket I said “I’ve found some really important stuff on this ticket and would like to quickly debrief the team, it’s really important.” I could see that developer getting ready to be frustrated…
I opened up my mind map to show a sea of green ticks and positive comments. I relayed how the feature felt great to use and pointed out the design and coding decisions that were awesome.
That developer then asked me to pair with him to help with some TDD.
Story 2 – The time in crunch
I was embedded into a team that was going through crunch, during which we agreed that I’d share issues found via exploratory testing in Slack for immediate triage and fix. I was raising a number of issues thick and fast and could see what kind of negative feeling this was leaving. I decided to share some positive feedback about an awesome fix that’d come in along with a picture of Ramone the Testing Otter ™.
In the after crunch retro I was delighted to hear one of the developers say “That positive note and the pictures of otters really lifted my spirits and got me through this”.
Story 3 – The new developer
I was working with a number of new developers for who this was their first or second job. I ran charisma testing to be able to show them they they were doing awesome work and help to dispel some imposter syndrome. I actually have a quote from one of them below:
“As a developer who suffers with nasty bouts of imposter syndrome, I used to dread discussing my tickets with members of test. The solely negative feedback I’d receive very much affected my confidence in my abilities, and the relationships I’d built with the testers I worked with. Since working with people who carry out charisma testing, I’ve learnt the benefits of chatting with test early, and getting the feedback I need to implement user-centric, sound functionality. Yes, imposter syndrome is still prevalent in my daily life, however, knowing what I’ve done well in some places makes it a lot easier to be wrong in others.”