Feedback Is Your Golden Ticket

I have had some very interesting conversations over the past few weeks with testers wanting better access. More specifically, testers who are eager to really get more involved with upfront planning in their projects, and even their sprints. In most of these conversations, I am hearing a lot about their involvement in the meetings they are attending, and inevitably the list of meetings that they are aware of, but can’t secure a spot at the table. On each occasion, our conversation immediately starts with targeted thoughts on process. Generally, we find a way to start discussing “how testers are seen”… and at some point I end up asking: “Can you tell me a bit about how you manage feedback?”

Tester: “You mean… like 360 feedback requests? From HR?”

Me: “Oh I do apologize. That does sound like what I asked. What I meant was, can we have a look at some of your feedback you provide to your developers?”

A (Super Quick) Note About Test Reports

Now… before anyone starts taking notes or making a list, I would like to point out that our friend the internet already contains a MASSIVE amount of excellent literature on what goes into a good test report. I do not want to get deep into this here. I will limit myself to the idea that anything can be considered a good test report strategy if it is:

  • Visible, and Accessible… I would think to go look there, and quickly find it when I need information. It could be visual, verbal, written... I don’t care. I just know how to find it quickly.
  • Timely… It represents information that is relevant to decisions I am about to consider (or should consider) now.
  • Valuable… It provides me information that might impact my approach to the decisions I am about to make and/or the work I am about to do.

I am choosing to stop here. Clearly we can list more, but I would like to focus less on the content of test reporting, and more on the following questions:

  • “Why would <x> want to read/view/hear your feedback?”
  • How does the answer to this question impact the meetings and discussions <x> might invite you to?

This being said, while everything in this post can certainly apply to test reports, the feedback you provide does not need to be formal. The best relationships are built individually.

A Friend In Need…

Before we try to tackle the two questions that I asked above, or even assign a name to <x>, I would like you to imagine the following scenario:

  • You have either just written your first ever blog, or possibly a new blog that is deeply personal to you.
  • You ask me for my feedback.
  • I send you back a list of typos, and a comment about your choice of grammar in paragraph 5
  • I then summarize the time I spent doing this, and the approach I used.

What are the odds that you will ask to spend some time with me when considering writing your next blog? I might imagine that you may reach out to me to proofread it for spelling and grammar before hitting publish, but I have a hard time believing you would be motivated to call me up to discuss an idea, and share with me what you are thinking about. Did I offer any evidence that your ideas might matter? Even if I did come up with some stellar catches on misquotations, or some insight on where you created a logical contradiction… I offered zero feedback that might link to the experience of reading your blog… whether it was a good thing or not.

Back To Testing… And Relationships

I have used the blog feedback analogy a few times now, and it seems to resonate with testers. We do understand feedback. We crave it. Our role often can feel immensely isolating and unrewarding without it. Well… So do our friends who spend their time writing the code we evaluate. Let’s take a minute to examine our own feelings from the analogy above, and try to explore the sort of feedback that a skilled tester might provide that can be exceptionally accessible, timely and valuable to a developer.

Scenario: The team was tasked with building an entirely new workflow to streamline the creation of an account on your company’s monthly fee service. Product has told you that we were losing over 50% of our users during sign up, and when we asked why people dropped off, we were told that the sign up seemed to be “endless, confusing and flaky”. We were given the incredibly specific requirement “Make it faster, easier and not suck anymore”.

(Personal comment: I really wish that last part felt ridiculous and unrealistic)

One of the developers on your team has just provided you with their first stab at the new workflow. We could mine it for bugs and record a list of every issue we found (as soon as possible). Trust me, this IS accessible, timely and valuable. But what else? Some other dimensions to consider that potentially offer immense value to your friend the developer:

  • How was the sign up experience? Play the role of a new potential user (if possible find someone at work who has not tried the sign up process)… and offer real feedback on the experience.
  • Do not focus solely on the pain points… highlight the aspects that were amazing as well. “I really felt the capturing of my account information was incredibly intuitive, and I appreciated being able to constantly see my progress on the side”. Bring attention to details that you felt were really engineered well and you felt you appreciated as a user.
  • Provide a contrast with the previous workflow… remember this is how it will be measured. Is it BETTER? Why? Why Not?
  • Contrast it with similar products or services. This sort of research can help the developer consider their approach against existing established models.
  • Identify where some dimension or approach within this new workflow might be applicable and helpful in planned upcoming areas of work.
  • Where you discover usability to be a tad confusing on first pass through, describe the associated feelings at different phases. Ask others to attempt the same thing to see if your experience was unique or common. Perhaps speak to customer support representatives to see if they can provide some insight. (Many workflow issues never get logged. They instead become an ongoing operational cost at the support desk)
  • If there is a chance that the new account creation flow will be highly interoperable with other planned work, or needs to work with work going on with another team, offer your thoughts on how that might be best accomplished in the upcoming sprints to provide the developer with that feedback sooner than later.
  • And most importantly… Ask if there is any feedback or information that you have not touched on that the developer might find useful, or if there is anything that they might want more feedback on with deeper more extensive testing. This can be a “right now” thing or a “going forward” thing.

Boosting <> Placating

Related image

The tone suggested above is intentional. It is supportive. Assume that your developers put pride in their work, and offer them the sort of feedback you would enjoy if you submitted something you laboured over and deeply cared about. We are assisting one another to succeed… make that obvious. This is not to take anything away from the skills and mastery of testing. The critical thinking and approaches that go into discovering complex/hard to discover bugs should still be something you should highlight. Demonstrating the research you have done to help provide comparisons and contrasts, and market expectations only strengthen your case when you have strong suggestions about potential changes.

However, by focusing on feedback that contributes to a developer’s overall ability to reflect and to succeed, this moves you away from being considered a “downstream validation service once code is written” and towards “a colleague with whom I can share my concerns, and who offers the sort of feedback that might help me craft a better solution”. From there, it really is not a big jump to ideas like inviting you to pair during development, and to participate in strategy sessions and high level design discussions.

Let your feedback demonstrate your potential, and indicate your interests in project involvement. Build the relationships you wish to foster on your teams by providing the sort of feedback that helps people see what you can offer if given the chance to be part of the right conversations. Nobody is going to shift you left unless you help them see why it would be a great thing.

So… start today. Show’em what you got.

Martin (马丁) Hynie

Written by

The world is a simple place. We often pay people to make it sound complicated. Me? I just want to build cool things with cool people.