Aqui na Monitora nós trabalhamos, entre outras coisas, com outsourcing de teste de desenvolvimento. Isso faz com que nós tenhamos que trabalhar conjunto com equipes geograficamente espalhadas, então nós trabalhamos com equipes na Ucrânia, no Paquistão, Malta, Londres e outros países. Isso traz algumas especificidades e exige uma agilidade dos times de desenvolvimento e de teste diária. Basicamente os engenheiros de QA, os engenheiros que trabalham com teste recebem o requisito conjunto com os desenvolvedores, os programadores daquela funcionalidade. A partir desse momento os desenvolvedores partem para a programação e os engenheiros de QA começam a criar casos de testes funcionais para cobrir os cenários que foram solicitados pelo PO, pelo gerente de projeto, pelo cliente. No momento que os programadores finalizam a programação eles devem criar os testes unitários, uma primeira estratégia de teste que nós utilizamos, os testes unitários para cobrir aquele código, e os engenheiros de QA, terminando o design dos casos de teste, preparam ciclos de teste pertinentes para aquela funcionalidade. O que nós indicamos relação à teste unitário é que os projetos que tenham interface gráfica tenham pelo menos 50% de cobertura dos testes unitários e para os projetos que não têm interface gráfica, como o microservices, por exemplo, que eles atinjam 80% de cobertura. Feito isso, como nós trabalhamos com builds automáticos, processos de integração contínua, todo momento que a funcionalidade é "buildada", os testes unitários são executados e os próprios desenvolvedores já conseguem identificar e corrigir alguns defeitos. Quando o desenvolvedor diz que a funcionalidade está ok para os testes finais, a equipe de teste coloca isso ambiente similar ao de produção e executa os testes funcionais. Relação aos testes funcionais, para os engenheiros de QA, as estratégias que a gente mais utiliza são testes de integração, testes de sistemas e testes de performance. Alguns casos, quando o usuário final é mais crítico, a gente também realiza alguns testes de aceitação com o usuário. Então quando a funcionalidade está pronta a gente executa os casos de teste que foram desenvolvidos específicos para aquela nova funcionalidade. São os testes de sistema e teste de aceitação, para garantir que aquilo está como esperado. Feito isso, não tendo defeitos específicos naquele novo código, a gente passa para o teste de integração do ecossistema. A maioria dos sistemas que a gente trabalha, ele não é único, ele se integra, ele consome e expõe informações para outros sistemas. Então a gente tem que garantir que essas integrações estão funcionando. Embora não seja integração entre os componentes desse sistema, é integração entre os sistemas que compõem grande sistema de software. A gente realiza esses testes de integração para garantir que tudo está funcionando como o esperado relação à nova funcionalidade e aos outros sistemas que existem. Feito isso, não tendo mais defeitos nesse contexto, a gente passa para os testes de regressão, que é grande desafio. Os profissionais que estão trabalhando com aquela funcionalidade precisam entender o ecossistema para identificar os impactos que aquela nova funcionalidade pode ter e selecionar os casos de teste de regressão, para garantir que funcionalidades já existentes, que já estão funcionando não tenham sido quebradas, que defeitos não tenham sido inseridos nessas funcionalidades que já estão funcionando, produção para os usuários finais. Feito isso, a gente faz o que se chama de sign-off, a equipe de QA dá o sign-off na versão e ela está apta a ir para a produção. Nós criamos uma serie de documentos que vão desde de detalhes técnicos, as builds que foram criadas, os testes que foram executados, os defeitos possíveis que foram levantados e foi feito o que a gente chama de bumpar, decidiram que eles não seriam corrigidos naquela funcionalidade porque são defeitos que não são críticos, os defeitos que foram levantados e que foram corrigidos. Então a gente prepara uma especificação técnica para manter o histórico de todas as versões de determinado sistema e também preparamos uma documentação para o usuário final. Quando estamos inserindo uma funcionalidade nova a equipe de QA é responsável por especificar como aquela funcionalidade está funcionando, como ela foi implementada, como para executar determinada ação o usuário tem que lidar com o sistema, e nós repassamos essa documentação para o gestor do projeto, que é quem lida com o usuário final, para que ele prepare materiais de treinamento adequado e assim por diante. Dos grandes desafios, do meu ponto de vista, no contexto de qualidade de software, para os engenheiros de qualidade de software, para esse ambiente, uma é que o tempo sempre é curto para todos os profissionais que estão envolvidos, mas não conseguimos colocar nada produção sem estar codificado. Então ainda no dia-a-dia é normal que as pessoas envolvidas falem "está codificado, está pronto". Nós temos a sorte de estar ambiente que o teste é mandatório, não se coloca nada produção sem o teste, mas, pelo negócio, a prioridade de todo software é entregar valor para business, para negócio, para uma empresa, para uma companhia que precisa daquela funcionalidade. Então o tempo do mercado também tem que ser respeitado. Dos grandes desafios que a gente encontra é selecionar o mínimo suficiente de casos de teste para encontrar os defeitos mais críticos, priorizar esses defeitos e ter o conhecimento de todo o ecossistema, de todo o negócio do cliente inclusive, para poder falar "esse defeito tem que ser corrigido, eu como QA não vou liberar esse sistema com esse defeito" e também dizer "eu, como QA, entendo que esse defeito não é crítico para o meu usuário final, então eu posso liberar essa versão agora e aceitar que esse defeito seja corrigido posteriormente". Isso exige conhecimento de negócio que muitas vezes nós não estamos preparados. Nós fazemos faculdade de computação e nós não temos domínio sobre processo de negócio financeiro, contábil ou processo de negócio inovador. Nós trabalhamos aqui dos sistemas com a área de aviação e ninguém é experiente aviação, mas nós temos que aprender com o cliente para podermos tomar essa decisão por eles, qual é o defeito que vai ter grande impacto produção e qual é o defeito que eu aceito deixar para uma próxima versão porque eu prefiro colocar a funcionalidade no ar hoje e deixar esse defeito para corrigir depois porque observando a empresa como todo, o meu cliente como todo, eu aceito esse risco. Então esse é desafio para os profissionais da área e para desenvolvimento de software como todo. A seleção e priorização dos casos de teste também é desafio porque a gente não pode encarecer muito o projeto. Todo mundo que trabalha com teste gostaria de testar tudo sempre, o tempo todo, mas isso encarece. Então nós temos que ter mente o objetivo final de software, que é entregar valor para o cliente. Sim, nós temos que observar e selecionar os melhores casos de teste para cobrir os cenários mais críticos e não deixar de maneira nenhuma que erros críticos sejam encontrados pelos usuários finais, mas algum defeito, que a gente chama de corner case, cenário que não é o comum produção, mesmo sabendo que tem algum defeito, a gente tem que aceitar para que o objetivo final seja alcançado o quanto antes. Estimar caso de teste indústria é desafio. Aqui nós trabalhamos com uma ferramenta que chama Zephyr, é plugin pago de sistema que chama Jira, que é usado mundialmente, é dos mais famosos para isso, mas ainda assim eu particularmente sinto falta de ferramentas para estimar casos de teste ou para que ajude o profissional de teste a estimar os casos de teste. Nós temos técnicas na literatura e aqui nós tentamos aplicar as técnicas pontos por caso de teste sempre que possível, mas isso toma tempo, então é importante que os profissionais estejam muito bem treinados para que eles consigam executar toda a teoria de teste, bom design de caso de teste, estimar esse caso de teste baseado uma técnica, caracterizar os casos de teste de acordo com a estratégia que ele está sendo criado, reunir os casos de teste nos ciclos adequados, as switches de casos de teste, para cada uma das funcionalidades, para cada uma das etapas: aceitação, integração, regressão. Fazer isso de uma forma rápida porque isso é a qualidade do trabalho que a gente executa e aí impacta diretamente na qualidade do produto. Eu acredito que os maiores desafios na indústria ainda sejam os clássicos desafios de teste: seleção, priorização, estimativa e design de casos de teste porque exige habilidades técnicas do profissional, mas também uma habilidade de conhecer do negócio, entender da feature e o poder de análise, que é algo que, do meu ponto de vista, a gente só consegue exercitando muito, todos os dias, trabalhando com requisitos, criando casos de teste e tendo pensamento crítico sobre aquilo que é criado. Então relação à técnicas, eu acho que na indústria hoje a técnica funcional é muito mais utilizada do que a estrutural, e de estratégia, testes unitários, testes de sistemas, de integração e de performance são essenciais para toda empresa que quer trabalhar com testes de software e ter processo de software bem definido para garantir o sucesso do produto final e entregar valor para o nosso cliente.
