Nonviolent communication, as developed by Marshall Rosenberg, is built on four components: observations, feelings, needs and requests. Observations describe what is happening without judging it. Feelings express your own experience. Needs name what lies behind those feelings. Requests state clearly which concrete action is needed.
Key Takeaways
- Marshall Rosenberg’s nonviolent communication has four components (observations, feelings, needs and requests) and two sides: honest self-expression and empathic listening.
- Keeping observations separate from judgments prevents misunderstandings: instead of “The developer keeps putting things off”, say specifically that in the last two sprints the code arrived on the last day of the sprint.
- Statements like “You disappointed me” shift responsibility for your own feelings onto someone else. Nonviolent communication says instead: “I was disappointed because I needed this conversation.”
- Vague requests lead to nothing happening: instead of “Send me automation reports more often”, a concrete request such as Mondays, Wednesdays and Fridays gives the other person something to act on.
- Reading up on the principles of nonviolent communication briefly every day, for example before difficult meetings, gradually builds them into the way you communicate.
Testers Communicate All Day: Communication Is Core Work, Not an Extra
Testing means talking. Backlog refinement with developers, product owners and architects. Retrospectives. One-on-ones with team members or your manager. Bug discussions, which can get delicate fast. Even analyzing automation results happens through conversations in the team.
This communication load is part of the job, not a side issue. Testers sit at an interface and talk to almost every role in the project. That is exactly where a good communication method helps: it gives you a structure when things are tense and your first reflex is off the mark.
Marshall Rosenberg’s model of nonviolent communication offers that kind of structure. Maroš Kutschy learned about it through a book, an audiobook and an audio workshop, and he has applied it to typical testing situations.
What Is Nonviolent Communication According to Rosenberg?
Nonviolent communication is a model with four components: observation, feeling, need and request. You build a statement in this order, without judging the person you’re talking to.
The model has two sides. The first is honest self-expression, meaning how you speak. The second is empathic listening, meaning how you take in what others say. Both sides use the same four components.
“Violent” here doesn’t mean loud or aggressive in the literal sense. It means judging. As soon as you judge someone instead of describing what happened, communication becomes violent in this sense. Nonviolent means observing, and keeping observation separate from judgment.
Observing Instead of Judging: The First Component
The first step is to name what you observed without putting a judgment into it. Testers slip into judging easily, especially when they pass something on to their manager.
An example: a developer regularly delivers his code only on the last day of the sprint. For you, that means there’s still testing to do on that last Friday, and if a problem turns up, the developer has already left for the weekend.
The judging version is: “John puts things off.” That’s a verdict. The observing version is: “In the last two sprints, he made his fixes available for testing on the last day of the sprint.” The second version gives your manager information to work with instead of a label on the person.
Name Your Feelings, Don’t Disguise Your Interpretations
The second component is real feelings. The catch: a lot of what sounds like a feeling is really an interpretation of how other people behave.
Take a refinement where you, as the tester, check a story against the Definition of Done and find it isn’t ready. You ask the product owner to come prepared next time, but the developers and the product owner brush it off and want to sort out the questions during the sprint.
The supposed feeling then comes out as: “I feel ignored in refinements.” Being ignored isn’t a feeling. It’s your interpretation of how others respond to you. Naming a real feeling is often hard for testers, because their work is so technical. Still, a feeling that is actually spoken carries further than an interpretation dressed up as one.
Taking Responsibility for Your Own Feelings
The third component is the needs behind the feelings. The core idea: you take responsibility for your feeling instead of pinning it on someone else.
An example: you want to introduce a new automation tool, moving away from the old Java framework with Selenium to Cypress or Playwright. You’ve built a proof of concept and set up a meeting with the test architect. He doesn’t show up.
The blaming version is: “You disappointed me because you didn’t come.” That turns your feeling into the other person’s fault. The responsible version turns the sentence around: “I was disappointed because I needed to clear up a few open questions with you.” “You disappointed me” becomes “I was disappointed”, tied to what you needed.
That takes a different way of thinking about yourself. To people outside, owning your feelings like this can seem strange at first. It takes openness to say what you really need.
How to Make a Clear Request in Nonviolent Communication
A request is clear when the other person knows exactly which action will meet your need. Vague wishes leave open what should actually be done.
A test manager needs more automation reports. The vague request is: “I’d be happy if you sent me reports more often.” What “more often” means stays unclear. The clear request names the action: “Send me the automation reports on Mondays, Wednesdays and Fridays.”
Testers insist on clear requirements before they test. The same clarity pays off in your own communication. A concrete request spares the other person the guesswork.
The four components at a glance, each with a weak and a nonviolent version:
| Component | Weak version | Nonviolent version |
|---|---|---|
| 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 disappointed me." | "I was disappointed because I needed to clear up open questions.” |
| Request | ”Send me reports more often." | "Send me reports on Mondays, Wednesdays and Fridays.” |
Listening Means Being There with Your Whole Self
The other side of the model is empathic listening, and it uses the same four components. Empathy here means being fully present, not interrupting and listening to the very end.
Certain reflexes sabotage listening. One of them is storytelling. A colleague tells you about problems with their proof of concept, you listen for a moment and then jump in with stories of your own to show what an experienced tester you are, for example: “Ten years ago I had similar problems with HP UFT.”
At that moment, the other person doesn’t want to hear it. Interjections like that move the focus from their concern to your experience. Listening means being there, not taking over the stage.
Knowing the Theory Isn’t Enough: Autopilot Strikes Back
Knowing the model and applying it in the moment are two different things. In real situations it’s easy to forget the theory and switch to autopilot, which runs against exactly these principles.
You can practice in small steps. In one-on-ones, stay quiet and listen, form your questions in your head and ask them only once the other person has finished. Afterward, take a quick look back: was my request clear enough? Did I explain exactly what needs to be done?
That raises a question the model doesn’t answer for you: where is the line between too much detail and not enough? You have to find that balance yourself, case by case.
A practical anchor helps against the autopilot. Spend a minute or two reading the book before you start up your computer. Before a conversation you know will be difficult, reread the relevant passage. That brings the principle back to mind before the reflex takes over.
“You know the theory, but when it comes to real situations, you sometimes forget everything and just act on autopilot, which goes against this principle.”
(Maroš Kutschy)
Testers work with differing opinions and many people to talk to, all the time. Being open and empathic toward the people around you is therefore not a soft extra. It’s part of doing testing well.
Frequently Asked Questions
Why is communication considered a core part of a tester’s job rather than a secondary task?
Testers act as an interface and interact with nearly every role in the project: backlog refinement with developers, product owners, and architects; retrospectives; one-on-one meetings with supervisors; and defect reviews, which can quickly become sensitive. Even the analysis of automation results relies on communication. A method provides guidance when the situation is tense and your first instinct fails you.
What is “violent” about ordinary communication if no one raises their voice?
What’s meant here is judgment, not volume or aggression. As soon as you judge someone instead of describing what happened, communication becomes violent in this sense. The model therefore works with four components: observation, feeling, need, and request. It has two sides, honest self-expression and empathetic listening, and both use the same four components.
How do you address the fact that a developer always delivers their code on the last day of the sprint?
Descriptive rather than judgmental. “John procrastinates” is a label applied to the person. “In the last two sprints, he made his fixes available for testing on the last day of the sprint” states the same thing as an observation. This approach gives the manager information they can work with and makes the problem verifiable rather than personal.
Is “I feel ignored” a feeling?
No. Being ignored is an interpretation of how others react to you, not a feeling of your own. Such disguised perceptions merely sound like emotional statements. Testers often find it difficult to name genuine feelings because their work is technically oriented. Nevertheless, expressing a genuine feeling carries more weight in a conversation than interpreting someone else’s behavior.
How do you tell someone you’re disappointed without blaming them?
By turning the sentence around. “You disappointed me because you didn’t come” becomes “I was disappointed because I had to clarify a few outstanding issues with you.” The feeling remains with you and is linked to your need. To outsiders, it may seem strange at first to take ownership of your own feelings.
Why do vague requests often go unheeded?
Because the other person doesn’t know what action is being requested. “I’d appreciate it if you sent me reports more often” leaves open what “more often” means. “Send me the automation reports on Mondays, Wednesdays, and Fridays” specifies the action. Testers demand clarity in requirements before they start testing: the same clarity is worth applying to your own requests.
Which reflex most often sabotages active listening?
Storytelling. A colleague describes problems with their proof of concept; you listen briefly and then interrupt with your own stories to showcase yourself as an experienced tester, perhaps by sharing similar difficulties from past tooling projects. This shifts the focus from their concern to your experience. Empathetic listening means: staying present, not interrupting, and listening until the end.
How do you practice these principles so they are available in real conversations?
In small steps, because in a real-life situation, autopilot can easily take over. During one-on-one conversations, stay silent, formulate questions in your head, and ask them only after the other person has finished speaking. Reflect briefly afterward: Was the request clear enough? As a reminder, it helps to review the material for one or two minutes before turning on your computer or before a difficult conversation.
