Estamos em uma era em que todos os dias nascem softwares novos. Existem softwares para tudo e para todos dispositivos. O que não pode ser esquecido é que um software bonito, mas que não funciona pode significar prejuízo, muitas vezes vale mais a pena ter um software feio funcional.
Com isso em mente, pode-se dizer que o principal erro é não testar, não ter uma equipe de teste apropriada. Mas fora isso, neste post iremos discutir sobre os erros clássicos em teste de software.
1: Atribuir a responsabilidade pela qualidade unicamente à equipe de teste
A qualidade do software deve ser de preocupação de todos, inclusive dos desenvolvedores e principalmente deve ser um assunto importante a ser tratado pelo gerente do projeto.
Antes da primeira linha de código, deve-se ter claramente definido qual nível de qualidade alvo e como se fazer para mensurar e garantir o mesmo ao final do projeto. Isso inclui estimar quanto será gasto com testes, em quanto tempo e quais técnicas. Isso nos leva ao próximo erro.
2: Começar a testar tarde demais
A equipe de testes já sabe o que esperar, já sabe o que é bom e ruim, já sabe o que é uma boa interface ou um bom projeto de usabilidade. Sabendo disso, eles também devem fazer parte da fase de projeto, de concepção, analisando telas antes mesmo de elas serem programadas.
Não faz sentido esperar uma tela levar 2 ou 3 dias para ficar pronta e funcionando para a equipe de testes dizer que não está com uma boa usabilidade. Esse erro poderia ser evitado antes, na fase de planejamento. Lembre-se de que quanto mais cedo um erro for encontrado, menos recursos terão que ser usados para corrigi-lo.
Isto dito, além de reportar os erros com clareza, planejar e executar os casos de teste, a equipe de testes pode ser muito útil no planejamento do software.
3: Usar o teste como um trabalho temporário para programadores novos
Por um vício, pode ser que o cargo de um testador seja visto como caminho para o desenvolvimento, infelizmente. Quem quer ser programador deve ser posto para programar e não para testar.
Testar requer organização, meticulosidade, determinação e paciência, atributos que podem não se encontrar em novos programadores. Não comprometer os resultados dos testes por estar com a equipe não especializada já é um bom motivo.
Mas fora isso ainda há um fator agravante, eles não almejam isso, estão ali esperando para ir para o desenvolvimento na primeira oportunidade, e pior, quem realmente for um bom testador pode ficar preso em um cargo que não lhe agrada. Não parece justo. Desenvolvedor e testador são papéis diferentes e não tem necessariamente uma relação.
4: Insistir que testadores sejam programadores
Também existe o outro lado da moeda, um bom testador não será necessariamente um bom programador. Para um ótimo testador não deve-se oferecer o desenvolvimento como uma promoção a sua carreira. Valorize-o sendo Analista de Qualidade.
5: Não treinar e nem motivar os programadores para testar
Ter um setor de qualidade de software não isenta os desenvolvedores de testarem suas releases antes. O setor de qualidade não é um serviço terceirizado de testes para os desenvolvedores, portanto não deve ser visto como tal.
Caso haja o vício de não testar as coisas direito antes, a release corre um alto risco de se estender mais do que o planejado. Quantas vezes será aceitável uma release ou um sprint voltar com erros para os desenvolvedores consertá-los? Isso não pode atrapalhar a estimativa inicial.
Uma boa solução para este problema é observar quantos RC (releases candidates) são necessários para que uma versão estável seja lançada. Os desenvolvedores têm que ser acostumados a ter como meta a aprovação do primeiro RC, e isso deve ser comemorado. Em contrapartida, ao final de cada sprint gere relatórios estatísticos que comprovem a qualidade dos últimos RCs, e discuta com a equipe (programadores e testadores) o porquê de certas versões ou softwares precisarem de mais RCs para serem aprovados.
6: Dar mais atenção à execução dos testes do que ao seu projeto
A execução de um teste pode ser a tarefa mais simples de um testador. Claro, requer atenção, principalmente na descrição dos bugs encontrados. Mas saber o que testar e de que forma testar é mais importante. Os testes também devem ser planejados com base na descrição inicial do software ou do changelog da versão. Os pontos críticos devem ser levantados para que sejam cobertos com eficiência.
Na prática isso significa ter na sua equipe de qualidade no mínimo um testador experiente, líder, que possa fazer esse planejamento com eficiência. A execução dos casos de teste em si podem ser deixadas para os testadores de menor experiência.
7: Não rever os projetos de teste
Este é um processo que deveria acontecer no mínimo a cada nova versão, ou a cada sprint. Cada função nova em um software pode esconder bugs. A inexistência de bugs em uma função nesta versão não significa que esta será livre de erros nas próximas versões.
Uma falha na atualização dos casos de teste pode deixar uma área descoberta no futuro, mesmo que ela seja testada hoje. Posteriormente ela pode ser esquecida, por fazer parte de uma versão anterior, e não ser adicionada a um caso de teste específico e consequentemente não será testada.
8: Informar problemas incompleta ou ineficientemente
Esta é uma parte importante no dia-a-dia de um testador: saber relatar um problema com um nível profundo em detalhes. Um bug apenas com um título pode não ser suficiente para que o desenvolvedor consiga reproduzí-lo e corrigí-lo.
Testadores neste momento tem que botar em ação sua habilidade descritiva, dando um passo a passo completo de como reproduzir este bug, o contexto em que esta função foi testada, os parâmetros utilizados e, se for possível, uma imagem que apresente o sintoma. Não há nada mais frustrante para um desenvolvedor do que procurar por um defeito mal informado e com poucas informações. O mais comum é que o mesmo peça para o setor de qualidade o descrever melhor. Perceptivelmente, isso pode gerar um círculo vicioso, fazendo com que a equipe como um todo perca tempo.
9: Tentar automatizar todos os testes
A automatização de testes pode sim ser utilizada a seu favor, desde o desenvolvimento ao processo de homologação do software pela equipe de qualidade. Mas não exagere nesse quesito. Por mais eficientes que sejam as ferramentas de testes automatizados, elas não irão substituir por completo a mente do usuário.
Crie um conjunto básico de testes automatizados que possam evitar o uso de trabalho manual para descobrir erros básicos. Com o passar do tempo e a evolução do software, esse conjunto pode crescer e melhorar a eficiência do mesmo. Porém não foque em ter um conjunto de testes automatizados que cubram 100% do seu software, isso pode ser um desperdício de recursos. Existem características que só um testador pode avaliar.
E então, você já cometeu algum desses erros? Acha que deixamos algum importante de fora da lista? Deixe um comentário!
