Métricas de Teste de Software e Casos de Testes em Ambientes Ágeis

Bom dia pessoal,

Tenho uma dúvida sobre quais métricas de teste vocês utilizam no dia a dia, e qual o processo para documentar/criar cenários de teste que vocês utilizam, pois estes foram processos que mudaram bastante desde a mudança do cascata para o ágil.
Trabalho atualmente em um projeto ágil em que utilizamos o Rally para track das user stories, e baseamos os cenários de teste nos critérios de aceitação. Ainda temos um framework de automação (Selenium + Java), mas não tiramos nenhuma métrica ainda.

Obrigada!
Clarissa

No contexto que trabalho atualmente a grande pergunta é:

Eu preciso tirar uma métrica do que estou fazendo?

Se rola sim, tento ver com o time para analisar a qualidade da entrega.
Senão, nem me esquento em ver isso. Só mudo algo se o PO ou SC vem me pedir. Mas ainda sim questiono o motivo para fazer tal coisa.

Seguindo numa linha parecida do @Ramses-Saccol-de-Almeida … sabendo que métricas são úteis somente quando necessárias, vem as perguntas: onde tá doendo o sapato ? Exemplos abaixo:

  • o time não tá entregando a tempo do PO/QA aceitar a story ? Mede o tempo entre os estados lá do Rally e tenta diminuir esse tempo

  • os testes de aceitação estão deixando passar muitos bugs ainda ? Traz eles pra antes, faz reunião de review com os envolvidos, e dae sim mede os bugs decorrentes daquela feature

  • os testes de Selenium+Java são impactados pelas novas features ? Será que deviam… Qual a taxa de execução deles ?

  • qual a taxa de execução e de erros dos testes unitários dos Devs (to sendo otimista e assumindo q eles existem) ? Se agrupar por categorias, muda algo ?

@Clarissa-Rodrigues105 se você está iniciando em uma cultura de testes automatizados no seu projeto, eu aconselharia você a medir o volume de bugs encontrados hoje em comparação com o que será encontrado após a aplicação dos testes automatizados (em ambiente de Produção). Em alguns projetos isso pode ser relativo, dependendo da complexidade da estória e outros fatores, mas eu acho interessante ter esse tipo de métrica para mostrar o ganho que a automação tem para o projeto/time e defender essa cultura para o cliente e outros times. O QA consegue ter essa percepção, mas as vezes é complicado disseminar isso sem ter dados concretos. É claro que não são só os testes, critérios de aceitação bem definidos nas estórias, reviews com o cliente com mais frequência, code-reviews, entregas menores e contínuas, todas essas ações vão contribuir para a entrega de software com qualidade.
Abraços.

@Rafael-Cardoso disse em Métricas de Teste de Software e Casos de Testes em Ambientes Ágeis:

se você está iniciando em uma cultura de testes automatizados no seu projeto, eu aconselharia você a medir o volume de bugs encontrados hoje em comparação com o que será encontrado após a aplicação dos testes automatizados (em ambiente de Produção).

Isso é uma boa, mas é bom alinhar as expectativas com os gerentes: testes automatizados não trazem retorno imediato!

Entrei em uma empresa há dois meses para automatizar testes e apesar de ter feito algumas coisas já, posso dizer que a automação dos testes ainda não contribuiu para a redução dos erros em produção, já que não foi pego nenhum erro ainda com os testes automatizados. Com o tempo espero que os testes automáticos contribua para que alguns testes repetitivos e demorados não precisem ser feitos manualmente e assim aumentar a eficiência dos testes manuais, e isso sim poderá diminuir os erros em produção.

@Bruno-Fernandes Concordo, não trazem retorno imediato e isso tem que ficar claro para todos os envolvidos. Mas no contexto dos projetos que trabalho hoje posso dizer que foi mais rápido do que eu esperava. Houve ganho não só na produtividade, com relação aos testes repetitivos e demorados (como você disse), já que não são mais testados manualmente, como também no volume de bugs identificados em Produção e no ambiente anterior ao de Produção. Isso atrelado a outras práticas ágeis tem melhorado muito o nosso trabalho e é visível pra mim como QA e para o time, mas em algum momento fomos questionados sobre o quão benéfico estava sendo para o produto, qual o ganho que tivemos com essas práticas? Acho interessante poder mensurar isso, se a forma como as coisas estão sendo feitas geraram resultados expressivos e poder replicar para outros times.

@Rafael-Cardoso se for pra mensurar o ganho com automação, não se esqueça de métricas qualitativas (redução do stress da equipe, mais tranquilidade nos deploys) numa escala likert (concordo totalmente ate descordo totalmente)

