A Tester's Survival Guide to Developers [Testμ 2026]

A Jungle of Species

Twelve or thirteen years into working in IT, the thing he keeps noticing is that working with people is a jungle. His reason is precise: not because every environment is a mess, but because of the range of species in it.

Developers, product owners, managers, and within each of those a spread of what people need before they will engage with you.

He was careful about what kind of talk this is. It is not academic, it is his own experience of working with these developers as a tester, and what he learned from each of them.

The structure is the useful part. For each type he shows the first encounter, which went badly, and then the second, where he brought the same bug and changed only how he opened.

The Driver

The driver is determined, decisive and results-driven, and wants impact rather than chatter. This is the developer who wants the important parts of an application, not the trivial ones anyone could fix.

His first encounter came at the start of his career. He reported a bug in the export feature and mentioned a null pointer exception in the logs.

The developer asked whether it blocked anything, and whether a user actually saw it. New to the application and pleased to have found something at all, he did not know.

He came away feeling dismissed, and in the developer’s view he had wasted their time. What this type needs is clarity, confidence and consequences.

The second attempt opened differently. The same issue in the export feature, but framed as affecting 30 percent of all users, potentially blocking exports and delaying critical deliveries, with the reproduction steps attached.

The answer this time was that it was worth their time. They prioritised it and came back with an update, and it worked because he led with impact and showed he understood what mattered to them.

The Analyst

The analyst is detail-oriented and needs precision and evidence. In his experience they sit through meetings without saying much, and when they do speak everyone stops, because they raise the thing nobody else thought of.

His first attempt was a loading spinner that sometimes worked and sometimes did not. He described it as something weird happening.

Asked what exactly he was seeing, he said he was not sure and it just did not feel right. Asked for reproduction steps, he admitted he had not written any down, and the developer turned back to their own work.

He is honest that the flakiness made it harder and that recording nothing was still his failure. The second attempt led with a request rather than a complaint: he had found something, was not certain what it was, and wanted to understand it better.

Then the specifics. Half the time he pressed the button the spinner failed to load, here was the screenshot proving it, and could they walk through an example together.

That produced a joint debugging session rather than a dismissal. He had wanted to spar about it from the start, and what the developer needed first was something concrete to work from.

The Supporter

The supporter is people-oriented and values harmony and collaboration. This is the developer who knows how your weekend went and how your family is doing.

By the time he met one, the driver and the analyst had trained him to arrive fully prepared, and that turned out to be the problem.

He reported the bug, said he had already found the root cause in a validation check, and told them to fix the validation logic at a specific line in the export service and let him know when it was done.

It was, in effect, an assignment. No shared understanding, no ownership, no conversation, and this is the one encounter where the developer rather than the tester came away feeling down.

The second attempt withheld the answer on purpose. He had found a bug in the export feature and wanted to run it by them, described what he had tried and how it affected users as information rather than urgency, and asked whether they had any idea what was causing it.

The developer suggested working it out together, and they ended up doing exactly that over coffee.

The Enthusiast

The enthusiast is energetic and idea-driven, values freedom and fun, and gets bored by routine. They arrive at meetings with twenty ideas nobody asked for, and he suspects he is one of them.

His first encounter went sideways immediately. Told about the bug, the developer asked what the idea behind it was; asked to fix it, they proposed redesigning the entire flow.

Told it was blocking a large share of users right now, the response was to imagine adding AI to it. The developer then went off and built something impressive that was not the fix.

He takes his share of the blame: he led with ideas rather than a concrete problem, gave nothing specific to fix, and applied no brakes. His illustration of the type is the developer who worked weekends and produced ten fixes on Monday that nobody could explain, which was generous and unrepeatable.

The second attempt opened in their language. He had found something super weird, and kind of cool, then gave the specifics: what he expected, what he saw, and everything he had already tried.

He offered a few more ideas of his own, then set the boundary: let us work on the fix together, and I will show you what is wrong. The developer had room to think outside the box as long as it stayed inside the scope, and the bug got fixed.

The Systems Thinker

The fifth type came later than the others and sits apart from them. The systems thinker is analytical but sees the whole picture rather than the task in front of them, and needs context, patterns and thoughtful discussion.

He proposed fixing a bug by changing a validation. The developer replied that the same validation is used by the import flow and the batch job, and asked whether anyone knew what happened there.

He had not considered it. He was proposing a local fix to a system-wide problem, having skipped his own thought process at the boundary of his own application.

