Alan’s posterous

"CMMi, ISO ou seja lá que for, não garantem que o produto será de qualidade e sim que o processo seja e se pararmos para pensar um momento, o processo realmente é de qualidade, temos um conjunto de métodos eficazes para produzir… processo e não produto".

Errado. Sem parecer ser arrogante, mas você já leu o CMMI 1.2 (CMMI, 2006) na íntegra? Não contam o verbete na Wikipedia ou artigos em blogs.

Pergunto se você já leu o documento na íntegra, porque, se o tivesse feito, saberia que já no nível 2 existe a preocupação com QUALIDADE do processo e DO PRODUTO. A partir do nível 3 há exigência da presença das áreas de processo (KPAs) da Engenharia, a saber: Requirements Development, Requirements Management, Technical Solution, Product Integration, Verification & Validation.

Todo o bla-bla-bla que você falou sobre qualidade de software é contemplado pelo CMMI. As KPAs de Engineering não são obrigatórios no nível 2, mas nada impede a empresa de implementá-las.

~~~

Antes de falar sobres testes automáticos, definamos o que seria qualidade de software. A ISO 9126 define seis categorias para os atributos de qualidade do software (também conhecido como FURPS):

• Functionality: Feature set, Capabilities, Generality, Security;
• Usability: Human factors, Aesthetics, Consistency, Documentation;
• Reliability: Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure;
• Performance: Speed, Efficiency, Resource consumption Throughput, Response time;
• Supportability: Testability, Extensibility, Adaptability: Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

Destes, suportabilidade é o que chamamos de qualidade interna; os demais são qualidade externa (McConnell, 2004). Já que o assunto é testes de software, para medir testabilidade, há várias métricas que se aplicam (Binder, 1994; Pressman, 2004): Lack of cohesion in methods (LCOM), Percent public and protected (PAP), Public access to data members (PAD), Number of root classes (NOR), Fan-in (FIN), Number of children (NOC) e depth of the inheritance tree (DIT).

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.

Já que insistem em pensar que testes automatizados são parte fundamental da questão de qualidade de produto de software, pergunto-lhe: qual a qualidade de seus testes?

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.

O argumento de testes automáticos serem sinônimo de qualidade é falacioso, por mais que você escreva-os em Cucumber e JUnit. Mesmo se você fizer todos os tipos de testes citados anteriormente e suas ferramentas de cobertura apontarem 100%, ainda não é suficiente porque pode haver erros de omissão em seu software, em que a lógica para execução de determinado requisito simplesmente não está implementada, ou um erro de combinação único de caminhos em seu programa que leve a uma condição não prevista. O primeiro caso ocorre muito freqüentemente, cerca de 35% do tempo, e o segundo tem freqüência de 40%. Ou seja, mesmo que você tenha 100% de cobertura, você terá apenas garantia de detecção de defeitos em 25% dos casos (Glass, 2002).

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. 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?

~~~

A última colocação é quase feliz, pois, sim, as PESSOAS são fundamentais em qualquer empreitada intelectual. As capacidades, qualidades, virtudes e conhecimentos técnicos individuais são essenciais. Sem pessoas qualificadas, invariavelmente, teremos Big Ball of Mud no final de um projeto. A colocação foi infeliz porque apenas as pessoas não bastam, desprezou-se outras variáveis. Logo após a importância das pessoas, aparece a compreensão do PRODUTO a ser construído. Em terceiro lugar, o PROCESSO DE SOFTWARE toma lugar. Seja ele qual for o software a ser construído, independentemente de seu tamanho ou complexidade, sempre haverá um conjunto de atividades a serem realizadas (especificação, análise, projeto, implementação, testes e entrega) com maior ou menor formalismo. A diferenciação entre processos dá-se na ordem, repetição e intensidade que cada uma ocorre. É importante pensar em processo de software como uma ferramenta de COMUNICAÇÃO, não uma amarra. Amarras ocorrem com más implementações de processos, como ocorreu com RUP no passado e tem ocorrido ultimamente com processos ágeis. Mesmo times compostos de pessoas tecnicamente brilhantes estão sujeitos ao fracasso por causa do não uso de processo, aumentando a possibilidade de problemas de comunicação e sincronia de atividades. 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. Novamente, o projeto pode ser tão detalhado e formal quanto se queira.

Cada vez convenço-me mais do que converso - e repito semestre após semestre - com meus alunos: o problema da indústria de software são os AMADORES SEM EDUCAÇÃO. A solução? Educação de qualidade. Por favor, que a educação também não seja repassada por cowboys.

Por fim, quando escuto falar "na prática, a teoria é outra", imediatamente, penso "na prática, é você quem não conhece a teoria".

Referências

• CMMI Product Development Team. 2006. CMMI for Development, Version 1.2. Technical Report CMU/SEI-2006-TR-008 and ESC-TR-2006-008, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, August 2006. Available from http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html
• Binder, R. V. 1994. Object-oriented software testing. Commun. ACM 37, 9 (Sep. 1994), 28-29. DOI= http://doi.acm.org/10.1145/182987.182988
• Glass, R. L. (2002) Facts and Fallacies of Software Engineering. Addison-Wesley.
• ISO. 2001. ISO/IEC 9126-1 Software engineering — Product quality — Part 1: Quality model.
• McConnell, S. 2004 Code Complete, Second Edition. Microsoft Press.
• Pressman, R. S. (2004) Software Engineering: a practitioner's approach. McGraw-Hill.
• Zhu, H., Hall, P. A., and May, J. H. (1997) Software unit test coverage and adequacy. ACM Comput. Surv. 29, 4 (Dec. 1997), 366-427. DOI=http://doi.acm.org/10.1145/267580.267590

* Curiosidade: Pressman e McConnel tratam do assunto qualidade na mesma página de seus livros: página 464.