Tester's Guide to Developer Personalities

Wessel Braakman identifies four specific developer types: the driver, the analyst, the supporter, and the enthusiast. This classification emphasizes adjusting communication styles rather than relying on standardized reporting. Braakman’s approach is rooted in personal experiences, offering practical insights over academic theory for testers to improve their interactions.

The 'driver' developer persona prioritizes issues with high user impact, often dismissing trivial bugs. A lack of clear impact assessment in bug reports frequently leads to drivers overlooking them. Framing issues through user statistics and business consequences is crucial for engaging these developers effectively.

Re-approaching a driver with specific data, such as a 30% user impact, effectively triggers action. Providing clear reproduction steps is essential for these developers to prioritize fixes, as they need concrete information to act. This shift in communication strategy leads to the developer committing to a fix and providing follow-up updates.

Vague reports, particularly regarding intermittent bugs or flaky tests, are typically dismissed by these analytical types. Testers must document exact reproduction steps clearly to gain the cooperation of 'analyst' developers.

Supporter-type developers value harmony and collaboration within their team. Giving direct orders without consultation destroys their sense of ownership over the solution. Directly assigning tasks makes them feel ignored rather than empowered, indicating that the reporter failed to respect their need for shared problem-solving.

The speaker moved away from dictating root causes to the developer, instead sharing information to foster mutual understanding. The developer responded positively to being consulted, creating a collaborative atmosphere that improved the final result. This approach allows the 'supporter' to feel like a valued partner in problem-solving.

Enthusiast developers prioritize new ideas over routine fixes, leading to scope creep if not properly guided. Giving a vague prompt can result in them redesigning an entire flow rather than addressing a specific bug. The fault lies in not providing a concrete, bounded problem, as enthusiasts require clear guardrails to remain productive.

The speaker found success by giving 'enthusiast' developers space for creativity within a defined scope. Matching their energy with personal enthusiasm also proved effective. This balanced approach allowed the developer to ideate freely while remaining within the project's limits, ultimately leading to the bug being fixed effectively.

The speaker initially focused on a local fix for a problem without considering external dependencies. The developer highlighted that the validation issue affected an import flow and a batch job, revealing its system-wide impact. This experience led the speaker to acknowledge the need to investigate broader system dependencies beforehand, shifting from suggesting solutions to initiating collaborative investigations.

Past conflicts were often rooted in miscommunication rather than outright dismissal, as the speaker didn't understand what information developers needed. 'Driver' developers required information on impact and importance. 'Analyst' developers sought facts and reproducible steps. 'Supporter' developers prioritized personal connection over purely task-focused communication, while 'enthusiast' developers needed clear scope and guidance.

The developer types, identified as red, blue, yellow, and green, are loosely based on the DISC personality assessment methods. While inspired by these established models, the speaker emphasizes that these classifications are primarily derived from their personal experience. The ultimate goal is to expand this guide to include more developer types and potential tester archetypes.

The speaker plans to develop more comics based on additional developer types, and potentially explore different tester archetypes. The ultimate goal is to create a comprehensive "Tester's Survival Guide" using these comics as an engaging format. The audience is invited to contribute their own experiences and suggestions for new developer types.

Wessel Braakman finds it easier to relate to developers because they share the common goal of creating the actual application. This direct involvement in development fosters a stronger connection. In contrast, business leadership often involves political layers that can complicate and hinder clear communication for testers.

Quality Assurance (QA) professionals should act as coaches for both development teams and business leaders, especially when quality is involved. They need to explain the long-term value of quality assurance from the project's inception. Quality is described as a collective team effort, not a solitary task, requiring alignment across all stakeholders.

Junior developers typically require more hands-on guidance and deep dives into logs during follow-ups. In contrast, senior developers can often manage with minimal context, such as a screenshot, to address a problem. The presenter notes that this differentiated approach is based on personal experience rather than academic theory, reflecting practical adaptation in the field. This also serves as an opportunity to educate juniors on quality assurance practices.

AI agents modifying their own knowledge bases require clear traceability for every autonomous change. Each modification needs human oversight and verification, with transparency about when and why changes were made. The speaker warns against allowing AI agents to operate entirely without human supervision, emphasizing the need for a 'human overhead' in such processes.