A 20ª Mesa Redonda DFTestes teve como tema “Quem é o grande vilão do Teste de Software, o bug ou o tempo?”. A discussão teve 9 respostas e participantes, sendo eles: eu, Sarah Pimentel, Luís Barros, Shmuel Gershon, Rodrigo Almeida, Felipe Silva, Elias Nogueira, Humberto Barboza e Talita de Oliveira.
Abaixo, faço um “resumo” de como foi a discussão, sempre lembrando que quem quiser ela na íntegra é só acessar esse link (é necessário se inscrever no DFTestes).
Quem é o grande vilão do Teste de Software, o bug ou o tempo?
Segundo a Sarah Pimentel:
Tanto o tempo quanto os bugs são vilões, quem está sendo pior depende do projeto, eu acho. Existe tanto aqueles sistemas onde nenhuma pratica de prevenção de defeitos foi aplicada e chegam com bugs críticos que bloqueiam e atrasam testes, quando os projetos nos quais a definição de requisitos atrasou, a arquitetura atrasou, o desenvolvimento atrasou mais ainda e o tempo do teste ficou reduzido a 25% do que era antes e claro que sempre esperam que a equipe de testes faça milagres porque só ela não pode atrasar.
Quanto aos bugs podemos atacá-los através de processos de prevenção de defeitos e quanto ao tempo, revisando o planejamento, implementando um processo de gerenciamento de mudanças e procurando alinhar a equipe de vendas (normalmente o tempo começa a ser um problema já na venda do projeto) o que realmente é possível entregar no tempo acordado.
Apesar do desejo intimo de ter a aplicação 100% testada, sabemos que isso é dito como impossível. Para isso, há algumas técnicas que nos ajudam a selecionar/priorizar testes para que possamos aproveitar nosso tempo da melhor maneira possível.
O Luís Barros deu a sua opinião dizendo:
Na minha opinião o TEMPO hoje é o grande vilão do teste de software.
O TEMPO compromete as verificações de documentação que, antes mesmo de ter uma aprovação formal já estão na mão dos desenvolvedores, pois o prazo já está apertado;
O TEMPO faz o desenvolvedor passar por cima dos testes unitários e de integração;
O TEMPO faz o prazo do time de teste ser reduzido. Aliás, a gente sofre muito com isso, pois o que é cortado primeiro de um projeto é sempre o teste;
O TEMPO faz um projeto ser “baseado em funcionalidade” (Funcionou tá bom!), onde só o “Caminho Feliz” importa.
E finalmente…
O TEMPO causa mais bugs pois, se tudo o que foi mencionado não acontecesse, certamente teríamos um software com muito menos bugs
Uma frase que já ouvi muito de caciques: “Não entregar tem um impacto muito maior do que entregar com erros!”
O Shmuel Gershon tem uma opinião diferente do pessoal:
Vilões? Ahn?
Primeiro, por que o bug seria um vilão? Se fosse um vilão, não ficaríamos tão feliz de achar um.
Acho que os bugs, longe de ser os vilões, são nossas bat-ferramentas, essenciais para sermos bons heróis. São eles que nos permitem aprender, e que nos permitem ensinar e transmitir informação adiante.
Segundo, por que o tempo? Tempo é o melhor amigo da qualidade de software. Se não tivessémos tempo suficiente, não ia dar pra fazer nada direito!
E a falta de tempo? Outro melhor amigo da qualidade, especialmente porque este fica do lado do cliente, defendendo seu valor — já pensou se ainda não tivéssemos recebido o Windows 97? não teria como avançar a tecnologia até chegar no Win7.
Bugs e Tempo, para ser vilões, só neste link e neste link. 🙂
O verdadeiro vilão dos testes, sou eu.
(não, não por que eu fico aqui contrariando todo mundo na DFTestes!)
Mas por que eu concordo com mas decisões, em vez de trabalhar com meus gerentes para tomar a decisão certa.
E porque eu não sou capaz de explicar toda a extensão do impacto de uma mudança no cronograma.
E porque as vezes uso métricas que em vez de ajudar, estão atrapalhando a operação.
É dura, esta vida de herói e vilão ao mesmo tempo…
Minha linha de pensamento sobre o assunto é bem parecida com a do Shmuel.
Todos são culpados! Até que se prove o contrário.
Em algumas organizações é muito fácil botar a culpa em fulano ou ciclano, principalmente, quando temos caciques (como lembrou o Luís), ou pessoas que gostam do poder, de tomar decisões sozinhas, etc.
Eu particularmente, vejo que o desenvolvimento de software é algo muito complexo, para um único ser humano levar a culpa. E por isso, sou a favor de quando algo de ruim acontece (“shit happens”), todos sentarem para buscar os fatores e a causa raiz para aquele problema ter ocorrido, deste modo todos evoluem e tem a oportunidade de discutir.
Nenhum dos dois são vilões, são apenas efeitos causados por seres humanos.
Porém, “o primeiro” bug, era sim um vilão, aquela traça maldita! rsrs
Hoje acredito que nenhuma falha acontece por causa de uma trasa, elas acontecem porque pessoas desenvolveram aquele sistema. E pessoas cometem erros, lembre-se errar é humano.
E como o Shmuel disse: “É dura, esta vida de herói e vilão ao mesmo tempo…”
O Rodrigo Almeida enfatizou a importância de termos um processo alinhado com a equipe de desenvolvimento, para podermos tornar o tempo o nosso amigo:
É preciso ter estratégia.
Estratégia para achar o bug nos testes críticos.
Tem que ter processo definido e alinhado com a equipe de desenvolvimento.
Desta forma o tempo vira aliado e não inimigo!
Segundo o Felipe Silva:
– O tempo é um fator neutro, quem faz ele parecer mau ou bom é a “áurea espiritual da entidade responsável pela estimativa e cronograma”, se está estiver acima do “limite mortal humano” então o tempo leva a culpa mesmo sendo algo constante, caso contrário o tempo leva a culpa pelo desperdício de orçamento? Esta segunda resposta é única e exclusiva da “índole da(s) entidade(s) superior(es)”. Falando claramente tempo vilão = planejamento não reflete a realidade, isso também não quer dizer que o planejador é o culpado, a não ser que ele seja capaz de prever o futuro, mas ele é no mínimo cúmplice (rs).
– O bug pode ser um vilão, principalmente para nós responsáveis pela qualidade, mas é este também “paga meu salário todo mês”, estão se eu colocasse em uma balança ele é mais meu amigo do que meu inimigo, sobre o bug só posso dizer ele é mais previsível do que o tempo, embora não seja possível testar 100% do software é possível testar a parte mais usada e deixar o bug hibernando por tempo indeterminado, contanto que este não acorde ninguém vai reclamar.
Se for para pesar Tempo x Bug eu diria que o tempo tem maior peso, pois a falta deste primeiro ajuda o segundo ser um risco maior.
O Elias lembrou bem, que muitas vezes o grande vilão é a cultura da empresa:
O principal vilão do Teste de Software é a cultura!!!
Em um software de missão crítica ou relacionados (aviões, máquinas médicas, etc…) nem o tempo nem o bug serão um “vilão”, pois a cultura cultivada dentro de uma organização que desenvolve e testa um software dessa linha está preocupado com a qualidade.
O que nós enfrentamos no nosso dia-a-dia é prazos curtos e uma quantidade grande de bugs dado também a pressão colocada sobre a área de desenvolvimento para entregar ‘qualquer coisa’ de uma forma mais rápida.
Uma empresa que preza por uma cultura de qualidade dificilmente terá como o vilão o bug ou o tempo!
O Humberto Barboza deu a sua opinião dizendo:
Respondendo a pergunta e concordando com alguns, dentro do nosso paradigma de teste de software o tempo é o grande vilão.
Infelizmente para a nossa atividade nunca dispomos dele para realizar o trabalho ótimo. E na grande maioria das vezes somos obrigados a fazer o melhor trabalho que pode ser feito, priorizando as atividades, dentro do tempo que dispomos.
Claro que essa discussão como já pudemos perceber nessa mesa redonda envolve muitas variáveis: a cultura da organização passada hierarquicamente abaixo de que o teste pode ser cortado se não houver tempo, a pressão sobre a equipe de desenvolvimento que entrega o produto sem a qualidade esperada porque não realizou devidamente os testes unitários e de integração, a pouca importância dada a fase de planejamento dos testes e a adoção da estratégia “Sair fazendo” sem o devido planejamento, padrões engessados (inclusive estou sofrendo pra caramba com isso no momento, porque adotamos o Scrum, mas, com os padrões de documentos existentes hoje é inviável trabalhar e estou tendo que pensar no meio do sprint, por que não houve tempo antes rsrs, em como adaptar e gerar métricas no cenário atual visto que sequer utilizamos uma ferramenta de controle de defeitos).
Liderança desinteressada que deixa exclusivamente a cargo do QA todas decisões, por hora acho que é isso.
A Talita de Oliveira respondeu a pergunta dizendo:
Bom, pelos projetos que atuei, a maioria dos problemas em fase de teste foi o tempo, mas no meu ponto de vista uma coisa leva a outra, como disse o Humberto tem a ver com a cultura da empresa. Digo que uma coisa leva a outra pelo fato da pressa, como já diz o ditado que pressa é inimiga da perfeição, dificilmente um time de testes por mais competente que seja não conseguirá entregar um projeto com a % mínima de bugs se não houver tempo. E essa falta de tempo acontece porque a fase de testes na maioria dos projetos está no final, pelo menos é assim que tenho trabalhado…em fases finais.
E quanto a equipe de testes aceitar desafio, é normal, pois ao longo da minha experiência a pressão sempre foi alta porque ouvi sempre: “Vocês são a parte final do projeto” ou “Vocês que dirão se a aplicação está ok ou não”. Então..acho que não só a equipe de testes é culpada, mas todos os envolvidos tem sim sua parcela de culpa.
Por que gostamos tanto de terceirizar a culpa?
A Sarah Pimentel lembrou que é sempre mais fácil terceirizar a culpa:
Se eu assumo que a culpa é minha ou que eu tenho qualquer responsabilidade sobre o que está acontecendo, eu sou forçada fazer algo a respeito. Se eu jogo a culpa no outro, o problema é dele e ele que se vire pra resolver, não impacta no meu dia a dia. Fiz uma vez um treinamento de relações humanas e meu professor me disse algo óbvio: não podemos mudar os outros, a não ser que eles mesmos estejam procurando uma mudança. Então se há uma situação que você quer resolver, ao invés de esperar pelo outro, procure em você o que você pode fazer para mudar a situação e naturalmente (na maioria das vezes) o outro vai ser influenciado pela sua mudança de comportamento.
Na minha opinião é da natureza do ser humano culpar o próximo. A Dorothy Graham falou um pouco sobre isso no CInTeQ 2010, contando que irmãos mais velhos, gostam de colocar a culpa nos mais novos (eu mesmo fiz isso muitas vezes rsrs).
Quando crescemos aprendemos que podemos botar a culpa não são nas pessoas, mas também no processo, metodologia, ferramenta, bug, tempo, etc. E assim fazemos, quantas vezes você já ouviu falar que vários projetos falharam por causa que usavam o modelo Cascata. Mas quem escolheu usar o modelo Cascata? As pessoas não foi!?
Segundo o Humberto Barboza:
Infelizmente quase nunca fazemos um “Mea Culpa”. Concordando com o que foi dito já na lista, boa parte da culpa é nossa que por gostar de desafios ou situações desafiadoras, aceitamos irresponsavelmente trabalhar com tempo reduzido, padrões engessados, ausência de ferramentas adequadas e até liderança inoperante, infelizmente. Tecnicamente erramos por exemplo estimando mal nosso trabalho, priorizando atividades menos relevantes e cedendo às pressões do nosso meio. Precisamos defender o nosso trabalho e demonstrar a importância de ser bem planejado, projetado e executado e qual o impacto na qualidade do produto e as consequências que pode ter.
Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.
Fique por dentro das novidades, assine o feed do QualidadeBR.
QualidadeBR 