HIT THE ROAD BUG, AND DON’T YOU COME BACK

 

 

 

PS: meu presente artigo foi publicado em 2/7/2022 no meu Linkedin.

Hoje meu artigo gira em torno de um parafraseio de um famoso pedaço de uma música: “hit the road bug, and don’t you come back”, que em tradução livre seria “pegue a estrada bug, e não volte”. Sim, frase é inspirada na famosa música de Ray Charles (“Hit the Road Jack”), um blues altamente dançante que vale a pena ouvir a versão cantada pelo grupo “Sweet Systers” e tocada pela “Tokyo Ska Paradise Orchestra” (veja AQUI).

Sim, quem trabalha em TI, sobretudo no apoio ao desenvolvimento de sistemas, que não deseja que os bugs fossem embora. Fizessem as malas e fossem embora.

Não é bem assim. Desenvolvedores, analistas de QA, gestores de projeto, usuários é que precisam expulsar o bug (por mais que seja 100% impossível) ou manda-lo para bem longe ou até isolá-lo. Todos precisam fazer isso juntos. Encontrar bugs e elimina-los não é tarefa apenas do QA/tester. É tarefa de todos.

“Mas sou faço isso, mas tem temos prazo a cumprir”.

“Não escreveu, não leu ou não validou, passou. O usuário tem de aceitar. A gente não vai pagar por isso não”.

“O bug é do colega do lado”.

“Bug não existe. Nosso sistema não tem falhas. Quando acontece é um comportamento aleatório”.

“Não precisamos melhorar o processo. Nosso processo é perfeito. Tudo funciona como uma máquina”.

“Nossos analistas de QA e desenvolvedores não precisam melhorar. Eles precisam entrar prontos aqui. Quem não sabe rua”.

“Aqui não tem isso. Usamos Ágil e usamos BDD. Sabemos fazer testes”.

Frases como essas permeiam todo o processo de desenvolvimento. E isso e ruim. Falácias claras (digo isso, com minha experiência de 30 anos em QA, por conhecer várias ferramentas de testes e usá-las, e ter escrito 10 livros técnicos e em sua maioria de testes/QA, mestrado e querer aprender sempre mais, e saber que tenho muito a aprender ainda até o momento em que eu for enterrado. Humildade e conhecimento sempre será necessária ao longo da vida).

Falácias que cometemos de forma clássica:

-Prazo nem sempre é tudo. Entregar um produto falho ou com problemas é pior que entregar no prazo cheio de bugs.

-Mesmo o usuário descobrindo um bug simples e bobo, este é problema da empresa que desenvolveu. Descobrir bugs é um processo.

-Não se empurra “bug”. Muitas empresas elegem um culpado, e caçam bruxas quando o erro muitas vezes é do excesso de pressão e do processo. Ninguém é máquina.

-Nenhum processo é perfeito. Todo mundo e tudo precisa melhorar. O aprendizado e e evolução são até final da vida.

-Até quem usa Ágil, e o defende com unhas e dentes, se esquece que nem Ágil e DevOps NÃO são 100% perfeitos, mas quando usados de maneira adequada ajudam a fazer a diferença. Isso sem se esquecer que o universo das empresas sempre está em constate mutação.

AVISO AOS NAVEGANTES USUÁRIOS E ESPECIALISTAS NAS EMPRESAS: Bug pode demitir sim! Ele não pode ser “colocado na estrada” e ir embora assim. Ele fica, se esconde, muda, muta,  evoluí, se propaga e pode (e vai se você deixar) acabar com seu negócio e até de demitir. Você verá mais adiante.

