Qual problema o teste automatizado da interface do usuário resolve?

No momento, estamos investigando testes automatizados da interface do usuário (atualmente, fazemos testes automatizados de unidade e integração).

Vimos o Selenium e o Telerik e decidimos o último como a ferramenta de escolha devido ao seu gravador muito mais flexível - e realmente não queremos que os testadores escrevam muito código.

No entanto, estou tentando entender o benefício geral. Quais são as opiniões das pessoas e que tipo de coisas funcionam bem e o que não funciona?

Nosso sistema está em constante desenvolvimento e lançamos regularmente novas versões de nossa plataforma (baseada na Web).

Até agora, o principal benefício que podemos ver é o teste de regressão, especialmente em várias implantações de clientes da nossa plataforma.

Realmente procurando pontos de vista de outras pessoas. "Pensamos" que é a coisa certa a fazer, mas em uma agenda já ocupada, estamos procurando informações adicionais.

Quando minha equipe implementou o teste automatizado de UI, muitas coisas boas aconteceram.

Primeiro, a equipe de controle de qualidade se tornou muito mais eficiente no teste do aplicativo e também mais proficiente com o aplicativo. O líder do controle de qualidade disse que conseguiu atualizar rapidamente os novos membros, apresentando-os aos conjuntos de testes da interface do usuário.

Segundo, a qualidade dos tickets de controle de qualidade que retornaram à equipe de desenvolvimento era melhor. Em vez de "A página quebrou quando eu cliquei no botão Enviar", obtivemos o caso exato que falhou, para que pudéssemos ver o que foi inserido no formulário. A equipe de controle de qualidade também deu um passo adiante, verificando todos os casos que falharam e testaram outros cenários nessa página para nos dar uma melhor visão do que aconteceu.

Terceiro, a equipe de controle de qualidade teve mais tempo. Com esse tempo extra, eles puderam participar de mais reuniões de design. Isso, por sua vez, permitiu que eles escrevessem os novos casos do conjunto de testes ao mesmo tempo em que os Devs estavam codificando esses novos recursos.

Além disso, o teste de estresse utilizado na suíte de testes valia seu peso em ouro. Sinceramente, me ajudou a dormir melhor à noite, sabendo que nosso aplicativo podia suportar praticamente qualquer coisa lançada nele. Encontramos algumas páginas que resistiram à pressão que conseguimos corrigir antes de ir ao ar. Simplesmente perfeito.

A última coisa que descobrimos foi que, com alguns ajustes da equipe de controle de qualidade, também poderíamos fazer alguns testes de injeção de SQL em nosso aplicativo. Encontramos algumas vulnerabilidades que conseguimos corrigir rapidamente.

A configuração do conjunto de testes da interface do usuário levou um bom tempo. Mas, uma vez lá, tornou-se uma parte central do nosso processo de desenvolvimento.

Testes automatizados de interface do usuário são os testes reais de integração. Eles testam todo o sistema da maneira como ele é realmente usado quando está ativo. Isso os torna os testes mais significativos. No entanto, eles também tendem a ser os mais frágeis e os mais lentos de executar.

Fique de olho na relação custo / benefício (com a fragilidade sendo parte do custo) e não hesite em ter algumas coisas que são testadas apenas manualmente (mas verifique se elas foram testadas). E, se possível, possibilite que os desenvolvedores executem partes específicas do conjunto de testes da interface do usuário na versão local do aplicativo, para que possam se beneficiar dos testes durante o desenvolvimento.

Ter os testes executados automaticamente em um servidor de construção (pelo menos uma vez por dia) é uma necessidade absoluta, é claro.

nós realmente não queremos que os testadores escrevam muito código.

IMO, este é um sonho. Criar testes automatizados é escrever código. A funcionalidade de gravação pode ajudá-lo a escrever um pouco desse código mais rapidamente e a começar a escrevê-lo manualmente (e diminuir a velocidade se você perder o ponto em que o código manualmente se torna mais rápido), mas, finalmente, escrever o código manualmente é o que você vai acabar fazendo muito. Espero que sua estrutura de testes o suporte bem e que o desenvolvimento não tenha se concentrado muito no sonho (muito vendável) de permitir que pessoas que não podem escrever código produzam testes automatizados.

e não queremos que os testadores escrevam muito código

