Tag: QA

Categories
Controle de qualidade Testes

Você automatiza seus testes de aceitação?

O Danilo Sato escreveu um post muito bom sobre automatização de testes de aceitação:

“Muitas equipes XP não automatizam seus testes de aceitação. Essa é uma afirmação dura, porém muito comum de acontecer. A equipe abraça TDD e testes de unidade automatizados, porém quando chega a hora dos testes de aceitação, a coisa complica. Por que isso acontece? Como melhorar essa situação?”

Testes de aceitação são essenciais e automatizá-los é extremamente desejável!

Quem acompanha meu blog já deve ter percebido que teste de software é um assunto que me interessa bastante. Ultimamente tenho trabalhado muito focado na qualidade dos softwares que entregamos na minha equipe e por isso estou constantemente explorando novas maneiras de testar ou procurando melhorar as maneiras antigas.

Nos últimos sprints temos feito da seguinte forma: o desenvolvedor que trabalhar no desenvolvimento de uma história não pode fazer testes de aceitação da mesma. Desta forma cada um sempre testa o que o outro fez (estamos usando Selenium para este tipo de teste).

Ao fim do 4o. sprint temos uma suite de testes expressiva que cobre praticamente 100% do que foi desenvolvido. Realmente percebemos que aqueles bugs extremamente simples que normalmente são encontrados em QA ou mesmo em produção foram encontrados em tempo de desenvolvimento e corrigidos com rapidez.

Rodando automaticamente estes testes são uma ferramenta poderosíssima para ajudar a garantir a qualidade da aplicação.

Recomendo fortemente a leitura do post do Danilo!

Categories
Controle de qualidade

Testes com Selenium em vários browsers

Uma empresa chamada Reality QA criou um serviço interessante. Eles testam a sua aplicação web em vários browsers e sistemas operacionais diferentes utilizando como roteiro de teste um script Selenium. Os testes rodam automaticamente nas plataformas alvo e são gerados relatórios e screenshots dos testes na medida que eles vão acontecendo.

Para ver como funciona, veja o screencast produzido pela empresa.

Como essa ferramenta é beta eles ainda não cobram pelo serviço mas já tem um link de “Buy” preparado no site.

Hoje já é possível testar em vários browsers utilizando o Selenium Core só que você tem que fazer tudo manualmente (em cada browser que irá executar o teste você tem que abrir e executar o script na mão). Talvez eles tenham usado o Selenium Remote Control e criado proxies para várias plataformas diferentes.

Achei essa idéia interessante, vou estudar uma forma de fazer alguma coisa do tipo aqui para a empresa. Depois eu conto como foi.

Categories
Controle de qualidade Engenharia de software TDD

Qual é o percentual ideal de cobertura de testes?

Ontem estava tendo uma discussão com um amigo aqui do trabalho sobre cobertura de testes.

A nossa discussão começou quando eu fui mostrar para ele um teste de aceitação em Selenium que eu fiz para uma parte do sistema de gerenciamento de conteúdo da empresa.

Ele estava argumentando que acha que os testes de aceitação com Selenium não são tão interessantes porque eles são muito frágeis – alterações na interface podem quebrar os testes. Realmente isso pode acontecer. Mas se acontecer é só reescrever o teste, oras! Antes dele quebrar ele será executado várias vezes e só nisso várias horas preciosas podem ser economizadas.

Repare o seguinte: você efetivamente testará as telas do sistema navegando nele, incluindo, editando e removendo itens. Se este trabalho pode ser automatizado, porque não fazê-lo? Não é melhor gastar o seu tempo para elaborar novas táticas de testes e novos testes de outras partes do sistema ao invés de ficar navegando em todas as páginas “manualmente”?

Discussões deste tipo me fazem lembrar do manifesto Testivus, que dentre outras coisas prega que: “An imperfect test today is better than a perfect test someday” (Um teste imperfeito hoje é melhor do que um teste perfeito algum dia). Mesmo que os seus testes não sejam os melhores do mundo e que vez ou outra precisem ser corrigidos, é melhor tê-los do que não ter teste nenhum. Com o tempo a cultura de testes fica impregnada na equipe e os testes vão ficando cada vez melhores e mais numerosos.

É claro que eu não concordo que os testes possam ser um monte de lixo que não testam nada. Eu só acho que não se pode ter uma abordagem dogmática em relação aos testes. Se a sua aplicação tem 50% de cobertura de testes eu não acho isso ruim. Aliás, é BEM mais do que a maioria que existe por aí. Mesmo assim você pode (deve) testar bem mais.

Concluindo, eu particularmente gosto muito de utilizar a abordagem de desenvolvimento guiado por testes (TDD). Com TDD você tem uma cobertura de testes significativa já que os testes vão sendo escritos na medida que a aplicação é escrita. Porém se isso não puder ser feito por algum motivo, não acho correto estipular um percentual mínimo ideal de cobertura de testes. Só acho que deve-se testar muito e quanto mais, melhor.

Coincidentemente saiu ontem uma matéria no InfoQ sobre este mesmo assunto que vale apena a leitura.