Nonviolent communication is a four-component model for expressing needs clearly and listening with empathy, developed by Marshall Rosenberg. The four components are observations, feelings, needs, and requests. Each applies to both speaking and listening. The model separates observable facts from evaluations, distinguishes genuine feelings from judgments, connects feelings to personal needs, and frames requests as specific, actionable asks.
Key Takeaways
- Mixing evaluation with observation is a form of communicative violence: saying “John procrastinates” is an evaluation, while “John delivered fixes on the last day of the sprint for two sprints” is an observable fact a manager can act on.
- Saying “you disappointed me” shifts emotional responsibility onto another person; nonviolent communication reframes this as “I was disappointed because I needed to discuss open questions,” keeping ownership with the speaker.
- Feelings and non-feelings are distinct: “I feel ignored” describes how you interpret someone else’s behavior, while “I feel frustrated” names an actual internal state and communicates it honestly.
- Vague requests block action; a request like “send me automation reports more often” leaves the recipient guessing, while “send me reports on Monday, Wednesday, and Friday” gives a clear, executable instruction.
Why testers spend more time talking than testing
Testing is a communication job before it is a technical one. Every artifact a tester touches comes wrapped in a conversation with someone else.
Backlog refinement, retrospectives, one-on-ones with a manager, bug discussions with developers, the analysis of automation results: each of these runs on dialogue, not just code. A tester who cannot get a point across cleanly will lose accuracy long before the test itself fails.
That makes a reliable communication model worth having. Maroš Kutschy points to nonviolent communication, the model developed by Marshall Rosenberg, as a structure that fits the daily reality of QA work. It gives a tester a repeatable way to say something hard without turning it into an attack.
What nonviolent communication actually is
Nonviolent communication is a four-part model that splits into two modes: expressing yourself honestly and listening with empathy. Both modes run through the same four components.
The four components are observations, feelings, needs, and requests. You apply them when you speak, and you apply them again when you listen.
The core idea is simple to state and hard to live. Separate what happened from your judgment of it, own your feelings instead of outsourcing them, and ask for something concrete. Most workplace friction comes from skipping one of these steps.
Observation is not evaluation
Start by reporting what you saw or heard, with no judgment mixed in. The moment you label a person, you have stopped observing and started evaluating, and evaluation reads as an attack.
Take a developer who keeps delivering fixes at the last possible moment. The tempting line to a manager is “John procrastinates.” That is a verdict, and it tells the manager nothing useful.
The observation version carries the same concern without the label: “During the last two sprints, John delivered his fixes for testing on the final day of the sprint.” That is a fact a manager can act on. The first version only invites a defense.
This distinction matters more for testers than for most roles, because a tester’s credibility rests on being precise. A judgment dressed up as a report damages that credibility.
Name the feeling, not the blame
The second component is your actual feeling, which is not the same as a story about how someone treated you. “I feel ignored” sounds like a feeling but isn’t one. It is a claim about what the other person did to you.
Picture a refinement meeting where a story arrives without meeting your definition of ready. You raise it, and the product owner waves it through with “we’ll answer the questions during the sprint.” Afterward you want to say something about it.
“I feel ignored in refinement meetings” puts the cause on them and starts a fight. “I feel frustrated during the refinement meetings” stays with your own experience. The second version is harder to argue with, because no one can dispute what you feel.
Testers often find this step awkward. A technical mindset leans toward facts and away from emotional language. That discomfort is exactly why the step gets skipped, and why it is worth practicing.
Own your needs instead of handing them off
Feelings come from needs, and the model asks you to take responsibility for both. The usual mistake is to make another person the author of your emotional state.
Say you ran a proof of concept for a new automation tool, maybe Cypress or Playwright instead of an older Selenium-based Java framework, and you set up a meeting to share the results with a test architect who never showed up.
“You disappointed me by not coming to the meeting” hands your feeling to him as if he caused it. The reframe keeps it yours: “I was disappointed by what happened, because I needed to talk through some open questions with you.” The shift from “you disappointed me” to “I was disappointed, because I needed” is the whole move.
The mindset underneath this can feel strange at first. You are responsible for your own feelings, and your feelings track your own needs. It reframes you as someone who can steer your reaction rather than someone things happen to.
Make the request something a person can do
The fourth component is a clear request: state the concrete action that would meet your need. A lot of communication ends in something so general the other person has no idea what to actually do.
A test manager who wants better visibility might say “I’d like you to send me automation reports more often.” More often than what, and starting when? The instruction can’t be carried out.
“I’d like you to send me the automation reports on Monday, Wednesday, and Friday” can. The receiver knows exactly what the next step is. Vague requests fail not because people refuse them but because nobody can tell when they are done.
Testers already demand this kind of clarity from requirements before they will test against them. The same standard applies when a tester is the one doing the asking.
Listening empathically uses the same four parts
The second mode of the model is listening, and it runs on the same four components turned outward. At its center is something plain: be there, with your whole attention, and don’t interrupt.
The habit that breaks empathy is hijacking the other person’s story with your own. A colleague is working through a problem with a tool proof of concept, and partway in you cut across with “ten years ago I had the same issue with HP UFT.” You have just made their problem about you.
A more useful approach is to stay quiet, hold your questions, and let the person finish. Write down what you want to ask, then ask it once they are done. The point is to understand what they said, not to wait for your turn.
The model only sticks with deliberate practice
Knowing the theory does not change how you behave under pressure. In real situations the autopilot takes over, and the autopilot does not follow the model.
The honest difficulty is that you can read the book, understand all four components, and still default to old patterns the moment a meeting gets tense. Maroš describes catching himself interrupting, or making a request that wasn’t clear, and only seeing it afterward in a personal retrospective.
When it comes to real situations, sometimes you forget everything and you just go by some autopilot, which is not according to this principle. — Maroš Kutschy
A small ritual helps reprogram that autopilot. Keep a short extract from the model somewhere visible, and read it for a minute or two before switching on the computer, or right before a meeting you expect to be hard. The reminder in the morning tends to surface again during the day.
Treat it as training, not a switch you flip once. Pick one or two moments a day to consciously run through the four components. Over time the pattern moves closer to instinct, which is the only place it does any good when a conversation turns sharp.
