Aumentando a Velocidade da Execução dos Testes com Selenium

Quando falamos de automação de testes um dos principais benefícios citados é a possibilidade de obtermos a execução de um ciclo completo de execução num espaço de tempo bem inferior aos testes manuais. No entanto, quando começamos a nos aprofundar no assunto vemos que existem diversas práticas que podem ser utilizadas na codificação dos testes para permitir uma eficiência ainda maior.

Uma das possibilidades para o aumento da velocidade de execução é a utilização dos Headless Browsers, tema que inclusive foi abordado pelo Elias Nogueira, do excelente blog Sem Bugs, em sua apresentação sobre CasperJS. Resumindo numa única frase o Headless Browser é um navegador sem a interface gráfica.

Estudando sobre o assunto vi que já existe uma implementação do WebDriver para Selenium, que utiliza o PhantomJS e de maneira bem simples permite que possamos nos beneficiar da utilização de um headless browser. O projeto chamado Ghost Driver funciona perfeitamente e sua integração ao seu projeto é extremamente fácil utilizando o Maven.

Para adicioná-lo ao seu projeto basta seguir as orientações do projeto no github e se ainda tiver dúvidas basta seguir as orientações do post no blog Assert Selenium do Manoj Kumar. Além disso, a excelente apresentação abaixo, realizada pelo Ivan de Marino, um dos responsáveis pelo projeto, resume bem os benefícios da utilização e as orientações básicas.

 

Fiz um teste rápido num dos meus projetos e o ganho de velocidade foi significativo, como exemplificado pela imagem abaixo:

Comparação

Ainda não conhece o Selenium? Em outubro estarei ministrando um curso presencial no CESAR.EDU, onde abordaremos os conceitos básicos para utilização do Selenium WebDriver apoiado por diversas práticas em sala, segue o link para mais informações:

banner_curso2

Validação de layout automatizada com Selenium

Validação de layout nos diferentes browsers é um problema comum em diversos projetos de desenvolvimento de software. Afinal, assegurar comportamento e aspectos visuais adequados em diversas combinações de browser/SO é algo que demanda bastante tempo.

Durante essa apresentação na SeleniumConf 2013, Frank O’Hara apresenta um solução, que em conjunto com o Selenium, permite de maneira automatizada indicar erros de layout na aplicação.

Ainda não tive a oportunidade de utilizar a solução, mas parece bem simples associá-la ao Selenium.

Links do projeto:

RedGlass github

DomReactor github

DomReactor

E vocês ? Conhecem alguma outra proposta de automação para validação de layout? 

O que fazer quando o defeito está no teste ?

Contribuir para o aumento do nível de confiança, prevenir e encontrar defeitos estão entre os principais objetivos que queremos alcançar quando testamos um software. Porém, para atingirmos essas metas não existe uma simples receita de bolo e precisamos estar sempre atentos para maximizar as nossas chances de entregarmos constantemente software de qualidade e que atenda às necessidades dos clientes.

Apesar de nossos esforços, invariavelmente temos que lidar com os defeitos escapados, que normalmente implicam em stress, re-trabalho e desgaste na relação com o cliente. Em meio ao problema, uma das primeiras ações que temos é a análise da causa raiz, ou seja, identificar o porquê do defeito ter ocorrido e consequentemente do mesmo não ter sido identificado nas etapas anteriores de validação.

Diversos podem ser os motivos para a falha na detecção do defeito, por exemplo:

– Cenário de teste não estava coberto.

– Teste existia, mas não foi priorizado para o ciclo de execução.

– Teste existia, foi priorizado, porém não foi executado corretamente.

– Teste existia, foi priorizado, executado corretamente, porém diferenças de ambiente não permitiram a detecção da falha.

– Etc.

You are doing it wrong

Porém, ainda há um outro motivo, que talvez seja um dos mais frustrantes – O teste existe, mas está errado.

Quando isso acontece, independente de planejarmos corretamente, o teste, seja ele manual ou automático, nunca nos trará o resultado correto e a falha inevitavelmente aparecerá em produção. Nesses casos, ainda temos como dificuldade adicional o fato de que a re-execução do nosso teste não ajudará na reprodução do erro, podendo inclusive gerar ruído na comunicação e dificuldades na identificação da causa do problema e consequentemente em sua correção.