Adotamos a abordagem oposta. Nós queria os testadores escrever código.

Aqui está o fluxo de trabalho que começamos a adotar. Não é fácil fazer isso porque o gerenciamento não depende absolutamente de testes automatizados do front-end. Eles estão dispostos a se contentar com "perto o suficiente".

1. Histórias de usuários.

2. Conceito operacional. Como a história provavelmente funcionaria. Revisão do projeto.

3. Esboço da tela: design da interface do usuário. Como ficaria.

4. Scripts de selênio. Se todos os scripts funcionarem, terminamos o lançamento.

5. Codificação e teste até o script funcionar.

O teste automatizado é a única maneira de demonstrar que a funcionalidade existe.

O teste manual é suscetível a erros e está sujeito à substituição do gerenciamento: "é bom o suficiente, esses testes com falha não importam tanto quanto liberá-lo a tempo".

"Qualquer recurso do programa sem um teste automatizado simplesmente não existe."

A apresentação visual é outra história. O teste manual de um layout visual é um caso excepcional, pois pode envolver julgamento estético ou examinar problemas específicos (pequenos) em uma tela grande e complexa de pixels.

Até agora, o principal benefício que podemos ver é o teste de regressão, especialmente em várias implantações de clientes da nossa plataforma.

Automatizar seu teste de regressão é uma coisa boa. Isso libera seus testadores para fazer um trabalho mais interessante - seja adicionando mais testes automatizados, testando o estresse do seu aplicativo ou qualquer outra coisa.

Além disso, ao automatizá-lo, você pode fazer com que seus desenvolvedores executem os testes e, portanto, previnem problemas que só serão descobertos posteriormente no processo.

Analisamos Selenium e Telerik e decidimos por este último como a ferramenta de escolha devido ao seu gravador muito mais flexível

Não tenho certeza do quanto você olhou para ele. Certamente existem outras opções também. Você já olhou Watir , WatiN , Sikuli para citar alguns?

e realmente não queremos que os testadores escrevam muito código.

Sinto-me mal pelas pessoas que precisam manter esses scripts. Na maioria das vezes, sem o código que pode ser facilmente modificado, os scripts se tornam frágeis e começa a demorar mais para modificá-lo do que para regravá-lo, o que desperdiça ainda mais tempo.

No entanto, estou tentando entender o benefício geral. Quais são as opiniões das pessoas e que tipo de coisas funcionam bem e o que não funciona?

A automação de teste é uma coisa bonita quando feita corretamente. Isso economiza tempo nos testes / verificações de regressão, de modo a dar aos testadores mais tempo para fazer o que eles fazem de melhor, testar. Não acredite nem por um momento que é uma bala de prata. Os scripts de automação requerem um tempo significativo para serem desenvolvidos, se o aplicativo já existir, mas os testes não, e exigem atualização constante a cada release. Testes automatizados também são uma ótima maneira de as novas pessoas da equipe verem como o sistema deve se comportar. Além disso, verifique se seus testadores decidem o que precisa ser automatizado. Se é uma verificação pequena que não leva muito tempo para ser verificada, é muito monótona e fácil de automatizar, comece com isso. Sempre comece com as verificações que mais ganham com a automação e trabalhe a partir daí.

Até agora, o principal benefício que podemos ver é o teste de regressão, especialmente em várias implantações de clientes da nossa plataforma.

É o principal benefício e, se configurado corretamente, pode testar a maioria dos navegadores necessários com uma pequena alteração na configuração.

"Pensamos" que é a coisa certa a fazer, mas em uma agenda já ocupada, estamos procurando informações adicionais.

Como afirmei anteriormente, a automação de teste exige esforços consideráveis; no entanto, quando feita corretamente, ainda não conheci uma equipe que disse: "Gostaria que não tivéssemos configurado nossa automação de teste".

Você está certo que a regressão é enorme. Além disso -

• se seus testes são escritos de forma modular, você pode obter mais retorno, misturando e combinando conjuntos de testes

• reutilizamos scripts de teste automatizados para carregamento de dados, para que não tenhamos de julgar um banco de dados para realizar testes de tamanho grande

• teste de performance

• testes multi-thread

• em sistemas web - troca entre navegadores e troca entre sistemas operacionais. Com os problemas de consistência do navegador, atingir uma base tão ampla quanto possível é algo imenso.

