Por que acredito que ainda estamos longe de uma cultura de qualidade em TI
Já passei por diversas empresas na minha carreira em TI e posso afirmar: ainda estamos mais preocupados em desenvolver no prazo do que…
Já passei por diversas empresas na minha carreira em TI e posso afirmar: ainda estamos mais preocupados em desenvolver no prazo do que entregar produtos com qualidade.
O primeiro ponto é que quase sempre reduzimos qualidade a testes. No entanto, não é raro olhar para equipes de tecnologia e notar que, na correria do dia a dia, até os testes acabam sendo despriorizados. Vez ou outra, até nos deparamos com algumas notícias de produtos digitais que apresentam falhas de segurança e perdem (muito) dinheiro e credibilidade com isso. Está claro que, na era do sucesso do cliente, esses erros devem ser prevenidos o mais efetivamente possível. Não dá mais para acreditar que más experiências de uso são perdoadas pelo usuário. Experimente deixar que seu cliente passe por uma e sinta na pele que 29% dos consumidores desistem de uma marca depois de uma única experiência ruim.
A garantia de qualidade, ou quality assurance (QA) tem como principal função prevenir e reduzir problemas em produtos e projetos digitais. Geralmente, profissionais de QA se encontram dentro de equipes de desenvolvimento de software, apoiando o processo e passando um pente fino nas versões que são entregues. Ao testar sistemas, como sites e aplicativos, o QA permite identificar problemas desde usabilidade até profundas lacunas de segurança que colocam dados de consumidores em risco.
Todo mundo sabe que qualidade é importante. No entanto, me chama muito a atenção o fato de que o tema de qualidade de software tem caminhado lentamente no Brasil e que ainda haja tanto espaço para evolução. É muito difícil encontrar empresas que levam essa etapa a sério e estão com cronogramas e cerimônias preparados para alimentar o profissional de QA com as estratégias certas.
Muitas empresas estão focadas em automatizar testes de software, acreditando que a automação é a resposta para tudo. Não é. É óbvio que ter processos automatizados garantem maior segurança, especialmente em jornadas críticas do produto que nunca devem falhar. Porém, quero chamar a atenção para o fato de que testes automatizados resolverão apenas uma parte do problema.
Há muito potencial no teste humano e manual, que parece estar sendo despriorizado pela agilidade dos códigos. Olhar humano é capaz de entender comportamentos não usuais e dar sugestões de melhoria que podem revolucionar um produto. Códigos não dialogam. Códigos (ainda) não entendem as nuances específicas do comportamento humano. Quando mescladas, as estratégias de testes manuais e automatizados potencializam a entrega de softwares de qualidade.
Ainda assim, vou além: só fazer teste por fazer é perda de tempo e dinheiro.
Acredito que o diálogo tenha que ser um pouco mais horizontal. O QA não deve mais se limitar apenas à equipe de desenvolvimento. Na verdade, seu potencial está na ampla interação com equipes diferentes: produto, customer support, customer success, atendimento… Todas as possibilidades que visem melhorar a experiência do cliente são válidas.
A cabeça do desenvolvedor médio ainda está focada em entrega e não em qualidade, ignorando a união poderosa da tecnologia com indicadores de negócio. Essas duas coisas podem mais ser vistas como independentes dentro de uma estratégia de testes de software. Elas não podem competir; muito pelo contrário, tecnologia e negócio devem se unir numa cultura de qualidade com processos claros e diálogo para entender o produto e deixar claro que a qualidade não é responsabilidade apenas do QA. Vou soar óbvio, mas qualidade só acontece quando há comprometimento de toda a equipe. Não é raro (aliás, pior é muito comum) termos desenvolvedores que mal testam o seu próprio código no ambiente de testes, só sobem e pedem para o QA testar. E alguns se acham expostos se esse profissional abre um bug por algo banal. Quando na verdade a mentalidade deveria ser a contrária.
O caminho para esse comprometimento está na aculturação. Se problemas em projetos e produtos digitais são facilmente aceitos, não dá para acreditar que haverá senso de urgência para corrigi-los. Se os desenvolvedores estão acostumados a entregar produtos em cima da hora, sem teste, será muito difícil convencê-los do contrário.
A cultura de qualidade serve para mitigar essa percepção, unindo normas, fluxos de trabalho, interações entre equipes e ferramentas adequadas para previr problemas e ameaças. E novamente, isso tudo ainda estamos sub-utilizando a capacidade do profissional de qualidade a simplesmente testes.
Usando minha experiência como base, vejo que as empresas não se preocupam em criar uma cultura que englobe equipes, técnicas e processos. Esse tema nunca é levado a sério. Já vi profissionais excelentes de QA atuando de maneira limitada dentro de times de desenvolvimento, tendo testes postergados e apressando o processo para entregar o produto. Naturalmente, na pressa, bugs e falhas passam.
Não posso afirmar que existe a possibilidade de criar produtos zero-bug. No entanto, é óbvio que uma cultura de qualidade auxilia no maior número de entregas mais ágeis de produtos melhores.
Para te dar um panorama, esses são alguns pilares da cultura de qualidade:
Composição de equipes ágeis
Grande colaboração entre times
Elaboração e uso de técnicas e processos de testes
Automação de cenários e jornadas críticos
Manutenção para corrigir eventuais problemas
Interações sucintas entre pessoas
Entregas contínuas
Feedback rápido
Avaliação contínua de aprimoramento de processos existente
Sugiro que, assim que termine de ler este texto, você se pergunte em quantos lugares já viu todas essas coisas (ou a maioria delas) acontecendo ao mesmo tempo.
Para finalizar, deixo aqui minha recomendação, a leitura do Manifesto de Testes Ágeis, e a reflexão de como realmente podemos trabalhar a qualidade de maneira contínua e verdadeira dentro dos times de tecnologia e negócios.