Identificar testes com defeito não é algo simples e corremos o risco de executá-lo diversas vezes e confiarmos em resultados enganosos. Para tentar minimizar esse tipo de situação, podemos realizar algumas ações:
– Revisar os testes existentes

– Se forem testes manuais, mudar o responsável pela execução

– Aprofundar-se no funcionamento de mocks e stubs utilizados para teste

– Conhecer as limitações das ferramentas utilizadas

– Revisar as pré-condições e o ambiente de validação

E você já enfrentou o problema de ter falhas escapadas devido a testes defeituosos? Que ações tomou para tentar evitar que o problema se repetisse?

Quais são as necessidades de um tester?

O que o motiva no seu trabalho como testador? Stephen Janaway, profissional de testes há 12 anos, tenta nos ajudar a entender nossas necessidades profissionais e a determinar como você pode deixar de sentir que trata-se apenas de um trabalho para um estado de “auto-atualização”.

A seguir, apontamos alguns dos principais aspectos discutidos por ele.

Stephen inicia fazendo uma relação com a pirâmide das necessidades de Maslow, tentando entender como as principais necessidades dos seres humanos são atendidas. Considerando, que de maneira geral as pessoas tem um grande desejo de atingir seu potencial, de progredir. Para Maslow, as pessoas que alcançaram o ponto de auto-atualização tinham características comuns, como: criatividade, espontaneidade, visão clara do certo e errado, etc.

Em seguida, ele monta a pirâmide associando cada um dos grupos as necessidades dos testadores, tentando esquecer descrições de cargo e funções, mas considerando o que nos satisfaz como testadores.

Stephen aborda que no nível mais básico (aceitação) a função é vista como algo que qualquer um pode fazer e que não é respeitado ou apoiado pelos superiores. No nível seguinte os testes passam a um nível de aprendizado, onde os mesmos são incluídos, mas vistos como algo irritante. No terceiro nível começa a existir o respeito e os testers são vistos como parte do time, consultados e respeitados. Já no nível de interação o negócio depende e percebe o valor adicionado pelos testes. Por fim, chegamos ao grupo onde há o reconhecimento interno e externo da comunidade, onde ele cita Maslow “O que um homem pode ser, ele deve ser.”.

Imagem1

Por fim, o palestrante pergunta: Em que nível você acredita estar? O que pode fazer para subir ou se manter no topo ?

Segue, abaixo, o vídeo da palestra, são apenas 15 minutos, bem objetivo e vale a reflexão.

TestBash 2.0 – A Tester’s Hierarchy of Needs – Stephen Janaway from Software Testing Club on Vimeo.

Os testes estão atrapalhando a qualidade?

No primeiro post de 2013 relacionado a testes, compartilho com vocês uma palestra que encontrei do James Whittaker na conferência StarWest (Software Testing Analysis and Review) 2011. Largamente conhecido por suas contribuições a nossa área, ele questiona de maneira forte qual o verdadeiro papel dos testes.

James aborda diversas questões, que nos levam a refletir a importância de cada uma de nossas tarefas, por exemplo:

– Como ganhar respeito para os testes?

– Os testes são apenas uma disciplina que apoia o desenvolvimento?

– Os softwares estão ficando melhores… Porquê?

– Os bugs que você encontra poderiam ser encontrados pelos usuários?

– A única coisa que se mantém atualizada é o código.

O vídeo tem 55 minutos, mas tenho certeza que é um tempo bem investido. Assista e avalie como você se sente em relação ao seu trabalho com testes e principalmente como você pode torná-lo melhor?

 

“A única coisa que importa é o produto”

                                                                                     James Whittaker

Pessoalmente, concordo com muita coisa dita por ele no vídeo. Se prestarmos bastante atenção, o tom forte utilizado é apenas para chocar e chamar a nossa atenção a um problema visível e que muitos preferem empurrar com a barriga. Cada vez mais precisamos entregar valor, e ficar gastando tempo com atividades que pouco beneficiam o desenvolvimento do produto é um erro grave, do mesmo modo que o tempo perdido com trabalho que poderia ser melhor executado por ferramentas.

Você concorda com o cenário geral descrito por Whittaker? Ele, inclusive, aponta que estávamos enganados e que, sim, usuários e desenvolvedores podem testar melhor que uma equipe de testadores.

