DevQA: UI Testing , como fazer?
0 gostou335 visualizações
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: 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.....................................................................................................
- 4. - Phantomjs.org................................................................................................ Publicado originalmente em O Tapioca: http://www.otapioca.com.br/?p=2910