Como saber quais casos de testes executar em um sprint ?

A maior preocupação da empresa que trabalho é a seguinte. Tenho 1000 mil cados de testes, quando eu estiver em um sprint como saber quais casos de testes executar ? Existe uma maneira de rastrear ?
Pois, a maioria dos erros que acontecem, é os programadores trabalhar em uma parte do sistema e uma outra parte nada haver com que eles trabalharam atrapalhar alguma coisa. Teria uma forma de saber quais testes executar sem roda todos os 1000 mil casos de testes ?

Olá @Marcos-VIctor !

Não sei qual a complexidade do seu sistema, nem o tamanho de sua equipe, mas realmente 1000 casos de testes por Sprint deve ser complicado de manter. Acredito que o ideal seja você trabalhar outros aspectos além de “filtrar quais cenários executar”.

Vou colocar abaixo algumas coisas que já fiz, e que espero que lhe ajude no seu contexto:

  • Se houver novas funcionalidades, iniciar pelo testes relacionados à nova funcionalidade.
  • Na planning, mapear o que realmente vai ser impactado pelas alterações e se possível, focar somente no que vai ser impactado (regressão).
  • Com estimativa, tu encaixa na Sprint os cenários mapeados acima de acordo com a capacidade do time para este tipo de atividade.

Outras dicas, que podem te ajudar:

  • Organize teus cenários de testes em níveis de relevância para o negócio. Durante a execução, iniciei pelos cenários de maior relevância.
  • Se possível, tente automatizar os fluxos mais utilizados/mais importantes no sistema. Seria interessante dedicar um tempo da tua sprint para automatizar alguns testes. Isso vai te ajudar nos testes de regressão.
  • Incentive/apoie o time de desenvolvimento com técnicas de testes/integração contínua. No processo de entrega, se eles estão alterando algo e outra coisa nada a ver quebra, pode existir alguma dependência que não deveria e etc. Antes de entregar para testes, se eles puderem validar isto com testes unitários e acompanhamento via integração contínua, vai facilitar/agilizar o trabalho.

Se eu lembrar de mais algum item coloco aqui. Espero que ajude, abraço

– Samuel

@samuellucas, obrigado pelas dicas, era mais ou menos que eu esperava mesmos. As dicas foram de grande ajuda.
Curiosidade para se tiver mais algumas dicas rsrsrs: O sistema que trabalhamos é para Gestão de Fundações, é um sistema muito grande. O sistema está desenvolvido em Asp.NET e C#. A equipe de desenvolvimento é composto por 3 programadores e 1 tester.

Realmente meu amigo… é a melhor estratégia é a ‘divide and conquer’ a automatizar o máximo possível :)

1000 casos??
alt text

Já teve, em algum momento nessa vida a revisão do que tem?
Sobre a sprint, como já foi dito, cuide do que é novo e cuide do que o novo pode impactar…

Já passou da hora de automatizar isso, né? Começa pelas histórias do sprint corrente, depois vai automatizando as funcionalidades mais importantes. Senta com o PO e vê com ele quais são as funcionalidades mais importantes, dentre as que não estão automatizadas.

Então, ano passado eu e um programador começamos com a pesquisa sobre automação de teste e vimos que conseguiríamos aplicar a automação de testes com SpeckFlow, mas a empresa não quis implementar neste momento por duvida de como rastrear os testes que já existirem depois de um tempo.

Esquece BDD por agora, vcs não tem nada de automação ainda, BDD vai trazer uma “documentação”, mas se ninguém usar não vale nada, só vai adicionar complexidade pra criar e manter testes. Vale mais criar testes bem feitos, que sejam fáceis de entender e manter. Usa um Selenium WebDriver ou WatiN pra C#, automatiza esses testes o quanto antes, não dá pra ficar sem regressão nenhuma de uma aplicação que tem 1000 casos de teste.

Log in to reply

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