Definir qualidade de software é difícil pois são muitos os fatores que influenciam os resultados. Mais do que ser uma lista extensiva de soluções, este artigo tem como
objetivo identificar a maioria dos pontos – são, aliás, perfeitamente
lógicos e conhecidos – que têm de ser testados e validados, e apontar a
direção e algumas ferramentas. É uma visão na perspectiva de QA (Quality Assurance), mais especificamente de testes. Posso dividir estes fatores em dois grupos:

• Organizacionais ou processuais

Englobam o tipo de gestão de projeto, metodologia de desenvolvimento da equipe, qualidade e processo de levantamento de requisitos.

Técnicos

Os artefatos de código e semelhantes produzidos pelos developers e os processos levados a cabo por testers.

Este artigo foca-se, primordialmente, nos fatores técnicos, que passo a enumerar.

Correção do código produzido

É importantíssima a exigência que cada programador coloca em si
próprio para escrever código de qualidade: primeiramente, código o mais
correto possível. No entanto, não basta tentar escrever código correto, é também
necessário pensar nas implicações de performance do que se escreve (por
exemplo, fazer um select completo a uma tabela grande sem necessidade),
de thread safety, de segurança (caso mais comum, SQL injection para o
qual PreparedStatements são uma grande ajuda), de documentação
(comentários relevantes) e de estética do próprio código (definir e
seguir convenções).

Este ponto depende também da própria qualidade das pessoas na equipe e a diferença, além de se pagar, nota-se!

Testes Unitários

Escrever testes unitários é a forma mais direta que a equipe tem de garantir correção do código.

Em TDD (Test Driven Development)
o teste unitário é a unidade básica e o código é desenvolvido para
satisfazer cada teste. Esta aproximação é altamente eficaz mas exige
disciplina e considero que é difícil de ser usada pela maioria das
equipes. No entanto, mesmo em ambientes não TDD este tipo de testes é
essencial, não só para garantir que o código está correto, como para
verificar que não se quebra código anterior cada vez que se alteram ou
adicionam funcionalidades. Quanto maior for a percentagem de caminhos possíveis de código coberta por testes unitários – o chamado code coverage – maior é a indicação de garantia de qualidade do código como um todo.

Ferramentas:
JUnit, TestNG, DbUnit, Cactus, Atlassian Clover (code coverage)

Code Reviews

Ainda dentro dos mecanismos de controle que a própria equipe pode usar durante o desenvolvimento, encontram-se os code reviews. Devíamos fazer sempre code reviews,
embora seja aceitável que não tenhamos 100% do código revisto, apenas
uma boa percentagem. E esta boa percentagem é um equilíbrio entre o
esforço que a equipe tem a rever e a melhoria de qualidade percebida.

Ter este tipo de controle cria um tipo de peer pressure
na equipe. Ninguém é dono do seu pedaço de código, todos sabem que os
outros colegas vão validar o que escrevem, por isso vão ter um cuidado
extra no que produzem.

Desta forma más práticas e erros são detectados cedo no processo e toda
a equipe ganha, pois todos os membros aprendem com as
correções que são feitas, especialmente os membros menos
experientes que têm neste processo um mentoring por parte de toda a equipe.

Ferramentas:
Atlassian Crucible

Análise Estática

Ferramentas de análise estática permitem detectar erros e
standards no código de forma simples. Poucos programadores, ou mesmo nenhum, conseguem perceber alguns erros detectados por estas
ferramentas e não
são apanhados na grande maioria dos outros testes, por isso são uma
grande adição.

Ferramentas:
FindBugs (obrigatório!), Checkstyle

Sistema de builds / integração contínua

Builds automatizados é obrigatório! Muitos são os projetos hoje em
dia em que cada developer tem o seu próprio processo de build separado
no seu IDE.

Seguindo a regra de ouro de que quanto mais cedo se detecta um erro
melhor, o processo de builds pode e deve ser escalonado num motor de
integração contínua que permite rapidamente detectar quando um membro
da equipe quebra o build.