Coisas a serem ignoradas - especialmente em sistemas Web, observe os casos em que os elementos de sua exibição são criados com IDs dinâmicos e variáveis ​​- os scripts de teste automatizados geralmente não lidam bem com isso, e você pode precisar de uma reformulação séria para atualizar isso.

Apenas um exemplo: medir com precisão a duração da renderização da página da web

Usando testes de automação, é muito mais fácil testar o desempenho do navegador da web. Para medir o tempo máximo de resposta que você provavelmente aceita, basta definir uma constante em seus scripts de teste e / ou passar como parâmetro de função, por exemplo, neste pseudocódigo: $ sel-> wait_for_page_to_load ($ mypage, $ maxtime).

Fazer testes entre navegadores com valores baixos pode ser bastante esclarecedor.

A alternativa seria que os funcionários fizessem medições de tempo com um cronômetro.

O teste automatizado da interface do usuário resolve a capacidade de:

• repita rapidamente o teste de um grande número de componentes
• lembre-se de testar um grande número de funções cada vez
• comparar execuções e tempos de execução de suítes de teste à medida que o aplicativo cresce
• configurar é executado com centenas de entradas diferentes e condições variáveis
• permitir que pessoas que não escreveram o teste o executem e vejam problemas visuais
• permite que os usuários finais vejam o aplicativo sendo usado de maneira rápida e fácil
• distribuir a interface do usuário de teste para uma rede, servidor ou serviço remoto
• inicie o teste de volume usando máquinas paralelas.

No entanto, como outros observaram:

Telerik ...

a ferramenta de escolha devido ao seu gravador muito mais flexível

é uma bandeira vermelha para muitos de nós.

Os scripts gravados dessa maneira tendem a não ser uma solução de longo prazo porque:

• O ID do banco de dados / objeto tende a mudar de caso para caso
• scripts gravados manualmente geralmente dependem de tags de layout de página que mudam frequentemente
• ações comuns precisarão ser repetidas vezes, em vez de permitir a reutilização (consulte a abordagem SitePrism e PageObject)
• às vezes você precisa usar ferramentas como o xpath para obter informações adicionais com base nas informações da página atual. Um script simples gravado não fará isso.
• desenvolvedores e testadores que escrevem código não serão incentivados a usar classes CSS, IDs e atributos de dados HTML5, que são práticas que levarão a testes mais robustos e com manutenção.

A Telerik tem algumas vantagens que devem ser consideradas:

• destinado a clientes móveis
• ferramentas integradas para gerenciar o crescimento
• lida com Android, iOS e Windows Phone

Uma abordagem que pode ajudar a preencher as lacunas é gravar o script inicial usando o gravador de páginas de ferramentas, mas depois alterá -lo para usar IDs, classes e atributos de dados para que dure com o tempo. Essa é uma abordagem que eu realmente usei com o plug-in do firefox selenium.

Torna o "Teste Especialista" (semelhante ao "Teste Exploratório", mas realizado por usuários finais ou membros da equipe com grande conhecimento de negócios) mais fácil de executar, registrar resultados, medir e automatizar.

