BugBang Responde I: Horas x Qualidade (A eterna briga das empresas)

Esse é o primeiro post da série BugBang responde. Essa série foi criada com base em e-mails que recebo de leitores questionando alguns pontos que eu considero muito interessantes e gostaria de compartilhar com outros leitores.

Alguns pontos devem ser considerados sobre esse post e estão listados abaixo:

  • Ninguém é dono da verdade: As respostas são baseadas na minha experiência e em literaturas referenciadas junto das respostas, portanto são limitadas ao meu conhecimento, minhas pesquisas e ao contexto em que trabalho ou trabalhei.
  • As respostas não são uma solução genérica e definitiva, mas um ponto de vista e algumas dicas de por onde trilhar ou o que estudar/praticar para alcançar o resultado esperado sobre um cenário bem específico, além de algumas opiniões minhas.
  • Informalidade: A linguagem usada abaixo é ainda mais informal do que a de costume aqui do blog, pois se trata de uma conversa por e-mail.
  • Conteúdo autorizado e aprovado: Antes de postar qualquer e-mail aqui eu pedi autorização da pessoa que fez as perguntas.
  • Anonimato: Por motívos óbvios não serão citados o nome da pessoa nem da empresa para a qual essa pessoa presta serviço.

Os pricipais motívos de ter criado essa série são dois:

  1. Compartilhar as dúvidas de uma pessoa para que outras pessoas que tenham as mesmas dúvidas possam encontrar as respostas e debater sobre o tema.
  2. Como minhas respostas são limitadas principalmente a minha experiência e minhas pesquisas, também desejo compartilhar as respostas para que outras pessoas que tenham respostas e pontos de vista diferentes possam argumentar. Nesse caso tanto o autor das perguntas, quanto os demais leitores que busquem pelas respostas e claro, eu, seremos beneficiados das novas respostas. :)

O primeiro post da série vemcom um título forte (mérito do autor da pergunta) e entre outros aspectos, aborda uma questão extremamente polémica e complexa de responder:

“Como provar que ter uma equipe de qualidade/testes não é uma despesa, mas sim um investimento para empresas que não acreditam nela? “

Pergunta:

Olá Camilo,

Me chamo ******* e fiz um curso com vc aqui em Lavras, há algum tempo atrás, gostaria de aproveitar a oportunidade para uma pergunta que vem sendo recorrente na minha vida de gerente de testes, hehehe… Na empresa que trabalho, na estrutura organizacional da área de projetos, temos alguns cargos, responsáveis pelas propostas técnicas dos projetos a serem confeccionados, nesta cadeia de profissionais temos, Analistas de Negócio, Arquitetos de Sistema e Gerentes Funcionais, classe a que no momento pertenço.

Em a alto nível, nossos Analistas de Negócios coletam com os clientes as necessidades e repassam o Problema aos Arquitetos, por eles este problema é quebrado em problemas menores e a proposta técnica é escrita com auxilio de casos de uso e requisitos funcionais escritos pelos gerentes funcionais, pois bem, meu problema está nesta fase de concepção, vamos a ele.

Sou responsável por levantar as horas de homologação, baseado para isso no documento técnico escrito, bem, faço isso, com o auxilio de um arquivo de tarefas e horas como se fosse um histórico, refinado de tempo em tempo, tendo em vista as experiências adquiridas. A cada uma destas tarefas, podemos aplicar um fator de complexidade e assim ao final e com o lançamento de todas as tarefas do projeto, acumulamos as horas necessárias para trabalharmos.

Pois bem, aí que está o problema, pois as horas são sempre questionadas visto que todos veem os testes como horas que oneram o projeto, ninguém enxerga como produtiva uma hora que agrega qualidade ao final e aí está o fundamento de minha pergunta.

  • Como é feito normalmente no mercado, a questão é sempre horas, como é negociado o tempo, vc tem algo a me indicar, ajudar ou esclarecer ?
  • Como eu poderia provar que minhas horas não estão superestimadas e sim talvez as outras possam estar subestimadas ?
  • Quais são argumentos válidos para que eu consiga mudar esta imagem dos testes ?

Ressalto que já fiz provas estatisticas que comprovam em números os ganhos do sistema após o uso da equipe de testes mas a novela das horas continua. Me ajude, uma luz já será muito útil. Um abraço,

Resposta:

Olá *******,

Esse é um problema realmente complexo. . . É muito complicado mostrar o valor da qualidade, principalmente porque na maioria das vezes nossos entregáveis são abstratos, como bugs e checklists, enquanto desenvolvedores entregam código fonte e analistas de negócio entregam casos de uso, user stories ou outras formas de documentação.

Vou tentar te passar um pouco do que eu acredito, mas não é regra. . .

Como é feito normalmente no mercado, a questão é sempre horas, como é negociado o tempo, vc tem algo a me indicar, ajudar ou esclarecer ?

Existem dois grandes tipos de estimativa, a top down e a bottom up:

A top-down, estima os épicos (como chamamos em Agile) ou um grupo grande de itens, podendo chegar a um projeto, uma fase inteira do RUP ou algo igualmente grande. Nesse caso, a chance de errar é de aproximadamente 400% de acordo com o cone da incerteza (para todo o projeto). . . Muitas empresas praticam essa abordagem, principalmente as que usam modelos tradicionais de software e/ou fazem estimativas baseados em pontos de função. Particularmente recomendo evitar esse modelo.

