Qual estágio do Agile (SCRUM) devemos começar a criar testes de automação?

9

Um pouco da minha experiência - sou testador manual por quase 2 anos em um ambiente Agile usando SCRUM (sprints de uma a duas semanas). Então, eu estou querendo introduzir testes de automação no meu trabalho usando o Selenium WebDriver (com Java).

Minha pergunta é durante quando devo testar a funcionalidade manualmente e quando devo convertê-las para testes de automação?

Tenho lido e adotado abordagens diferentes, como:

Quando um novo sprint estiver sendo iniciado, converta as histórias do usuário em scripts automatizados do sprint anterior, OR;
Converta as histórias de usuário no mesmo sprint.

Qualquer conselho / s seria muito apreciado. Agradeço antecipadamente.

— Jay
fonte

4

Não publique a mesma pergunta em dois sites diferentes de troca de pilhas. Por favor, apague um deles.

— R Sahu

2

Cruz postada em sqa.stackexchange.com/questions/27017/… .

— R Sahu

13

A automação de teste (e todos os outros testes) deve fazer parte da definição de concluído . Isso para criar um produto potencialmente transportável. Você pode enviar se não foi testado?

O teste também deve ser uma abordagem de equipe inteira, portanto a automação de teste não é de responsabilidade do testador. Comece a pensar em testar o mais rápido possível no processo.

A automação de teste é tão importante no Agile porque:

A agilidade organizacional é limitada pela agilidade técnica

Em outras palavras, quando você demora para fazer alterações em seu produto, não importa como você estrutura suas equipes, sua organização ou qual estrutura você adota, você demora para responder às mudanças.

https://less.works/less/technical-excellence/index.html

Se você adiar o teste para outra iteração, estará sempre atrasado. Tornando mais difícil mudar a direção do produto, é mais difícil refatorar e proteger o comportamento externo do produto. Ter qualquer teste manual repetitivo é fundamental para atrasar você, automatize-o!

Muitos testadores dirão que você não deve começar a testar de ponta a ponta até que a interface do produto esteja estabilizada. Não espere, faça bom uso do PageObjects e verifique se os seus testes são sustentáveis e que é responsabilidade do desenvolvedor criá-los e corrigi-los.

— Niels van Reijmersdal
fonte

Eu discordo do primeiro "deveria". A definição de done é algo que a equipe Scrum precisa resolver por si mesma. Se a equipe considerar importante o teste automatizado, ele será incluído como parte de sua definição. No entanto, o processo em si não diz que eles devem, ou mesmo que deveriam. É algo que depende inteiramente da equipe, e não há resposta certa, errada ou preferida.

— Aroth

@aroth Concordo com você, mas em quase todos os casos você cria um produto de software maior e deseja adicionar testes ao DoD. Por isso, acho bom dizer às pessoas que você deveria, pelo menos pensar seriamente. Como testador, acredito que testar no final por uma equipe separada é o primeiro passo para Wagile. Mas sim, existem situações e / ou casos em que o teste pode nem ser necessário.

— Niels van Reijmersdal

2

O principal é que você não marque uma história completa, a menos que tenha escrito testes automatizados para essa história.

Então, 1 parece estar fora, pois você está escrevendo testes para uma tarefa concluída em um sprint anterior. e se os testes falharem?

— Ewan
fonte

Portanto, se na semana um de um novo sprint, nenhuma história de usuário desse sprint estiver em um estado em que possa ser testada por regressão, você sugere que o OP deve voltar para casa e não fazer nada? Não soa muito eficiente para mim ;-)

— Doc Brown

O testador deve usar essa primeira semana para questionar a especificação "hmmmm como usuário, eu esperaria ter música de fundo na minha página da web ..." encontrar bugs em histórias incompletas e geralmente causar problemas. Devs estão autorizados a dizer que não posso começar a planos de teste até aos são escritos

— Ewan

