O documento discute como realizar testes de interface do usuário, abordando 4 aspectos principais: 1) verificar se as informações estão corretas, 2) testar se as mudanças na tela ocorrem como esperado após ações do usuário, 3) testar a acessibilidade, e 4) verificar a usabilidade. Também discute a importância da automação dos testes de interface.
DevQA - Da zona de conforto ao comprometimento com a qualidade
DevQA: UI Testing , como fazer?
1. DevQA: UI Testing , como fazer? - por Kamilla Queiróz
Os testes de interfaces são uma das atividades mais trabalhosas e difíceis de serem
executadas, pois além do aspecto subjetivo da pessoa que está testando e a complexidade
das técnicas envolvidas, ainda existe a questão de saber se efetivamente aquela interface
será funcional para o usuário que irá usar o sistema.
Como fazer testes de interfaces ? Será que só existe a forma manual ? Porque são tão difíceis
de fazer e manter ? Esse artigo tenta mostrar o que pode ser testado e quais as dificuldades
no que não pode ser testado efetivamente.
Se tentarmos focar no que podemos avaliar nos testes de interface, poderíamos resumir em:
1 - Testar se a informação está correta;................................................................
2 - Testar se as mudanças na tela esperadas foram causadas pela ação correta;.............
3 - Testar as capacidades de acessibilidade;..............................................................
4 - Verificar a usabilidade da aplicação.
1 - Testar se a informação está correta
Para saber se as informações estão corretas, de início, podemos começar com uma técnica
simples de verificação ortográfica, onde as palavras são verificadas baseadas em um
dicionário, usando a ferramenta Apache Lucene.
Verificar se os nomes dos campos estão corretos ou se eles fazem sentido pro usuário, já faz
parte da questão subjetiva de cada usuário e conhecimento prévio do nicho de negócio que a
aplicação está atendendo.
Por exemplo, um campo Valor do Lançamento de Crédito para um contador experiente pode
ser muito simples, mas para um estagiário de contábeis do primeiro semestre que está
iniciando sua carreira, ao contrário, pode ser um fator que eleve a complexidade do
entendimento.
Algumas técnicas como interfaces heurísticas, falam de psicologia para tratar a informação de
forma efetiva para o usuário, então fica fora do espoco de teste e sim fazendo parte do
espoco do projetista da interface reconhecer esse melhor padrão. O que podemos fazer, é
rastrear se a interface está chegando no objetivo pretendido, ou seja, se um dado usuário
está conseguindo fazer o que ele quer, onde falaremos mais a frente.
Para aplicações web, podemos testar também quanto a informação, se os links, se o CSS e o
HTML estão dentro dos padrões. Isso mitiga problemas de interfaces em diferentes browsers e
diferentes dispositivos.
Ferramentas como a W3C Tools podem verificar isso de forma manual ou de forma automática
usando uma API
2 - Testar se as mudanças na tela esperadas foram causadas pela ação correta.
Verificar se o usuário clicar no botão "Tipos de pagamentos" e a aplicação mostrar os tipos de
pagamento possíveis dado um certo produto é uma das ações que podemos testar quanto à
interface. Isso é levantado facilmente pelos cenários de teste especificados.
Contudo, se fizermos um mapeamento de todos os fluxos possíveis dos cenários que foi
especificado, teremos uma explosão de possibilidades, assim, o foco é criar scripts de teste
que consigam uma boa cobertura do código, ou seja, aqui temos que fazer os scripts
2. pensando em chegar em todas as possibilidades do código e não dos fluxos alternativos dos
cenários. É importante perceber essa distinção.
Nesse ponto, já esperamos que a qualidade de cobertura dos cenários para o negócio que
estamos criando já esteja em um nível aceitável. Caso não, e, possivelmente acontecerá, os
fluxos alternativos mostraram 'furos' nos cenários, e assim mais cenários para cobrir todas as
possibilidades devem ser feitos e logo mais código deves ser criados para atender essas
funcionalidades. No final, iremos verificar a cobertura do código e não dos fluxos..
3 - Testar as capacidades de acessibilidade
Acessibilidade trata da questão que pessoas que não tem tanta habilidades ou que tenham
alguma deficiência ou restrição, possam usar a aplicação, ou seja, significa que as pessoas
com menos habilidade ainda possam perceber, entender, navegar e interagir como o sistema.
A W3C, também tem vários guias que descrevem inúmeros itens de acessibilidade que
podemos ter na nossa aplicação e lista várias ferramentas que podemos usar para avaliação
do nosso sistema.
- Lista de Itens de Acessibilidade...........................................................................
- Wave - Ferramenta de Medição de Acessibilidade
Por exemplo, um dos testes dentro da ferramenta é o teste de contraste, que verifica se as
cores se diferem em um nível possível, para que uma pessoa que tenha alguma deficiência
visual possa reconhecer. Ele também é um bom indicador para mostrar onde você quer
gostaria de atrair uma maior atenção de usuários comuns, ou seja, um botão de concluir uma
ação como uma compra ou pagamento.
Você pode fazer isso utilizando plugins como por exemplo para o Chrome: Accessibility
Developer Tools.
4 - Verificar a usabilidade da aplicação
Como mencionado mais acima, não podemos avaliar ainda com certeza a efetividade de uma
interface para um dado usuário antes de que a aplicação esteja em uso, mas podemos
verificar se ele está conseguindo fazer o que realmente ele quer.
Ferramentas como fluxo de comportamento, usando mecanismos como Clickstream ou
Heatmap, avaliam os caminhos que o usuários usaram para conseguir fazer o que ele
realmente desejavam, ou seja, se o usuário ficou procurando em cada menu a opção que ele
queria ou se ele entrou em várias telas e clicou no cancelar. Mostrando assim um padrão de
comportamento, e dessa forma pode sugerir que a interface não está adequada ao perfil de
usuário pretendido.
Nesse sentido já há algumas ferramentas sendo usadas, por exemplo a Loop11, mas ainda
existe outras.
Automatizando Testes de Interface
Sabemos então que Teste de Interface se difere dos testes de classe por exemplo, por como
dito, trabalhamos com elementos e interações de usuários, mas que tem tanto valor agregado
quanto os testes realizados em server-side.
E automatizando os testes de interface, ganharíamos na identificação dos problemas
encontrados. Mas alguns pontos devem ser motivadores quanto a automação desses testes:
3. - Em inclusões de novas funcionalidades em uma dada página, com o reaproveitamento,
modificação ou sobrescrita de algum Javascript por exemplo, se já automatizado esses testes,
é possível verificar onde os testes pararam e fazer a análise do erro;
- Atualização de biblioteca, caso os testes de interfaces estejam automatizados, a equipe de
testes e qualidade não gastaria tempo demasiado na validação dessa atualização;
- Scripts costumam ser mais simples, assim todos os integrantes da equipe são capazes de
realizar manutenção e atualização;
Garantia de evolução
Outra questão para aumentar o esforço nos testes de interfaces, é a questão da manutenção.
Se eu construir vários scripts que testam minha interface, qualquer modificação que pode ser
simples na perspectiva de código, pode ser um terror para a perspectiva dos testes de
interface.
Assim, é importante componentizar usando padrões de projeto para testes, como podemos vê
em Page Objects e Builder. Da mesma forma que temos reuso e a componentização na
implementação, scripts de testes também são códigos, e precisam de um bom nível de reuso
e modificabilidade.
Dependendo do nível de estabilidade do sistema, podemos querer somente garantir que a
interface não mude, por exemplo durante um refactoring de código, ou alguma
reestruturação interna necessária para para evolução do sistema ou infraestrutura.
Assim, podemos investir em Testes de Regressão Visual, onde é feito o armazenamento em
formato de imagens ou screenshots da aplicação, para posterior verificação de forma
automática.
Assim podemos investir tempo na execução dos Testes de Interface abordando:
Quanto à acessibilidade
- Testes de Contrates.........................................................................................
- Verificador de Links.........................................................................................
- Verificador de CSS...........................................................................................
- Verificador de HTML.........................................................................................
- Verificador de JavaScript
Quanto à usabilidade
-Rastreio de Ações.............................................................................................
-Heatmap......................................................................................................
-Clickstream Analysis
Links Relacionados:
- Best Web Analytics 2.0 Tools: Quantitative, Qualitative, Life Saving!..............................
- Testing the user interface: Automated and exploratory testing....................................
- Uso de Headless Browsers em Testes Automatizados................................................
- Um pouco sobre as palestras no TDC 2015 Florianópolis.........................................
- Introdução à Interfaces Eurísticas........................................................................
- Ferramentas de Teste de Usabilidade...................................................................
- Applitools.....................................................................................................
- Validaor de API...............................................................................................
- W3C Tools.....................................................................................................