AVISO AOS NAVEGANTES, CONSULTORES RENOMADOS E DEFENSORES DA AUTOMAÇÃO E QUE FICAM COPIANDO O TRABALHO DOS OUTROS SEM DAR O DEVIDO CRÉDITO, E QUE “COBRAM” OS OLHOS DA CARA: Molinari não está morto. Quando elogio alguém espero que a pessoa me responda e seja educado. Tenho trabalhado com diversas ferramentas de automação e mergulhando em novas. Amo automação. Mas não fico falando como a automação fosse resolver tudo. AUTOMAÇÃO AJUDA EM MUITO SIM. AJUDA NA MELHORIA DA QUALIDADE EM MUITO, MAS NÃO DEVEMOS CONSIDERÁ-LA COMO UMA SOLUÇÃO PARA TUDO. Um tolo com ferramenta na mão ainda será um tolo. Eu jogo limpo, jogo feliz. Tento me superar um pouco a cada dia. E preciso... Sou um eterno aprendiz. Muita coisa minha positiva virá. Sacou? Hoje vejo quem me deu a mão de verdade. Outro dia sai de muitos grupos de Whatsapp, por conta de que estava com excesso de mensagens que precisa limpar todo santo dia. Cansa. Algumas pessoas de um desses grupos passaram a me menosprezar e não me responder mais mensagens quando contacta a pessoa em algum outro grupo. Não fico apregoando ou “colocando” no pescoço um anúncio sobre minhas habilidades, sejam elas soft e hard skills. Agora sei quem é amigo e quem não é. Percebi que quando alertei sobre projetos futuros alguns trataram de copiar e se adiantar colocando algo meio tosco. Falta “sustância” nesse conteúdo, como diria um amigo. Casos assim têm ocorrido com outros consultores. Já tive até texto de um blog meu copiado e “xerocado” sem o devido crédito. Texto esse inédito que havia escrito 24 horas antes apenas usando minha experiência. O “cara de pau” clonou o texto. Pior foi uma ouvinte numa palestra que pediu para eu autografar uma cópia completa de meu livro (que já é um crime), cuja cópia já estava autografada por mim. Recusei-me a assinar. Fui educado e me recusei a assinar.

PORQUE DO AVISO? Prefiro ser sincero e alertar, com a devida educação e cuidado, do que ser falso e mentiroso. Fazer mais do mesmo é ruim. Se inspirar em pessoas e hábitos positivos é lindo. Eu faço isso. Tenho meus ídolos.

Bug demite? Como assim? Vou contar uma estória por fim, no qual você entenderá.

Estava em empresa a alguns anos atrás, e soube de caso que passou dos limites. Durante o desenvolvimento de uma nova parte de um sistema já existente, foi feito o levantamento e a validação para seguir para o desenvolvimento. Nesse processo o cliente, uma grande multinacional, fez um documento específico que foi lido e validado. No contrato entre essas duas empresas, ficou acordado que TUDO que estivesse no documento enviado pelo cliente deveria ser desenvolvido. A equipe de validação foi ao cliente transformou item a item em requisitos. Validou novamente com o cliente e entregou ao desenvolvimento.

Tudo ocorreu perfeito, ou quase...

A nova parte foi desenvolvida, e entregue ao cliente. Foi aí que tudo começou.

No sistema faltava algo. Uma tela importante não estava lá. Analistas disseram que não havia requisito para tal e que tudo havia sido validado com o cliente. Porém, na reunião com o cliente detectaram a tal tela estava no documento entregue na forma de uma imagem enorme e o que havia sido desconsiderada pelo pessoal de requisitos. Uma simples foto que deixaram passar.  Ninguém (diga-se “quem desenvolveu”) queria pelo retrabalho. Queriam que o cliente pagasse. O fato que havia um contrato que afirmava que tudo estava no documento deveria ser entregue.

O caso chegou ao diretor da unidade Brasil da empresa que desenvolveu, responsável por toda empresa no Brasil. Ele foi ao cliente afirmou que não iria desenvolver. Bem...

O cliente foi reclamar na sede principal da empresa na Alemanha. O diretor da unidade Brasil, foi chamado na Alemanha. Sabe o que aconteceu? Foi demitido. O cliente estava certo. Estava no contrato. A equipe Brasil da empresa errou, mesmo tendo revalidado os requisitos na época.

O bug da ausência de um requisito não escrito e não visto DEMITIU o gestor da unidade Brasil.

Agora eu digo e afirmo:

Bug mata? Mata.

Bug dá prejuízo? Dá prejuízo.

Bug causa prejuízo de imagem quando cliente o encontra? Sim. Bug no cliente é como uma “infecção” que pode gangrenar um sistema. Como bem colocado por Rodrigo Peter, “Bug é Predador” e não presa.

Bug demite? Sim.

Pior bug é aquele bug que não queremos ver.

Então caro leitor, pare e pense. As consequências de um simples bug podem ser inimagináveis. Então vamos terminar ao lindo som de “Hit the Road Jack” (veja AQUI).