Dois anos atrás eu montei uma palestra para falar sobre “O Verdadeiro Valor dos Testes”, pesquisei sobre os erros mais impactantes sobre cada fase de desenvolvimento do software. A minha ideia era mostrar o que a ausência da qualidade ou a falta de empatia com o cliente pode gerar para uma organização. A mais crítica para mim é a falta de confiança.
Quando falamos em empatia com o cliente em desenvolvimento de software, não é só responsabilidade do UX apresentar uma melhor experiência para o cliente. É responsabilidade de cada um que faz parte da entrega do software. Um QA que analisa o comportamento do cliente para aprender como testar. Um desenvolvedor que ao implementar um código analisa o impacto que pode causar para o cliente. Um P.O que ao apresentar a demanda para o time, ter a responsabilidade de compartilhar o negócio a fim de inspirar o time para fazer a melhor entrega de valor.
A qualidade e a empatia nascem quando o time inteiro tem essa visão. Então teremos a melhor entrega de software para o cliente! A preocupação em não prejudicar o cliente, não entregar algo que ele não queira, em não entregar algo que demore para ser utilizado, em não entregar algo que não seja de fácil compreensão.
Mesmo no melhor cenário de melhor entrega de software para o cliente, pode acontecer de encontrarmos inconsistências ou bugs. É normal! E quando temos um time com essa visão, pensamos, ufa! Que bom que encontramos e podemos consertar antes de atingir nosso cliente!
É importante alinhar com o seu time o que é um bug. “O combinado não sai caro”, é uma boa frase para acordos no seu time. Gosto de dizer que o QA sempre tem uma visão além do alcance, isso pode gerar alguns conflitos no time. O QA sempre deve ter a visão de quem é o cliente. É natural o QA querer defender essa visão.
Quem nunca ouviu frases do tipo: “Bug de layout não é um bug”, “Erro ortográfico não é um bug”? Tudo depende do acordo com o time. Mas sim, são bugs simples mas são bugs.
A pergunta que eu faço é: Você sabe a consequência de um bug?
Em um dos slides dessa palestra tem uma situação que exemplifica o valor de um bug de layout. Um alerta de míssil foi disparado no Havaí em 2018 quando já havia uma tensão entre EUA e a Coréia do Norte. O Alerta só foi revogado 38 minutos DEPOIS da emissão. A tela compartilhada não distingue o Teste do Alerta de verdade.
Durante a tensão que o Havaí estava, uma coisa que não poderia ter acontecido era a perda da confiança no sistema de alerta do Governo! O caos e a desconfiança foi instaurado.
A verdade é que nunca poderemos saber se um bug pode ser catastrófico ou não, mas como responsáveis pelo que estamos entregando, a prevenção é a melhor medida. Por isso a qualidade nos ajuda de diversas maneiras. Agir e não reagir, se prevenir com testes em diferentes camadas.
Os diferentes tipos de teste nos ajuda a saber se estamos construindo da maneira correta, o mais cedo possível. É como se fossemos construir um veleiro. Com testes começamos pelo casco forte e impermeável que irá sustentar o veleiro. Sem testes começamos pelo casco sem saber se ele será impermeável. Só iremos saber depois de pronto, quando entregarmos a um capitão e ele colocá-lo na água para navegar. E então o capitão começa o processo de tirar a água de dentro do veleiro o mais rápido possível para não afundar. Mas o capitão deveria estar preocupado com a navegabilidade do veleiro, não com tirar a água. Podemos construir da maneira ágil ou tradicional, mas devemos construir o veleiro impermeabilizado desde o começo.
Os testes nos ajuda a saber o quanto estamos acertando mais cedo, a colaboração do time desde o começo com testes de usabilidade, teste dos requisitos, com um time focado no valor para o cliente e não pensando somente em sistema.
O valor para o cliente, empatia, qualidade, foco no cliente, isso não pode mais ficar só no discurso. Precisamos construir software da maneira correta. Encontre a sua com a ajuda de um QA 🙂
QApabilities 