Quais os tipos de testes que pode realizar?
Os testes de software são bastante amplos e podem ser categorizados em vários tipos. De forma simplificada, podem pertencer a dois grandes grupos – testes técnicos e testes funcionais.
Testes técnicos
Os testes técnicos ocorrem na fase de desenvolvimento e são feitos pelos programadores. A imagem abaixo ilustra a organização dos diferentes tipos de teste.
Testes unitários: efetuados a um método/função do código (métodos privados não são testados de forma direta). Todas as dependências que sejam de código desenvolvido no projeto devem ser simuladas, isto é, assumir que a resposta do componente respeita a estrutura pretendida.
Testes de integração: destinados a verificar se dois sistemas/componentes do sistema conseguem comunicar conforme o esperado. Por norma este tipo de testes não é desenvolvido, devendo ser apenas em casos onde se justifique. A equipa deve decidir sobre a sua criação ou não conforme as vantagens, uma vez que os testes end-to-end também cobrem esta parte.
Testes end-to-end (E2E): realizados a interfaces públicas (webservices REST/SOAP, métodos de API, etc.) que testam o software desenvolvido como sendo uma caixa preta (black box). Verificam, em primeiro lugar, se o sistema se comporta conforme o indicado pelos critérios de aceitação, e em segundo lugar, potenciais bugs.
Testes de UI: verificam se a interface de utilizador (UI em inglês) se encontra conforme o esperado. Podem ser feitos de forma manual ou através de ferramentas de testes E2E orientados para frontends. É importante garantir que as funcionalidades cumprem os requisitos de usabilidade e acessibilidade.
Testes de carga: visam avaliar a capacidade de um sistema para responder a elevados números de pedidos simultâneos ou durante determinado período de tempo.
Testes funcionais
Os testes funcionais e de acessibilidade são feitos pela equipa de testes, que é composta por analistas funcionais ou especialistas de UX (experiência do utilizador em inglês). Estes testes ocorrem após os testes técnicos (quando a funcionalidade está desenvolvida) e antes dos testes de aceitação (quando o cliente aceita a funcionalidade). Os diferentes cenários de teste são identificados e descritos no caderno de testes, por forma a garantir que são testados e a acompanhar os resultados – ver guia Como documentar testes funcionais.
Testar modelo: a primeira validação que se faz assim que uma funcionalidade está disponível para ser testada é verificar que os elementos de design estão de acordo com o protótipo aceite e que o conteúdo de texto não tem erros. Uma estratégia utilizada é copiar o texto que está na página para um documento Word para que o dicionário valide o texto.
Testar desktop: na segunda etapa fazem-se testes às funcionalidades, para validar a lógica e os diferentes cenários identificados no caderno de testes. Esta validação deverá ser feita nos browsers mais utilizados (Chrome, Firefox, Edge), onde se verificam os critérios de aceitação definidos nos user stories (no Jira, por exemplo).
Testar tablet e mobile: no caso de se tratar de uma aplicação web, devem ser feitos testes nos browsers mais utilizados em tablets e smartphones, como é o caso do Google Chrome (Android) e do Safari (iPhone). Se o sistema for uma aplicação móvel para smartphones, os testes são feitos nos sistemas operativos mais utilizados (Android e iOS); aqui testa-se o site no telemóvel para validar se é responsive, sendo feita uma comparação com o protótipo aceite.
Testar dados: comparar os dados apresentados no ecrã com os da base de dados (BD), seja pela consulta direta à BD com queries ou download de um Excel com os dados extraídos da BD.
Testar usabilidade e acessibilidade: estes testes são importantes para garantir que as aplicações e os sites são acessíveis a utilizadores com algum tipo de limitação. Podem ser feitos de forma manual, no entanto é recomendado recorrer a sites que permitem ter resultados fiáveis, de modo mais rápido. Também é importante fazer testes com utilizadores que representam o público-alvo.
Validadores automáticos
AccessMonitor – apresenta uma pontuação de 0 a 10 e identifica erros críticos, bem como melhorias de usabilidade e acessibilidade.
W3 – apresenta avisos/warnings e erros que devem ser corrigidos.
Lighthouse – gera um relatório com uma avaliação em vários critérios e apresenta uma pontuação de 0 a 100%.
Outros testes de acessibilidade feitos de forma manual
Tabs – testar se, ao clicar no tab, os campos de ação ficam disponíveis para serem executados, e respeitam a ordem correta.
Enter – testar se a tecla Enter funciona em botões e links.
Espaço – testar se a tecla Espaço funciona em botões de ação.
Testes de leitura de ecrã para audiovisuais
Leitor de ecrã NVDA – aplicação instalada no desktop que lê, em áudio, o conteúdo na página no idioma selecionado. Ao fazer este teste, é importante garantir que os elementos de texto são lidos de forma correta, pela ordem que é suposto, bem como indicadores (números), botões de ação e links.
Verificação das checklists de usabilidade e acessibilidade
Para obter o Selo de Usabilidade e Acessibilidade preenchem-se as checklists apresentadas no site do selo:
Sessões de testes com utilizadores:
Também são feitos testes de acessibilidade ao convidar pessoas selecionadas pela entidade. Os participantes assinam um contrato de confidencialidade para participar. A equipa que organiza a sessão acompanha os utilizadores dando-lhes as indicações necessárias para proceder aos testes. Segue-se a checklist de acessibilidade e também um guia de testes (caderno de testes). As sessões são gravadas, os resultados são recolhidos e analisados, é feito um relatório que serve também para o Selo de Ouro de Acessibilidade. Este relatório é feito pela equipa de UX e funcional.
É recomendado que se façam testes de usabilidade para garantir que o sistema é utilizado com facilidade pelo público-alvo. Estes testes são feitos, por norma, com um conjunto de pessoas que representam os utilizadores finais. Para tal, são selecionadas pessoas conhecidas com os perfis que se pretende testar; estas assinam um contrato de confidencialidade e são acompanhadas pela equipa que organiza a sessão, seguindo um guia de testes que lhes é apresentado.
Reportar resultados dos testes
Em qualquer uma das fases de teste acima descritas, a seguir à sua análise, se for identificado algum problema crítico, é incorporado na release, mas os restantes problemas e melhorias são planeados para releases futuras conforme a prioridade atribuída. Ver guia Como documentar testes funcionais.
Last updated