Por Robson Catarina em de de

5 erros mais comuns para quem esta começando em testes de software

5 erros mais comuns para quem esta começando em testes de software

Em momentos atípicos como estes que estamos passando de pandemia, o mercado de trabalho acaba se tornando praticamente um touro mecânico: vira para um lado, vira para o outro, sacode daqui, sacode dali e acaba derrubando vários pelo caminho.

Alguns olham para estes momentos com olhos de pavor, e outros enxergam oportunidades. Conheci muitos nesta situação, que enxergaram as oportunidades da TI e começaram a migrar suas carreiras para essa área. Alguns já migraram e outros ainda estão migrando, mas destas pessoas e de outras que entraram na área de qualidade de software, vejo certos erros que eu mesmo cometi por diversas vezes e venho compartilhar com vocês 5 dos erros mais comuns, com o objetivo que busquemos sempre a melhoria continua, não só do lado profissional como também no pessoal.

Ficou curioso? Então continue a leitura para conferir quais são eles!

1 | Achar que a automação é a bala de prata

Aqui nós já começamos com um ponto bem polêmico e quero deixar bem claro que não sou contra automação! A automação é sim muito importante e nos dá ganhos bem expressivos principalmente em momentos que precisamos revisar uma aplicação que passou por ajustes críticos,  mas um grande erro é o foco excessivo que se dá para automação principalmente após a euforia dos primeiros resultados.

Vejo muitas pessoas focadas em demasia na automação e esquecem de se aperfeiçoar/praticar os fundamentos dos testes e técnicas básicas como testes de usabilidade ou testes exploratórios. Confira meu outro texto, aqui no blog da TT sobre 10 principais tipos de teste de software.

Dependendo do nosso contexto, da criticidade da demanda, do tempo disponível entre outros fatores, muitas vezes é necessário que nós levantemos as mangas e venhamos a nos debruçar sobre a aplicação de forma manual, afinal, precisamos nos colocar no lugar do usuário final.

 

2 | Estudar apenas ferramentas da moda

Nessa minha jornada de quase 10 anos na área de testes, vivenciei muitas coisas e vi o mercado da área de qualidade evoluir rapidamente de diversas perspectivas. Dado o fato de que é muito fácil encontrarmos materiais e tutoriais falando de diversas ferramentas, vejo com frequência pessoas em dúvida sobre por onde começar, e normalmente acabam optando pela que é mais popular. Gosto sempre de reforçar que não há problemas em começar pela mais popular, mas é importante lembrar de que uma ferramenta de testes não é como um clube de futebol, onde devo focar apenas nela e “defendê-la” como se todas as outras fossem ruins.

O mercado está repleto de ferramentas e nos limitarmos a apenas uma ferramenta é o mesmo que nos limitarmos para o mercado. Além disso, de nada adianta estudar uma ferramenta que é popular atualmente se o mercado não a utiliza. Precisamos sim nos atualizar sobre as novas ferramentas mas não fincar raízes apenas nelas. Ademais, é de suma importância que, mais importante do que a ferramenta em si, é o conceito que está por detrás dela, afinal se não sabemos os alicerces dos conceitos de testes, não vamos conseguir extrair o melhor da ferramenta, seja ela qual for.

 

3 | Falta de comunicação

Este é um ponto que é simples e complexo ao mesmo tempo. Por ser algo com conceito muito simplório e abstrato, muitas vezes acaba sendo negligenciado e mal desenvolvido por muitas pessoas. Quando falo sobre falta de comunicação, não falo apenas sobre a falta de interação entre as pessoas, mas também do objetivo da comunicação.

Tornando um pouco mais palpável o tópico, vejo muitas pessoas que estão começando com medo de perguntar, como se fossem ser rechaçadas e perdem grandes oportunidades de aprendizado. Que fique claro: se você está começando na área/recém começou, é totalmente compreensível os questionamentos por mais simples que pareçam, afinal as pessoas do seu time já esperam por eles.

Se tratando da área de testes de software, isso se torna mais necessário ainda pois um Analista de Testes precisa estar completamente a par do projeto e sem dúvidas. Uma simples dúvida pode ser o suficiente para gerar defeitos em um software e consequentemente trazer prejuízos, sejam eles tangíveis ou não.

 Outro texto que é interessante você dar uma olhada é esse aqui, confira: O que você precisa saber para se tornar Analista de Testes

 

4 | Falta de documentação

Outro ponto polêmico. Criar ou não cenários de testes?
Registrar os defeitos ou só colocá-los em post-its e deixá-los no quadro? Mas e se o projeto tiver prazo apertado? São várias as combinações possíveis para a discussão, e a resposta para este tópico é: depende. 

Apesar de soar como uma resposta genérica, o ideal é analisarmos a situação pois cada caso é um caso. Ainda assim, pode se dizer que na maioria das vezes devemos sim, no mínimo, registrar todos os defeitos encontrados e mapear os cenários de testes antes de começarmos uma bateria de testes, por mais que esta tarefa seja bem trabalhosa e cansativa.
Muito melhor que o achismo para tomada de decisões, é uma métrica por exemplo de quantos bugs foram encontrados em determinada funcionalidade, ou de qual o percentual de testes executados  versus o prazo restante para a homologação, e para isso os registros são cruciais. Vejo muitos times entregando softwares recheados de bugs e que, se tivessem feito a simples tarefa de mapeamento de cenários, certamente teriam feito uma bateria de testes mais completa do que simplesmente executando os testes que viessem à cabeça na hora. 

Além disto, estes registros ficariam para os próximos analistas de testes que podem vir a testar tal software no futuro, auxiliando no conhecimento do histórico de problemas e consequentemente deixando-os mais bem preparados para as validações.

 As habilidades que o profissional de TI precisa desenvolver [2021]

 

5 | Não olhar para o todo

E por fim, a famosa visão holística, ou “big picture” como alguns falam. O ponto aqui é que um Analista de Testes não pode simplesmente ficar fechado no seu mundinho achando que a bateria de testes que ele escreveu é o suficiente. Na verdade, quase sempre a bateria de testes que o Analista de Testes escreveu é somente a ponta do iceberg

Nós devemos sim interagir com o restante do time, validar se não esquecemos de nada, confirmar com outros times envolvidos direta ou indiretamente se temos outras combinações, se é necessário um teste integrado entre times, colher feedbacks… Enfim, devemos sempre nos monitorar para evitar aquela mentalidade de criação de silos, onde cada um faz sua determinada tarefa na sua “caixinha”. 

Devemos tirar o máximo proveito de uma coisa chamada diversidade cognitiva que nada mais é do que a construção de um determinado produto/tarefa com outras pessoas (principalmente as que pensam diferente). Isso é extremamente enriquecedor tanto para o que estamos fazendo quanto para nós mesmos enquanto profissionais. Saia do comodismo, pense fora da caixa, olhe a sua volta, se desafie constantemente pois se você não fizer isso por você mesmo, ninguém vai fazer.

Ufa! Bastante coisa né? Qualquer dúvida, estamos à disposição! Se quiser saber mais sobre a nossa Formação de Testes de Software, é só clicar aqui!

Não esqueça de nos acompanhar em nossas redes sociais. 

Robson Catarina

Autor: Robson Catarina

Analista de Testes Sênior | CTFL | CTAL-TA

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

POSTS RELACIONADOS

« Voltar para o início do blog