Eu venho disso de um fundo diferente. Nos meus antigos empregadores, desenvolvemos ferramentas comerciais automatizadas de teste (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Vimos o teste automatizado da interface do usuário como preenchendo duas funções:

1. Teste de regressão completo

2. Configuração automatizada de ambientes de teste

Nós nos apoiamos fortemente nas ferramentas para realizar testes de regressão todas as noites. Simplesmente não tínhamos o poder de testar todos os botões e caixas de diálogo para verificar se não quebramos nada entre a interface do usuário e a lógica de negócios.

Para testes mais importantes, descobrimos que uma única pessoa poderia ativar várias VMs e usar scripts para chegar ao ponto de um teste real. Isso permitiu que eles se concentrassem nos bits importantes e não tentassem seguir um caso de teste de 24 etapas.

O único problema com testes automatizados era o hábito de despejar muitos testes na caixa sem qualquer tipo de supervisão para eliminar testes duplicados ou desnecessários. De vez em quando, tínhamos que remover as coisas para que a suíte pudesse ser concluída em menos de 12 horas.

O teste automatizado, de qualquer tipo, fornece testes de regressão; executando o teste que costumava funcionar, você verifica se ele ainda funciona (ou não), independentemente do que você adicionou. Isso ocorre independentemente de o teste ser um teste de integração (que geralmente não toca na interface do usuário) ou um AAT (que geralmente requer a interface do usuário).

O teste automatizado da interface do usuário permite que o sistema seja testado como se um usuário estivesse clicando nos botões. Dessa forma, esses testes podem ser usados ​​para verificar a navegação no sistema, a correção de marcadores e / ou mensagens, o desempenho e / ou o tempo de carregamento em um ambiente de teste específico, etc. etc. O objetivo principal é reduzir o tempo gasto pelo pessoal de controle de qualidade clicando nos botões, bem como integração e testes de unidade fazem para o programador. Ele pode configurar um teste por vez (geralmente gravando seus próprios cliques do mouse e entradas de dados em um script) e, uma vez que o teste funcione corretamente, tudo o que ele deve fazer para verificar se a correção do sistema em teste é executada novamente. Algumas estruturas, como o Selenium, permitem a migração de testes entre navegadores, permitindo o teste de vários ambientes nos quais o site deve funcionar corretamente.

Sem testes automatizados, você é limitado pelo número e velocidade de seus testadores de controle de qualidade; eles devem literalmente ter um sistema prático, testando se seu novo recurso atende aos requisitos e (da mesma forma que importante) que você não quebrou nada que já estava lá.

O teste determina muitas coisas diferentes. Muitos desses testes podem ser automatizados, para permitir a remoção de trabalhos pesados ​​e para fazer mais. Para determinar se seus testes podem ser automatizados, primeiro você precisa ver se a pergunta que eles fazem é apropriada.

• Você está determinando se um componente funciona de acordo com as especificações?
• Deseja testar todas as diferentes entradas e saídas possíveis?
• teste de estresse do componente?
• Ou você está tentando testar se "funciona"?

A maioria deles pode ser automatizada, porque é de natureza mecânica. A nova função aceita entradas, então o que acontece quando lançamos dados aleatórios para ela? Mas alguns, como testar se o sistema funciona, exigem que alguém realmente o use . Caso contrário, você nunca saberá se as expectativas dos usuários são as mesmas do programa. Até que o sistema "quebre".

Na minha experiência, o teste automatizado da interface do usuário cobre muitas lacunas, incluindo:

• Falta de documentação (exemplo: usando o executor de teste automatizado para demonstrar a funcionalidade existente)
• Requisitos desatualizados devido à fluência do escopo (exemplo: identificando a diferença entre os requisitos e o código capturando a tela durante as execuções de teste)
• Alta rotatividade de desenvolvedores e testadores (exemplo: JavaScript legado de engenharia reversa capturando a tela durante as execuções de teste com a ferramenta de desenvolvedor aberta)
• Identificando violações de convenções de nomenclatura padrão por meio de testes de regressão XPath (exemplo: pesquisando em todos os nós de atributo DOM por nomes de camelo)
• Reconhecendo as falhas de segurança que apenas um computador pode descobrir (exemplo: sair de uma guia enquanto envia um formulário simultaneamente na outra)

Gostaria de compartilhar a experiência de nossa equipe. Temos usado nossa própria ferramenta de teste de interface do usuário, o Screenster, para testar os aplicativos da Web de nossos clientes e de nossos clientes. Ele provou ser uma alternativa útil ao Selenium para tarefas de teste visual / CSS. O Screenster é uma ferramenta de automação de teste que realiza uma comparação baseada em captura de tela de diferentes versões das suas páginas da web. Primeiro, ele cria uma linha de base visual para uma página, fazendo uma captura de tela para cada ação do usuário. Durante a próxima execução, ele faz uma nova captura de tela em cada etapa, a compara com a da linha de base e destaca as diferenças.

Resumindo, o Screenster tem as seguintes vantagens: Linha de base visual: capturas de tela para cada etapa do usuário durante a gravação de teste Comparação baseada em captura de tela: O Screenster compara as imagens capturadas durante uma reprodução com as da linha de base e destaca todas as diferenças Os seletores de CSS inteligentes: o testador pode selecionar Elementos CSS nas capturas de tela e executar ações com eles - por exemplo, marque-os como ignorar regiões para excluir outras comparações