A Collection of Suggestions I Strenuously Resisted

As soon as I started working as a tester, I knew that this was what I wanted to do for the rest of my professional life. Being completely inexperienced in software development, my idea of testing was that its purpose was to find bugs. Oh and I loved finding bugs. Starting from gaps in the requirements, to functional bugs, to inaccuracies in the documentation, to missing identifiers of texts that needed to be translated, I was there, creating my bug tickets. Life was good.

But alas, my manager and senior developers thought that I could contribute more to the quality of the product by doing additional activities, beyond just finding my beloved bugs. Here is a collection of suggestions that I received, which I initially, emphatically,  denied.

Provide test ideas to developers before they start coding

The architect of the project noticed that I could spot gaps in the user stories as soon as they came in the backlog. He suggested that I add my testing ideas in the story, so the developers could take care of the pitfalls before they even started coding. I was outraged! If I laid out all of my ideas, how would I find bugs? If they wrote good software, how would I ever be happy with no bug to be found? I even had the audacity of contradicting him. He smiled politely and let me sleep on it, until I came to my senses.

Share my knowledge with the rest of the team

Not only were the developers interested in having my test ideas beforehand, even worse, they wanted to know how I came to think about them. They wanted to learn how to do exploratory testing efficiently and I was supposed to be the one telling them all of the testing craft’s secrets. I was not thrilled with the idea, nevertheless I paired with them for a couple of timed sessions and we found many issues together. We also discussed how a bug ticket should look like, so that it is easy for everyone to understand its importance and resolve it in a timely fashion. Eventually they became quite good at it, leaving me with even less bugs to find. At least, I had a hidden sense of pride for my “students”.

Merge bugs and enhancements into a single list

Another outrage. My well thought of corner-case bugs in the same bucket as things like “change colour of button from #4286f4 to #2977f4”. I half-heartedly accepted and agreed to have a look at these enhancements, reported by all sorts of people, from developers to sales colleagues. What I found out was that most of them were valid points that would significantly increase the good adoption of our product, sometimes with minimum effort. That gave me another perspective of how to approach testing, going beyond finding problems and looking into ways to actually improve our service.

Talk to people from sales

Another waste of my precious time. I knew what they would tell me. More features released faster, even if they were functionally incomplete, because this was what the customers wanted. In a nutshell, I thought that my job was to ensure that the customers got software that worked and not if what they got had any value to them (I wish I had come across Alberto Savoia’s “Test is dead” presentation much earlier than I did). After the first discussions, I reluctantly started seeing the error of my ways. Even if I couldn’t make any decisions on how features were prioritized, it sure made a difference to my testing approach, understanding what things the customers found important. What their resilience to failure was and how long they allowed for a fix. What their business was like and how our product could serve it. I swallowed my pride and admitted defeat yet again.

In all of the above cases, I embarrassed myself by either loudly refusing or grumpily accepting to even consider anything that was out of my testing comfort zone. Luckily, with approaches for creating quality software like Modern Testing becoming popular, most of the ideas I resisted are becoming mainstream. Will there be more things in the future that I will resist? Sure! Have I learned anything from my mistakes? I did. Developing software, and testing as part of it, is a creative process fulfilling the people that practice it. But if you don’t share your craft with the rest of your team and don’t listen to the people that consume your work, you will inevitably be left behind by both.

Have you Tried Turning it Off and On Again? – Appreciating Your Customer Support

A long time ago I was working in customer support, spending my days speaking to unhappy customers who had purchased some sort of electronic device. People generally didn’t pick up the phone to tell us how pleased they were with their purchases. Sometimes they would call to ask for a technician, others to ask how to properly use their machines. And of course, there were the ever fun moments of somebody simply yelling and venting about their faulty product.

Writing tickets about these incidents addressed to the company, I was wondering about things like “Don’t they see that step x of the manual doesn’t work?”, “How hard is it to make a note telling us how long it will take to be fixed?”, “No, YOU tell the customer that it is normal for the machine to make a buzzing sound, loud enough to be heard next door”.

Years later, working on the other side in a development team, I thought about my frustrations from my customer support years. The last thing I wanted was to make the same mistakes I had been complaining about. So, here are some of the measures we put in place to get the most from the customer support’s expertise and knowledge and to enable them to provide better solutions for our customers.

One backlog to rule them all

All issues coming from customer support requiring technical assistance were logged in the development backlog. The only thing that distinguished them from a “normal” internal bug ticket was that they were marked with a “support” label. Filtering on that label made it easy for the product owner to assign priorities to them or even turn them into new features. Another benefit of having support tickets in the development backlog was that it improved the transparency of the efforts put in developing new functionality versus fixing existing issues.

Make backlog accessible to support

We gave customer support access to view the development backlog, so they could follow the resolution of their ticket. Instead of having a generic comment on their plate like “working on it” or “TBD” they could see the priority given to it as well as the work it took to fix it. The more details you have on the history trail of the fix, the easier it is to convince the customer that their problem is being addressed. Urgency is perceived differently by customers than production teams.

Support ticket – Handle with care

We agreed that support tickets needed to have a higher degree of information than the average bug ticket. If the ticket could be closed because the software “worked as designed”, we needed to point out where this was documented, so that the next time support could point customers to that. If it was not documented, we needed to provide solid arguments why the implementation made sense. When an issue would take long to fix or be addressed we needed to add some justification of our actions. Preferably, something that we wouldn’t be embarrassed to say out loud ourselves.

Rotate developers handling support requests

Each week a different developer would take care of the support tickets. They could handle the situation themselves, or assign it to another team member that they thought would be more efficient in resolving the situation. This was beneficial because everyone from the development team got to see what issues from real users looked like. Developers would also think about what kind of information they would like support to add, so that fixes would be faster, improving the support lifecycle.

Analyse customer support requests

Besides the obvious bugs that people reported, we took time to analyse the issues that customer support handled on the fly and never reached development. If people would call for the same problem over and over again and support would help them solve it over and over again, why not take care of it and make everybody’s life easier? Besides that, closed support tickets sometimes contained excellent features ideas. Customers might not actively get in contact to request a feature but might drop an idea or two while waiting for their problem to be fixed.

Keep support in the loop

One of the worst situations that you can get in as support, is to have a customer ask you questions about a feature you are not even aware it exists. Sometimes you can swing it with a “please describe to me what you see” and then hope you can improvise something based on previous functionality. To avoid this situation, before releasing a new feature we would first enable it for our support (we had toggle switches in place) so that they could try it out and be ready for customer questions. We also asked them to note down anything positive that the customers noticed to have a better understanding of what people like. As a bonus, their feedback provided a good usability and acceptance test.

Respect customer support

If you measure your product’s quality by customer satisfaction, you probably want to have the people that talk to your users feeling respected and valuable. This is especially the case when customer support is outsourced and doesn’t have an invested interest in your product’s success. Take the time to listen to the people that deal with the end users of your product and learn from their experience. Give them a channel to communicate the difficulties they face and what they need to improve their work. Create an environment of trust so that they can provide an honest feedback to you and how you handle your support requests.

Nowadays, we would have more automation in place to improve our customer support. Maybe training an AI system to triage tickets or to even provide automatic responses to common requests. To extract behaviour patterns from existing tickets and help define new features based on them. But will customer support be completely automated? Forrester’s top customer service trends for 2018 sees a decrease in the number of support agents employed, nevertheless predicts that there will still be a need for highly skilled professionals to handle difficult customer issues. So improving the collaboration between customer support and your development team to create super agents that care about your product might not be a bad idea after all. Heck, they will be the ones that your AI system learns from.