Dúvida sobre o processo de teste automatizado ágil

Boa tarde a todos, é o meu primeiro post no fórum e gostaria de utilizar do espaço para tirar uma dúvida que talvez seja também a dúvida de outros.

Trabalho com testes, em ambiente ágil, com SCRUM, há um ano e meio, primeiro como bolsista, e agora depois de graduado, como PJ. O tempo todo na mesma organização.

Entretanto, o lugar onde trabalho hoje, lida com o processo de testes de modo manual, salvo raríssimas exceções, e tendo participado da Agile Testers BH desse ano, e estando estudando a área de testes, entendo que essa não é a melhor maneira, e lido na prática com problemas desse protocolo falho, como esforços repetidos, regressão constante do sistema, etc.

Trabalho em um esquema de time de desenvolvimento, onde somos um analista de qualidade, como chamamos, para diversos desenvolvedores, e existe essa mentalidade de que “desenvolvedor só desenvolve e tester só testa”, então na organização o nosso perfil padrão é o de não ter afinidade nem estímulo para conhecimento técnico em programação, sendo raros os casos dos QA que conhecem um pouco de desenvolvimento, seja backend ou frontend, o que acaba por dificultar a migração para um protocolo de testes automatizados.

Sendo assim nossas atividades ficam restritas a casos de teste, criados antes do desenvolvimento, realização de testes manuais após a conclusão do desenvolvimento das histórias de usuário e a confecção de manuais de usuário para as histórias entregues na sprint.

Dessa maneira, devido aos prazos nas sprints, muitas equipes também deixam de desenvolver código de teste unitário e funcional, ficando toda a responsabilidade dos testes em um protocolo manual e focado somente na interface.

Em meus estudos aprendi sobre a pirâmide de testes, fiz cursos de teste automatizado de front com Selenium, de back com JUnit, Jasmine, teste de carga com Locust e Jmeter, assim como conheci o PostMan, RestClient, e uma infinidade de outras ferramentas, que poderiam ser utilizadas, entretanto o cenário ágil, as atividades que já temos de realizar, e a dificuldade técnica que eu e os demais temos, tem tornado confuso para eu saber onde investir força/tempo para avançar com nosso protocolo rumo a automação, de modo sustentável e consistente para a realidade ágil.

Como não tenho outras pessoas mais experientes para dividir a dúvida, gostaria de dicas, de leitura, ou até experiências pessoais mesmo, de pessoas que também tenham tido essas dificuldades, e como superaram. Quero avançar com o protocolo de teste, mas sei que haverá resistência dos demais, e grandes dificuldades, de modo que não sei como avançar gradualmente na implantação, ou de onde partir.

Analisando a pirâmide de testes, imagino que o ideal seria nós também contribuirmos com os desenvolvedores no nível de testes unitários, ajudando na criação e manutenção, mesmo que não desenvolvamos tudo sozinhos. Assim como com testes de integração e de UI, mas esbarro, realmente, na dificuldade técnica e em não saber que casos automatizar, em quais níveis, em um tempo curto de sprint.

@Bruno-Mazzi acredito que o esforço principal nesse cenário seja no mindset primeiramente dos QAs e posteriormente dos Devs De entrega Para qualidade. Sem isso é quase impossível ter sucesso na tua iniciativa.

O primeiro passo realmente é alterar a mentalidade da equipe para foco na qualidade. Caso você tenha dificuldades nesse processo, tente levantar dados reais de mercado que mostrem como a evolução do processo de garantia de qualidade dentro das organizações é capaz de gerar benefícios reais e significativos. Muitas vezes só mostrando que evoluir o processo de garantia de qualidade do software gera mais lucro é que vai funcionar.

Ola Bruno, ja que a dificuldade eh tecnica e tempo, poderias comecar pelos casos de testes mais simples e ir montando uma suite aos poucos, mostrando a equipe que o seu tempo de manual ira reduzindo ao passar do tempo… Nao sei mais como anda a cultura ai no Brasil, pois estou a quase dois ano fora, porem na epoca que morava no Brasil nao ajudavamos nos unites tests, so faziamos o testes de UI, aqui automatizamos API tambem (Rest ou Soap).

