Há muitos anos, no dia em que decidimos lançar uma grande atualização do nosso produto, uma decisão que, naturalmente, exigia a minha aprovação enquanto Diretor de QA, eu caminhava pelo corredor quando o CEO passou por mim.
Parou e disse-me: “Então posso assumir que vamos lançar sem defeitos?”
Sem pensar tanto quanto provavelmente deveria, respondi despreocupadamente: “Claro que não. Não existe software sem defeitos.”
Ele ficou estupefacto e horrorizado com a minha resposta. Ficou tão perturbado comigo que terminou a nossa conversa e afastou-se furiosamente pelo corredor.
Na altura, atribuí isso ao facto de ele ser novo no negócio e no ciclo de vida do software, tendo vindo da indústria editorial (uma longa história — fica para outra altura). Porque toda a equipa de desenvolvimento sabia que íamos lançar com defeitos. Mas sabíamos desde o início quais eram esses defeitos, e isso fazia toda a diferença na nossa avaliação de risco.
No entanto, tenho vindo a notar, com alarme, que recentemente este equívoco por parte do meu antigo CEO se tornou generalizado na nossa indústria. Software sem erros, “software com zero defeitos” é uma nova afirmação/mantra que vejo e ouço cada vez mais. E não apenas por parte de CEOs ignorantes (redundante, eu sei), mas também por parte de pessoas da indústria que deveriam saber melhor. E que, na verdade, sabem. O que considero muito preocupante.
Há um sentido em que o pensamento de “zero defeitos” não é apenas um disparate mendaz e interesseiro. No Ocidente, é sobretudo conversa fiada e uma exibição para causar efeito. Mas no Japão tem, de facto, significado. E em todas as suas indústrias.
Trabalhei no Japão durante um ano, e isto deixou-me estupefacto, mas de uma forma muito positiva. Porque a definição de “defeito” deles é muito diferente da nossa. Por exemplo, se houver uma embalagem de pastilha elástica no chão da fábrica, isso é considerado um defeito, tanto quanto um problema com a maquinaria ou com o resultado de um processo. Se levássemos realmente a sério os “zero defeitos”, pensaríamos nesse problema da mesma forma que os japoneses. Mas não pensamos, portanto não o faremos.
O que eu estava a tentar dizer àquele CEO desafortunado, talvez de forma demasiado brusca, é que qualquer software comercial moderno é infinitamente complexo e, por conseguinte, também são infinitas as formas como pode interagir consigo próprio ou com o seu ambiente. Só é possível encontrar todos os defeitos se tivermos uma quantidade infinita de tempo para testar. Mas nenhum de nós é imortal.
Mesmo que fosse possível encontrar todos os defeitos até ao último na primeira tentativa, não teríamos tempo para os corrigir a todos e lançar um produto neste século — o tempo de chegada ao mercado é uma realidade. Por isso, mesmo que sejam encontrados, teremos de lançar o produto com eles.
Assim, toda a noção de “software com zero defeitos” é, desde logo, inerentemente delirante.
De onde surgiu a noção de software com zero defeitos?
A raiz deste delírio está na ideia de que o papel da QA é “assegurar” a qualidade. Não faz nada disso. Essa é a tarefa da Gestão de Produto e da Engenharia. O papel da garantia de qualidade é *avaliar* o grau de sucesso que obtiveram nessa tarefa.
Mas há outra camada perniciosa neste problema.
Recentemente, estava a discutir esta mesma questão com um programador. Referiu-me que a forma como o significado de “software com zero defeitos” lhe tinha sido explicado era aquilo que acabei de dizer acima. Significa lançar o produto com todos os erros que a equipa decidiu que precisava de corrigir para o poder lançar. E depois lançá-lo com todos os defeitos que decidiu não corrigir. Uma definição com a qual o meu interlocutor, já agora, não concordava.
Ora, isto é claramente apenas uma manobra de fumo e espelhos baseada em definições. Estamos realmente a lançar o produto com defeitos, sabemos que estamos, mas estamos a usar o slogan “zero defeitos” para esconder esse facto de nós próprios — e da administração, naturalmente. Todos sabemos que esta se deixa facilmente hipnotizar por slogans vazios que a fazem sentir-se bem-sucedida.
É apenas uma redução seletiva de defeitos, nada mais.
Have an account? Log In
Como podemos afastar-nos do embuste dos zero defeitos?
E a base deste embuste é a própria linguagem, uma linguagem que molda e condiciona o nosso pensamento antes mesmo de podermos começar a responder conceptualmente ao que está a dizer. É esta linguagem falsa que cria, desde logo, a situação de termos de explicar por que razão está errada. E assim começamos a ser encurralados pelo vocabulário de um slogan.
Esta é uma prática muito comum no desenvolvimento de software. Infelizmente, não se limita a mentirmos a nós próprios sobre os “zero defeitos”. Infecta todos os níveis do nosso pensamento e da nossa ação, enquanto testadores, no nosso processo de desenvolvimento, nas nossas metodologias e nas nossas métricas.
Vejamos, comecemos a encarar a realidade sobre o que estamos e não estamos a fazer. E o primeiro passo nessa recuperação consiste em usar uma linguagem que descreva honestamente o que estamos e não estamos a fazer. Porque, se a própria linguagem que usamos para comunicar essas realidades for, em si mesma, fundamentalmente fraudulenta, desonesta e delirante, não estamos a criar software de elevada qualidade. Estamos a fabricar propaganda.
O outro problema com o discurso do “software sem defeitos” é que, mesmo que este seja um objetivo genuinamente assumido — no sentido em que as pessoas acreditam sinceramente que é possível, e não se trata apenas de um exercício de cinismo —, há outro problema, mais sério, que limita a utilidade desta ideia. Esse problema é o seguinte:
Como poderia saber, e provar, que encontrou “todos” os defeitos que existem para encontrar no software em teste? E não apenas o número de defeitos que conseguiu encontrar no tempo disponibilizado? Como poderia provar a si próprio que o conjunto de erros que encontrou é o conjunto completo de erros que o software realmente contém?
Não pode. Porque isso exigiria algum processo externo à própria QA para o determinar. Caso contrário, trata-se apenas de um argumento circular. E qual seria esse processo externo?
E isto é verdade independentemente do número de erros que já tenha encontrado. Poderia ter encontrado um milhão deles. Isso não prova que não exista um erro número um milhão e um à espreita nas sombras do software.
Existe algo de valioso no conceito de software sem defeitos?
Os problemas lógicos e epistemológicos evidentes de falar e pensar em termos de “software sem defeitos” são simplesmente inultrapassáveis. A própria designação não pode ser recuperada, por mais que a reformulemos.
Mas se olharmos para além do slogan enganador, para aquilo que, à partida, o torna atraente e conceptualmente válido para pessoas que, de outro modo, pensam de forma racional, encontraremos algo de valor no qual nos podemos concentrar.
Esse “algo” é uma questão diferente, mas uma questão que responde às necessidades práticas e emocionais aparentemente abordadas pelo falso discurso do software sem defeitos, e de uma forma mais coerente e defensável.
A questão que as pessoas na área do software estão realmente a tentar compreender, recorrendo aqui à autoilusão, é enganadoramente simples. Nomeadamente: “Quando sabemos que podemos parar de testar?”
É a única pergunta que faço aos candidatos a cargos de liderança de QA na minha organização. Porque, na realidade, essa é a única pergunta à qual a QA precisa de responder. E, se não consegue, a QA é uma completa perda de tempo. Para responder a essa pergunta, temos primeiro de responder a uma questão anterior.
More Articles
Software sem defeitos vs. % de cobertura de testes
Como sabemos se os defeitos que já encontrámos — independentemente do seu número — podem ser plausivelmente aceites como representativos do espectro de risco criado pela forma como o software em teste foi especificado e desenvolvido? De modo a podermos afirmar, com confiança, que os defeitos ainda não detetados representam um risco aceitável para a decisão de disponibilizar o software ao público?
Quando colocada desta forma, percebemos que esta pergunta não é, de todo, uma pergunta sobre defeitos. É uma pergunta sobre cobertura de testes. A sua análise dos erros encontrados, por mais vasta que seja a sua quantidade, não significa nada se não puder ser correlacionada com, e comparada com, uma compreensão analítica da cobertura de testes alcançada até à data pelo esforço de QA, face à cobertura que ainda falta alcançar.
Porque, se esse conjunto de defeitos conhecidos, independentemente do tempo que tenha sido dedicado aos testes, representar apenas 30% de cobertura efetiva de testes — e não souber disso —, então não tem qualquer base racional para saber o que isso significa em termos de uma decisão de disponibilizar o software.
A verdadeira discussão em torno de esforços de QA verdadeiramente eficazes, e o seu verdadeiro objetivo, não pode ser sobre “zero defeitos”, mas sim sobre “100% de cobertura de testes”. Pela razão que expliquei acima.
A grande vantagem desta forma de pensar sobre a qualidade do software é o facto de se basear numa definição de cobertura de testes adequada, elaborada pela própria QA antes dos testes. Por conseguinte, essa definição pode ser testada face às especificações, aos requisitos, a problemas anteriores dos clientes e às necessidades dos clientes, etc., e modificada conforme necessário.
Avançar: cobertura de testes sem lacunas
Pensar neste problema em termos de defeitos falha precisamente porque não é algo que possa ser definido de forma significativa antecipadamente, uma vez que o número e a gravidade dos problemas só podem ser descobertos depois dos testes.
Além disso, não é avaliado face a uma definição preexistente (e significativa) do que o limiar de “zero” poderia realmente significar. É uma perda de tempo definir o sucesso em termos de uma variável que é, por si só, indefinida e indefinível.
É por isso que a única forma de salvar a ideia de software sem defeitos consiste em canalizar esse pensamento e planeamento para uma cobertura de testes sem lacunas. A motivação por detrás do mantra dos zero defeitos não está, por si só, errada. Foi simplesmente desviada do seu verdadeiro objetivo. Faça esse ajustamento e tornar-se-ão possíveis definições significativas e mensuráveis de qualidade de software aceitável.
Se está pronto para aprender mais e, ainda assim, aprender com especialistas e diretores executivos, aqui está um podcast de que pensamos que vai gostar: TRABALHO EM EQUIPA, IA E CONTENTORIZAÇÃO (COM MICHAEL RITCHSON, DA NASA)
Leia também: AS 10 MELHORES FERRAMENTAS DE RASTREIO DE DEFEITOS PARA TESTES DE SOFTWARE
