Selênio e membros não técnicos da equipe

Trabalho em uma equipe que desenvolve um site com um grande número de páginas. Atualmente, o responsável pelo controle de qualidade da equipe executa todos os testes manualmente. Estou pensando em fazê-lo criar um monte de scripts do Selenium. Eu não acho que ele pode automatizar todos os testes, mas ele pode automatizar muitos deles.

Como ele não tem experiência em programação, quão difícil será para ele criar e gerenciar um lote de scripts do Selenium? Em quais problemas ele precisará de ajuda?

Eu acho que o Selenium como uma ferramenta autônoma de "registro e reprodução" é ideal para usuários não técnicos. O idioma de gravar o meu caminho e depois reproduzi-lo é intuitivo, e a interface, embora obviamente voltada para não-novatos, não é muito intimidadora.

O Selenium 2 / Selenium RC é obviamente uma ordem de complexidade mais alta, e acho que você não pode pedir a um não programador que faça interface com isso. (Fiquei frustrado com a falta de interface completa para linguagens não Java, na verdade. Eu sei que a versão atual é transitória, mas eu realmente poderia usar uma solução PHP completa agora, não em uma versão mítica do futuro. Mas isso não é o que você está perguntando.)

Acho que se o seu testador ainda não conhece o Selenium, ele vai te beijar na boca por lhe contar sobre isso.

O Selenium-IDE foi desenvolvido para ser usado por não programadores. Mas minha experiência é que os scripts produzidos dessa maneira (usando XPath gerado) são muito frágeis.

Portanto, criar neles não deve ser problema. O gerenciamento não será tão ruim se seu aplicativo for razoavelmente estável. Ou quase impossível se o seu aplicativo estiver em desenvolvimento e / ou mudando com frequência.

Selenium-RC é puramente uma ferramenta de desenvolvedor.

Eu recomendo fortemente que você faça essa pergunta no site beta do Software Quality Assurance & Testing , ou procure perguntas semelhantes que já foram feitas lá. Você encontrará uma experiência muito maior com o uso do Selenium para o controle de qualidade de gravação e reprodução.

A resposta de Eric é a experiência da maioria dos engenheiros de controle de qualidade que usaram ferramentas de gravação e reprodução: Os testes resultantes foram frágeis e difíceis de manter. Um desenvolvedor pode usar o Page Objects com o Selenium RC para criar um conjunto de testes de interface do usuário muito mais sustentável e é uma opção melhor quando disponível.

Isso não quer dizer que o Selenium IDE não será útil para o seu testador; no entanto, a utilidade (e o potencial de prejudicar os esforços de teste em vez de ajudar) depende muito de quão fixa é a interface do usuário. Você obterá seus melhores resultados com gravação e reprodução se a interface do usuário puder ser congelada no início do ciclo de desenvolvimento. Pode ser necessário ensinar ao testador como obter novos XPaths quando os XPaths antigos estão quebrados e como saber se o teste está falhando devido a uma alteração na interface do usuário (porque o XPath não é mais válido) ou devido a um erro de funcionalidade.

Eu acho que usar o Selenium IDE é melhor do que nenhuma automação para qualquer projeto que tenha alguma interface de usuário geralmente estável. A execução de centenas de testes manuais na interface do usuário estável toda vez que há uma pequena alteração é uma perda de tempo real. Basta definir as expectativas de acordo e perceber que a alteração da interface do usuário terá um impacto significativamente maior no cronograma do controle de qualidade quando você começar a usar a automação de gravação e reprodução para essa interface. Seu testador pode escolher as áreas que ele automatiza com sabedoria.

Não tive problemas em treinar pessoas que não são de programação para escrever testes do Selenium com XPaths relativos em Java / JUnit. O programador o configura e escreve um modelo de teste básico; o testador desenvolve mais testes - gravando e ajustando-os. Se o testador precisar de algo específico, ele pede ao programador que o escreva. O Testador precisa ter um entendimento realmente básico de HTML e XPath, e um pouco de ajuda para escolher a API Selenium (assim como o plugin Selenium para Firefox e Firebug).

O engraçado é que, no começo, eu estava pensando em algo chique como pepino ou algo semelhante, mas essa combinação Selenium / JUnit provou ser boa e simples o suficiente. Curiosamente, os testadores sem experiência anterior em Java não tiveram problemas sérios ao escrever testes JUnit. A única coisa importante é que um programador experiente configura o teste, de modo que o testador basicamente precisa produzir novos testes e chamar os métodos Selenium.

