Quais os tipos de testes que pode realizar?
Last updated
Last updated
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.
Os testes técnicos ocorrem na fase de desenvolvimento e executados pelos programadores. A imagem abaixo ilustra a organização dos diferentes tipos de teste.
Testes efetuados a um método/função do código (métodos privados não são testados diretamente). 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 destinados a verificar se dois sistemas/componentes do sistema conseguem comunicar conforme o esperado.
Normalmente este tipo de testes não é desenvolvido, devendo-o ser apenas em casos onde se justifique tal necessidade.
A equipa deve decidir acerca da sua criação ou não conforme as suas reais vantagens, uma vez que os testes E2E também cobrem normalmente esta parte.
Testes efetuados a interfaces públicas (webservices REST/SOAP, métodos de APIs, 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 efetuados para verificar se a interface de utilizador se encontra conforme o esperado. Podem ser realizados manualmente ou através de ferramentas de testes E2E orientados a frontends.
É importante garantir que as funcionalidades cumprem os requisitos de usabilidade e acessibilidade.
Testes que visam avaliar a capacidade de um sistema em responder a elevados números de pedidos simultâneos ou durante um determinado período de tempo.
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 apresenta 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.
Na segunda etapa fazem-se testes às funcionalidades, validando 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).
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 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.
Comparar os dados apresentados no ecrã com os dados da base de dados, seja pela consulta direta à BD com queries ou download de um excel com os dados extraídos da BD.
Os testes de acessibilidade são importantes para garantir que as aplicações e sites são acessíveis a utilizadores algum tipo de limitação. Podem ser feitos manualmente, no entanto, é recomendado recorrer a sites que permitem ter resultados fiáveis, mais rapidamente. Também é importante fazer testes com utilizadores que representam o publico alvo.
Access Monitor – Apresenta uma pontuação de 0 a 10 e identifica erros críticos, bem como melhorias de usabilidade e acessibilidade.
W3 – Apresenta warnings e erros que devem ser corrigidos.
LightHouse – Gera um report com uma avaliação em vários critérios e apresenta uma pontuação de 0 a 100%.
Tabs – Testar se, ao clicar no Tab, os campos de ação ficam disponíveis para serem executados, respeitando 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.
Leitor de ecrã NVDA – Aplicação instalada no desktop que lê o conteúdo que está na página, transmitindo áudio no idioma selecionado. Ao fazer este teste, é importante garantir que os elementos de texto são lidos corretamente, pela ordem que é suposto, bem como indicadores (números), botões de ação e links.
Para obtenção do selo de usabilidade e acessibilidade, preenchem-se as checklists apresentadas no site do selo:
Também são feitos testes de acessibilidade convidando pessoas que a entidade seleciona. Os participantes assinam um contrato de confidencialidade para participar na sessão. 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 é facilmente utilizado pelo publico 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 que se pretende testar. Estas pessoas assinam um contrato de confidencialidade e são acompanhadas pela equipa que organiza a sessão, seguindo um guia de testes que lhes é apresentado.
Os testes funcionais e de acessibilidade são feitos pela equipa de testes que é composta por analistas funcionais ou especialistas de UX. Estes testes ocorrem depois dos 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 .
Em qualquer uma das fases de teste acima descritas, posteriormente à 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.