Bom, aqui na empresa começamos implementando os testes automatizados (utilizando Selenium) nas principais telas do nosso sistema, chamadas de “Estrelas”, pois são o core do nosso produto, se uma dessas telas pararem de funcionar totalmente, ferrou.

Nós fazemos relatório de indicadores mensais da quantidade de bugs em produção, e estamos observando que a maioria dos bugs não estão acontecendo mais nas Estrelas.

Criamos uma métrica para identificar qual a porcentagem do sistema está coberta por testes automatizados. Para isso, eu tenho uma classe Pai (para os Pages Objects) com métodos auxiliares onde, todas minhas ações de navegação passam em um método específico dessa minha classe.
Dessa forma eu criei um método que ao executar os testes, eu pego o título da página e no final da execução da minha suite, eu sei por quantas páginas eu naveguei.
Sabendo isso e a quantidade de páginas que eu tenho na nossa aplicação (que é gigantesca) eu sei a porcentagem de telas que eu passo na execução dos testes automatizados.

Não sei se essa é a melhor métrica, mas como não tínhamos nenhum cálculo da cobertura dos testes automatizados, essa foi o inicio e vamos aprimorando aos poucos

@Ramses-Saccol-de-Almeida @Gabriel-Oliveira @Rafael-Cardoso @Bruno-Fernandes @cassio Estou em um time que está fazendo uma aplicação nova, então no meu caso acho que uma boa métrica seria bugs encontrados pela automação durante o desenvolvimento, e não necessariamente diminuição deles, pois a idéia é reduzir o trabalho repetitivo e auxiliar validando o “happy path” com antecedência, liberando espaço para outras iniciativas (melhorias automação e processos).

A idéia é demonstrar o valor da automação para o time em si e gerentes, pois sim, demanda tempo ter uma suite atualizada e rodando, a manutenção é alta, visto que outro time cuida de alguns componentes genéricos de tela. Vocês conhecem algum framework para estas métricas de automação?

Sobre casos de teste, quando uma user story é validada, vocês seguem os critérios de aceite dela ou criam algum caso de teste/algo assim?

@Clarissa-Rodrigues105 cuidado com alguns termos usados de maneira meio “livre” demais… automação não encontra bugs. Automação previne que o bug volte. A propósito, deixo como provocação o fato de que testes de regressão também não encontram bugs.

Quem encontra bugs é o Testador no decorrer do seu trabalho (fazendo script de automação, explorando a aplicação e confrontando com o documento de requisitos, conversando com pessoas e comparando suas premissas com o de outras pessoas, etc).

Portanto, métricas de bugs encontrados eu não acho legal. Métricas de bugs resolvidos vs encontrados (não necessariamente filtrado para ser somente da origem de “automação”) talvez fosse boa sim. Métricas de tempo de resolução de bugs talvez fosse boas também (teoricamente, o fato de haver automação de testes deve ter melhorado esse tempo).

@Clarissa-Rodrigues105 disse em Métricas de Teste de Software e Casos de Testes em Ambientes Ágeis:

… Estou em um time que está fazendo uma aplicação nova, então no meu caso acho que uma boa métrica seria bugs encontrados pela automação durante o desenvolvimento…
A idéia é demonstrar o valor da automação para o time em si e gerentes, pois sim, demanda tempo ter uma suite atualizada e rodando, a manutenção é alta, visto que outro time cuida de alguns componentes genéricos de tela.

Por que? Parece ser um bom argumento, mas “força” mais ela…Isso realmente vai ser bom?

@Clarissa-Rodrigues105 Bom, neste caso, acho que utilizar uma ferramenta de bug tracking para gerenciar seus bugs te ajudaria. Sei que com o JIRA, você consegue gerar métricas, puxar relatórios, etc. Por outro lado, eu particularmente não gosto da idéia de registrar bugs nessas ferramentas quando se trabalha com Ágil (eu não utilizo), acho que se perde um tempo precioso. Mas, vai das necessidades de cada time.
Com relação a documentação de teste, como trabalhamos com BDD, utilizando o Cucumber, nossos cenários de teste ficam dentro do próprio projeto, mas me baseio nos critérios de aceite do cliente para escrevê-los.

Vender automação com metrica para gerente … me sinto em 2005… hahahhahaha

Hoje meus PO’s e gerentes querem automatizar tudo para ter certeza que nada vai quebrar a cada virgula que se altera…

Não sei se conseguiria trampar em um lugar que eu preciso falar provar que uma das task do meu trampo como qa engineer é importante…

Log in to reply

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