What is Nonviolent Communication (NVC) and why is it important in software testing?

Non-violent communication (NVC) according to Marshall Rosenberg is a communication model based on four components: Observing without judgment, expressing feelings, disclosing needs and making clear requests. NVC is important in software testing because it reduces misunderstandings, promotes teamwork and contributes to appreciative communication.

How can the four components of Nonviolent Communication be applied in software testing?

In software testing, the four NVC components help to observe neutrally without judging, express real feelings clearly, disclose needs and take responsibility, and formulate clear requests. This makes communication more precise and avoids misunderstandings.

What role does empathic listening play in the everyday life of a tester?

Empathic listening is central to the successful application of NVC in everyday testing. It means listening fully and actively without interrupting or interjecting your own stories. This enables testers to respond better to colleagues and stakeholders and communicate more effectively.

What are the challenges of implementing Nonviolent Communication in software testing?

One challenge is to overcome the autopilot mode and consistently apply all four components of the CSF. It is often difficult to set aside evaluations or formulate clear requests. Nevertheless, consistent application leads to improved cooperation and appreciative team communication.

How do testers and teams benefit from the integration of non-violent communication in the long term?

By consciously integrating CSFs, testers develop sustainable soft skills, improve team collaboration and create a culture of open communication. This not only promotes the quality of testing, but also the working atmosphere as a whole.

What tips are there for consciously integrating non-violent communication into the everyday work of a tester?

Testers should regularly reflect on how they communicate, actively listen empathically and practise the four NVC components. It helps to consciously take time for conversations and to formulate clear requests instead of vague expectations. In this way, step by step, NVC becomes an integral part of everyday working life.

Nonviolent communication in software testing

Non-violent communication according to Marshall Rosenberg consists of four components: Observations, feelings, needs and requests. Observations describe what is happening without judgment. Feelings express your own experience. Needs name what is behind them. Requests clearly formulate what specific action is needed.

Key Takeaways

Non-violent communication according to Marshall Rosenberg consists of four components: Observations, feelings, needs and requests, broken down into honest speaking and empathetic listening.
Separating evaluations from observations prevents misunderstandings: Instead of “The developer is putting things off”, it is better to state specifically that the code was delivered on the last sprint day in each of the last two sprints.
Statements such as “You disappointed me” shift the responsibility for your own feelings onto others; instead, non-violent communication demands “I was disappointed because I needed this conversation.”
Unclear requests lead to inaction: instead of “Send me automation reports more often”, a concrete request, for example on Mondays, Wednesdays and Fridays, provides a basis for action.
Anyone who briefly reads the principles of non-violent communication every day, for example before difficult meetings, gradually anchors them in their own communication behavior.

Testers communicate constantly: Communication is core work, not an accessory

Testers talk. Backlog refinement with developers, product owners and architects. Retrospectives. Individual discussions with team members or superiors. Error discussions, where things can quickly get tricky. Even the analysis of automation results is done through team discussions.

This communication burden is part of the job, not a sideshow. Testers sit at an interface and talk to almost every role in the project. A good communication method helps here: It gives you a framework when the situation is tense and the first reflex is to miss the mark.

Marshall Rosenberg’s model of non-violent communication provides such a framework. Maroš Kutschy got to know it through a book, an audio book and an audio workshop and applied it to typical test situations.

What is non-violent communication according to Rosenberg?

Nonviolent communication is a model consisting of four components: Observation, Feeling, Need and Request. You build a statement in this order without judging the other person.

The model has two sides. The first is honest self-expression, i.e. how you speak. The second is empathetic listening, i.e. how you take in what others are saying. Both sides use the same four components.

“Violent” does not mean loudness or aggression in the literal sense. It refers to judgment. As soon as you judge someone instead of describing what happened, the communication becomes violent in this sense. Non-violent means observing and separating observation from judgment.

Observing instead of evaluating: the first component

The first step is to name what is observed without making a judgment. Testers easily slip into evaluating, especially when they pass something on to a superior.

An example: A developer regularly only delivers his code on the last day of the sprint. For you, this means that a test is due on the last Friday, and if a problem arises, the developer is already at the weekend.

