Post de um BLOG de qualidade
Foi encontrado há pouco tempo um post de um blog já desativado que tratava da qualidade de software segundo GOHORSE.
O mais interessante é que existe um material rico e verdadeiro dentro de uma espécie de “desabafo” deste pobre entusiasta da qualidade de software.
Vejamos a seguir o post do mesmo:
OBS: note que no final, o horse está já em uma situação já DOCUMENTADA no Axioma n8 do Extreme GOHORSE; interessante que, mesmo com toda uma extensa e bem explicada documentação, horses insistem em não concordar com ese método de desenvolvimento ágil única e exclusivamente aplicada em TODAS as empresas do Mundo, mesmo que em algumas equipes ou desenvolvedores individuais. Estas taxas de adesão de pessoal beira realisticamente quase 100% das organizações de informática em geral.
Eu sou um entusiasta do assunto Qualidade e teste de software, e sei que um dos pilares para se alcançar um “software de qualidade” é a utilização de um modelo de processo de desenvolvimento, que contemple etapas de testes bem definidas e padronizadas, por exemplo o RUP, XP, Scrum etc.
O XGH – Extreme Go Horse é um modelo de processo para gerenciamento de projetos de desenvolvimento de software que propõe princípios, valores e práticas mais “realistas” para as empresas de desenvolvimentos de software como:
Seja autêntico, não é necessário respeitar padrões:
“Escreva o código como você bem entender, se resolver o problema, commit e era isso.”
Teste é para os fracos:
“Se você meteu a mão num sistema que utilize XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.”
Outras práticas e princípios do XGH podem ser encontrados nesse blog
Muitas pessoas já conhecem o XGH, mas aquelas que não conhecem já perceberam, obviamente, que o XGH, se trata na verdade, de uma ironia a forma como os softwares são desenvolvidos em muitas empresas de TI do mercado. O XGH foi divulgado em um blog, que expunha os princípios, valores e práticas do processo. Periodicamente o conteúdo “cômico” era atualizado, mas o blog feliz ou infelizmente foi descontinuado e a documentação, seja ela qual for, foi perdida.
Seguindo a brincadeira, eu vou formular algumas práticas e princípios para a etapa de testes de software do XGH, ainda que o mesmo no seu axioma 20 afirme que “Teste é para os fracos”. Mas sendo o XGH um modelo de processo flexível, pode ser que por algum motivo “subversivo” seja necessário incrementar uma etapa de testes no processo:
Princípios e práticas da etapa de testes do XGH:
- Testar está na moda, rotule seu sistema com “testado e aprovado”
Garantir qualidade do software é muito importante para o marketing, então não deixe de garantir a qualidade para os seus potenciais clientes, ainda que não teste diga que teste, essa ideia vende. - É função do motoboy testar software.
Testar software é trivial, não é necessário conhecimento técnico. Para economizar recursos coloque o motoboy da empresa para testar. Outras opção para tester é algum parente do dono da empresa. - Não precisa de documentação. Testar software e só correr as telas do sistema.
Isso é desenvolvimento ágil. Não é necessário produzir documentos para auxiliar em uma atividade que não agrega valor ao produto. É só colocar o sistema para rodar e vê se está funcionando. - Depois que tudo tiver pronto, O software é testado.
Testamos tudo depois que o sistema estiver pronto, dessa forma não interrompemos as outras etapas do processo que são mais importantes. - É suficiente reporta só uma falha por cenário.
Não devemos perder tempo com um cenário que já está “bugado“. O desenvolvedor vai corrigir o bug e da próxima vez que o sistema for testado, se houver mais bugs, eles serão encontrados. - O importante é entregar o software. As correções dos defeitos ficam para versão 2.0
Os testes são realizados durante o tempo que sobrar do fim do desenvolvimento até a data de entrega do produto. O sistema não pode deixar de ser entregue. O que foi corrigido foi corrigido, o que não foi fica para próxima versão.
Até então conseguir pensar nesses seis princípios, se alguém tiver alguma outra ideia, compartilhe comigo.
A ironia implícita nesse post é uma reflexão crítica sobre o mercado de software, no que tange ao desleixo para com a qualidade de software.
Você e desenvolvedor? Como a sua empresa trata da qualidade de seus produtos? O processo de desenvolvimento utilizado lá segue o modelo XGH? Existem testes, e se existem são ad-hoc? São questões a se pensar.
A concorrência no mercado de software, cada dia mais se acirra, e qualidade de software se torna cada vez mais indispensável para que as empresas se mantenham no mercado. Pode está tudo indo bem agora, mas não tarda e os sistemas cronicamente “bugados” da sua empresa, deixarão de atrair os clientes que buscarão a qualidade que seus produtos não têm, e ai que a concorrência te tira do mercado. Você vai deixar isso acontecer?
Está na hora de abandonar o XGH não é mesmo?
(note o desespero do autor nas últimas 2 frases)… é o GOHORSE passando por cima de você meu amigo! 😉