@christiano-guerra automação de testes parece ser o menor dos problemas dele…

Na verdade… é um processo natural após resolver problemas de mindset e equipe… ;)

@Leonardo-Galani, o problema que eu vi é o mindset, mas se ele nem começar a automatiza, este mindset nunca ira mudar… Acho que vc já ouvi falar em modularização, se os desenvolvidos não fazem unit, isso é um problema gerencial e/ou organizational, mas pelo o que ele colocou, testes manuals são realizados

@Bruno Mazzi Faça gradualmente o que está ao seu alcance, cada dia um passo e um dia terá um material vivo para apresentar dos resultados que obteve deste universo que é sua área de atuação e que se relaciona com outras!

@Bruno-Mazzi enquanto os times não tiverem essa mudança cultural você pode fazer algumas ações e “vender” aos seus pares e gestores:

1 - Criar um dashboard com indicadores de qualidade sendo afetados positivamente pelo seu trabalho com automação(mesmo que o resultado seja pequeno. Sem indicador apontando melhora nos resultados não vais conseguir evoluir)
2 - Criar guildas com o objetivo de disseminar a iniciativa entre os demais QA. O resultado de uma guilda é a geração de ações sobre o tema. Logo ao menos 1 pessoa já abraçaria a causa se comprometendo a realizar a ação. Sugiro que a ação siga o modelo 5w2h para controle do que, como e quando fazer.
3 - Divulgar o resultado potencializando os ganhos com redução de custo (trabalho repetitivo que foi eliminado) e garantia da qualidade sobre o requisito.

De inicio começaria por ai. Mas não esqueça que o ponto chave para a evolução com menor custo e maior agilidade e trabalhando no mindset dos profissionais.
Espero ter ajudado.

Se o time não tem esse mindset… o código não será ‘test-friendly’ e a probabilidade de ter que fazer gabiarras para fazer algo simples é enorme.
Ele já não tem experiências de mercado e outros problemas… logo vai ser bem doloroso e a o beneficio de automarizar teste se perde para todos.

@leonardo-galani “Dessa maneira, devido aos prazos nas sprints, muitas equipes também deixam de desenvolver código de teste unitário e funcional, ficando toda a responsabilidade dos testes em um protocolo manual e focado somente na interface.” Posso concluir que tem algo ja feito? assim como posso concluir que pela pouca experiencia que ele tem, ele pode comecar por algo menor e ir ampliando, assim como pode trocar ideias com a equipe de desenvolvimento, para tentar tornar o codigo mais limpo para a equipe de teste, so que no meu ponto de vista, nao adianta ele ficar mostrando que automacao eh bom, se a propria equipe de teste nao quer mudar, passei por isso na ultima empresa, em Angola, tentei mostrar como melhorar de todas as formas possiveis, e o gerente da fabrica ja tinha passado pela area de teste, mas mesmo assim preferia ficar pensando em entrega, mesmo que com o codigo sujo, com ID’s repetido e fazer manual, se nao consegui mudar o mindset da equipe, melhor maneira que achei foi mudar de empresa. Na primeira empresa que trabalhei eu consegui mudar alguns conceito mostrando na pratica, conforme o @Anderson-Tavares colocou, cai dentro e comecei a codificar e mostrar ao PO a diferenca.

Bom, mostrei apenas um lado positivo, e outro negativo, pode ser que nao de certo, vai depender muito da cultura da empresa e da equipe.

Agradeço a todos que dedicaram um tempo nas respostas. Tenho trabalhado o mindset dos outros QA na companhia como um todo sim, desde o início, por ser mais jovem aqui e ter chegado há pouco tempo a gente questiona tudo e quer melhorar as coisas.

Temos nos reunido para discutir esses assuntos comuns e tentado conseguir, até com a empresa mesmo, capacitações, como de teste de carga com o Locust, em Python, que fizemos recentemente e já foi de certo modo uma quebra de paradigma, uma vez que existe essa cultura de que testador virou testador porque não tem talento para programar, etc, o que reforça um pouco o nosso papel no processo como o de validadores de regras de negócio, após o desenvolvimento, sem automatização alguma, e mais focado na interface, design, etc.

