(Escrito na data de postagem)
Para quem só lê meu blog eventualmente pode se perguntar com que trabalho, por incrível que pareça, com computação… Com isso, este é meu primeiro artigo relacionado à área que estou publicando aqui no blog.
Por alguns anos da minha vida tive o prazer de trabalhar com Testes de Softwares, consegui passar por diversos projetos e conhecer inúmeros tipos de estratégias para a execução efetiva dos testes. O que mais gosto quando executo testes é conhecer o sistema, ser a persona, se posicionar como alguém que de fato estaria usando o sistema para uma ação crítica ou rotineira.
Com isso vi nascer uma Intranet com diversos módulos, participei de um projeto internacional de Gestão de frota de veículos, e por fim, também trabalhei com diversos sistemas de um conjunto SaaS de telemetria de energia elétrica, gestão de gás e saneamento. Atualmente não testo mais sistemas, sendo que minha nova praia é gestão, contudo o feeling acaba me forçando a “dar uns pitacos” e acompanhar a equipe de testes mais de perto.
A área de Tecnologia da Informação é tão volátil que me impressiona. Em poucos anos o cenário da área se transforma e percebo que coisas que antes eram habituais, já não são mais usadas. Trabalhei em empresas pequenas e grandes, em fábrica de software e em empresas especializadas, já trabalhei em equipes de 30 testadores, com terceirizados, com alocados e já trabalhei sozinho. Sei das diferenças no dia a dia dos testes, contudo acho curioso que coisas que aprendi como fundamentais, hoje nem sequer são usadas, enfim, parte da evolução.
Ainda assim, acredito que toda a parte que rege um Plano de Testes tem um grande valor, testes manuais são e serão usados por muito tempo ainda e é de suma importância saber estruturar uma documentação mínima para servir como guia. Com isso chego à proposta desse artigo, pincelar um pouco sobre cenários de teste.
Quando comecei a trabalhar com teste de sistemas em 2015 aprendi a fazer casos de teste. Um caso de teste pode ser definido como um documento que evidencie o passo a passo para a execução de uma unicidade de teste, apresentando os acessos, pré e pós condições, resultados esperados e passos para a reprodução do teste. Um único caso de teste pode ter inúmeros passos e demorar para ser escrito e executado, é uma documentação fidedigna e completa para garantir a qualidade máxima dos testes manuais. Usam-se ferramentas para escrever e gerenciar as execuções dos testes, com isso várias pessoas podem trabalhar em conjunto e revezarem entre documentação e execução das baselines de testes.
A definição acima é linda, contudo quem é que tem tempo e instrução para fazer N casos de testes para N atividades em cada ciclo de incremento do sistema? Infelizmente falta mão de obra para a maioria das empresas.
Por isso apresento-lhes (como se fosse uma novidade) os Cenários de Testes. Estes são formas mais rápidas de listar os testes de uma funcionalidade, de forma menos descritiva, mas direta ao ponto. Recomendo a utilização dos cenários de testes em ambientes que não há nenhum roteiro de testes. O famoso, melhor ter algo do que não ter nada. Mas, brincadeira a parte, a utilização dos cenários pode ser de fato efetiva.
Para escrever um cenário de testes devemos ter em mente a funcionalidade do sistema testado. Algumas perguntas podem ser feitas:
- A funcionalidade é integrada com outras funcionalidades ou é algo isolado?
- Ela é de uso crítico?
- Ela será usada rotineiramente ou eventualmente?
- Quando é a data de vencimento para a entrega dos testes?
- Qual é a disponibilidade de tempo para a execução dos testes? (já considerando a documentação dos cenários)
Essas perguntas servem de base para imaginarmos a dimensão da funcionalidade.
Para ser o mais simples possível, vou dispensar o uso de ferramentas para documentar os cenários, pois bem, abra um bloco de notas, um Word ou documento do Google, como preferir. Após isso liste as pré-condições para o teste:
Exemplo:
- Usuário deve ser do tipo consultor
- Usuário deve estar logado no sistema no módulo de relatórios
- Usuário deve ter a permissão “acesso dinâmico”
- Usuário deve estar na tela de “Relatório de Manutenção Dinâmica”
Com isso em mãos imagine a unicidade de cada teste, desde os layouts até a execução das ações.
Exemplo:
- A tela deve conter uma lista pré-carregada com os últimos registros
- A tela deve conter os botões datas e de gerar relatório
- O botão de gerar relatório só deve ser ativado quando o usuário já tiver selecionado as datas
- A cor de fundo do sistema deve ser vermelha, preta e branca em listras tricolores
- O sistema deverá apresentar um loader enquanto o relatório é gerado
- Após o relatório ser gerado o sistema deverá habilitar o botão para exportar em CSV
- O sistema deve mostrar a mensagem “Relatório gerado com sucesso, você já pode exportá-lo” após o usuário gerar o relatório
Enfim, são N possibilidades, depende da funcionalidade e da criatividade do testador que está a escrever os cenários, com o tempo isso irá se facilitando e dinâmico, também é possível reaproveitar alguns dos cenários de testes em outras funcionalidades que tenham semelhança em si. Ao ter mais de um testador na equipe, o ideal é que o que escreveu os testes não os execute, invertendo os papéis para cada funcionalidade.
O mais importante de tudo é ter seriedade na escrita dos cenários, estar com a mente limpa para surgir a criatividade, diversos artigos, vídeos e exemplos podem ser achados no Sr. Google, seja prático e procure o melhor para o seu caso, a teoria está aí para ajudar e não para servir de julgamento, adapte-a, teste, inove.
