[et_pb_section fb_built=”1″ theme_builder_area=”post_content” _builder_version=”4.27.9″ _module_preset=”default” custom_padding=”0px|||||”][et_pb_row _builder_version=”4.27.9″ _module_preset=”default” theme_builder_area=”post_content” custom_padding=”0px|||||”][et_pb_column _builder_version=”4.27.9″ _module_preset=”default” type=”4_4″ theme_builder_area=”post_content”][et_pb_text _builder_version=”4.27.9″ _module_preset=”default” theme_builder_area=”post_content” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n
The most recognizable symptom of the problem is known to any agile team: development delivers the build at the end of the sprint, QA begins testing, defects appear that no one anticipated, and the team enters a negotiation mode over what makes it into the release and what is postponed. The conversation usually leads to an implicit question\u2014why didn’t QA find this sooner?\u2014which no one answers because everyone knows the real answer: QA was not in the conversation where the problem was born.<\/p>\n
The friction between QA and development in most teams does not have a technical origin. It has a structural origin: the work model is designed for QA to receive the software at the end and validate it, not for QA to participate in defining what is built and how it is validated from the start. Changing that outcome requires changing the structure, not the talent or the tools. <\/p>\n
<\/p>\n
The most common pattern in teams reporting friction between QA and development is what the industry describes as “throw it over the wall”: business writes the requirements, development builds what they interpret, QA tests what they receive, and each function has a different definition of what “done” means.<\/p>\n
In that model, the defects that appear in the testing phase are not failures of QA or development: they are the inevitable consequence of three groups working with three different interpretations of the same requirement without having aligned them beforehand. 67% of software errors are introduced in the design or requirements phase (Capers Jones), not in the implementation. A work model that does not involve QA until after implementation cannot catch those errors before they become costly defects. <\/p>\n
Elite teams, according to the DORA State of DevOps 2024, deploy 127 times faster and recover from failures 8 times faster than low-performing teams. That performance difference does not come from better tools: it comes from a collaboration model where quality is a shared responsibility from the start of the cycle, not a verification stage at the end. <\/p>\n
<\/p>\n
<\/p>\n
The Three Amigos method is a structured session where the Product Owner, developer, and QA engineer review each user story together before the team begins coding it. The goal is not to divide tasks: it is to reach a shared interpretation of what the system should do, what edge cases exist, and what criteria define that the story is finished. <\/p>\n
Each profile brings a perspective that the others do not have: the Product Owner clarifies business value and real use cases; the developer identifies technical constraints and dependencies that affect scope; the QE engineer detects ambiguities, uncovered scenarios, and failure conditions that the team had not considered. The result of 30 to 45 minutes of conversation before development prevents hours of rework after delivery. <\/p>\n
The Three Amigos session is the first line of defense against the defect that no one anticipated because no one asked the right question at the right time.<\/p>\n
<\/p>\n
Acceptance criteria written in natural language\u2014”the system must process the payment correctly”\u2014leaves room for three different interpretations depending on who reads it. The same criteria in BDD format eliminates that ambiguity: <\/p>\n
Given<\/em> the user has a sufficient balance, That format\u2014Given\/When\/Then\u2014produces three simultaneous benefits: development knows exactly what behavior to implement, QE knows exactly what scenario to test and what result to expect, and the criteria can be converted directly into an automated test case without additional reinterpretation.<\/p>\n The effectiveness of the BDD format is not in the tool that implements it, but in the conversation it forces: no criteria can be written in Given\/When\/Then if the three profiles have not reached a common interpretation of the expected behavior.<\/p>\n <\/p>\n The Definition of Done (DoD) is the team’s agreement on what conditions a story must meet to be considered finished. In teams with the sequential handoff pattern, the DoD is usually defined from a development perspective: the code compiles, unit tests pass, the PR is approved. QA appears later as an additional stage, not as part of the definition of ready. <\/p>\n A DoD that integrates quality from the start includes QE criteria as an integral part: unit tests written by the developer, automated BDD acceptance criteria, minimum coverage defined by the team for that module, and QE review of the edge cases identified in the Three Amigos session. When QA is part of the definition of ready and not a subsequent stage, the developer’s “I’m done” and the tester’s “it’s not ready yet” stop being two opposing positions. <\/p>\n <\/p>\n
when<\/em> they execute a transfer for an amount less than their available balance,
then<\/em> the system debits the amount, generates the receipt, and updates the balance in real time.<\/p>\n<\/h3>\n
3. Definition of Done with integrated quality criteria<\/h3>\n
<\/h3>\n
4. Quality gates in the pipeline shared by the team<\/h3>\n