Acho que esse problema do mindset ainda leva algum tempo para ser quebrado, mas é gradual, e acredito também que um bom exemplo seria motivador para os demais, mas essa é a grande questão pra mim hoje. Minha equipe desenvolve, na medida do possível, e ultimamente tem conseguido, entregar teste unitário e funcional automatizado, da forma mais básica possível, sem componentização, padrão de projeto, nada. E eu iniciei meus estudos por teste automatizado de frontend, mas hoje entendendo um pouco melhor sobre o processo de teste como um todo já acho que não faria sentido criar mais uma estrutura de teste de interface replicando todos os mesmos casos de testes já garantidos desde o backend, então não sei o que valeria automatizar pela interface, nem consigo ser de grande ajuda na criação/manutenção dos testes dos testes unitários e funcionais/integração no backend, e na correria das sprints nem uma coisa nem outra tem saído num ritmo de progresso que me satisfaça.

Olá @Bruno-Mazzi, segue algumas palavras sobre seu texto. Espero ajudar :)

“processo de testes de modo manual” e "…mentalidade de que “desenvolvedor só desenvolve e tester só testa”…"
Já vivi um pouco disso Brunão, e concordo com os colegas que comentaram acima sobre o “Mindset”. Você precisará mostrar a importância da qualidade para todos (Gerência, Devs e outros QAs). Mostrar que qualidade é algo que deve estar presente durante todo o processo de desenvolvimento e não é não apenas uma fase desse processo. Que todo o time é responsável pela qualidade e não só o QA.

Não tente mudar todos de uma vez. Nem todo mundo está disposto a sair da zona de conforto, logo, nem todos comprarão a ideia de primeira, isso pode trazer falhas que indique [erroneamente] que suas ideias não serão úteis no contexto da empresa.
Ao invés disso, comece pequeno, sugira melhorias dentro de um time, valide essa melhoria. Se der certo, você terá embasamento para mostrar aos demais, a importância daquela melhoria.

Tomar algumas decisões podem ajudar…

Definition of Done:
Criar um “Definition of Done” para cada fase de desenvolvimento (planning, development, test, UAT…) e seguir a risca cada um desses DoDs. Exemplo: Se o time entende que Teste Unitário é importante para entregar com qualidade, TA deve fazer parte do DoD (provavelmente em na fase de development). Então se uma story está em “development”, ela não está pronta para testar até que todos itens do DoD tenham sido executados, inclusive o Test Unitário.

One Piece Flow:
Trabalhar com One Piece Flow, priorizar a entrega de uma story ao invés de abrir uma nova. Isso vai tirar um pouco aquela ideia de “Dev desenvolve, Tester testa”. Se você tester, tem 5 stories para testar e os devs do time continuam abrindo story para desenvolver, coloque os devs do time para ajudar nos testes. Entregar Stories antes de começar stories.

Esses itens podem inclusive, ajudar a expor problemas que estavam mascarados (estimativa incorreta, por exemplo).

Em times ágeis, Dev e Tester estão sempre próximos e em constante comunicação. Adquirir/melhorar skills técnico, ajudará nessa comunicação e facilitando a solução de muitos problemas do time. Quando você perceber os resultados, outros times também vão se interessar pelos resultados obtidos.

Relatórios (como já mencionado em outro comentário), podem ajudar a mostrar quais são os resultados atuais e os bons resultados colhidos a cada ação tomada.

Definitivamente não será fácil, você precisará de força, persistência e paciência. Mas valerá a pena! Dúvidas, estou a disposição.

Grande abraço

Sobre DoD:
http://www.mindmaster.com.br/definition-of-done/
https://www.agilealliance.org/glossary/definition-of-done

Sobre One Piece Flow:
Youtube Video

Ouve esse podcast sobre testes ágeis, tem muita coisa bacana…
https://m.soundcloud.com/testcastbrasil/testcast-05-agile-testing

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.