É muito comum as pessoas nos perguntarem coisas como “quanto tempo vocês recomendam que eu separe para testes?”, ou “quanto do meu orçamento deve ser destinado para testes?” Nossa resposta quase sempre gira em torno da seguinte pergunta: que tipo de risco você quer mitigar?‍

Apesar de muitos defenderem que o tempo de teste deve basear-se numa porcentagem do tempo de desenvolvimento ou numa porcentagem do valor total do projeto, nós não acreditamos em respostas prontas. Sem dúvida estes pontos servem como parâmetros, mas não servem como parte de um método estratégico de tomada de decisão.

Como já dissemos aqui no blog, teste de software é gestão de risco. Portanto a tomada de decisão sempre deve ser ponderada de acordo com o produto ou projeto em questão. Afinal os riscos atrelados a um software de gestão financeira são totalmente diferentes dos riscos inerentes a um portal de conteúdo, por exemplo. É muito provável que o tempo de teste investido para um deles seja proporcionalmente maior, e que, inclusive, seja utilizado de forma diferente.

OK, mas qual é uma boa base para se tomar essa decisão?

A Open Web Application Security Project (OWASP), conceituada comunidade aberta de segurança de software, publicou um método de análise de risco. O objetivo da publicação é alertar para os principais riscos de segurança no desenvolvimento de aplicações mobile. No entanto, o método utilizado serve de apoio para quase qualquer situação de análise de risco. O estudo na íntegra está disponível neste link: PDF.

O método proposto pela OWASP exige que respondamos a 5 perguntas e tomamos a liberdade de adaptar o método para a nossa realidade: testes de software.

1. O que nós queremos proteger e por quê?
2. Quais são os pontos cruciais do produto/projeto?
3. O que poderia dar errado?
4. Quais são os testes mais adequados?
5. Quais riscos nós aceitamos correr?

O que nós queremos proteger e por quê?

Aqui devemos pensar nos ativos a serem protegidos. O que é importante para a aplicação e/ou marca. Qual seria o impacto se estes meus ativos fossem comprometidos? Afinal, o que está em jogo? Alguns pontos de análise:

Dados

A minha base de dados é confidencial? Existe o risco de eu levar uma multa caso esses dados sejam corrompidos? O meu negócio depende da proteção desses dados?

Dinheiro/Transações/Processos

A minha aplicação lida com transações financeiras? Há espaço para fraudes em alguma parte do processo? Existe a funcionalidade compra online? O fluxo de compra online é fluído? O meu público consegue efetuar a compra independente da velocidade de internet ou dispositivo utilizado?

Privacidade/Propriedade Intelectual

A privacidade do meu usuário é essencial? O meu negócio poderia perder credibilidade no caso de vazamento de informações? Nossa aplicação lida com informações comprometedoras ou segredos industriais?

Experiência do usuário

Quão relevante é a experiência do usuário? Corre o risco de perder (ou não ganhar) usuários caso a experiência esteja aquém da desejada? Qual o nível de exigência do meu público?

Quais são os pontos cruciais do produto/projeto?

Neste ponto devemos ter um olhar especial pelas funcionalidades da aplicação/projeto, se possível mapeie-as por ordem de relevância. Quais são as principais funções da aplicação? Essas funções podem ser comprometidas de alguma forma?

O que poderia dar errado?

Nesta etapa, é importante identificar os elos vulneráveis da corrente. Quais problemas são mais prováveis que aconteçam?Tenha em mente o tipo de tecnologia utilizado e imagine em que condições a aplicação seria utilizada e assim você conseguirá listar os principais “pontos de fraqueza”.

Quais são os testes mais adequados?

Após responder todas as questões acima, já conseguimos ter uma ideia dos testes que podem ser realizados. Por exemplo, se a minha aplicação está aguardando um grande fluxo de acesso, o indicado é realizar um stress testing.

Quais riscos nós aceitamos correr?

A essa altura é muito provável que você já saiba em que pontos do projeto deve ser investido mais tempo de teste. Agora o desafio é filtrar essa informação, portanto o objetivo dessa 5ª pergunta é medir o custo/benefício de garantir a qualidade dos pontos identificados ao responder as questões anteriores.

Organize toda a informação coletada anteriormente por ordem de importância, assim você poderá, eventualmente, identificar pontos que inicialmente podem ser despriorizados.

Para ajudar neste processo, algumas questões, como as descritas abaixo podem ajudar:

• Eu aceito que a aplicação não tenha um excelente desempenho num navegador/dispositivo pouco utilizado pelos meus usuários?
• Quão relevante é para mim se a aplicação tiver alguma quebra de layout?
• Erros de ortografia são críticos?
• Verificar o acesso a partir de uma conexão lenta realmente faz sentido para o meu tipo de aplicação?

Modelo de análise de risco para testes de software

Em resumo, o principal objetivo desse método é cruzar três tipos de informação a respeito da aplicação:

Portanto, o processo de tomada de decisão deve ser totalmente orientado à aplicação:

1. Analisando primeiro os objetivos que ela deve atingir;
2. Depois pelos pontos que podem comprometer o cumprimento destes objetivos;
3. E por último as duas primeiras informações devem ser cruzadas com o prazo e orçamento disponível.

Com esse método é possível garantir que o tempo e orçamento disponíveis estão sendo utilizados da maneira mais adequada ao seu projeto.