The evaluative variant is: “John is putting things off.” That is a judgment. The observational variant is: “In the last two sprints, he has made his fixes available for testing on the last day of the sprint.” This second form gives your manager information to work with instead of labeling the person.

Naming feelings, not disguising perceptions

The second component is real feelings. The catch: A lot of what sounds like a feeling is not a feeling, but an interpretation of the behavior of others.

Take a refinement in which you, as a tester, measure a story against the Definition of Done and find it insufficiently prepared. You ask the product owner to come prepared next time, but the developer and product owner wave you off and want to clarify the issues during the sprint.

The apparent statement of feeling is then: “I feel ignored in the refinements.” Being ignored is not a feeling, but your interpretation of how others react to you. It is often difficult for testers to express a real feeling because their work is technical. Nevertheless, the expressed feeling carries further than the disguised perception.

Taking responsibility for your own feelings

The third component is the needs behind the feelings. The core: you take responsibility for your feelings instead of blaming someone else.

Example: You want to introduce a new automation tool, away from the old Java framework with Selenium and towards Cypress or Playwright. You have built a proof of concept and organized a meeting with the test architect. He doesn’t show up.

The deflecting version is: “You let me down because you didn’t show up.” This makes your feeling the other person’s fault. The responsible version turns the sentence around: “I was disappointed because I had to clarify a few unresolved issues with you.” “You disappointed me” becomes “I was disappointed”, coupled with what you needed.

This requires a different way of thinking about yourself. For outsiders, it initially seems strange to stand up for your own feelings. It takes openness to say what you really need.

How do you formulate a clear request?

A request is clear when the other person knows exactly what action fulfills your need. Vague requests leave open what exactly needs to be done.

A test manager needs more automation reports. The unclear request is: “I would be happy if you sent me reports more often.” What “more often” means remains unclear. The clear request specifies the action: “Send me the automation reports on Mondays, Wednesdays and Fridays.”

Testers demand clarity in their requirements before testing. The same clarity is worthwhile in your own communication. A specific request saves the other person from guesswork.

The four components at a glance, each with the weak and non-violent variants:

component	weak variant	non-violent variant
Observation	”John puts things off."	"In the last two sprints, he delivered on the last day.”
Feeling	”I feel ignored."	"I was disappointed.”
Need	”You let me down."	"I was disappointed because I had to clarify open questions.”
Please	”Send me reports more often."	"Send me reports on Mondays, Wednesdays and Fridays.”

Listening means being there with your whole being

The second side of the model is empathic listening, and it uses the same four components. Empathy here means being fully present, not interrupting the other person and listening to the end.

Certain reflexes sabotage listening. One of these is storytelling. A colleague tells you about problems with their proof of concept, you listen briefly and then interrupt with your own stories to show yourself as an experienced tester, for example: “Ten years ago, I had similar problems with HP UFT.”

At that moment, the other person doesn’t want to hear that. Such interjections shift the focus from their concerns to your experience. Listening means being there instead of taking over the stage.

Knowing the theory is not enough: the autopilot strikes back

Knowing the model and applying it in the real moment are two different things. In real-life situations, it’s easy to forget the theory and act on autopilot, which contradicts these very principles.

This can be practiced in small steps. In one-to-one conversations, stay quiet and listen, formulate questions in your head and only ask them when the other person has finished talking. Have a brief review afterwards: Was my request clear enough? Did I explain exactly what needs to be done?

This raises a question to which the model does not provide a ready-made answer: Where is the line between too detailed and not detailed enough? You have to strike this balance yourself in each specific case.

A practical anchor helps against the autopilot. Read a book for a minute or two before booting up the computer. Before a conversation that you know will be difficult, briefly read the relevant passage. This will help you remember the principle before the reflex takes over.

You know the theory, but when it comes to real situations, you sometimes forget everything and just act as if you’re on autopilot, which contradicts this principle.
Maroš Kutschy

Testers are constantly working with different opinions and many communication partners. Being open and empathetic towards the people around you is therefore not a soft additional quality, but part of good test work.