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?

Anúncios

Privacidade na web! Será que existe?

Ao meu ver existem dois pontos relativos a privacidade pessoal na web que devem ser levados em consideração:

  1. Nós estamos escancarando cada vez mais nossas informações na internet (principalmente através das redes sociais). Nossos dados, opiniões, relações, fotos, desejos, gostos, etc! Está tudo nos facebooks, twitters, youtubes,  google+, amazon (suas compras e seus hábitos de compras), etc. Essa informação é facilmente encontrada por qualquer um, e ela por si só já é perigosa. Precisamos ter muito cuidado.
  2. Mas adianta ter cuidado?? Até as coisas que não abrimos para o mundo todo, como nossos emails ou nossas conversas via voz no skype, estão sendo (podem ser) devidamente analisadas e acompanhadas por entidades superiores. E o que nós podemos fazer diante disso? No momento nada…

O ponto 1 acima é algo que precisamos aprender a conviver e aprender com tempo. Mas o ponto 2, é algo inadmissível que precisa ser mudado e precisamos criar formas na web onde não fiquemos nas mãos desses “magnatas da informação”. Recentemente essa questão de espionagem atingiu a mídia do mundo inteiro com o caso Snowden. Recentes relatos mostram como essas “magnatas da informação” ajudam (e podem ajudar) o governo dos EUA a espionarem e bisbilhotarem a privacidade alheia. Microsoft (outlook e skype), Google (principalmente youtube e gmail), etc são somente alguns exemplos de “magnatas” que tem “nossas vidas” nas mãos deles.

E agora? O que fazer?

Minha previsão sobre isso tudo é que, a longo prazo, essas magnatas vão modificar a forma como implementam seus serviços para uma forma mais “descentralizada” da informação (aonde as empresas magnatas não terão poder e domínio sobre todas as informações). Mas isso é uma coisa difícil de acreditar e ainda mais difícil de checar se é realmente acontece o que as magnatas dizem que acontece.

Então a possibilidade mais tangível ao meu ver (uma vez que as pessoas amadureçam como usuários da internet) é que vamos gradativamente parar de utilizar serviços e sistemas dessas magnatas e migrar para soluções descentralizadas que serão mais seguras (apesar de não serem lá tão maduras ou bonitas como as soluções das magnatas). Esses serviços e soluções provavelmente usarão tecnologia P2P (peer-to-peer), ou algo mais avançado que ainda não conhecemos. Soluções aonde a informação seja descentralizada e seja de todos, regulamentada e protegida por todos, ao invés de somente por uma empresa “dona” dos dados. Soluções assim já são realidade hoje em dia, e um exemplo muito bom é o do BitCoin (leia aqui se você não conhece o bitcoin).

A outra possibilidade é comprar máquinas de escrever ao invés de usar computadores 🙂 A Rússia já está fazendo isso para produção de documentos confidenciais (veja aqui isso)

Temos que lembrar que a humanidade toda é um bebê no mundo da web, e precisamos começar a amadurecer, crescer, abrir os olhos e parar de engatinhar… Caso contrário, temos que continuar aceitando calados os pontos 1 e 2 que citei acima.

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 🙂