Não seria correto dizer que um tema de tal abrangência seria coberto em sua totalidade em um simples texto, sendo assim, é importante explicar o que está por vir. Apresentaremos, de forma simples e direta, as técnicas, os processos, as metodologias e as ferramentas que podem ser utilizadas para a garantia da qualidade de um software.

Minha pretensão é passar a você os pilares de um conhecimento, que, acredite, é muito vasto. E digo mais, muitas vezes contraditório entre as literaturas, para que se possa adquirir um serviço, estruturar um projeto, entender o contexto e debater o assunto e, acima de tudo, para que se consiga tomar decisões com mais segurança.

Um ponto importante para ressaltar é que, apesar de conseguirmos atingir um nível aceitável de qualidade – mesmo sem um processo maduro de desenvolvimento – isto não reflete o cenário ideal, principalmente por remeter a um maior tempo, maior custo e, com certeza, muito maior estresse. É importante buscar o equilíbrio entre processo de desenvolvimento e processo de testes de software, para que se possa garantir uma solução de alta qualidade, com custo e tempo adequados.

O que pretendo dar aqui é uma visão abrangente do contexto de testes, através da abordagem de temas distintos. Mas antes gostaria de tocar em um ponto que é objeto de grande discussão: a inserção de testes nos processos de gestão de projetos tradicionais (cascata) e processos de gestão ágeis.

O tema é objeto para outro artigo com foco exclusivo no assunto. Mas para que fique alinhado, por ora, basta afirmar que a inserção de um processo estruturado de testes é viável tanto em projetos que rodam com metodologias ágeis, como nos desenvolvidos em metodologias tradicionais, e que, ao analisarmos o todo, com certeza os testes não remetem a gastos, e a tempos excedentes, mas, sim, à redução de custos, riscos e ganho de tempo.

Então agora vamos entender como testar, quando testar, o que testar, com que ferramentas e quais as melhores práticas que se pode utilizar, levando-se em conta os seguintes temas:

• Padrões de Mercado
• Nível de Investimento em Testes
• Formas de Avaliação de Custos com Testes
• Técnicas de Teste
• Fases & Técnicas de Teste
• Testes Funcionais
• Testes Não-Funcionais
• Processos de Automação
• Técnicas de Aplicação
• Ferramentas de Gestão e Controle
• Ferramentas de Automatização
• Conclusão e Divagação Sobre o Futuro dos Testes de Software

Falando Sobre Padrões de Mercado

É importante sabermos quais os guias mais utilizados no mercado e para tal apresento a ISO 29119 e o Syllabus do ISTQB (International Software Testing Qualifications Board). Ambos os guias devem ser utilizados como documentos de cabeceira para quem quer trabalhar com qualidade de software.

Recentemente foi desenvolvido no Brasil o modelo SQMMI- Software Quality Maturity Model Integrated voltado para empresas menores que tinham dificuldades de implementar o MPT e o TMMI. O SQMMI também pode ser implementado em empresas de maior porte e desta forma o mercado brasileiro atualmente tem dois modelos de melhoria de processo de teste de software.

Estes documentos têm foco maior na estruturação e na execução de testes, ao contrário dos modelos de maturidade, que possuem foco maior na gestão e no controle.

Os modelos mais difundidos para testes de software são o MPT.br – Melhoria do Processo de Testes Brasileiro, que pude implementar em todos os níveis e tive o prazer de ser o primeiro a alcançar o nível 5 no Brasil na empresa em que trabalho,  e o TMMI – Testing Maturity Model Integration, que, de forma geral, diverge do MPT.Br apenas no custo de implementação. Outros modelos também abrangem o tema testes de software, mas com menor intensidade e podem conviver com os aqui citados, exemplo: CMMI – Capability Maturity Model Integration e MPS.br – Melhoria de Processos do Software Brasileiro.

De forma geral, a maior preocupação com a implementação de tais modelos é a necessidade de estudos, tempo e dinheiro que devem ser investidos, não apenas no processo de estruturação e certificação, mas também no processo de manutenção para recertificação. Com certeza, esses modelos trazem um maior nível de controle e uma visão muito mais madura da que se tem antes de passar pelo processo de certificação.

Falando Sobre Nível de Investimento em Testes

Em consulta à literatura que trata do assunto e a pesquisas de mercado, o investimento deve ficar entre 15% e 40% do valor total investido no desenvolvimento da solução. É importante que entenda que existem diversos pontos a serem considerados, e que o percentual, normalmente varia de acordo com o nível de complexidade e com o foco de atuação do sistema.

Falando Sobre Formas de Avaliação de Custos com Testes

Este é um assunto complexo, pois são diversas as formas de avaliação, mas para que exista o conhecimento básico das práticas mais utilizadas, abaixo apresento as mais difundidas:

• Pontos de Função: com base em metodologia de avaliação de esforço de desenvolvimento, calcula-se o esforço de testes;
• Pontos de Testes: utilizando o esforço calculado em pontos de função e agregando fatores de ambiente, nível de conhecimento, qualidade de documentação, e demais aspectos existentes, calcula-se o esforço de testes;
• Casos de Uso: com base na representação gráfica de ações e eventos, entre um determinado perfil e o sistema, define-se a quantidade e a complexidade de testes, ou seja, o esforço de testes necessário;
• Complexidade de Telas: extração de casos de teste, com base na percepção da complexidade das telas;
• Requisitos: extração de casos de teste, com base nos documentos de requisito,
• Histórias de Usuários: extração de casos de testes, com base nas descrições do software apresentadas na visão dos usuários.

Falando Sobre As Técnicas de Teste

Você escutará sobre testes de CAIXA-PRETA, TESTES DE CAIXA-CINZA e TESTES DE CAIXA-BRANCA, e por isso é importante que se conheçam os termos. Vou esquecer a teoria e apresentar da forma mais simples possível:

• CAIXA-PRETA
  • Aqui não existe contato com o código. Neste tipo de testes valida-se o resultado da compilação e/ou publicação, seja através de um app mobile, um site na internet, um sistema desktop ou um serviço disponibilizado. Aqui o analista de teste interage com o sistema, aplicando o que conseguiu aprender através das documentações disponíveis, da exploração da solução e do conhecimento de usuários.

• CAIXA-CINZA
  • Normalmente, ao seguir esta estratégia, faz-se uma engenharia reversa para que se possa ver e analisar o código, para que assim, seja possível entender fatores limitantes e mensagens de erro que possam “aprimorar” a construção de casos de testes (forma comumente utilizada para a definição de testes estruturados de acordo com as melhores práticas).

• CAIXA-BRANCA
  • Por fim, nesta abordagem tratamos de “código”. São feitas validações de estrutura, avaliação da qualidade da estruturação e da implementação do código, complexidade do código para manutenção, coesão e acoplamento, padronização, segurança, padrão de projeto, etc.

Falando Sobre Fases & Técnicas de Teste

Para complicar um pouco mais, agora que são conhecidos os níveis de atuação, de fora (CAIXA-PRETA) para dentro (CAIXA-BRANCA), vamos falar das fases e nomenclaturas utilizadas no mercado. Normalmente o que se encontra são:

• CAIXA-BRANCA
  • Teste Unitário
    • Validação de sub-rotinas, métodos, classes e trechos isolados de código;

• Teste de Integração
  • Em resumo é a validação da transição de dados entre componentes de um mesmo sistema e partes complementares.

• CAIXA-PRETA & CAIXA-CINZA
  • Teste de Sistema
    • Aqui testamos o sistema, colocando-se no lugar do usuário final, replicando-se as possíveis ações do mesmo, validando as funcionalidades do sistema em um ambiente espelho do ambiente real, seja em estrutura, em dados, ou em perfis de acesso.

• CAIXA-PRETA
  • Teste de Aceite
    • Neste tipo de validação o sistema deve ser testado por um grupo de usuários reais, podendo o teste ser acompanhado pelos desenvolvedores, para que eles possam anotar possíveis falhas, caso ainda existam. O foco é a validação das funcionalidades do sistema em um ambiente espelho do ambiente real, seja em estrutura, em dados, regras de negócios, requisitos ou em perfis de acesso.

• Teste de Aceite Operacional
  • Neste caso são testes que devem ser executados no ambiente final de publicação, devendo cobrir contingência e todos os demais aspectos – funcionais e não-funcionais – necessários para garantia da qualidade do sistema, no contexto em que este funciona (por ex.: segurança é crucial para um sistema financeiro).

• Teste de Regressão
  • Este teste é feito para identificar, a cada nova versão do software, a manutenção da qualidade das funcionalidades anteriormente implementadas e as novas funcionalidades inseridas. Neste tipo de teste é comum a identificação de “efeitos colaterais” – problemas causados em outras partes já existentes no sistema – quando da implementação ou manutenção de uma nova funcionalidade ou módulo do sistema.

Adicionalmente aos testes acima apresentados, temos também os testes alpha, beta e gama:

• CAIXA-PRETA
  • Testes Alpha (Anterior ao Teste de Aceitação)
    • São feitos após o desenvolvimento, com um pequeno grupo de usuários ou com desenvolvedores que não participaram do projeto, e é mais comum de ocorrer antes dos testes de aceitação. Normalmente nestes testes, ainda são identificadas muitas falhas. Um ponto importante é que neste tipo de testes, normalmente existe a presença de desenvolvedores que acompanham o andamento e registram as falhas.

• Testes Beta (Teste de Operação Diverge por ser em Ambiente Controlado)
  • Ocorrem após o desenvolvimento, e são feitos por um grupo selecionado de usuários (que pode ser grande), que valida a solução em um ambiente real e apresenta os problemas identificados para a correção que será feita pelos desenvolvedores. (por ex: Google e alguns bancos costumam fazer isto).

• Testes Gama
  • A solução é disponibilizada para que os usuários finais utilizem e, caso sejam identificadas falhas, eles mesmos reportem. É bom ressaltar que, disponibilizar para a base usuária, não significa que o software não foi testado anteriormente. O ponto aqui é o nível de profundidade com o que os testes iniciais foram aplicados).

Falando Sobre Testes Funcionais

Os testes funcionais, como o próprio nome diz, são os testes que validam as funcionalidades de um sistema ou aplicativo. Os testes funcionais podem ser manuais ou mesmo automatizados, mas sempre orientados à identificação de problemas relacionados às funcionalidades e regras de negócios que o sistema possui.

Falando Sobre Testes Não-Funcionais

Os testes não-funcionais remetem a aspectos tais como: a aparência, a facilidade de uso, a velocidade e a robustez do sistema para que este suporte a quantidade, simultaneidade, velocidade e segurança esperadas. Dentre os testes não-funcionais, podemos citar:

• Teste de volume
• Teste de performance
• Teste de usabilidade
• Teste de acessibilidade
• Testes de recuperação
• Testes de integridade
• Testes de Segurança
• Entre outros

Falando Sobre Processos de Automação

Principalmente para os testes funcionais, existe a possibilidade de automatização com o auxílio de ferramentas, nas quais se consegue criar scripts (códigos) que simulam as operações que eram executadas de forma manual, com o benefício de possibilitar a sua execução em diferentes plataformas, sistemas operacionais, browsers e tamanhos de telas. Isto traz um ganho muito grande de custo, tempo, qualidade e redução de riscos.

Falando Sobre Técnicas de Aplicação

Como técnicas de aplicação de testes, cito a validação de valores máximos e mínimos para os dados de entrada e saída do sistema, a tipagem de valores apresentados em um determinado campo, o uso de partição de equivalência, com a identificação de agrupamentos de testes (por ex.: regras de aceite de dados entre datas etc.).

Falando Sobre Ferramentas de Gestão e Controle

Algumas das ferramentas que sugiro, caso sua pretensão seja montar uma equipe, são:

• Jira – Ferramenta para o registro de não conformidades e para a gestão de atividades:
•  Mantis – Ferramenta free utilizada para o registro e controle de bugs e que também pode ser utilizada como fonte de conhecimento através do registro de lições aprendidas.
• TestLink – Ferramenta free para gestão do processo de testes, com possibilidade de customização visual e funcional para o contexto da organização de testes e integração com ferramentas de registro de bugs/falhas como o Mantis, o Jira, e outras mais.

E quais ferramentas devo utilizar? A resposta é: se tem dinheiro para investir, use o JIRA, pois com certeza sua organização terá praticamente tudo o que precisa em uma única ferramenta; entretanto, se a empresa quer investir pouco, pode partir para  uma junção entre Mantis e TestLink, pois ambos são de plataforma aberta, ou seja, com custo zero. Existem muitas outras ferramentas no mercado, o que fiz aqui foi citar algumas das ferramentas que entendo possam cobrir a maioria dos casos.

Falando Sobre Ferramentas de Automatização

• Selenium (web) – É um conjunto de ferramentas que pode ser utilizado juntamente com diversas interfaces de codificação, como o Eclipse e o Visual Studio, o que viabiliza, de forma simples e direta, o desenvolvimento de scriptspara automatização de testes na web.
• Appium (mobile) – O Appium é uma ponte de conexão, entre o Selenium e dispositivos móveis, que viabiliza a automação de testes para celulares e tablets.
• Test Complete (desktop) – O testcomplete também pode ser utilizado para automatização WEB e MOBILE.

As opções acima apresentadas são somente algumas das que entendo serem factíveis para uso, e que cabem em qualquer contexto e tamanho de empresa. Existem também muitas outras ferramentas no mercado, como as da Borland, da HP e outras mais. É importante ressaltar que tanto o Selenium, quanto o Appium são ferramentas free, e suficientemente poderosas para serem utilizadas em qualquer contexto web ou mobile.

As ferramentas para a execução de testes de estresse, de carga e de volume, podem ser o Jmeter e o SoapUI para testes de REST & SOAP.

Conclusão e Divagação Sobre o Futuro dos Testes de Software

Até aqui apresentei os padrões de mercado, as abordagens (caixas branca, cinza e preta), os tempos de teste (desde a unidade até o pós lançamento e novas versões), o que são testes funcionais e não-funcionais, falou-se sobre processos, técnicas e ferramentas tanto de gestão e controle, quanto de automação, e dei uma pincelada no que tange a viabilidade de inserção do processo de testes em metodologias ágeis e tradicionais de desenvolvimento. Assim, espero que o texto, “uma versão simplificada” e “adaptada” de um “apanhado de conhecimentos e conversas”, tenha sido de valor.   Se o assunto gerou interesse, e despertou vontade de aprofundar as leituras, os interessados verão que existem diferenças entre ISTQB, ISO, e outras fontes, mas o importante é entender o que pode, quando pode, e como pode ser feito. Mãos à obra!

Por: Maicol Peixe