Teste de Software for Dummies

Mesmo os bons softwares, são repletos de defeitos. Para ilustrar, uma taxa de 15% à 30% de defeitos a cada mil linhas de código é considerada aceitável para a indústria de TI. Ou seja, todos os softwares têm defeitos, no entanto, os softwares realmente bons têm poucos defeitos críticos não corrigidos; promovendo assim um ambiente mais estável no ponto de vista do usuário final.

por Cristiano Caetano

A resposta curta seria: porque não existe software perfeito. Mesmo os bons softwares, são repletos de defeitos. Para ilustrar, uma taxa de 15% à 30% de defeitos a cada mil linhas de código é considerada aceitável para a indústria de TI [1][2]. Ou seja, todos os softwares têm defeitos, no entanto, os softwares realmente bons têm poucos defeitos críticos não corrigidos; promovendo assim um ambiente mais estável no ponto de vista do usuário final. O processo de desenvolvimento de software, por mais maduro que seja, ajuda apenas a reduzir a introdução de defeitos; contudo os processos também não são perfeitos. A arquitetura e o desenvolvimento de software são atividades tão peculiares, tão dependentes da criatividade e da natureza imprevisível dos seres humanos que, às vezes, o processo aplicado com sucesso em certo projeto, provavelmente será um completo fracasso em outro projeto. Quem nunca viveu essa situação tão comum?

Tomemos como exemplo, a indústria automotiva, por mais automatizado e padronizado que seja o processo de projeto e construção, os automóveis ao final da sua construção são submetidos ao time de controle de qualidade. Durante o checklist do time da qualidade, eventualmente defeitos são encontrados. Os Recalls de peças são exemplos claros de defeitos de projeto, afinal errar é humano. Entretando, as diferenças páram por aqui, as atividades de projeto e construção de um automóvel geram uma ínfima quantidade de defeitos se compararmos com o desenvolvimento de um software. O grande desafio da engenharia de software para a próxima década, sem dúvida, será aperfeiçoar as técnicas, ferramentas e processos existentes a fim de fomentar a produção de software mais homogênea e consistente por meio de abordagens fabris.

O Bug é o grande vilão dessa estória. Bug é uma palavra genérica para representar qualquer classe de defeito. Esse termo foi introduzido quando os primeiros computadores, que eram feitos de válvulas, apresentavam algum tipo de problema inexplicável. Os engenheiros vasculhavam o interior do computador e, às vezes, descobriam que a origem dos problemas eram causados por insetos de verdade, como pode ser visto no primeiro registro de um Bug de computador apresentado na Figura 1.

Figura 1. Primeiro registro de um Bug de computador - 1945

Mas afinal, nos softwares atuais, por que existem tantos Bugs? Poderíamos escrever um livro para tentar responder essa pergunta e, ainda assim, não seríamos capazes de identificar todas as causas possíveis. No entanto, podemos elencar algumas causas como as mais prováveis, como podemos observar nos itens destacadas abaixo:

• Falta de comunicação entre os membros da equipe.
• A complexidade do software.
• Erros de programação.
• Mudança de requerimentos no meio do projeto e requerimentos ambíguos.
• Pressão da gerência para terminar o produto o mais rápido possível.

E a tal da qualidade? A qualidade, segundo o CSTE CBOK [3] é definida como a conformidade com os requerimentos definidos pelo cliente. Ou seja, se estamos seguindo os requerimentos à risca, então o produto atenderá as necessidades do cliente. No entanto, a qualidade não pode se resumir somente a esse aspecto, a qualidade deve abranger a melhoria contínua dos demais processos da organização, tais como serviços, vendas, suporte técnicos entre outros, garantindo assim a satisfação do cliente em todos os aspectos.

Nivelamento conceitual
Nesta seção vou descrever os principais conceitos e termos relacionados ao processo de teste de software. A lista apresentada não é completa e não discute em profundidade cada tópico apresentado. No entanto em artigos futuros, cada tópico será apresentado individualmente e discutido com maior profundidade.

Bottom-up Testing
Nesse tipo de teste cada módulo ou componente é testado individualmente e, pouco a pouco, os demais componentes são combinados e testados. Em alguns casos simuladores ou mocks, são utilizados no lugar dos componentes reais para substituírem alguns componentes que são necessários, porém não estão disponíveis ainda.