Link do post falando das ferramentas que o google tornou open-source para testes, mencionado no vídeo :

 – Google Testing Blog

No início do vídeo James faz um rápido questionário com a platéia, adicionei as perguntas abaixo em português, compartilhe conosco sua resposta:

Existe profissional de TI fazendo corpo mole na sua empresa?

Em qualquer profissão existem pessoas que fazem o conhecido “corpo mole”, alguns , inclusive,  se esforçam tanto na enrolação, que fica até difícil de percebermos, e acabam compensando sua pouca produtividade com grande esforço no “marketing pessoal” ou no “relacionamento” com os colegas.

As conseqüências das ações desse tipo de profissional nem sempre são imediatas ou graves, porém não há dúvida do custo e do prejuízo que essas atitudes podem ter no projeto e até mesmo na empresa.

Apesar desse tipo de profissional existir em todas as áreas e funções, no post de hoje, vamos focar em como reconhecer um testador desse tipo. Vamos apresentar algumas dicas para perceber quando um tester não está trabalhando como deveria, mas não se espante se você visualizar as mesmas características em outros profissionais.

Esse tipo de problema ainda ocorre, porque é fácil se safar sem realizar algum trabalho efetivo, e geralmente os líderes de equipe e gerentes de projeto não possuem as ferramentas e conhecimentos necessários para avaliar o progresso do trabalho de um testador. (Link – Artigo)

É extremamente fácil dizer que algo foi testado.

– Conhecimento superficial: Os profissionais que fazem corpo mole, em geral possuem conhecimento extremamente limitado sobre o sistema, afinal eles não teriam o trabalho de se aprofundar e conhecer os detalhes de cada requisito ou estória de usuário. Isso gera diversas consequências que facilitam a identificação desses profissionais:

1 – Encontram apenas Bugs superficiais e de pouco valor

2 – Não conseguem participar efetivamente das reuniões de planejamento

3 – Se limitam a fazer apenas o que lhes é pedido

Algumas mudanças na maneira de acompanhar o progresso do trabalho podem ajudar na tarefa de identificar esses profissionais:

– Evitar acompanhar a execução dos testes apenas através de relatórios gerados pelas ferramentas. Em seu lugar, questionar os envolvidos na execução, compreender o que foi testado, reportado e os próximos passos.

Outra ação, que talvez, apresente um resultado interessante é assegurar que diversas técnicas de execução são utilizadas: Automação, testes exploratórios, estáticos… Dessa forma, o profissional “corpo mole” precisará demonstrar seu conhecimento de uma maneira que permitirá uma melhor medição do seu trabalho.

Para finalizarmos o post, um vídeo divertido, onde George Constanza, da série Seinfeld, explica sua técnica para demonstrar que está cheio de atividades no trabalho.

E vocês? Que outras características observam nos Profissionais “George Constanza”?

Os 7 princípios do teste de software

No post – Os bons testes falham – falamos sobre um dos princípios de teste definidos no livro “Fundamentos de testes de software”. Hoje, compartilho com vocês dois vídeos, bem curtos, que resumem os 7 princípios definidos no livro. Os mesmos servem como referência, principalmente para aqueles que estão iniciando na área de testes.

O primeiro vídeo, exibido acima, aborda os 4 primeiros princípios, são eles:

1 – Teste demonstra a presença de defeitos.

Os testes reduzem a probabilidade que erros desconhecidos permaneçam no sistema, mas mesmo que nenhum defeito seja encontrado isso não é prova de conformidade.

2 – Teste exaustivo é impossível.

Mesmo com auxílio da automação, o número de combinações possíveis de cenários de teste numa aplicação é gigantesco, inviabilizando a possibilidade de se afirmar que TUDO foi testado.

3 – Testes devem iniciar o quanto antes e erros encontrados tarde custam mais para corrigir.

Iniciando o mais cedo possível no ciclo de vida do desenvolvimento do software, diminuímos o custo das correções e possibilitamos que erros de design, requisitos e arquitetura sejam encontrados no momento ideal. (Link para vídeo que aborda o assunto)

4 – Agrupamento de defeitos 

80% dos defeitos são causados por 20% do código. Ao identificar essas áreas sensíveis, os testes podem prioriza-las, enquanto ainda procuram por erros nas demais regiões.

O segundo vídeo, exemplifica os princípios anteriores e apresenta os 3 últimos pontos:

5 -Paradoxo do Pesticida

Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis, ou seja, não conseguem encontrar nenhum novo defeito. Por isso, os testes precisam ser revisitados com frequência.

6 – Teste é dependente do contexto

Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
7 – A ilusão da ausência de defeitos

De nada adianta o sistema estar correto funcionalmente, porém não atender a real  necessidade do usuário.

O Cliente

Entre todos os princípios listados, acredito que os números 3 e 7 representam os principais aspectos da nossa atividade. A busca constante por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que o sistema entregue atenda as reais necessidades do cliente, agregando valor ao seu negócio.

E vocês que aspectos consideram mais importantes nos testes de software?

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Entendendo os testes de performance

Todos já enfrentamos diferentes problemas de performance ao acessar nossos serviços favoritos na web. Lentidão e até mesmo indisponibilidade por longos períodos são problemas que ainda afetam a maioria das aplicações web.

Desse modo, podemos apontar que a Performance é um requisito não-funcional CHAVE para as aplicações web. E menosprezá-la pode causar grandes consequências.

Podemos definir os testes de performance, como:

Através dos testes de performance podemos simular o ambiente de produção, que a aplicação será submetida e avaliar como a mesma irá se comportar.

Lembrando que….

…de forma, que através da correta execução dos testes de performance, em conjunto com um monitoramento eficiente, podemos submeter diversos pontos da aplicação aos níveis de carga esperados e avaliar o seu comportamento.

No contexto das aplicações web: “Se um usuário tem de esperar muito (para acesso, processamento do lado do servidor, para formatação ou exibição do lado do cliente), ele ou ela pode decidir ir para outro lugar.” (Pressman, 2005)

Logo, desprezar esse requisito não-funcional pode gerar perdas irrecuperáveis para um negócio.

Do ponto de vista conceitual, fala-se sempre em três tipos de teste:

Performance: Avalia se a aplicação em teste atinge os requisitos em relação a questões como: tempo de resposta, throughput e utilização sob um nível de carga esperado.

Carga: Submete a aplicação a diferentes níveis de carga, com o objetivo de identificar a capacidade máxima de operação, além de gargalos, memory leaks, etc…

Stress: Avalia a robustez, disponibilidade e confiabilidade da aplicação em condições extremas (cargas muito elevadas, escassez de recursos)

Os três são comumente confundidos, porém como descrito cada um tem sem objetivo específico e a correta utilização dos mesmos durante o desenvolvimento poderá proporcionar um nível completo de informações sobre o comportamento da aplicação.

Por fim, é importante enfatizarmos que: “Caso não sejam executados da maneira correta, os resultados são, na melhor das hipóteses, inúteis e, na pior das hipóteses, enganosos, fazendo com que uma empresa menospreze ou superestime a capacidade de sua aplicação.” (Savoia, 2000)

Logo, é fundamental que, desde o início do ciclo de vida da aplicação, o RNF relacionado a performance seja priorizado, para que todo um ambiente de testes seja preparado de maneira adequada para simular o ambiente de produção e desse modo auxiliar o desenvolvimento a atingir o nível de qualidade desejado.

Gostou do assunto testes de performance? Participe, deixando seu comentário no post.

Em breve, voltaremos ao assunto falando do Apache JMeter.

E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!

Teste está morto parte 2

Como havia prometido, volto hoje ao tema abordado na semana passada. Tentarei destacar os principais pontos abordados no vídeo recomendado na parte 1. E antes de tudo, obrigado a todos pela participação no blog, na DFTestes e no Linkedin. A colaboração de vocês é fundamental para o enriquecimento da discussão.

A primeira grande contribuição do vídeo trata-se da abordagem inicial a evolução das metodologias de desenvolvimento e consequentemente as diferentes formas de atuação dos testadores. O palestrante, Alberto Savoia, a divide em dois grandes momentos: Old Testmentality e New Testmentality. Partindo da dependência completa dos documentos de requisitos, aos ciclos mais curtos das metodologias ágeis associados a uma maior integração entre desenvolvedores e testadores.

Durante a chamada Old Testmentality, as aplicações só eram entregues quando estivessem completamente “prontas”. Enquanto, que na New Testmentality, as entregas passaram a ser frequentes, exigindo uma participação constante do cliente na construção do “produto correto”.

