[Dúvida] Como medir a qualidade de um software

Olá pessoas. Bom dia.

Trabalho em um local o qual realizamos a entrega mensal da versão de um mesmo software, em cada entrega são adicionadas algumas correções, novas funcionalidades e melhorias. Porém, devido a inexperiência do time, tanto no desenvolvimento, quanto dos QA, acabamos construindo um software com uma qualidade menor do que a desejada e, algumas versões que entregamos, parecem estar piores que as outras.

O que gostaria de saber é se alguém trabalha com alguma métrica/medida para medir a qualidade do software que trabalha. Principalmente para saber se uma release que fazemos está melhor do que a anterior e coisas do gênero.

Eu tive uma ideia e gostaria de saber da opinião de vocês. E também ficaria extremamente agradecido se puderem compartilhar como que vocês fazem onde trabalham. :D

Minha ideia é basicamente a seguinte. Dar peso aos Casos de Testes, avaliando 3 aspectos:

  • Probabilidade de acontecer (caso falhe);
  • Impacto (quantidade de usuários que serão afetados);
  • Importância (importância do requisito estar ok).

Cada um desses aspectos será avaliado em uma nota de 0 à 5, fazendo com que cada CDT possua um peso. E digamos que eu tenha todos os requisitos do sistema expresos em forma de CDT, o somatório dos pesos do CDT será a nota máxima do sistema e, cada CDT que não esteja correto, decrementa o seu peso da nota do sistema.

Dessa forma eu terei uma avaliação se uma determinada release está melhor ou pior e assim podendo gerar algumas outras métricas.

O que acham?

Oi @calistro , bom dia!

Uma abordagem que já utilizei é prioridade dos incidentes que surgem no projeto/release. Assim, você consegue acompanhar se release x teve mais bugs críticos, ou nem tanto.

Gostei da abordagem por pesos nos casos de testes. Dependendo, você pode distribuir sua estratégia de execução (automatizada ou não) com base nestes pesos, executando ciclos de testes começando pelos cenários de maior peso e seguindo a ordem de prioridade.

Gostaria de contribuir com alguns questionamentos que tive enquanto lia:
Você citou inexperiência do time Dev e QA. Vale a pena investir um tempo a cada release para o time buscar formas de evoluir tecnicamente - dojos, workshops, code reviews, codificação em par - ou isso é trabalhado de outra forma?

Vocês utilizam alguma técnica de análise de impacto? Cada release, mudança ou afins impacta em todo o sistema? Talvez alguns “problemas” estejam passando por que o time está investindo tempo em funcionalidade e etc que não são tão impactadas ao invés de dar foco - ao menos inicialmente - no que realmente tem risco de mudança, defeito, etc.

Sobre os cenários, vocês mapeiam novos? Fiquei pensando em como estes novos cenários podem ser considerados na métrica, uma vez que o número de cenários vai aumentar.

Parabéns pela iniciativa, espero ter ajudado hehe! Não deixa de compartilhar o resultado com a gente depois ;)

Abraço

@samuellucas

Gostei da abordagem por pesos nos casos de testes. Dependendo, você pode distribuir sua estratégia de execução (automatizada ou não) com base nestes pesos, executando ciclos de testes começando pelos cenários de maior peso e seguindo a ordem de prioridade.

Então, esse foi um dos motivos que eu tive a ideia também. Como a equipe é pequena e está sendo meio inviável testar todos os cenários em cada release, então, dessa forma, teríamos um norte das princiais coisas para se testar. :D

Você citou inexperiência do time Dev e QA. Vale a pena investir um tempo a cada release para o time buscar formas de evoluir tecnicamente - dojos, workshops, code reviews, codificação em par - ou isso é trabalhado de outra forma?

Começamos a fazer code reviews e codificação em pares. Mas o maior problema se dá a quantidade de estagiários sem experiência que temos, tipo, temos 15 estagiários para 1 contratado, daí fica difícil dar a devida atenção :(
Daí estamos fazendo alguns treinamentos e workshops, para tentar melhorar um pouco. xD

Vocês utilizam alguma técnica de análise de impacto? Cada release, mudança ou afins impacta em todo o sistema? Talvez alguns “problemas” estejam passando por que o time está investindo tempo em funcionalidade e etc que não são tão impactadas ao invés de dar foco - ao menos inicialmente - no que realmente tem risco de mudança, defeito, etc.

Uma semana antes de iniciarmos o sprint do próximo release, realizamos uma reunião para definirmos as prioridades e demandas para o próximo release, com isso tentamos fazer uma análise de impacto, mas acabamos falhando um pouco neste aspecto. Vou dar uma lida a respeito. :D

Sobre os cenários, vocês mapeiam novos? Fiquei pensando em como estes novos cenários podem ser considerados na métrica, uma vez que o número de cenários vai aumentar.

Estava pensando em sempre trabalhar com percentual. Desta forma, nesta release temos uma qualidade de 70%, na próxima, indiferente da quantidade de novos cenários e coisas do gênero, temos que manter essa qualidade de 70%, para assim irmos criando metas para melhorarmos a qualidade do software e até mesmo a abrangência dos CDTs. :D

Parabéns pela iniciativa, espero ter ajudado hehe! Não deixa de compartilhar o resultado com a gente depois ;)

