O Dr Alan Kelon [ou quase dr., não sei se já terminou] com a arrogância clássica da academia deu uma aula de engenharia de software a esse pobre AMADOR SEM EDUCAÇÃO que vos escreve.

Se eu fosse um novato, recém integrado na faculdade, sem base acadêmica para duvidar de um Dr. [ou quase] eu estaria destruído com minha ignorância.

Esse é o temor que tenho da academia, a sua falta total de pé-no-chão ou conhecimento real daquilo que ensina, é o que me fez abandoná-la e nunca mais pisar por lá.

Tantas citações a obras importantes é típico da academia, mas o discurso que eu gostaria de ouvir não existe:

“Quando eu implantei CMMi na XPTO…”

“Quando eu trabalhava com RUP, nós…”

Na prática a teoria é outra

Caro Dr., eu estudei muito sobre isso, li todos esses documentos e até cheguei já a acreditar que eram válidos para garantir a qualidade de um produto. Claro, isso no início desse século quando eu era estagiário e sem conhecimento real.

Depois de passar por implantação de CMMi mais de uma vez, ISO e Mps.Br, foi que aprendi o valor da teoria e como aquilo que está escrito não reflete a realidade na “engenharia de software”.

Talvez o que mais me marcou em verificar que não existe engenharia de software [ou ela é ainda muito incipiente] foi ter participado de avaliações ISO em outros setores como indústria, imobiliária e serviços. Fica evidente para todo mundo que a avaliação nesses setores é de processo e não de produto e serviço porque eles tem métricas reais e aplicáveis em suas industrias.

Quando CMMi ou ISO falam em qualidade de produto eles não dizem como fazer e sim o que fazer, essa é a diferença básica entre processo e produto, caro Dr.

Essa bobagem semântica  faz toda a diferença, quando eu avalio a qualidade de um produto como uma garrafa PET, existem métricas reais para testar a qualidade [como por exemplo durabilidade], existe um processo normatizado por órgãos [como ANATEL, ANVISA, e tantos outros] que garantem a qualidade mínima do produto ou serviço.

Esse foi o seu primeiro erro conceitual, dizer que tem que fazer é diferente de dizer “como” tem que fazer. “O que” é processo, DR. “Como” é produto, Dr.

Testes de Software

Vou fazer um mea-culpa porque quando escrevo eu sempre esqueço que meus leitores não me conhecem e não podem advinhar o que fica nas entrelinhas, eu não gosto de citar referências por preguiça de sair catalogando nomes de livros e autores [só quando lembro na integra de cabeça e acho importantissimo] e espero que as pessoas não acreditem em uma só linha sem verificar. Como vão verificar, eles acham a referência por si só, não preciso colocar bibliografia nos meus textos.

Esse trecho fica evidente que falho por omissão:

Há controvérsias sobre testes automáticos garantirem qualidade interna, na verdade, não vejo onde há relação direta. Testes são sim de suma importância, independentemente de serem automatizados ou não, que fique claro, mas não garantem totalmente a qualidade, nem externa e muito menos interna (em breve explicarei o porquê), muito menos é o único método para se conseguir qualidade. Inspeções e revisão de software (e especificações associadas), juntamente com analisadores estáticos, são tão efetivos quanto testes na detecção de defeitos e tem possibilidade maior de melhorar a qualidade interna de produtos de software.

Quando falo em testes, é óbvio para quem me conhece que estou me referindo sobretudo a TDD e também BDD. Testes por si só não garantem nada, nem sequer que as falhas estão cobertas.

O processo de TDD é que fortalece a qualidade interna do software porque ao você aplicar as práticas desse processo, você se torna minucioso na verificação de coesão, complexidade, acoplamento sem precisar de ferramentas de análise de código.

Eu não estou afirmando que não use ferramentas de análise de código, longe disso, só que essas ferramentas não verificam qualidade real no código, no máximo elas avaliam erros clássicos e mau cheiro no código. É perfeitamente possível escrever um código horroroso e ilegível e passar por todas as ferramentas de análise de código facilmente, isso acontece na prática no cotidiano.