@DocBrown: na primeira semana de um novo sprint, o testador tem uma quantidade incrível de trabalho a fazer. Eles precisam entender o que os desenvolvedores estão construindo trabalhando com o proprietário do produto e os desenvolvedores. Eles precisam trabalhar com o desenvolvedor para garantir que eles testem o código. Eles podem começar a trabalhar em um plano de teste automatizado. Eles podem até começar a escrever alguns testes. Se você possui uma estrutura de teste adequada, na qual seus testes são gravados com um alto nível de abstração, é possível escrevê-los antes que o código esteja pronto.

— Bryan Oakley

1

Idealmente, você deve escrever testes automatizados no mesmo sprint em que o código foi escrito. O código não deve ser considerado "concluído" até que os testes automatizados tenham sido gravados e você deve obter o código no estado "concluído" ao final de um sprint.

Você deve iniciar o processo no primeiro dia do sprint trabalhando com o desenvolvedor para entender o código e ajudá-lo a entender suas necessidades como testador. Por exemplo, se você estiver criando páginas da Web, poderá ajudá-las a entender a necessidade de adicionar identificadores exclusivos para cada elemento da página com o qual você precisa interagir.

Lembre-se de que, no scrum, seu trabalho não é escrever testes. Seu trabalho é trabalhar com a equipe para concluir os objetivos do sprint. Isso significa comunicação e colaboração, o que deve acontecer muito cedo no sprint. Você pode começar a trabalhar em projetos e planos de teste bem antes que o código esteja pronto para ser testado.

— Bryan Oakley
fonte

0

Se você for testar automaticamente, também poderá criar os testes antecipadamente. Isso o ajudará a definir qual comportamento você espera e o estimula a pensar como um cliente, tornando seu software mais utilizável no final. E você se beneficiará do teste imediatamente ao implementar a funcionalidade.

— Martin Maat
fonte

11

Isso não funciona com ferramentas de teste de interface do usuário como o Selenium. Você precisa de uma interface de trabalho e estável para poder criar os testes.

— Doc Brown

@ DocBrown: Eu não acho que isso seja necessariamente verdade. Se você me fornecer uma especificação para uma nova página da web, eu posso começar (e talvez terminar!) Escrevendo testes automatizados antes que a página seja escrita. Você só precisa colaborar com o desenvolvedor para concordar com o que é a estrutura da página, quais são os IDs do elemento e assim por diante.

— Bryan Oakley

0

Você pode fazer qualquer um deles, mas normalmente deseja direcionar o teste de regressão com testes de automação. Isso significaria que eu faria o manual até ter certeza de que é sólido o suficiente para ser um teste de regressão. Pode estar no meio de um sprint para algumas funcionalidades e pode estar em um sprint futuro para outras funcionalidades.

— vira-lata
fonte

0

Como foi afirmado em outra resposta , quando o teste ocorre, isso deve fazer parte da definição de concluído . No entanto, eu discordo de algumas dessas respostas, então queria expandir com as experiências que encontrei.

Em um ambiente verdadeiramente ágil, todos são capazes de fazer tudo. Não haveria alguém 100% dedicado ao teste, você também desenvolveria habilidades para ajudar com algum trabalho básico da interface do usuário ou algo mais. No entanto, raramente vivemos em um mundo ideal.

O que eu recomendaria seria fazer uma abordagem híbrida. Para sua Definição de Concluído, eu diria que o teste manual deve fazer parte do Sprint no qual o trabalho está codificado. Você sabe que ele funciona e qualquer bug pode ser relatado imediatamente, possivelmente corrigido, antes que o Sprint termine, para que você possa planejar o próximo 1. Ao se concentrar nos testes manuais, você se familiariza com o que o código deve fazer. No início do próximo Sprint, quando você pode não ter muito o que fazer, é possível configurar seus testes automatizados que podem ser executados como parte do processo de construção para evitar erros de regressão.

— Krillgar
fonte

Eu nunca vi um sprint em que ainda não havia muito o que fazer nos atuais objetivos do sprint no primeiro dia. Escrever testes automatizados requer colaboração e planejamento, e isso deve começar na primeira hora do primeiro dia do sprint.

— Bryan Oakley