[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
O sintoma mais reconhec\u00edvel do problema \u00e9 conhecido por qualquer equipa \u00e1gil: o desenvolvimento entrega o build no final do sprint, o QA inicia os testes, surgem defeitos que ningu\u00e9m previu, e a equipa entra em modo de negocia\u00e7\u00e3o sobre o que entra no release e o que \u00e9 adiado. A conversa costuma derivar numa pergunta impl\u00edcita \u2014 porque \u00e9 que o QA n\u00e3o encontrou isto antes? \u2014 que ningu\u00e9m responde porque todos conhecem a resposta real: o QA n\u00e3o esteve na conversa onde o problema nasceu.<\/p>\n
A fric\u00e7\u00e3o entre QA e desenvolvimento na maioria das equipas n\u00e3o tem origem t\u00e9cnica. Tem origem estrutural: o modelo de trabalho est\u00e1 concebido para que o QA receba o software no final e o valide, n\u00e3o para que o QA participe na defini\u00e7\u00e3o do que se constr\u00f3i e de como se valida desde o in\u00edcio. Mudar esse resultado exige mudar a estrutura, n\u00e3o o talento nem as ferramentas. <\/p>\n
<\/p>\n
O padr\u00e3o mais comum em equipas que reportam fric\u00e7\u00e3o entre QA e desenvolvimento \u00e9 aquele que a ind\u00fastria descreve como “throw it over the wall”: o neg\u00f3cio escreve os requisitos, o desenvolvimento constr\u00f3i o que interpreta, o QA testa o que recebe, e cada fun\u00e7\u00e3o tem uma defini\u00e7\u00e3o distinta do que “pronto” significa.<\/p>\n
Nesse modelo, os defeitos que surgem na fase de testes n\u00e3o s\u00e3o falhas de QA nem de desenvolvimento: s\u00e3o a consequ\u00eancia inevit\u00e1vel de tr\u00eas grupos terem trabalhado com tr\u00eas interpreta\u00e7\u00f5es distintas do mesmo requisito sem as terem alinhado antes. 67% dos erros em software s\u00e3o introduzidos na fase de design ou de requisitos (Capers Jones), n\u00e3o na implementa\u00e7\u00e3o. Um modelo de trabalho que n\u00e3o envolve o QA at\u00e9 depois da implementa\u00e7\u00e3o n\u00e3o consegue detetar esses erros antes de se tornarem defeitos dispendiosos. <\/p>\n
As equipas de elite, segundo o DORA State of DevOps 2024, fazem deployments 127 vezes mais r\u00e1pido e recuperam de falhas 8 vezes mais r\u00e1pido do que as equipas de baixo desempenho. Essa diferen\u00e7a de desempenho n\u00e3o vem de melhores ferramentas: vem de um modelo de colabora\u00e7\u00e3o em que a qualidade \u00e9 uma responsabilidade partilhada desde o in\u00edcio do ciclo, n\u00e3o uma etapa de verifica\u00e7\u00e3o no final. <\/p>\n
<\/p>\n
<\/p>\n
O m\u00e9todo dos Tr\u00eas Amigos \u00e9 uma sess\u00e3o estruturada em que o Product Owner, o programador e o engenheiro de QA rev\u00eam juntos cada hist\u00f3ria de utilizador antes de a equipa come\u00e7ar a codific\u00e1-la. O objetivo n\u00e3o \u00e9 dividir tarefas: \u00e9 chegar a uma interpreta\u00e7\u00e3o partilhada do que o sistema deve fazer, que casos de fronteira existem e que crit\u00e9rio define que a hist\u00f3ria est\u00e1 conclu\u00edda. <\/p>\n
Cada perfil contribui com uma perspetiva que os outros n\u00e3o t\u00eam: o Product Owner clarifica o valor de neg\u00f3cio e os casos de uso reais; o programador identifica restri\u00e7\u00f5es t\u00e9cnicas e depend\u00eancias que afetam o \u00e2mbito; o engenheiro de QE deteta ambiguidades, cen\u00e1rios n\u00e3o cobertos e condi\u00e7\u00f5es de falha que a equipa n\u00e3o tinha considerado. O resultado de 30 a 45 minutos de conversa antes do desenvolvimento evita horas de retrabalho ap\u00f3s a entrega. <\/p>\n
A sess\u00e3o de Tr\u00eas Amigos \u00e9 a primeira linha de defesa contra o defeito que ningu\u00e9m previu porque ningu\u00e9m fez a pergunta certa no momento certo.<\/p>\n
<\/p>\n
O crit\u00e9rio de aceita\u00e7\u00e3o escrito em linguagem natural \u2014 “o sistema deve processar o pagamento corretamente” \u2014 deixa espa\u00e7o para tr\u00eas interpreta\u00e7\u00f5es distintas consoante quem o l\u00ea. O mesmo crit\u00e9rio em formato BDD elimina essa ambiguidade: <\/p>\n
Dado que<\/em> o utilizador tem saldo suficiente, Esse formato \u2014 Given\/When\/Then \u2014 produz tr\u00eas benef\u00edcios simult\u00e2neos: o desenvolvimento sabe exatamente que comportamento deve implementar, o QE sabe exatamente que cen\u00e1rio deve testar e que resultado esperar, e o crit\u00e9rio pode converter-se diretamente num caso de teste automatizado sem reinterpreta\u00e7\u00e3o adicional.<\/p>\n A efic\u00e1cia do formato BDD n\u00e3o est\u00e1 na ferramenta que o implementa, mas sim na conversa que obriga a ter: nenhum crit\u00e9rio pode ser escrito em Given\/When\/Then se os tr\u00eas perfis n\u00e3o tiverem chegado a uma interpreta\u00e7\u00e3o comum do comportamento esperado.<\/p>\n <\/p>\n A Definition of Done (DoD) \u00e9 o acordo da equipa sobre que condi\u00e7\u00f5es uma hist\u00f3ria deve cumprir para ser considerada conclu\u00edda. Em equipas com o padr\u00e3o de handoff sequencial, a DoD costuma estar definida a partir da perspetiva do desenvolvimento: o c\u00f3digo compila, os testes unit\u00e1rios passam, o PR est\u00e1 aprovado. O QA surge depois como uma etapa adicional, n\u00e3o como parte da defini\u00e7\u00e3o de pronto. <\/p>\n Uma DoD que integra a qualidade desde o in\u00edcio inclui crit\u00e9rios de QE como parte integral: testes unit\u00e1rios escritos pelo programador, crit\u00e9rios de aceita\u00e7\u00e3o BDD automatizados, cobertura m\u00ednima definida pela equipa para esse m\u00f3dulo, e revis\u00e3o de QE sobre os cen\u00e1rios de fronteira identificados na sess\u00e3o de Tr\u00eas Amigos. Quando o QA faz parte da defini\u00e7\u00e3o de pronto e n\u00e3o \u00e9 uma etapa posterior, o “j\u00e1 terminei” do programador e o “ainda n\u00e3o est\u00e1 pronto” do testador deixam de ser duas posi\u00e7\u00f5es opostas. <\/p>\n <\/p>\n
quando<\/em> executa uma transfer\u00eancia por um montante inferior ao seu saldo dispon\u00edvel,
ent\u00e3o<\/em> o sistema debita o montante, gera o comprovativo e atualiza o saldo em tempo real.<\/p>\n<\/h3>\n
3. Definition of Done com crit\u00e9rios de qualidade integrados<\/h3>\n
<\/h3>\n
4. Quality gates no pipeline partilhados pela equipa<\/h3>\n