Como testar?

Antes de me dizer, responda-me: Você faz que tipo de teste? Unitário, integração, sistema, aceitação? Testes funcionais, estruturais ou baseados em defeitos? Para testes funcionais, você utiliza classes de equivalência, análise de valor limite, grafo causa-efeito e ainda tenta error-guessing? Para testes estruturais, você aplica grafos de fluxo de controle? Como define seu critério de cobertura de instruções, decisões, condições e caminhos? E quais das métricas já citadas ou quaisquer outras tem adotado? (Zhu, Hall and May, 1997) Se você não tiver uma boa estratégia para cada uma destas táticas, sinto muito informar-lhe, mas VOCÊ NÃO SABE TESTAR SOFTWARE.

Eu não sigo as estratégias do Zhu “Who?”, eu sigo um AMADOR SEM EDUCAÇÃO chamado Kent Beck que não é nada científico mas funciona. Sim, eu faço testes unitários, integração, aceitação, stress, carga e o que der mais para fazer com o tempo disponível para entregar o software o mais saudável possível. As ferramentas de análise de cobertura são frágeis e deixam escapar a real cobertura, da qual temos que aplicar triangulação e outras práticas não-acadêmicas criadas por AMADORES SEM EDUCAÇÃO.

O bacana de tudo são esses números:

Ou seja, mesmo que você tenha 100% de cobertura, você terá apenas garantia de detecção de defeitos em 25% dos casos (Glass, 2002).

Minha vó dizia que os números quebrados tem mais credibilidade, se fosse pelo menos um 25, 37%… vá lá.

Não estou a par de nenhum estudo rigoroso que mostre relação positiva entre presença de testes automáticos e código mais coeso, desacoplado, limpo, claro e legível também.

Dr. o mundo não vive de Papers apenas, saia da academia e visite uma empresa que faça TDD e outra que não, o senhor avaliará por si só. Alias, quem deveria fazer esses estudos era a academia, não? Como farão se não saem às ruas?

Caso alguém tenha, por favor, entre em contato. Gostaria de saber também, se possível, quais processos preocupam-se com qualidade externa em detrimento de qualidade interna. Seriam os processos ágeis?

Todos os processos avaliam qualidade externa pelo que escrevi acima.

O seguinte trecho quase me faz não responder esse artigo:

Por fim, o PROJETO é a quarto e última variável necessária para construir software, porque planejamento e gerenciamento são nossas únicas armas para controlar a complexidade

O que diabos complexidade tem a ver com planejamento e gerenciamento?

Desde quando voce planeja a complexidade de um software?

Fazendo notação matemática do algoritmo?

Desculpe, mas nem todo mundo tem o tempo do Dr. Knuth para entregar software, precisamos de verificação rápida e não notação matemática e não existe um mecanismo que faça isso antes de ter um software escrito.

Novamente, o projeto pode ser tão detalhado e formal quanto se queira.

Não, DR. O projeto não pode ser tão detalhado e formal quanto o queira, isso eu acreditava antes de fazer coisas reais e ficava apenas em cima de livros, se a engenharia de software realmente existisse, eu tinha mecanismos reais para fazer esse detalhamento, mas hoje esses mecanismos reais não existem.

Cada vez mais me convenço de que a academia está morta e não produz nada de real, apenas papers repetitivos de bobagens que ninguem lê.

Deveriam ter terminado a notação formal da orientação a objetos mas estão preocupados demais com “modelos de qualidade” [sic] que nunca avaliaram na prática e não fazem idéia de como mensurar.

Isso não é científico, Dr.

Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated matter. Matters, like “coupons for viagra“, are connected numerous types of health problems. If you need to take prescription medications, ask your druggist to check your testosterone levels before. Sometimes the treatment options may turn on erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.