Muitas vezes nos preocupamos tanto com os Testes Funcionais (principalmente quem faz uso de metodologias ágeis) que não reservamos tempo para testes não funcionais como testes de segurança, de desempenho, de usabilidade entre outros.

Foi exatamente isto que muitas pessoas pensaram quando viram o ‘escândalo’ causado por Marco Agner através das suas descobertas de falhas no site ingressos.com.

Em seu blog ele publicou em 03 de maio de 2014, falhas de segurança no site do serviço prestado pela empresa Ingressos.com caracterizando como falhas críticas por dois motivos:

• Expõem informações de clientes;
• Coloca em risco o principal serviço oferecido;

Estas falhas, apensar de extremamente graves, nada mais é que descobrir o ID de um parâmetro GET recebido por um arquivo .php.

Explicando melhor o comando GET, basicamente é você ter uma URL parecida com isto:

http://exemplo.com.br/arquivoexemplo.php?nome=ROGER

E alterar os valores correspondentes com o que você procura, no exemplo acima estou buscando os dados de ‘ROGER’ , se eu quiser ver os dados do
Paulo, alteramos para ‘PAULO’ ao invés de ‘ROGER’ , se eu quiser ver os dados da Maria, então portanto, ‘MARIA’ ao invés de ‘ROGER’.

Ex.: http://exemplo.com.br/arquivoexemplo.php?nome=PAULO

Ex.: http://exemplo.com.br/arquivoexemplo.php?nome=MARIA

Agora, a descoberta do autor que foi a grande jogada, veja como era banal:

Esta é a impressão de um ingresso, isto mesmo, ingresso!

Perceba acima o ‘ID’ com o número: 29042014 28557363 359458690931, e agora veja os dados da compra que ele realizou:

Buscando o ID novamente então: 29042014 28557363 359458690931, logo na primeira visualização já percebe-se que os primeiros dígitos são a data e os últimos dígitos são a hora que o usuário efetuou a compra. Portanto agora faltava descobrir os outros números que foram encontrados no código, como mostra o autor através de uma imagem:

Ok, código descoberto, alterasse para o código de uma outra pessoa e pimpa! Abre o ingresso meu, seu, de quem quiser. Além disto o autor destaca que poderia alterar o código ilustrado na imagem acima e sem informar os outros dígitos que também funcionava.

O post original de Marco Agner está disponível através deste link. (Acessado em 04/03/2015)

Ou em forma de impressão (.pdf) através deste link.

Repercussão

A falha descoberta por Agner teve grande repercussão especialmente nos sites da INFO e EXAME onde impulsionaram a notícia do feito do autor.

Veja na INFO através deste link.

Veja na EXAME através deste link.

Equipes Ágeis x Testes não funcionais

Equipes ágeis inicialmente tendem a garantir a funcionalidade dos incrementos para depois atacar as não funcionalidades como segurança e desempenho, por exemplo. Isto quando o ‘Líder de Testes’ traça este tipo de estratégia.

Este assunto já é bastante antigo, Scott Ambler causou muita discussão quando ele declarou em 2008: “O conceito de product backlog do Scrum
funciona bem para requisitos funcionais simples, mas… se torna insuficiente para requisitos não-funcionais e restrições de arquitetura.” através deste artigo no site Dr.Dobb’ s.

Seu artigo também teve bastante repercussão naquela época especialmente no Scrum Development Yahoo Group (Grupo de Desenvolvimento em Scrum do Yahoo) no qual uma das soluções para este tipo de problema foi que os requisitos deste tipo seriam tratados na ‘Definição de Pronto’ do time. Isto é, cada história não é considerada pronta até que tenha sido determinado que a implementação da estória satisfaça o requisito não funcional, de desempenho, por exemplo. Esta análise seria feita através de um processo de revisão e/ou testes de carga.

Conclusão

Testes não funcionais são sempre muito importantes, como Agner nos mostrou, o que ocorre é que algumas empresas ainda não perceberam a importância da Qualidade de Software em seu processo de desenvolvimento, empresas com fluxo muito intenso como a I ngresso.com, no exemplo de Agner, deve-se realizar testes não funcionais para não deixar lacunas como o desenvolvedor encontrou. Portanto é provado que existem problemas na equipe de Qualidade de Software desta empresa.

Provavelmente um usuário leigo não encontraria as falhas que o desenvolvedor encontrou, mesmo assim ainda continua sendo uma falha encontrada e repercutida no ambiente de produção no qual os custos desta falha serão bastante alto, pois não pode-se dizer que a utilização dos serviços desta empresa são seguros na presente data.

Considero o teste funcional o mais importante pois antes de realizar qualquer validação sobre um incremento devemos saber se ele cumpre os requisitos estabelecidos, ao efetuar testes não funcionais a um incremento no qual seus requisitos não foram validados corre-se o risco da
entrega ser falha e consequentemente um incremento não utilizável. Portanto, antes de qualquer teste, sugiro o teste funcional para após deste providenciar os testes não funcionais.

Concorda com isto? (comente abaixo)