Black Box Testing
Nessa estratégia, os testes são executados por meio do fornecimento de dados de entrada ao componente sendo testado e pela análise do resultado produzido, no entanto, sem entender ou verificar o processo que produziu o resultado.

Branch Testing
Nessa estratégia, cada possível caminho executado por meio de pontos de decisão (if, case, etc) são testados a fim de garantir que todos os cenários foram testados pelo menos uma vez.

Boundary Value Analysis
Técnica de teste utilizada para selecionar os dados que farão parte da execução de um teste por meio dos limites (máximo e mínimos) das entradas e saídas de um componente de software, parâmetros de um procedure ou function, etc.

Bug
Termo genérico para representar qualquer tipo de defeito de software.

Configuration Testing
Nessa categoria de testes, os testes são executados contra todos os ambientes (hardware e software) suportados. A idéia é manter uma matriz contendo as plataformas/ambientes suportadas e o status da execução dos testes contra essas plataformas/ambientes.

COQ - Cost of Quality
Custo gasto em atividades relacionados ao processo de garantia de qualidade. O COQ inclui o custo de prevenção, medição, correção, materiais, equipamentos, etc.

Debug
Processo onde o desenvolvedor depura o programa a fim identificar a causa de um defeito. Veja Também Bug.

End-to-End Testing
Nessa categoria de teste, os testes contemplam cenários onde a aplicação ou determinado módulo da aplicação é testado do começo ao fim. Veja também Integration Test e Top-Down Testing.

Integration Testing
Neste cenário os diversos sistemas que compõem uma solução de software são combinados e configurados num ambiente semelhante ao ambiente onde serão usados na vida real Dessa forma conseguimos testar o fluxo das operações do começo ao fim do ponto de vista do usuário final. Também conhecido como System Test.

Load Testing
Essa categoria de teste tem a função de aplicar uma carga de operações ou transações simultâneas contra a aplicação a fim de conferir se a aplicação atende os requisitos de performance ou resposta. Esse tipo de teste também é conhecido como Performance Testing.

Pass/Fail Criteria
Comparação com o resultado esperado de um Test Case a fim de determinar se o teste passou ou falhou.

Recovery Test
Classe de testes cuja principal função é avaliar como a aplicação lida com problemas inesperados e desastres.

Regression Test
Essa abordagem tem a função de garantir que os módulos ou componentes da aplicação que não foram modificadas ainda funcionam corretamente após o programador modificar alguma outra parte da aplicação.

Test Case
Conjunto de passos que descrevem um cenário de teste bem definido cuja principal função é comparar as respostas dos estímulos gerados pelos passos com um resultado esperado.

Test Plan
Indica um documento que descreve o escopo das atividades de teste, a abordagem, os recursos humanos envolvidos, os módulos que serão testados, o schedule, riscos, etc.

Test Suite
Indica um conjunto de Teste Cases que são agrupados por algum tipo de atributo em comum.

Test Automation
Categoria de teste onde os testes são automatizados por meio da utilização de ferramentas e frameworks especializados para esse tipo de função.

Test Coverage
Indica o percentual de tudo o que pode ser testado em relação ao que foi testado até agora.

Top-Down Testing
Nessa categoria de teste, a aplicação é testada como um todo do início ao fim do ponto de vista do usuário final. Ou seja, o sistema é compilado completamente e o testador executa os Test Cases simulando situações de uso reais.

UAT - User Acceptance Test
Conjunto de testes conduzido de forma garanta que o software atinge as necessidades do usuário final por meio da execução de cenários e dados de testes reais. Veja também Integration Testing.

Verification
Em resumo, o processo de Verification garante que o software está sendo desenvolvido conforme os padrões e processos definidos pela organização.

Validation
Basicamente, o processo de Validation garante que o sistema está sendo escrito conforme o que está definido nos requisitos a fim de garantir que o software está sendo desenvolvido para atender as necessidades do cliente.

Para saber mais...

[1] Get the Bugs Out
http://www.windowsitpro.com/Windows/Article/ArticleID/24255/24255.html

[2] Researchers Find Fewer Bugs In Linux
http://www.developerpipeline.com/55800125

[3] Guide to the CSTE Common Body of Knowledge (2006)

[4] StickyMinds: Software Quality & Test Magazine
http://www.stickyminds.com/

[5] Software QA Testing and Test Tool Resources
http://www.aptest.com/resources.html