Igualmente importante é adicionar ao processo de build meios adicionais
de controle de qualidade na forma de plugins ou tasks extra – correr
testes unitários, gerar relatórios de code coverage, correr ferramentas
de análise estática de código, etc.

Ferramentas:
Ant, Maven, Ivy, Cuise Control, Hudson, TeamCity, Atlassian Bamboo

Equipa de testes / QA

Este ponto não é técnico, mas o considero importante. Em todos os
projetos em que trabalhei em Portugal, apenas uma vez trabalhei em uma equipe
de QA (Quality Assurance) organizada. Na maioria dos projetos
os testes de “qualidade” resumiam-se a fazer deploy da aplicação para
outro ambiente e ter alguém – muitas vezes da parte do cliente – para testar
ad-hoc a aplicação. E quem fazia estes testes era, muitas vezes, o
interessado em passar a aplicação à produção – muitas vezes o próprio
project manager da equipe.

É muito importante ter uma equipe, ou mesmo apenas uma pessoa, de QA,
que tem responsabilidades de testes em determinadas fases. É ainda mais
importante que esses membros não façam parte da equipe de
desenvolvimento, pois estariam com “maus hábitos”; nem da gestão de
projetos, pois vai querer é satisfazer o cliente; nem do cliente, que
simplesmente não vai testar devidamente e depois a culpa é da equipe.
Grande parte dos projetos têm baixa qualidade porque o desenvolvimento
para clientes envolve os tais “compromissos” entre qualidade e
tempo/dinheiro de que os PMs tanto falam.

Testes funcionais

Quer se tenha um processo de desenvolvimento em cascata ou iterativo, depois de cada release deve-se passar à fase de QA em que os
testes funcionais são executados.Estes testes devem ser feitos com base num plano de testes já elaborado
ou nos próprios requisitos do projeto – sejam eles use cases, user
stories ou outra coisa qualquer. Nestes testes o caráter específico de um membro QA entra em cena: o
espírito inquisitivo e a capacidade de interpretar os requisitos do
ponto de vista do utilizador.

Testes de carga

Num modelo de desenvolvimento iterativo, os testes de carga não
precisam ser feitos no fim de cada iteração, mas apenas em releases
major.
Duas perspectivas devem ser testadas: performance e escalabilidade.

Algumas ferramentas podem ser usadas para testar as duas perspectivas –
por exemplo, a aplicação que testa o tempo de invocação de algo pode
lançar x threads para testar como escala.

Para testar devidamente escalabilidade, deve ser levada em conta a
infraestrutura do projeto. Não é necessário replicar um ambiente de
produção, é aliás impossível, na maioria das vezes devido aos custos, mas
se em produção temos uma base de dados numa máquina e um aplication
server noutra, vamos deixá-los separados também para testes para ter em
conta todas as variáveis.

Ferramentas:
WebLoad, JMeter, Grinder

Testes de segurança

Uma das áreas menos testadas no desenvolvimento de aplicações web é
a segurança, normalmente até acontecer algo de mau. Mesmo a maioria dos
testers não sabem fazer testes de segurança, nem o que é uma ataque de Cross-Site Scripting (XSS). E mesmo a maioria dos developers não têm grandes cuidados com segurança além dos típicos ataques de SQL Injection. A falta de ferramentas é um dos grandes problemas nesta área.

Ferramentas:
WebScarab

Testes de UI

O teste mais básico de UI é ver se as coisas fazem rendering correto nos diferentes browsers. Validar automaticamente o código gerado de acordo com standards é também importante. Para facilitar o trabalho, existem diversos projetos de automatização de testes de UI.

Ferramentas:
Selenium, Watir, Windmill

Outros testes importantes são os de integração e de regressão.Todos estes pontos são bastante lógicos, penso eu. Tudo o que se
possa fazer para aumentar a qualidade final do que se desenvolve é
positivo. A qualidade deve estar na mente de todos e não ser uma moeda
de troca, razão da mediocridade de grande parte das aplicações feitas
para clientes que vi na minha vida profissional.

Qualidade custa também dinheiro, sim, mas o retorno é grande, tenho certeza.