O que é Testabilidade?

A Testabilidade examina as diferentes probabilidades e características comportamentais que levam o código a falhar se alguma coisa estiver incorreta...

por Patricia Aline Tannouri

A Testabilidade examina as diferentes probabilidades e características comportamentais que levam o código a falhar se alguma coisa estiver incorreta.

Um programa tem alta testabilidade se ele tende a expor suas falhas durante os testes com entradas que geram defeitos. Um programa tem baixa testabilidade se ele tende a ocultar as falhas detectadas durante os testes, produzindo saídas corretas para entradas que geram defeitos.

Requisitos incompletos, desatualizados, ambíguos ou contraditórios trazem baixa testabilidade. É muito difícil para um testador identificar problemas se não houver acesso a informações detalhadas sobre os critérios de teste.

É necessário ter um critério de teste para que a testabilidade passe a ser simplesmente “uma medida de quão difícil é satisfazer uma meta específica de teste”.

O código que oculta falhas é difícil de testar. Quando todos os erros que são criados durante uma execução são cancelados, uma falsa idéia é criada de que o software está correto. Mas na verdade ele é um software tolerante a falhas. Em um software crítico, onde pode existir risco de vida, qualquer falha não-detectada pode ser fatal. Se os erros são ocultados durante várias e várias transações, quando finalmente um defeito causa uma falha, pode ser impossível detectar a origem.

A testabilidade pode também ser definida como “a probabilidade de um pedaço de software falhar na próxima execução dos testes assumindo que uma entrada do software inclui uma falha”.

Três peças de um quebra-cabeça

Testabilidade de software, teste de software e revisão por pares são três peças em um quebra-cabeça chamado de “software verdadeiramente e suficientemente confiável”. Se um módulo de software for submetido a quantidades enormes de testes bem sucedidos, aprovado em revisão por pares e tiver alta testabilidade, então o quebra-cabeça está resolvido, e a alta confiabilidade foi alcançada.

Testabilidade de software x mineração

Para entender melhor o significado de Testabilidade considera-se a seguinte analogia: Se falhas de software são como ouro, então o teste de software é como o minerador de ouro. A testabilidade de software é como o exame feito por um geólogo antes de a mineração ocorrer.

O trabalho do geólogo não é de escavar em busca de ouro. O geólogo estabelece a probabilidade de que escavar em um determinado local será recompensante. O geólogo pode dizer: “Neste vale pode ou não haver ouro, mas se houver será no topo.” Em outro local o geólogo pode dizer: “Se não encontrar ouro no primeiro palmo desta terra, então não há ouro.” Então será necessário cavar um palmo para verificar se existe ouro.

A Testabilidade sugere que haja intensidade nos testes onde o geólogo sugeriu. Ela fornece o grau de dificuldade que será enfrentado durante os testes em um local particular para detectar um defeito. Se depois desses testes não for possível observar falhas, então existe a certeza de que o programa está correto.

Incorporando Testabilidade no Software

É de comum acordo que os testes devem ocorrer desde o começo do projeto, e os artefatos do projeto devem ser revisados quanto a sua testabilidade desde o começo. A testabilidade pode ser incorporada nos vários estágios do desenvolvimento de software, como mostrado a seguir:

1. Fase de Especificação de Software: Durante o processo de revisão da especificação, a equipe de testes deve ser questionada quanto ao seu entendimento dos requisitos.

2. Fase de Detalhamento do Projeto: Para incorporar testabilidade nesta fase, as entradas e saídas devem estar indicadas claramente. O projeto deve elucidar o caminho do sistema claramente para que a equipe de teste saiba quais programas são tratados em cada cenário.

3. Fase de Codificação: Esta fase é a mais crucial. Toda a cobertura de cenários que a aplicação deve e não deve fazer deve passar por testes unitários nesta fase.

4. Fase de Testes: O plano e os scripts de teste projetados nesta etapa devem cobrir todas as medidas de testabilidade, e estar profundamente testados de acordo com os requisitos funcionais e não-funcionais.

Mitos sobre Testabilidade

Alguns mitos sobre testabilidade atrasam seu uso nos projetos:

Mito: A testabilidade é cara.

A testabilidade não precisa ser cara. Um pequeno investimento durante a fase de projeto pode trazer grandes melhorias na detecção de falhas.

Mito: A testabilidade pode ser um plug-in.

