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

-3

Sempre que estamos envolvidos com o planejamento de algo, independente de ser um projeto de software, podemos estimar nossas atividades para alcançar o objetivo desejado.

Por exemplo: Aquela viagem tão esperada nas próximas férias, estamos planejando levar X horas da origem para destino, mais Y horas em determinado passeio, Z dias em uma cidade N em outra, assim sucessivamente.

Por meio desse exemplo já podemos perceber que a todo tempo estamos estimando sem perceber, quase um ato involuntário.

Mas será que damos a devida importância para estimativa de horas? Ou ainda, será que sabemos como estimar de forma que o planejado seja mais próximo do realizado? Como estamos estimando? Já parou para pensar nessa questão dentro dos projetos que tem integrado?

Leia mais em: http://www.matera.com/br/2015/05/29/estimar-ou-nao-estimar-eis-a-questao/

Achei importante a questão da estimativa de reteste… geralmente colocava em minhas estimativas uns 20 a 30% para retestes. Porém, recentemente conversando com um pessoal, inclusive com a liderança de testes, disseram que não se deve estimar retestes, pois este é um custo que não se pode repassar ao cliente (usamos a estimativa para calculo do valor a ser cobrado). Disseram que reteste é retrabalho e que o cliente não pode pagar por algo que foi feito errado. Esta seria a minha versão do “balela”! Não concordo com esta afirmação, pois como foi dito no artigo, o objetivo do teste é “encontrar erros”. Se todos os testes passarem, nenhum erro for encontrado e nenhum reteste for necessário, então não seria este o caso da inutilidade dos testes? Passando este tempo testando ou não, o resultado final seria o mesmo. Acho que o tempo é perdido quando passo horas testando algo que não possui problemas. Ao meu ver a única serventia disso é ter indicadores de que não foram evidenciados problemas no software.

Poderiam comentar sobre a estimativa de retestes?

“Legal essa matéria”. Mensagem enviada em 20/10/1979…

@Ramses-Saccol-de-Almeida , por favor, ilumine minha mente antiquada com sua luz.

Por que esta discussão só seria legal em 1979? Por que agora não faz mais sentido? A ironia não explicou muita coisa…

Bruno! Vejo que há uma divergência de concepção entre você e sua equipe. Essa “balela” (como você disse) faz total sentido dentro de uma cultura mais ágil, pois retrabalho não gera valor. Se houve retrabalho, algum ponto ficou de fora (verificar todas as etapas de envolvimento do time). Pelo visto, você possui um cultura profissional diferente do restante da sua equipe. Fale com seus gestores, pois a comunicação é de extrema importância no time para que todos caminhem na mesma direção, que é fazer uma entrega para o cliente com valor.

Patrícia Gonçalves

@Bruno-Fernandes , esse assunto nem em 1979 era legal, mas já que o sarcasmo não caiu, vamos lá…

Estamos em 2015…As coisas evoluíram…O jeito de fazer software…O jeito de interagir com o cliente…O jeito de achar novas soluções aos problemas…E em pleno 2015, eu preciso de mais uma matéria sobre estimativas…Sério?
Na minha opinião (e deixo bem enfatizado isso), não vejo necessidade nenhuma em se iniciar um tópico sobre isso. Prefiro conversar mais sobre a união e qualificação do profissional de teste, melhor, de um profissional como um todo, do que como estimar testes…
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…

@Bruno-Fernandes , se esse assunto realmente te interessa, continue a discussão aqui, ignore o meu comentário e siga a vida. Ninguém é obrigado a concordar com a visão que tenho sobre o assunto. Nem muito menos vir defender o ponto de vista alheio…
Boa semana e bons testes…

@Patrícia-Araújo-Gonçalves, aqui não trabalhamos com ágil ainda, estamos no método tradicional…
O que acho estranho é que na prática, o reteste sempre existe, principalmente quando o teste é bem feito, então minha dúvida é: Por que não se deve colocar este reteste na estimativa?
Bom, pensando aqui em minha pergunta, uma resposta seria: Para deixar estourar as horas mesmo e identificar problemas no processo que podem ficar ocultos caso as horas sempre estejam ok. Acho que este seria um ponto que justificaria a não estimativa do reteste.

@Ramses-Saccol-de-Almeida, agora sim, obrigado pela explicação!

Bruno! Acho que antes de pensar em estourar horas a “preocupação” deveria ser entender o porquê que o retrabalho aconteceu. Isso sim seria uma ação de maturidade do time em vez de tentar encontrar os “culpados” ou “deixar estourar”. Independente de metodologia (tradicional ou ágil), na minha opinião não faz o menor sentido estimar retrabalho. O que você vai fazer com essa métrica de esforço de reteste? Quem vai pagar essa conta?

Patrícia Gonçalves

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.

Log in to reply

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