Obrigado. ahhahahaha
Pode deixar que vou atualizando a situação aqui. :D

@calistro como o nível de conhecimento dos QAs é muito baixo pois ainda são estags, eu focaria de inicio em um pair testing para elevar rapidamente a régua de conhecimento.
Em seguida priorizaria a automação do que chamamos de caminho crítico. Ou seja, o que realmente não pode falhar ao atualizar uma release.

Disponibilizei uma planilha que podes utilizar para [Priorizar cenários de testes automatizados]. É bem simples e funciona bem.
(https://drive.google.com/open?id=0B7rdXypnAsJwMHp6VC05a0ctbHc)

Essas 2 ações são rápidas e dão resultado a curto/médio prazo.

Apenas lembrando que ao medir a “qualidade” pela quantidade de defeito, você não está medindo a qualidade mas sim a ausência de qualidade. Pra medir a qualidade deve ser considerado também outros fatores.
Espero ter contribuído.

Achei interessante o questionamento, e com isso pensei em algo para medir isso… gostei da resposta do Anderson Tavares. Em complemento a isso, também sugiro outras alternativas, a serem avaliadas por você e seu time:

  • Tente focar na pirâmide de testes e ter o mínimo possível de testes frágeis e/ou que gerem falsos positivos/negativos.
  • Há ferramentas em praticamente todas as linguagens, ferramentas essas que podem ajudá-los a quantificar e medir por exemplo, cobertura de testes no código. Por exemplo, no Ruby, temos algumas que avaliam a cobertura de testes. A partir disso, é possível mensurar pelo menos se o código tem X% de cobertura nos testes unitários. E então começar uma força tarefa para aumentar essa porcentagem.
  • Há também outras para avaliar a complexidade do código. Quanto mais complexo, maior é a chance de bugs surgirem. Bem como atualizações críticas de segurança, etc. Essas ferramentas geram relatórios, e através deles, é possível traçar outras métricas.

Lembrando é claro, que cobertura de testes unitários diminui riscos, mas, não quer dizer que ter um código 100% coberto, nao possua bugs, já que os mesmos podem existir a partir das integrações ou estarem lá, mas, se mal feitos, não ajudam muito.

@anderson-tavares Desculpa a demora. @.@

como o nível de conhecimento dos QAs é muito baixo pois ainda são estags, eu focaria de inicio em um pair testing para elevar rapidamente a régua de conhecimento.
Em seguida priorizaria a automação do que chamamos de caminho crítico. Ou seja, o que realmente não pode falhar ao atualizar uma release.

Gostei bastante da ideia em testes em pares, eu já tinha pensado isso mas não tinha achado uma maneira efetiva de se fazer (principalmente por causa das diferenças de horários). Mas achei algo que talvez funcione. Pensei em implementar um ‘test review’. Quando a equipe receber uma demanda, o tester irá planejar todo os testes (através de CDT) e vai passar para outro tester (de outra equipe) validar os cenários e pensar em outros. Acho que pode ser uma boa alternativa para os testes em pares.

Disponibilizei uma planilha que podes utilizar para [Priorizar cenários de testes automatizados]. É bem simples e funciona bem.
(https://drive.google.com/open?id=0B7rdXypnAsJwMHp6VC05a0ctbHc)

Achei interessante a planilha. Era algo assim que eu estava pensando em classificar os Casos de Teste, já será útil para o automatizado também. Obrigado :D

Apenas lembrando que ao medir a “qualidade” pela quantidade de defeito, você não está medindo a qualidade mas sim a ausência de qualidade. Pra medir a qualidade deve ser considerado também outros fatores.
Espero ter contribuído.

Concordo plenamente. ahahahahha
Qualidade envolve diversos aspectos, Requisitos Funcionais, Não Funcionais, Usabilidade, Feedback do usuário… E diversos outros fatores. Só não sabia como expor minha dúvida. xD

Obrigado, com certeza contribuiu sim. :D

@marcelo-toledo Estamos começando agora a implementar algumas ferramentas dessas, como por exemplo, o Sonar (avaliar a complexidade e ‘qualidade’ do código) e começamos agora a fazer testes unitários descentes. Então, ainda estamos com uma cobertura bem baixa. @.@
Mas estamos trabalhando para melhorar isso. :D

Obrigado pelas dicas. :D

Log in to reply

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