Um roteiro para planejar testes de software

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

No senso comum, os testes de software servem para encontrar erros. Nestes casos a palavra “erro” é usada de forma generalizada para indicar falhas no sistema. Os erros no sistema indicam um estado incorreto durante a execução que pode levar a uma falha no software.

A falha é quando ocorre discrepância entre o resultado obtido de um software e o resultado prescrito nos requisitos.

Os testes de software estão cada vez mais ligados à estratégia das empresas desenvolvedoras, pois ajudam a garantir vários itens que considerados diferenciais de seus produtos.

Os testes ajudam a garantir vários itens muito importantes.

Qualidade

A qualidade está relacionada ao fato de seu produto atender, ou não, as necessidades de seu cliente, sejam elas implícitas ou explícitas. Os testes ajudam a garantir que o produto atende todas as especificações.

Economia

Reduz o tempo gasto com retrabalho relacionado às manutenções corretivas, muitas vezes originadas por falhas de projetos e programação.

Segurança

Hoje, a maioria dos sistemas desenvolvidos conta com algum tipo de sistema de segurança, seja para uma área restrita de um site ou para lidar com transações de informações sigilosas.

Dependendo do projeto os testes de segurança podem ser considerados fundamentais, valendo de tudo para tentar “burlar” o sistema.

Confiabilidade

Neste caso os testes são para medir o período máximo de tempo que o software permanece funcionando sem apresentar falhas. Muitas vezes durante os testes podem ser encontradas soluções para aumentar a confiabilidade do sistema.

Negócio

Os testes podem gerar informações importantes para a gerência de uma empresa influenciando na decisão de liberar, ou não, o sistema desenvolvido. Neste caso, a equipe deve estudar as falhas encontradas e então criar estratégias para eliminá-las.

Técnicas de teste de software

Caixa branca

Esta técnica visa checar o comportamento interno do software. O responsável pelos testes deverá ter acesso ao código fonte do sistema, de forma a poder criar casos de testes para todas as interações possíveis.

Os itens verificados nestes testes variam de acordo com a complexidade do software e podem ser verificado desde validações e caminhos lógicos até se o código está de acordo com os padrões aceitos no mercado.

Caixa preta

Os testes de caixa preta levam em consideração o comportamento externo do software, não importando como ele funciona internamente. Estes testes são feitos fornecendo dados de entrada e comparando os dados de saída com os dados esperados (já conhecidos anteriormente).

Geralmente os testes de caixa preta são baseados nos requisitos do sistema.

Caixa cinza

Os testes de caixa cinza mesclam os testes de caixa preta e caixa branca. Exemplo: são fornecidos dados e entrada e então são verificados o comportamento interno do sistema e os dados de saída.

Fases de testes de software

Veja abaixo algumas fases referentes ao testes de software:

Teste de unidade

Nesta fase são realizados testes em partes do sistema e podem ser em sub-rotinas ou em trechos do código. O objetivo é encontrar falhas em partes pequenas do sistema funcionando de forma independente do todo.

Teste de integração

Nesta fase, como o próprio nome diz, são feitos testes na integração das partes do sistema. As falhas são comumente encontradas na comunicação entre os componentes. Por exemplo, um componente espera um valor Y mas o componente que deveria passar este valor retorna W.

Teste de sistema

Aqui serão realizados testes usando o sistema do ponto de vista do usuário final. Sempre que possível é recomendado que estes testes sejam feitos no mesmo ambiente e condições do usuário final.

Teste de aceitação

Testes realizados por usuários finais do sistema a fim de conferir se o sistema atende a todos os requisitos solicitados e se está de acordo com todos os critérios de aceito do sistema.

Teste de operação

Fase em que os testes são realizados pelos administradores do ambiente final do sistema. São feitas simulações para garantir que o sistema entrará no sistema de produção de forma segura e estável.

Como fazer os testes

O ideal seria que sempre houvesse uma equipe destinada a realizar testes de software, produzindo os relatórios necessários para que os problemas possam ser estudados e resolvidos.

Mas nem todas as empresas possuem estrutura que suporte ter uma equipe que siga todas as instruções para a realização de testes.

Nestes casos, uma boa saída é nomear alguém da empresa que não esteja envolvido na produção do sistema para realizar os testes. Claro que nestes casos as empresas devem definir quais os principais testes devem ser realizados de forma a atingir as partes mais críticas do sistema.

Os erros encontrados devem ser documentados com informações suficientes que ajudem na reprodução do erro, facilitando assim a solução do problema.

A documentação do erro deve ser definida pela empresa. É importante manter um histórico de falhas encontradas pois assim, ao final do projeto, pode ser feito um estudo e obter um aprendizado em cima dos erros que foram encontrados.

Conclusão

Os testes ficaram, por muito tempo, em segundo plano nas empresas que desenvolvem softwares, mas de um tempo para cá vêm sendo cada vez mais adotados como forma de garantir a qualidade dos produtos e muitas vezes como diferencial competitivo.

É certo que nem todas as empresas têm capacidade de ter uma equipe destinada a testes, mas precisam precisam procurar alternativas para realizar o mínimo de testes necessários para um software. [Webinsider]

.

<strong>Filipe Giacomin</strong> (filipegb@gmail.com) é gerente de tecnologia da agência <strong><a href="http://www.e-brand.com.br/" rel="externo">e-brand Estratégias Online</a></strong>. Mantém o blog <strong><a href="http://www.filipegb.com.br/" rel="externo">FilipeGB</a></strong> e um perfil no <strong><a href="http://twitter.com/filipegb" rel="externo">Twitter</a></strong>.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

3 respostas

  1. Filipe, teoria bonita, mas preciso registrar que as técnicas mais atuais (leia-se, nos últimos 5 anos no Brasil) têm focado na assertividade do código, logo na fase de desenvolvimento.

    O foco tem sido em não liberar código sem teste prévio. Prefencialmente, o código só deveria formar um build (ou release, ou versão, como queira) caso tenha passado em todos os testes.

    Boas leituras são sobre Test Driven Development e Domain Driven Development, para começar.

    Sob a ótica dessas técnicas, a equipe de testes torna-se cada vez menos necessária, já que os testes são baseados nas especificações e desenvolvidos sob a ótica do usuário.

    Não estou dizendo que não temos que realizar testes, nem que a equipe de testadores está fadada à morte. Não!

    Há outros aspectos subjetivos no assunto de testes, como desempenho, aparência, harmonia de cores, intuitividade, opinião, layout, etc. que só as pessoas podem avaliar.

    Por exemplo: o que é um aplicativo bonito? O que é um aplicativo rápido. Pior ainda, o que é um aplicativo lento? O que é um aplicativo intuitivo?

    O assunto é longo, muito longo mesmo, mas queria deixar a contribuição sobre as técnicas que antecipam *muito* a fase de deploy da aplicação, automatizando o que pode ser automatizado.


    Atte.,
    Vinicius Assef.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *