A heurística da MALDADE
Quebrando a ilusão do software perfeito
Introdução
Segundo James Bach:
“Não quebramos o software. Nós quebramos as ilusões sobre o software. ”
O que significa é que investigamos, observamos, descobrimos e relatamos como e onde um software apresenta inconsistência.
Como diz James Lyndsay, alguns testadores trabalham como “cães de caça”, ou seja, eles seguem uma trilha imperceptível, sem muitas vezes saber o que está no final, considerando que há um problema em algum lugar. A aplicação é explorada sem parâmetros, alguns bugs podem até ser encontrados, porém muitas vezes sem saber como reproduzi-los novamente. Através do uso de heurísticas, é possível nortear os testes com parâmetros, para que eles possam ser repetíveis.
Qual é o nosso papel?
Conforme Júlio de Lima escreve em seu ebook “Testes de softwares para iniciantes”, a pessoa que testa aplicações tem como um de seus objetivos principais a antecipação de problemas que só seriam identificados pelos clientes. Nossa tarefa é, através das técnicas empíricas e sistemáticas, colher informações sobre o produto, se está atendendo as expectativas do cliente, identificar e mitigar riscos, colaborar com o time e propor melhorias para o produto.
O que é uma heurística?
Conforme definido por Gabriel Santos no artigo “Heurísticas de teste de software: o que são e seus benefícios.”:
Heurísticas são processos que ocorrem naturalmente na mente do ser humano. Elas ajudam a solucionar problemas e tomar decisões em condições de incerteza, substituindo a forma complexa de fazer algo, por outra mais simples e ainda assim trazendo resultados satisfatórios.
Eu escolhi utilizar um acrônimo em que cada letra da palavra MALDADE representa uma ação a ser feita.
A heurística MALDADE surgiu após uma atividade realizada na mentoria do “Programa de Testes e Qualidade de Software”, em que o exercício prático em grupo era de quebrar a lojinha. Ou seja, dentro das técnicas que já conhecemos, nós pudéssemos identificar inconsistências nas aplicações API, Web ou Mobile da Lojinha.
Criando a heurística
Ao procurar no Google por “heurística para quebrar o software”, o resultado é decepcionante: não encontra-se nada. Porém, pesquisando o mesmo assunto em inglês, encontrei embasamento suficiente para criar a heurística que vai te ajudar a fazer os seus testes da quebradeira 😁.
Como base, utilizei o artigo “A Positive View of Negative Testing”(Uma visão positiva do teste negativo) de James Lyndsay, “Move Fast, Break Things: How to Test the Limits of Your Web App” (Mova-se rápido, quebre coisas: como testar os limites de seu aplicativo da web) de Alex McPeak e também pesquisa com a comunidade de testes, com a seguinte pergunta: “ O que vocês fazem quando querem quebrar o software que vocês testam?” as respostas estão representadas na nuvem de palavras abaixo.
A proposta da MALDADE é trazer sete características que podem ser exploradas tanto nos seus testes de aplicação Web, quanto para Mobile. São elas:
- Mude a ordem;
- Altere a conexão;
- SQL Injection;
- Deslocamento de página;
- Altere a resolução;
- Dados e tipos de campos;
- Expirar a sessão.
Abaixo, exemplifico como colocar em prática cada uma delas.
[M]ude a ordem
Nos casos de formulário, preencha o último item da lista e depois preencha o primeiro.
- Possíveis reações: As informações preenchidas permanecem nos campos?
- Exemplo: Em caso de endereço, colocar cidade antes do estado, depois preencher o estado e verificar se permaneceu ou apagou a cidade.
Nos casos em que não há formulário, realize uma ação secundária no lugar da primária.
- Possíveis reações: Permite realizar a ação secundária sem finalizar a primária?
- Exemplo: clicar em “Finalizar a Compra” sem ter selecionado um produto, ou as características (por exemplo: cor, quantidade, etc).
[A]ltere a conexão
Alterar o tipo de conexão com a internet ou retira-la totalmente, como é o caso do modo avião. Nesse princípio, será possível ver o comportamento da sua aplicação web e mobile de acordo com o tipo de conexão utilizada.
- Possíveis reações: O conteúdo foi carregado? Ocorreu timeout(tempo esgotado)? Foi tratada a exceção por falta de conexão ou timeout? Apareceu algum aviso na página informando que a conexão foi perdida? Ao enviar um arquivo e retirar totalmente a conexão, como a aplicação se comporta? Após a conexão ser reestabelecida, a sessão foi expirada? Em aplicativos que utilizam fila, mensagens ou eventos enviados durante a falta de conexão, elas são enviadas quando a conexão é reestabelecida?
- Exemplo para teste Web: Coloque em modo avião para testar a falta de conexão. Para testar diferentes velocidades de internet nos testes Web, você pode utilizar uma ferramentas de desenvolvimento do browser (no Chrome, é acessível com a tecla F12 ou Ctrl + Shift + L).
- Exemplo para teste mobile: Coloque em modo avião para testar a falta de qualquer conexão wireless. Para testar a velocidade, vá em configurações, busque por dados móveis, em seguida na opção rede preferida, selecione uma conexão inferior a habitualmente usada.
SQ[L] Injection
É um tipo de ataque à segurança na qual aproveita-se de falhas em sistemas que fazem uso de base de dados.
Esses ataques, geralmente, são utilizados através de formulários ou pela própria URL. O atacante insere alguma instrução SQL própria voltada para a linguagem utilizada pela aplicação. Ou seja, se for Java com JavaScript, usa-se uma instrução específica e indevida dentro da consulta SQL.
- Exemplo 1: Usar crases triplas antes e depois dos trechos de código para gerar code blocks. Iremos utilizar algo bem simples e online. O site é http://testphp.vulnweb.com, mantido e desenvolvido pela Acunetix WVS. Aplicaremos algo bem simples, logar no site sem usuário e senha:
Clique em Your cart e depois em login page. No campo Password, digite:
‘ or ‘’=’
ou “ ‘or 1=’1
ou “ “ ‘or 1=’1 “
ou ‘or 1=’1 “
e clique em login
O exemplo dado é muito simples, em que o invasor faz um teste com uma query(consulta) sql, supondo que a aplicação web usa uma autenticação de usuário e senha com o seguinte pseudocódigo:
![Definição de variáveis usuario = request.POST[‘username’] senha = request.POST[‘password’] # Consulta SQL para vulnerabilidade SQLi(SQL Injection) sql = “SELECT id FROM users WHERE username=’” + usuario + “‘ AND password =’” + senha + “‘“ # Execução da consulta database.execute(sql)](https://miro.medium.com/v2/resize:fit:1100/format:webp/1*wfbFE7iZIdUrBF2r7seXnw.png)
Assim, esses campos são vulneráveis a injeção, pois o invasor pode alterar o comando acima de uma forma que altere a instrução SQL executada pelo “banco de dados”. Como demonstrado anteriormente usando: ‘ or ‘’=’ o servidor executaria a consulta:
Além disso, numa instrução desse tipo, geralmente o primeiro ID de usuário numa base de dados é um administrador. Logo o invasor burlou a autenticação e ainda obteve os privilégios de administrador.
- Exemplo dois: Outra injeção seria a UNION, um acesso normal para consultar um artista no mesmo site: http://testphp.vulnweb.com/artists.php
Em que vemos três artistas cadastrados, mas podemos fazer a seguinte consulta para ter acesso ao primeiro artista: http://testphp.vulnweb.com/artists.php?artist=1
Nada de outro mundo, só clicar no primeiro.
Para fazer a injeção de UNION: http://testphp.vulnweb.com/artists.php?artist=-1 UNION SELECT 1, 2,’PTQS TURMA 1 SQLi’
Assim, o invasor consegue injetar na consulta original SQL através do operador UNION uma outra consulta, podendo ser maliciosa ou não.
Será que podemos fazer uma maldade?
O resultado da consulta injetada será associado ao resultado da consulta original. Isso permite que o invasor obtenha os valores das colunas de outras tabelas por exemplo.
[D]eslocamento de página
Fazer o deslocamento de página são as ações de “voltar” e “avançar”. Na Web, os navegadores já vêm com as setas na lateral superior esquerda. Você pode validar se foi criado o empilhamento das telas e também se, ao voltar ou avançar, o login por exemplo irá permanecer.
- Possíveis reações: Ao voltar pela seta do navegador, a página anterior é a página que estava antes? Avançar pela seta leva à página em que você estava antes da ação?
- Exemplo para Web: Faça login em um site da sua preferência e, depois de logado, volte e avance usando as setas. Veja se permaneceu o login. Faça em outras partes do site também. Em partes da aplicação que tem formulário, preencha eles, após voltar pelo navegador veja se os dados se perderam.
- Exemplo para Mobile: Faça login em um site da sua preferência, volte e atualize dando o scroll down(rolar para baixo).
Nos dispositivos móveis, ainda não tem a opção de avançar, mas tem o voltar. Você pode testar, entrando na sua aplicação de preferência e fazer um swipe left (deslizar para a esquerda) ou swipe right(deslizar para a direita) ou clicar no botão de voltar.
[A]lterar a resolução
Teste a responsividade da sua aplicação. Um site responsivo é aquele projetado para se adaptar a qualquer tipo de resolução, sem distorções. Quando falamos em testes Web, há algumas maneiras de alterar a dimensão da tela. A primeira forma, é ajustar o tamanho do browser, quando você restaura e arrasta as laterais da sua tela.
Outra forma de verificar a responsividade é através das ferramentas de desenvolvimento do browser (no Chrome, é acessível com a tecla F12 ou Ctrl + Shift + L). Depois de ativar, é possível trocar a responsividade colocando a resolução que você desejar ou escolhendo algum tamanho pré-definido. Válido para testes mobile.
Nos testes para aplicações mobile, você pode testar a alteração do tamanho da página habilitando a função de rotação e testando como o App se comporta.
- Possíveis reações: Os componentes da tela se adaptaram ao tamanho? Houve alguma distorção? Elementos sumiram ou ficaram inacessíveis?
- Exemplo para teste Web: Restaure o tamanho do browser de forma que ele não fique em tela cheia e altere as dimensões nas laterais.
- Exemplo para teste mobile: Ative a opção de rotação da tela, realize fluxos, por exemplo, de enviar o formulário e rotacionar a tela ao clicar em “enviar”. Observe o que acontece.
[D]ados e tipos de campos
Estamos quase terminando a maldaDe e espero que você tenha tido alguns insights quanto às possibilidades de fluxo alternativos.
Em dados e tipos de campo, o princípio é que você altere a entrada dos dados. Se é um CPF ou um número de telefone, coloque letras, ao contrário também. Em um campo em que é somente letras, atribua números. Para os campos que são do tipo data, preencha alterando as formas de entrada.
- Possíveis reações: Os campos que possuem máscara (forma como alguns tipos de dados podem ser organizados, com ponto, ou traço por exemplo a máscara de cpf, que pode ser 000.000.000–00) receberam dados diferentes dos quais eles foram programados? Qual o comportamento?
- Exemplo: Num campo que espera número de telefone, preencha com (51)09999.x@g!
[E]xpirar a sessão
Esse teste verifica se o aplicativo ou site faz o logout após ficar inativo por um tempo, garantindo que não seja possível utilizar a mesma sessão e que nenhum dado sensível permaneça armazenado. Você pode verificar com mais detalhes no OWASP (Projeto Aberto de Segurança em Aplicações Web). Se você não sabe qual é o tempo de sessão do que você testa, duas dicas: pergunte para o dev mais próximo ou teste na prática.
- Possíveis reações: Ao expirar a sessão, se usar o “voltar” do navegador, permanece na página ou avisa que precisa fazer o login? E no aplicativo, se abrir algum menu, ele inicia ou pede para logar?
- Exemplo: faça login na aplicação a qual você testou até aqui e deixe ela inativa por uns minutos, depois volte nela e veja se a sessão expirou e se é possível fazer a validação da heurística.
Conclusão
A heurística da maldade serve como um guia. Como tal, ela é uma solução falível para problemas complexos. Ela explora algumas facetas encontradas em nossas aplicações. Com certeza no dia a dia você vai encontrar outras artimanhas que são grandes sacadas nos seus testes, ou até mesmo lendo o artigo você pensou em outras possibilidades. Eu te encorajo fortemente a adaptá-la e até mesmo divulgá-la para outros tantos QAs e Devs que utilizam de heurísticas de teste.
Àqueles que decidirem experimentar a heurística, por favor, peço que respondam ao meu formulário de pesquisa clicando aqui. Ele é bem curto e irá me ajudar a entender sobre a sua percepção e o que encontrou durante seus testes.
Agradecimentos
Agradecimento especial ao Dennys Müller de Sá Benevides, que contribuiu para que essa heurística fosse construída, ele topou o desafio e trouxe a maldade do SQL injection. Muito obrigada, Dennys!
Agradeço ao Júlio de Lima por todo esse incentivo e por proporcionar essa mudança de mentalidade. Com certeza não sou e nem serei a mesma QA pós PTQS.
Agradeço aos revisores maravilhosos ❤ Cristhiane Jacques, Gabriel Santos, Júnior Sbrissa, Rafael Bandeira ❤