Considere usar uma estrutura de teste orientada por palavras-chave. A idéia é que os desenvolvedores desenvolvam palavras-chave de alto nível (ou você use as que vêm em uma biblioteca) e o testador simplesmente as reúne em casos de teste de alto nível.

As equipes nas quais estive nos últimos anos conseguiram muita vantagem com essa abordagem. Usamos a estrutura do robô, mas existem outras, como pepino (suportado por vários idiomas) e specflow (uma implementação de pepino para .net)

Por exemplo, usando essa abordagem, seu testador pode escrever um teste parecido com este:

| Login with valid credentials
| | Go to page | LoginPage
| | Login as a normal user
| | The current page should be | DashboardPage

Essas palavras-chave podem ser escritas em python (ou java ou uma linguagem .NET), assim:

class LoginPage(PageObject):
    def login_as_a_normal_user(self):
        username = self.browser.find_element_by_id("username")
        username.send_keys(DEFAULT_USER)
        password = self.browser.find_element_by_id("password")
        password.send_keys(DEFAULT_PASSWORD)
        ... and so on...

Existe uma biblioteca pré-fabricada para robô com palavras-chave genéricas baseadas em selênio ("ir para a página", "a página deve conter", "botão de clique" etc.) com as quais o testador pode se tornar produtivo imediatamente.

Muitas vezes, essas palavras-chave genéricas são suficientes, mas usar o conceito de objetos de página e palavras-chave específicas da página é uma maneira poderosa de escrever testes. Seus desenvolvedores podem criar uma classe para cada página do seu aplicativo e, para cada página, podem escrever palavras-chave de finalidade especial, para que o testador possa se concentrar mais na função lógica da página do que na implementação física.

Aqui estão algumas postagens que escrevi que abordam mais detalhadamente o uso de objetos de página com a estrutura do robô:

• Objetos de página da estrutura do robô
• Usando mixins com objetos de página

Experiência real de membros não técnicos da equipe que escrevem o código Selenium: não correu bem

Na verdade, tivemos essa mesma situação em que tínhamos um membro não técnico da equipe (nesse caso, um SQA sem experiência em programação). Infelizmente, isso não correu muito bem.

Grave e reproduza testes não mantidos criados

Primeiro, nossa equipe tentou as ferramentas de gravação e reprodução, mas, como já foi dito, os testes gerados são muito frágeis e difíceis de manter. Nosso SQA acabou caindo em um padrão de apenas gravar novamente um teste toda vez que ele era alterado, o que não era realmente tão eficiente, especialmente quando uma alteração era interrompida na maioria dos testes (tivemos uma alteração na página principal do site que quebrou cerca de 60 % de nossos testes).

Sem a ajuda daqueles com experiência em programação, o código escrito manualmente era horrendo

Nós escrevemos nossos testes Selenium em Java e o SQA nunca havia usado Java antes, então ele estava aprendendo por conta própria. Descobrimos que os testes acabaram usando algumas práticas de programação realmente ruins:

• Usando variáveis ​​estáticas públicas quando realmente deveriam ter sido variáveis ​​de instância privadas
• Ter blocos de código que não fizeram nada
• Muitos Thread.sleep () em vez de usar o WebDriverWait porque ele não conseguiu descobrir como escrever condições personalizadas
• Teste de unidade realmente estranho: eu vi algumas assertTrue(false)linhas para finalizar um teste
• Nomes de variáveis ​​ruins
• Suprimindo exceções que deveriam ter sido tratadas (ou impedidas de ocorrer em primeiro lugar)
• Testes aprovados, independentemente da entrada usada
• Algum código que nunca descobrimos e acabamos reescrevendo

Quando cheguei à equipe, o SQA original havia saído e a execução de qualquer teste resultou em várias exceções de console que nos disseram para ignorar. Depois disso, acabamos envolvendo os desenvolvedores e reescrevendo muito o código para fazê-lo realmente funcionar corretamente e ser sustentável e fácil de entender.

Se você quiser que pessoas não técnicas escrevam o código Selenium, peça a uma pessoa técnica para ajudá-las

Eu acho que alguns desses problemas poderiam ter sido evitados se tivéssemos alguém técnico vindo ajudá-los. Se eles tivessem explicado por que variáveis ​​estáticas públicas deveriam ser variáveis ​​de instância privadas, ou como o JUnit funciona, ou como usar o WebDriverWait, ou por que espalhar Thread.sleep () por todo lugar é ruim, poderíamos ter um código melhor.

Mas, como está, acabamos com um código que, em última análise, é insustentável e, no final, apenas reescrevemos a maior parte dele, resultando em um grande desperdício de tempo e dinheiro.