Primeiramente é importante entender que ter uma equipe de Testes robusta e madura é um INVESTIMENTO no seu projeto e/ou empresa.
O que todo mundo sabe é que, para aumentar a qualidade e a satisfação do cliente, deve-se investir em Testes. Isso está mais do que batido e inclusive é o primeiro ou segundo slide de qualquer pessoa que vá apresentar algo que seja ou envolva Qualidade ou Testes de software, seja um trabalho acadêmico ou uma apresentação comercial.
O que dificilmente fica claro para o gestor que decide optar por esse salto de qualidade no seu projeto, é justamente o significado dessa qualidade. Podem perceber que "ter qualidade no seu projeto" é algo meio que subjetivo. Qualidade em quê? Ter mais testadores na equipe? Ter menos bugs no projeto? Ter o cliente mais satisfeito? Contratar só analistas e desenvolvedores super experientes? O que é qualidade?
É importante especificar qual é o salto de qualidade que vai ser dado. Além de ter menos bugs e maior satisfação do cliente, é claro.
Quer aumentar a velocidade da sua equipe de desenvolvimento? Invista em Testes! Hã? Como?
Vamos ser práticos (e esse é mais um motivo pelo qual eu digo que metodologia ágil só é útil com projetos inovadores):
Imaginemos a seguinte situação, uma pessoa começa a desenvolver e a outra começa a criar os casos de teste. Por mais apertado que fique o cronograma, se os casos de teste estiverem prontos e o ambiente de testes populado com a massa de dados apropriada, a execução vai rápido. Garanto que para cada 40 horas de desenvolvimento, uma hora de execução de testes é suficiente (sim, é. acreditem - o Teste de regressão ainda mais curto). É simples e isso evita uma série de problemas, tais como retrabalho (os bugs existem, é só questão de analisar a hora que decidimos corrigi-los), custo (fica caro tirar um profissional de outro projeto para voltar a corrigir bugs para aquele projeto em desenvolvimento), estresse (nenhum cliente fica feliz em achar bugs em produção, por mais que eles cobrem a entrega no prazo previamente negociado) entre outros.
É importante entenderem que eu não prezo por sistema testado "nas coxas", mas o que eu venho percebendo é que se gasta cada vez mais tempo testando do que desenvolvendo. Quando poderia ter sido acelerado. Uma semana de Testes de regressão, a não ser que o sistema seja absurdamente grande ou a equipe de testes absurdamente pequena, já é mais que suficiente.
Ou seja, na minha opinião, a função do Testes de software é dar suporte e velocidade ao desenvolvimento. Porque os analistas e desenvolvedores são os caras, e não nós (rs).
Quais são as necessidades de um tester?
Há 6 dias
3 comentários:
Luiz,
Concordo parcialmente com a sua visão. Trabalho atualmente com testes de dois sistemas bem grandes, e observo que o que tem mais nos tomado tempo são os testes de regressão, pois se nas primeiras iterações demoravamos 5 dias para testar todo o sistema, nas pxs. conseguimos baixar até p/ 3 dias esse tempo, mas ainda temos de testar toda a nova implementação integrada com o que já estava construido. Nosso objetivo tem sido mostrar aos implementadores os pontos onde o sistema não está funcional e isso faz com que o erros sejam corriguidos com rapidez, oq acarreta num sistema mais coeso.
Parabéns pelo blog, abraço!
Só uma pergunta, como vocês testam as demais funcionalidades do sistema (testes de regressão)?
Se antes demoravam 5 dias e agora demoram 3 dias, o que fizeram para reduzir este tempo? Automatizaram? Priorizaram os casos de teste? Smoke test?
abraços
Opa. Desculpa a demora em responder. Na minha visao, o esforço aplicado p/ os testes de regressão cai devido:
a) Os testadores passam a conhecer mais do negócio, e estão mais hábeis em manusear o sistema e a documentação.
b) Sim, também utilizamos testes automatizados. Mas temos um sério problema de enxergar o que os testes automatizados 'testam'.
c) A priorização dos Casos de teste também ocorre. Mas fica para o final da iteração, pois no inicio gosto de ter uma visao de todo o trabalho que teremos. E caso, a gente veja que não vai dar para cumprir, vamos priorizando.
Pra ser sincero, vejo que a execução de testes é um pouco imensurável, porque somos bloqueados por diversos fatores, como por exemplo: ambiente cai, a funcionalidade tem mais defeitos que o esperado e por conta disso passamos um bom tempo escrevendo relatos, etc...
Postar um comentário