The second attempt is the most transferable in the talk, because what changed was admitting the gap. He arrived saying he had found a validation that could fix the bug, was not sure what else depended on it, and asked whether they could look at where it was used before deciding how to fix it.

The developer confirmed the import flow and the batch job, and warned that changing it could affect data quality and generated reports. Working through it together they found one more place using the same validation.

He did not bring the complete answer, and he did not need to. He brought awareness that a local fix might break something elsewhere, which was the piece the developer did not have.

The First Encounters

Looking back at the five failures, his reading of each is more generous to the developers than to himself.

• The driver - what felt like dismissal was miscommunication. He did not know what mattered to them or what they needed in order to act.
• The analyst - the lesson generalised. Reproducible steps matter whoever you are talking to, even though the enthusiast might have picked the bug up without them.
• The supporter - the encounter where he pushed too hard, and the only one where the developer was the person left feeling bad.
• The enthusiast - a powerful presence on a team who needs scope, some restriction and guidance to stay inside the box.
• The systems thinker - the one that made him feel slightly incapable, because they raised something he should have thought of himself.

The second time around, the same five conversations produced a fixed bug, a joint debugging session, a coffee, a scoped collaboration and a fix compatible with every place the code was used.

Spotting Each Type in Your Team

He closed with how to spot each one in a team you already work in, which is the practical use of the whole framework.

• The analyst - silent through the meeting, and everyone listens when they finally speak.
• The driver - driving decisions on the basis of user impact.
• The systems thinker - the one who tells you your team can make the fix, and names the other teams it will affect.
• The supporter - attentive to how everyone in the team is doing and how they work together.
• The enthusiast - producing ideas all day, and with the right guidance some of them are the right ones.

He was clear about the limits of his own model. The four colour types are loosely based on DISC, the fifth came from his own later experience, and there are far more personas than these five.

He also has plans for it. More comics, possibly tester types alongside developer types, and eventually a survival guide, with an open invitation to send him personalities and stories he has not met yet.

Q & A Session

The audience filled the Q&A box, and six questions were taken.

• Is it more challenging to work with developers or with business leaders?

  Wessel Braakman: Business leadership, and he flagged it as a personal answer rather than a general one. There are types of business leaders too, and the same presentation could be made about them. He clicks better with developers because they are building the actual application, where business leaders have to think about politics, and developers’ reasons for acting land more naturally with him.

• How do you align developers and business leaders when their quality goals conflict?

  Wessel Braakman: He took a moment on this one, having just described the two groups as genuinely different people. His answer is that testers can play a large role, because they can often explain the importance of getting quality right up front better than developers can. That makes coaching part of the job, aimed at teams and at business leaders alike whenever quality is the subject.

• What is the best way to approach junior versus senior developers on testing follow-ups?

  Wessel Braakman: With seniors he brings the problem or sends a screenshot and they take it from there. With juniors he takes their hand considerably more, and deliberately gives them a taste of what quality people do: where in the logs he found it, how he found it, and the steps to reproduce it, worked through together rather than handed over. The host suggested splitting by personality type rather than seniority, and his answer was that it is probably both.

• How do you handle requirement managers who arrive with extreme requirement lists?

  Wessel Braakman: He said upfront that it sits outside his talk and answered anyway. Someone has to prioritise the list, and in his experience that is the product owner; he has not worked with a separate requirement manager role. In his last project he wrote requirements together with his product owner, which is how he made sure they were testable and measurable. Where the role does sit outside the team, his advice is to get in contact and write them together rather than receiving a finished list.

• Which of the types should a manual tester be?

  Wessel Braakman: Ideally all of them, and he places himself mostly in the enthusiast camp. His first instinct is analyst plus systems thinker, meaning analytical precision about what you did and which steps you took, alongside the overview of what affects other teams and applications. Exploratory testing needs some enthusiast, working in a team needs some supporter because you have to care about your teammates, and making a decision needs some driver. He thinks you would struggle without at least some of each.

• Should agents be allowed to modify the knowledge base they use to make future decisions?

  Wessel Braakman: Also outside the talk, and he took it anyway. Treating agents as autonomous testing robots and the knowledge base as information about a feature or a bug fix, he thinks they may be allowed to modify it, on conditions. It must be clear that they changed it, when they changed it and why, with a human reviewing the change before it is accepted. Automation is welcome as long as it stays traceable and somebody can say they looked at it and can explain it, but never autonomously and without oversight.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.