Métricas mensurar o ganho (ou não) com a utilização de testes

[Fabrício Cabral]

Olá todos!

Suponha que você tenha desenvolvido um software que não há testes automatizados. Você deseja então incluir estes testes, mas gostaria de mensurar o ganho (ou não) que obteve com a adoção desta prática.

Pergunto: quais são as métricas mais importantes/utilizadas para se mensurar o ganho com a utilização desta prática? Indicam alguma literatura sobre este assunto?

Agradeço qualquer ajuda!

At.te.

--

--fx

[Leonardo Alexandre Ferreira Leite]

Nunca li nada sobre isso, mas deve ser algo difícil pacas.

Com testes e um bom design (que os testes ajudaram a conceber também) o principal ganho deve ser manutenibilidade. Vc conseguirá corrigir defeitos e implementar novas funcionalidades sem muita dor.

Você pode até mensurar o tempo de desenvolvimento de novas funcionalidades, mas irá comparar com o que? A comparação ideal seria com o tempo de desenvolvimento de funcionalidades do mesmo sistema sem a existência dos testes. Mas mesmo que isso seja possível em alguns cenários, ainda é trick, pois no cenário sem teste alguém pode até dizer que já implementou uma funcionalidade, mas com muitos problemas, seja defeitos ou com um design que compromete a manutenibilidade.

Outro caminho seria medir defeitos encontrados em produção. Para um mesmo sistema, esperasse que após a adoção de testes automatizados, haja uma diminuição na quantidade de defeitos introduzidos a cada nova versão. Mas fazer comparações com essa métrica também não deve ser fácil.

Minha opinião =)

[]s,

Leonardo Leite

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-real+unsubscribe@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Rafael Ponte]

Fabrício,

Acho que já tivemos essa discussão no grupo ano passado. Tenta da uma pesquisada para ver se encontra a thread, lá deve ter respostas e referências interessantes. Já seria uma bom ponto de partida!

Um abraço,

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

[Maurício Aniche]

Oi Fabrício,

Medir ganho é sempre desafiador. Afinal, vc precisa começar por definir o que é "ganho". Defeitos a menos? Menos tempo na manutenção? 

E também depende do quão longe você quer ir nesse estudo: vc quer realmente extrair dados e aplicar um pouquinho de estatística? Ou quer apenas ouvir o que os seus colegas acham 3 meses depois de ter testes?

Se vc estiver interessado em fazer algo mais a fundo, podemos pensar em algo juntos. Não é sempre que conseguimos dados de empresas! Me mande e-mail em particular. :)

Um abraço,

--

Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Maurício Aniche

Assistant Professor

Delft University of Technology

www.mauricioaniche.com

@mauricioaniche

[Gustavo Cruz]

Fabrício e Aniche

Tenho interesse nesse tipo de "desafio" também. 

Atualmente estou em um projeto de grande porte, onde a linha de desenvolvimento não contempla testes de qualquer tipo. Tenho tentado vender essa cultura entre os membros do time, mas tenho encontrado muita resistência como: "é chato testar", "gastamos muito tempo montando testes", "não sabemos direito montar os testes", enfim, vários questionamentos.

Se eu puder em um curto prazo de tempo mostrar que fazer os testes pode trazer benefícios, talvez a história mude.

Vamos conversar?

2018-02-16 6:01 GMT-02:00 Maurício Aniche <maurici...@gmail.com>:

Oi Fabrício,

Medir ganho é sempre desafiador. Afinal, vc precisa começar por definir o que é "ganho". Defeitos a menos? Menos tempo na manutenção? 

E também depende do quão longe você quer ir nesse estudo: vc quer realmente extrair dados e aplicar um pouquinho de estatística? Ou quer apenas ouvir o que os seus colegas acham 3 meses depois de ter testes?

Se vc estiver interessado em fazer algo mais a fundo, podemos pensar em algo juntos. Não é sempre que conseguimos dados de empresas! Me mande e-mail em particular. :)

Um abraço,

On Tue, Feb 13, 2018 at 3:19 PM Fabrício Cabral <fabri...@gmail.com> wrote:

Olá todos!

Suponha que você tenha desenvolvido um software que não há testes automatizados. Você deseja então incluir estes testes, mas gostaria de mensurar o ganho (ou não) que obteve com a adoção desta prática.

Pergunto: quais são as métricas mais importantes/utilizadas para se mensurar o ganho com a utilização desta prática? Indicam alguma literatura sobre este assunto?

Agradeço qualquer ajuda!

At.te.

--

--fx

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-real+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Maurício Aniche

Assistant Professor

Delft University of Technology

www.mauricioaniche.com

@mauricioaniche

--

Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-real+unsubscribe@googlegroups.com.

[Thiago]

Bom dia pessoal!

Também estou interessado no assunto. Talvez minha experiência ajude pois estou "do outro lado" da maioria.

Onde trabalho hoje temos uma cultura muito pesada em testes (ATDD e TDD) e eu particularmente (não falo em nome da minha empresa) desconfio fortemente que a balança custo x benefício esteja bem desequilibrada. Já começamos um trabalho de extrair quanto tempo utilizamos em testes de aceitação (utilizamos o concordion) para subsidiar futuras decisões.

Mas o desafio é excelente. O que é ganho? Porque nessa equação eu penso em fatores que não podem ser quantificados. Por exemplo, satisfação dos desenvolvedores durante o seu trabalho.

Enfim. Como posso ajudar?

Thiago Almeida

[Gustavo Cruz]

@Thiago,

Poderia nos contar no quesito satisfação dos desenvolvedores como fica a situação? O pessoal gosta de fazer testes? Acham chato? Massivo? Benéfico?

[Thiago]

A maioria acha chato e massivo. Principalmente a montagem da massa de dados. E a sensação de tempo utilizado para desenvolver os testes é muito grande. Por isso que acho que tenho que levar isso em conta. Porque os desenvolvedores "carregando" isso tem um efeito negativo não quantificável, mas que existe.

E o benefício é extremamente difícil de ser quantificado. Não é atoa que criaram essa thread aqui no grupo. hehehe.

O ATDD hoje pra nós funciona como teste de regressão (numa visão bem resumida). E meio caro de manter na minha opinião. A quantidade de bugs que passam/deixam de passar para a produção que é difícil demais de medir. Foi por causa desses testes específicos que tivemos poucos bugs? E os bugs que continuam aparecendo?

Uma coisa que sempre temos que manter em mente é que podemos melhorar o próprio desenvolvimento de testes. Acredito que o Aniche já comentou isso bastante em seus livros. Tomar o mesmo cuidado que temos com o código de produção com o código de teste. Hoje utilizamos concordion + spring + bdsetup para implementar o ATDD. E algum nível de arquitetura em cima disso. Podem ter caminhos melhores também.

Não estou falando aqui sobre testes unitários. Esses nós estamos mais confortáveis em fazer.

Thiago Almeida

[Jeremias Queiroga]

Começa por amostragem...

Pega um pequeno módulo, de preferência que já tenha um tempo ou esforço de desenvolvimento similiar já realizado, e aplica um processo de testes automáticas que definir.

Depois levantar os "ganhos", tempo, quantidade de bugs identificados, classificação dos bugs encontrados, quantidade de pessoas envolvidas, transforma isso em valore... Ao mostrar as CIFRAS.. a visibilidade é maior.

------------------------------------------------------------
Jeremias Queiroga