Em seguida, Savoia começa a destacar os pontos que o levam a pensar que o teste tradicional está morto. Começando pelo o que ele chama de Post-Agile, a qual tem como diferencial o fato de apresentar uma postura mais casual e descuidada em relação aos testes ágeis tradicionais.

Segundo Savoia, a questão central cada vez mais é a construção do “produto correto” e não o simples desenvolvimento correto do produto ou das funcionalidades, ou seja, o objetivo é entregar um produto, que em primeiro lugar, atenda às necessidades dos usuários. Não basta ser apenas perfeito funcionalmente.

O palestrante nos lembra que de fato existem diversas aplicações fabulosas construídas utilizando os conceitos tradicionais, mas que a estrutura existente nos dias atuais, como a computação nas nuvens, permitem diminuir o foco da qualidade de software e transferi-lo para garantir que estamos construindo o produto CORRETO.

Um grande exemplo citado é o twitter, que tornou famosa sua baleia com a enormidade de vezes que deixava os usuários na mão, mas mesmo assim eles continuavam voltando, pois o produto era o desejado.

Nesse novo cenário, que se desenha, segundo Savoia, precisamos nos voltar para outro tipo de bug, o chamado idea bug, que podemos traduzir como bugs de conceito ou de idéia do produto.

Um produto errado é muito pior do que um produto com o comportamento errado.

A chave é testar a idéia, ou seja, garantir que estamos desenvolvendo o produto certo.

E como podemos testar a idéia?

A sugestão de Savoia é começarmos utilizando protótipos iniciais (pretotype), os quais ele diferencia dos protótipos tradicionais, por serem desenvolvidos e aplicados em curtos espaços de tempo. É fundamental testar cedo e falhar rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham)

Alberto cita ainda alguns dos sinais observados, que o levam a crer no fim dos testes tradicionais.

Sinais do Testpocalypse:

– Diminuição no numero de contratações
– Comoditização dos testadores
– Saída dos antigos líderes e ausência de novos
– Mais e mais empresas partindo para o Post-Agile

Acompanhado essa corrente de mudanças existem enormes oportunidades. Savoia enfatiza a crescente necessidade do surgimento de novos líderes na área de testes, com uma mentalidade diferente, e que possam conduzir essa etapa de transição. Onde, como o mesmo aponta, ainda conviveremos por um longo tempo com as diversas formas de teste. (BdB – Imagine um mundo sem Bugs no Software)

Por fim, um dos slides afirma “Test is dead. Don’t take it literally, but take it seriously.”, traduzindo, “Teste está morto. Não leve isso literalmente, mas leve a sério.”. Logo, a palestra é uma alerta e não uma simples afirmação arrogante, que se julga acima de todos nós. Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.

P.S. Todas as imagens utilizadas estão nos slides da apresentação, disponível aqui.

Teste está morto parte 1

Não restam dúvidas de que automação de testes é uma atividade fundamental no desenvolvimento de sistemas. Desde os testes unitários até os de aceitação precisamos cada vez mais de uma estrutura que permita a entrega de aplicações de maior qualidade num menor espaço de tempo.

Na internet existem diversos materiais e vídeos, que podem nos ajudar a progredir nesse caminho. A indicação de hoje são os vídeos do Google Testing Automation Conference, conferência do google, que reúne os mais respeitados profissionais. Na página da conferência você encontra os vídeos e os slides das palestras realizadas. Buscando um pouco mais você pode encontrar também os vídeos das edições anteriores.

GTAC 2011 - Logo

A palestra de abertura da edição de 2011, apresentada por Alberto Savoia, têm como título Test is Dead (Teste está morto), ficou curioso? De forma brilhante, o mesmo passeia pelas metodologias de desenvolvimento de software, finalizando com os motivos que o levam a crer que o teste está morto.

São 35 minutos de palestra, somados a 15 minutos de perguntas. Logo, caso não possa parar agora, guarde o link e assista numa melhor oportunidade, vale bastante a pena.

Quer saber mais sobre como o pessoal testa as aplicações no google? Acesse o blog mantido por eles.

Outros vídeos interessantes do pessoal do google podem ser encontrados na página do youtube – Google Tech Talks.

Na próxima semana, publico a parte dois do post, onde comentarei sobre alguns dos pontos discutidos na palestra acima.