ESTIMAR OU NÃO ESTIMAR, EIS A QUESTÃO!

Perguntinha capciosa: @Bruno-Fernandes, vc está considerando que testes de regressão são “retrabalho” ?

Se não, concordo plenamente com a @Patrícia-Araújo-Gonçalves e o @Ramses-Saccol-de-Almeida - tens de trabalhar com o time para poder identificar o por quê as tarefas nunca são “fechadas de primeira”, seja qual for o processo que segues

@Gabriel-Oliveira , eu não considerava como retrabalho, considero o reteste como parte integrante dos testes, assim como os testes de programação é parte integrante da programação.
Se um erro é encontrado, a correção deste deverá ser testada, e esta previsão do reteste é o que eu incluía na estimativa, principalmente quando é um processo que é problemático.
Então respondendo a pergunta, não é a regressão que é retrabalho, mas o reteste mesmo.

@Patrícia-Araújo-Gonçalves pensando melhor, não faz sentido estimar retrabalho mesmo… seria o mesmo que um engenheiro estimar o risco do prédio não ficar bom e ter de fazer de novo…

Essa ideia de “estimativas” do PMI, gráfico de Gantt e outras besteiras são completamente furadas quando trabalhamos com Engenharia de Software e outras áreas de knowledge work (trabalho do conhecimento).

Todos nós somos trabalhadores do conhecimento. Engenharia de Software não é análogo à Engenharia Civil, não demoro o dobro do tempo pra desenvolver um software “duas vezes maior”. Não dá pra continuarmos difundindo ideias arcaicas.

É por isso que, no final dos anos 90, começaram a surgir métodos ágeis de desenvolvimento de software. Sim, já se passaram mais de 15 anos e infelizmente ainda tem MUITA gente desenvolvendo software igual na época do Woodstock.

Temos que difundir e estudar ideias inovadoras de gestão e de processos ágeis, quebrar o paradigma do pensamento “comando e controle”. Vamos difundir Management 3.0, Kanban, #NoEstimates, Lean, bora pensar no futuro em vez de discutir coisas que nunca funcionaram.

@Bruno-Fernandes

Acredito que você trabalhe numa fábrica, certo?

Então, se o retrabalho impacta nas atividades de testes, na minha opinião, vocês poderiam começar a pensar em testes que irão prevenir os erros, e não adotar uma abordagem de testes que apenas encontre erros.

Já trabalhei em empresas com esta mesma forma de trabalho, onde o estimado (ou quase isso) era o cobrado do cliente. Neste cenário, como a @Patrícia-Araújo-Gonçalves comentou, entender a causa do retrabalho e aprender com isso é mais importante para não ter os mesmos problemas no futuro.

Opinião pessoal: Visto que trabalhei num ambiente semelhante, não concordo em incluir isso na estimativa, e por consequência no valor repassado ao cliente, porque geralmente estes retrabalhos são causados por problemas internos, entre os times que estão executando o projeto.

@Aniela-Cole , não sei se entendi bem o conceito de “fábrica”, mas acredito que sim. Temos um sistema ERP para gestão de operadora de saúde. Os clientes pedem novas funcionalidades no software, ou fazemos novas implementações com bases Legais, e estas funcionalidades passam pelas fases de estimativa, aprovação, análise de sistema/análise de teste, programação e testes.

O trabalho da equipe de testes mais importante para prevenir erros, que vejo aqui, é a análise de testes, pois ao fazer os casos de teste estamos automaticamente revisando a documentação e conseguimos encontrar alguns problemas.

Entendi o problema de se estimar reteste… este custo não pode ser repassado ao cliente, ao invés devemos melhor o processo para que o reteste seja cada vez menor.

@Bruno-Fernandes Essa questão de retestes é uma “guerra antiga” rs
Eles ficam mascarados no meio do projeto, geralmente não são medidos mas pode ter certeza que se colocarmos na ponta do lápis nos demandam um bom tempo, que se não estimado como faremos nosso planejamento de teste? Termino a Sprint e libero com erros que impactam na funcionalidade?

"Disseram que reteste é retrabalho e que o cliente não pode pagar por algo que foi feito errado."
De certa forma é um retrabalho sim. Geralmente quando retestamos algo temos que voltar para outros pontos já validados para ter certeza que a correção não quebrou nenhum processo que funcionava corretamente, ou seja, está retrabalhando algo já validado.

Não sei te dizer quanto a cobrar ou não, na verdade a parte de cobrança fica mais envolvida com comercial, mas se falando em sprints eu considero sim que devemos olhar com no “carinho” para os retestes. Agora não sei essa questão do percentual se é muito bom, sabemos que estimativa não é um contrato assinado com sangue, é um norte para nos guiar com relação a planejamento, pode haver variação para mais\para menos, mas o que eu geralmente faço é tentar medir isso baseado em histórico e complexidade do teste.

Falando ainda em retestes, principalmente quando temos muito bate-volta de erros simples que poderiam ter sido identificados e corrigidos em teste unitário sabemos que isso demanda tempos sim, tanto do testador quanto do desenvolvedor, não vejo como “ignorar” a existência deles.
Acredito que precisaria achar uma forma de adequá-los a sua realidade.

Espero poder ter clareado alguma coisa :)

@Ramses-Saccol-de-Almeida Respeito sua opinião e como você mesmo disse ninguém é obrigado a concordar com a visão de ninguém e que ótimo que o mundo é assim, imagine só se todos gostassem somente do verde? o que seria do azul? Do amarelo?

Mas enfim, o motivador da escolha desse tema que tanto te desinteressa foi por ser tão abordado em reuniões de área, pós retrospectiva dos projetos, etc.
Sempre há muita polemica em torno desse assunto, me desculpe, desconheço essa polemica existir somente no passado.

Mas uma coisa terei que concordar com você, falou bonito quando disse:

“E o nome já diz…é uma estimativa…Não é uma verdade…
O que me deixa triste é ver gente abraçada isso, como se fosse uma verdade absoluta…”

Sim, o estimativas como o nome mesmo diz não é nada de concreto, são aproximações, previsões.
Quando fui escrever esse post uma das frases que mais me chamou atenção foi essa:

“Estimativas não são um problema de desenvolvimento de software, mas uma ferramenta que a sociedade usa para tomada de decisão, o erro está em acreditar que estimativa é preciso, se fosse preciso não era estimativa, era certeza.”

-1

@Patrícia-Araújo-Gonçalves , @Gabriel-Oliveira me desculpem mas testar algo e não encontrar nenhum defeito chega até ser frustrante, digo, falando particularmente.
Afinal esse é o objetivo do teste, garantir a qualidade e para isso validamos as funcionalidades em busca de defeitos, acredito que isso é “um processo natural”.
Regressão são outros 500, concordo com vocês se estivéssemos falando que a quantidade de defeitos encontrados foi algo fora do normal, nesse caso, sim faz todo o sentido fazermos uma triagem das causas raízes do problema. Do contrário, na minha visão, o retrabalho vai existir sim e não temos como fugir disso, o máximo que podemos é minimizá-los, mesmo porque somos humanos e estamos suscetíveis a erros.

-2

@Bruno-Fernandes disse:

seria o mesmo que um engenheiro estimar o risco do prédio não ficar bom e ter de fazer de novo…

Desculpe, mas não concordo com essa comparação.
Se pensarmos assim qual seria o motivo de existir uma equipe de testadores?
Qual sua função?
E acredite, em software se o requisito não for bem definido e esclarecido com o cliente, sim, independente de ter retrabalho ou retestes, como quiser chamar, o “prédio”(aplicação) pode ser desenhado diferente do que é esperado pelo “morador”(cliente) e sim você precisará realinhar os tijolos para atender a necessidade dele ;) (mas ai já entramos em outra discussão rs)

@afizac você está fazendo um desserviço a comunidade ao repetir a falácia “Afinal esse é o objetivo do teste, garantir a qualidade” e ir mais adiante e dizer “testar algo e não encontrar nenhum defeito chega até ser frustrante”. Você está cegamente reproduzindo o que seus professores e talvez até colegas, que aprenderam a fazer software como se fosse projetar um prédio, e isso eu acho inconcebível para um Tester - assumir verdades sem questioná-las.

Se você chegou até aqui e está se questionando sobre o que estou dizendo, ótimo, você está finalmente começando a entender o que um Tester faz.

O termo QA como “quality assurance” por si só talvez tenha te levado a essa visão. O termo é defasado e o artigo em [1] dá uma excelente explicação do porquê. Eu prefiro o termo “question asker”, como a Sarah Pimentel [2] e outros tantos tem adotado.

Ou talvez a sua confusão tenha vindo da diferença entre Teste e Verificação e Validação, por ter assumido que a definição do ISTQB é a única verdade universal. Saiba que existe um debate crescente na comunidade de testes sobre a diferença entre Test&Checking [3], onde “Checking Is Confirmation” e “Testing Is Exploration and Learning”, por exemplo.

Essas confusões são normais para quem está acostumado com a realidade dentro da Matrix (ISTQB). Num fórum como o Agile Testers, eu me sinto obrigado a lhe convidar a conhecer um mundo de conhecimentos e debates particularmente estranho, a primeira vista.

Neste mundo, reteste é um desperdício, assim como qualquer repetição de tarefa. Como todo desperdício deve ser reduzido ao máximo, surgiu automação e integração contínua, por exemplo. Abrir defeitos (diferença entre a implementação e a intenção do cliente) é um desperdício e geralmente a penalidade por você e a sua equipe não terem sido melhor questionadores.

Neste mundo, você trabalha com pessoas, sejam elas chamadas de Testers, Devs, PMs, Zezinho ou Uguinho. Neste mundo, você é convidada a questionar essas pessoas e se colocar no papel e na pele delas. Neste mundo, você pode se ver livre do seu papel de tester e ser “somente” uma pessoa com características únicas - curiosa, empática, questionadora, crítica, detalhista. Por coincidência, outras pessoas terão características similares as suas, e vocês podem se reunir em grupos de discussões ou comunidades para compartilhar como seu perfil ajuda seu time e cooperar para entender como pode ajudar mais ainda.

Se este mundo que apresentei não te agrada, sem problemas - seu livre arbítrio tem de ser respeitado e sua capacidade questionadora pode decidir se agarrar aos conceitos familiares que aprendestes. A Matrix continua e os software-prédios também. Você é muitíssimo bem vinda a trabalhar da forma que quiser.

Porém, por favor, respeite as pessoas questionadoras e tome mais cuidado com as falácias que espalha. Entenda que o fato de elas serem verdadeiras no seu contexto não tornam elas verdadeiras em todos os outros.

Abraços !

[1] - http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/
[2] - https://medium.com/@sarahpimentel/are-you-a-qa-as-in-question-asker-373c01581a36#.6dcwb7t60
[3] -http://www.developsense.com/blog/2009/08/testing-vs-checking/

-2

@Gabriel-Oliveira Respeito a sua opinião de da mesma forma gostaria que respeitasse a minha :)

Eu prezo pela qualidade e antecipar a problemas, acredito que não preciso dizer que um defeito encontrado em produção sai bem mais caro do que corrigido antes da entrega do projeto (eu não preciso ler isso em nenhum livro ou blog se eu trabalho na área ;) ). Sem falar no stress que pode ser gerado com cliente de acordo com nível de criticidade do negócio.

Quando comentei " me desculpem mas testar algo e não encontrar nenhum defeito chega até ser frustrante, digo, falando particularmente." como a própria frase diz, é um sentimento pessoal meu, não disse em nenhum momento que isso é uma regra e muito menos que não questiono as coisas, muito pelo contrário meu caro. Chego a ser meio chata nesse quesito, mas não me importo se serei taxada como tal desde que tudo esteja esclarecido.

Desculpe por “questioná-lo” mas eu realmente discordo de seu parágrafo:

“Neste mundo, reteste é um desperdício, assim como qualquer repetição de tarefa. Como todo desperdício deve ser reduzido ao máximo, surgiu automação e integração contínua, por exemplo. Abrir defeitos (diferença entre a implementação e a intenção do cliente) é um desperdício e geralmente a penalidade por você e a sua equipe não terem sido melhor questionadores.”

De forma alguma é um desperdício, considerando que se nos testes foram encontrados defeitos e de acordo com a severidade e impacto que podem trazer eles deverão ser corrigidos agora, se não forem agora uma hora ele voltará. E por mais que eu tenha testes automáticos para regressão e rodem em uma integração contínua se a build quebrar por efeito colateral de algum commit o mesmo não deverá ser corrigido e testado? Claro que sim, quem quer arriscar-se a liberar algo que não foi testado e foi garantido que a funcionalidade continua funcionando?

Vejo que precisamos aprender a dosar e ser mais flexíveis com relação aos erros e ponderar o que de fato seria impacto ou não para uma liberação, por exemplo, e decidir se seria corrigido. E posso ter desenvolvedores questionadores e ótimos codificadores e mesmo assim errarem, ou ainda, surgirem situações que não foram previstas na implementação e serem encontradas nos testes (por ter passado batido pela equipe), o que você sugere? Que eu ignore isso? Impossível meu caro, é como dizer feche os olhos para isso, toque o barco mesmo sabendo que tem um furinho nele, se começar a naufragar ai tomamos a ação, sou adepta a pró-atividade, a sempre antecipar os problemas.Pode não parecer mas isso faz a diferença.

Mas concordo com você com relação ao questionar, e vejo que isso falta um pouco nos times.

E é evidente que temos um mix de contextos, é por isso mesmo que criam-se debates aqui e essa “troca de mundos” é que nos interessa a seguir essas publicações e discussões.

Ps: Obrigada pelos termos e links, vou lê-los :)
Desconhecia o “question asker”, por exemplo

@afizac, sobre seus questionamentos:

E posso ter desenvolvedores questionadores e ótimos codificadores e mesmo assim errarem, ou ainda, surgirem situações que não foram previstas na implementação e serem encontradas nos testes (por ter passado batido pela equipe), o que você sugere? Que eu ignore isso?

Erros acontecem e devem ser tratados em retrospectivas e no dia a dia. Mas nem todo erro precisa gerar defeito. Se o cara quebrou o build, botar a foto do cara na parede como o quebrador-de-build e decrementar o contados de “estamos há X dias sem quebrar o build” tem um efeito muito mais útil do que abrir um defeito numa ferramenta esquecida pelo tempo.

De forma alguma é um desperdício, considerando que se nos testes foram encontrados defeitos e de acordo com a severidade e impacto que podem trazer eles deverão ser corrigidos agora, se não forem agora uma hora ele voltará.

Se um defeito for corrigido agora pelo Dev que está ao meu lado e que encontrou o bug comigo, por que raios eu preciso entrar na ferramenta, logar os passos e o resultado e etc e tal ?

Para evidenciar o trabalho que foi feito ? Ora, melhor evidência do que o problema corrigido não tem. Melhor ainda se um teste automatizado começar a ficar verdinho por causa da correção.

Para gerar métricas de desempenho ? Realmente precisamos de defeitos sendo usados dessa forma ? O gerente está tão afastado do time assim para precisar que uma planilha diga pra ele se o time está sendo efetivo ou não ?

Enfim, acho que desvirtuamos pacas o tópico e vou parar por aqui - talvez valha abrir outros para discutir esses questionamentos, se quiseres, ou até um Hangout focado em estimativas/defeitos/etc. Fecho minha participação aqui.

Confesso que não li tudo, mas resolvi jogar aqui uma coisa pra refletir: http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/

Todo mundo já ouviu falar ou leu sobre o movimento #noEstimates ?

Enjoy :)

Samy

@stefanteixeira Concordo com o Stenfan, estimativa somente é um chute no escuro, nunca vi uma estimativa dar certo, sempre o prazo não foi estimado corretamente, acho que entregar aquilo que tem mais valor ao cliente é a chave do negócio.

@Bruno-Fernandes Se o bruno quiser estimar os retestes, porque não? ele pode muito bem montar dados Estatístico de quanto tempo ele passou no ano fazendo reteste, e apresentar um plano de melhoria pra ter menos reteste. Um dos Planos seria automatizar, com os dados Estatístico ele tem uma maior barganha, nesses dados você pode colocar tempo e o dinheiro gasto.

Log in to reply

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