Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Anúncios

Onde encontrar material sobre testes de software?

No primeiro post de 2014, compartilho com vocês uma lista com alguns dos blogs/sites, perfis do twitter e canais do You Tube, que acompanho (ou tento acompanhar) para me manter atualizado sobre testes de software.

Blogs/Sites:

Software Testing Club      Ministry of testing      Jmeter.com.br

Outros:

  

     

Sentiu falta de algum? Pode adicionar nos comentários =D

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?

Como reduzir o tempo gasto em testes?

Teste é sempre um gargalo! Não dá pra estimar quanto tempo é gasto em testes (e certificação),  mas algumas fontes mostram que cerca de 50% do esforço para desenvolver um produto é gasto em testes. Com esse dado, e o senso comum de quem trabalha com desenvolvimento de software, teste de software se torna um excelente alvo para ser estudado com o objetivo de se reduzir o tempo gasto.

Obviamente, muitos estudos já foram feitos nessa direção, e nesse post vamos falar um pouco sobre um artigo que realizou um mapeamento sistemático com o objetivo de identificar todos os trabalhos existentes (acadêmicos) que tratam sobre redução de tempo e esforço de testes. O artigo, publicado em 2012, tem como título “Reducing test effort: A systematic mapping study on existing approaches” e pode ser encontrado aqui.

Primeiramente, é claro que poderíamos reduzir o esforço de testes simplesmente tendo menos testes, mas é claro que reduzir a qualidade do produto final é inadmissível, principalmente quando tratamos de sistemas críticos e safety-relevant.

Diante disso, o artigo identificou 5 categorias que se propõem a diminuir o esforço gasto com testes (consequentemente diminuindo o tempo também na maioria das vezes). As cinco categorias são:

  • Test Automation – 50% dos estudos identificados nesse mapeameanto sistemático abordam essa categoria. Isso não é surpreendente pois automatizando testes muito tempo consegue ser economizado.
  • Prediction – 28% dos estudos abordam predição, no sentido de dar suporte a decisões sobre quanto esforço de teste precisa ser gasto para um dado sistema e como distribuir esse esforço entre as diversas atividades.
  • Test input reduction – 15% dos estudos abordam essa categoria, com o intuíto de ajudar da seleção e priorização  de test cases (essa categoria também é conhecida como redução de suítes de teste)
  • Quality assurance (QA) before testing – Essa categoria (encontrada em 5% dos estudos) lida com atividades executadas antes dos testes propriamente ditos e que ajudam a reduzir os testes. Essas atividades são: análises estáticas, inspeçoes e revisões.
  • Test Strategies – Essa categoria (encontrada em 2% dos estudos) aborda pontos  como a seleção de diferentes técnicas de teste e também seleção de diferentes níveis de teste para economizar tempo e esforço.

É claro que esses pontos são focados em estudos acadêmicos, e que nos projetos reais da vida real podem existir outras abordagens para reduzir esforço dos testes. Você usa/conhece alguma abordagem? Compartilhe conosco 🙂

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.