A testabilidade é uma forma de garantir qualidade, e não pode ser adicionada em um produto como um ingrediente separado. Ela precisa ser gradualmente incluída.
· Um projeto simples leva a um software fácil de testar. Simplicidade nas funcionalidades significa que as características do software são as mínimas necessárias para alcançar os requisitos – nada de perfumaria. A simplicidade estrutural requer uma arquitetura limpa e lógica; a modularidade vai ajudar a limitar a propagação de falhas. A equipe de desenvolvimento deve seguir padrões.

· Inserir auto-testes (afirmações) dentro do código faz as falhas serem prontamente observáveis. Com uma afirmação, o programa vai falhar logo depois de encontrar um defeito, não continuando a operar escondendo as falhas. O uso de afirmações torna os problemas fáceis de apontar, e também fáceis de corrigir. O desenvolvedor pode dar uma olhada onde ocorreu o defeito que causou a falha.

· Qualquer coisa que o desenvolvedor faça para tornar as saídas mais visíveis vai aumentar a testabilidade do software. Os desenvolvedores podem adicionar chaves especiais que os testadores ativam para forçar o software a seguir um determinado comportamento, ou a seguir por algum caminho. Podem criar logs para descobrir exatamente quais ações o software executou.

· Comentários cuidadosos e completos no código-fonte e outras documentações técnicas podem facilitar o trabalho de desenvolvedores e testadores. As revisões por pares são muito mais eficientes quando o código está comentado claramente e existe documentação.

· Usar controles-padrão. Desenvolver scripts de teste automáticos para uma aplicação que não usa controles-padrão é um processo doloroso que desperdiça tempo e esforço.

· Comunicação frequente com a equipe de testes. Os testadores precisam saber todas as mudanças que ocorreram na especificação, bem como qualquer problema de código ou processo. É necessário garantir que a equipe de testes sabe quais áreas do produto estão prontas para testar e quais não estão. Isto economiza tempo e frustrações.

2) O que os gerentes podem fazer:

· O gerente deve ter certeza de que as referências do produto estão claras, completas e atualizadas. A queixa mais frequente dos testadores é que as especificações e/ou documentos de requisitos estão incompletos e desatualizados. Garantir uma pessoa responsável pela tarefa de atualizar a documentação, para que uma excelente documentação não se torne obsoleta poucas semanas depois que a codificação começou.

· Se testes automáticos estão planejados, insistir na aceitação antecipada da interface do usuário e das características do sistema. Os esforços de automação são inúteis em um ambiente onde a interface é volátil.

· Estimular fortemente a interação entre desenvolvedores e equipe de testes. Qualquer coisa que possa criar um espírito colaborativo vai aumentar as chances de entregar o software no prazo e com sucesso. Estabelecer linhas formais de comunicação entre os dois grupos bem no começo do projeto.

3) O que os testadores podem fazer:

· Os testadores devem aprender mais e mais sobre o projeto do produto que será testado e as tecnologias envolvidas. Isto ajuda a tomar decisões acertadas sobre o que e como testar e evita o desperdício de tempo de teste valioso em tarefas desnecessárias ou executadas incorretamente.

· Tirar vantagens das ferramentas de cobertura de código, automação, testes de stress, teste de carga e volume, ferramentas para ajudar a gerar dados válidos e ferramentas para gerenciar os processos de teste. Essas ferramentas usadas apropriadamente tornam o produto muito mais testável.

· Descrever os bugs claramente. Isso permite aos desenvolvedores fazerem seu trabalho mais rapidamente e com menos frustração (e respeitar mais os testadores). Chefes, outros testadores, o gerente do produto... todos podem querer entender o bug.

Conclusão

Criar um software testável não é responsabilidade somente de uma pessoa ou equipe. Cada um que está participando da produção do software tem sua parte na melhoria da efetividade dos testes. Quanto mais testável for o software, maior a chance de entregar um produto de alta qualidade e no prazo.

Referências

J. Voas and K. Miller: Software Testability: The New Verification. IEEE Software.

James Bach: Principles of Software Testability. ST Labs, Internal Publication.

Ipsita Chatterjee: Testing Testability: http://www.stickyminds.com/ Internal Publication.

T. Khoshgoftaar, R. Szabo and J. Voas: Detecting Program Modules with Low Testability. FAU Technical Report.