A bottom-up você estima as menores unidades, como casos de uso, user stories ou funcionalidade. Ao final da estimativa dessas unidades você tem uma estimativa mais real e pode até somar essas unidades e ter uma estimativa para todo o épico/iteração/projeto. A chance de erro de 400% permanece (não temos como evitar), mas dessa vez tanto o risco quanto o impacto do erro são menores, pois ambos estão distribuídos nos itens menores, ou seja, em alguns o erro vai ser pra cima e em outros o erro vai ser para baixo, o que tente a ser mais equilibrado.

No segundo caso (botton up), ainda podemos melhorar a estimativa. Podemos estimar apenas um grupo de user stories, funcionalidades ou casos de uso, assim vamos refinando nossas estimativas, mas não com base em vários projetos (com diferentes tecnologias, com times diferentes, business cores diferentes, ambientes diferentes, etc), mas sim no nosso projeto atual. Isso é o que fazemos em projetos ágeis. Para entender melhor, busque informações sobre estimativas em projetos ágeis, acredito que “planning poker” é um termo para pesquisar no google. Outro fator crucial é que essa estimativa não deve ser gerada de uma forma sistemática, com planilhas etc., mas sim com base nas pessoas do time. Esse ultimo é o modelo que eu mais acredito :)

Porem, para isso você provavelmente vai precisar da ajuda do gerente funcional de desenvolvimento e negócios, pois precisam alinhar esse planejamento.

Como eu poderia provar que minhas horas não estão superestimadas e sim talvez as outras possam estar subestimadas ?

Se atuar da forma que eu falei anteriormente, provavelmente não vai precisar provar isso, pois vai atuar sempre no seu limite e aos poucos a velocidade da sua equipe vai melhorando.

Não sei se entendi bem a segunda parte da pergunta, mas se o desenvolvimento por exemplo estiver subestimando as horas, provavelmente o número de horas extras e defeitos críticos devem estar altos, além de pouca cobertura de testes de unidade, grande número de débitos técnicos e insatisfação da equipe de desenvolvimento. Nesse caso, acredito que você tem uma boa quantidade de informações que mostrem pelo menos os defeitos críticos. Uma conversa com o gerente funcional da área de desenvolvimento mostrando esses problemas pode ajudar, pois provavelmente ele deve sofrer com esses mesmos problemas de estimativas. Caso positivo, tente introduzir esse pensamento de estimativas que eu comentei acima, e juntos vocês terão mais força para argumentar com a diretoria.

Só tome cuidado com as palavras. Não diga que a equipe dele está gerando muitos defeitos, afinal, esses defeitos poderiam ter sido pegos antes se os QAs do projeto escrevem seus testes antes do desenolvimento e fizessem um kick off da funcionalidade mostrando os testes para o desenvolvedor antes da implementação. Vocês são um time :)

Quais são argumentos válidos para que eu consiga mudar esta imagem dos testes ?

Essa é uma pergunta muito complexa e provavelmente podemos ter centenas de respostas diferentes para pessoas/organizações diferentes e mesmo assim, alguns deles provavelmente não entenderão nem mesmo depois de todas as centenas de respostas. . . Eu acredito muito que não mudamos a cabeça das pessoas com respostas, mas sim com atitude e somente assim podemos mudar a cabeça daqueles que realmente não acreditam.

Não sou muito a favor de tracking, mas nesse caso pode ser importante mostrar sempre para toda a equipe (não só diretores, mas devs, outros gerentes e QAs/testers também). Mostre que o número de defeitos está menor, que o numero de reclamações dos clientes estão diminuindo, que os desenvolvedores estão mais produtivos (corrigem menos bugs, tem mais tempo para funcionalidades e customizações), etc.

Você conhece as pessoas que tem que “convencer”, busque conhecer o que essas pessoas veem de valor e comece a coletar informações para mostrar que a equipe de teste de software está ajudando a criar mais desse valor. Provavelmente os diretores e os clientes querem menos defeitos em produção e o gerente funcional de desenvolvimento quer menos bugs e documentação mais fácil de entender.

Seu papel como gerente funcional de QA é coletar essas informações e facilitar as coisas para que o seu time melhore esses indicadores o tempo todo. Quando conseguir mostrar esse valor, com certeza lhe darão mais tempo e mais pessoas para isso. Nesse ponto, você deve começar a melhorar as suas técnicas e refinar seus indicadores. Um dia, que pode não estar tão distante, existirá uma confiançamais sólida na sua equipe, então esses indicadores não serão mais necessários :)

Fim da resposta ======

Tem uma resposta diferente? Tem algo a complementar? Fique a vontate para comentar no post!
Deseja ter uma pergunta postada aqui? Envie um e-mail para camilo at camiloribeiro ponto com .
Quer ainda mais respostas e pontos de vista? Cadastre-se na lista DFTestes e compartilhe seu conhecimento e suas dúvidas :)

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

One thought on “BugBang Responde I: Horas x Qualidade (A eterna briga das empresas)

  1. Excelente Artigo Camilo. Muito esclarecedor e com certeza vai ajudar sim, a mostrar para aqueles que ainda pensam que testes são “uma despesa”, e não um investimento sério que é feito para melhorar a qualidade do software final (e consequentemente, da imagem da empresa).
    Estou ansioso por mais artigos como este, valeu.
    Abraços,

    Rogério

Leave a Reply