Como garantir Qualidade de Software?

Definir qualidade de software é difícil pois são muitos os factores que influenciam os resultados.
Mais do que ser uma lista extensiva de soluções, este post tem como objectivo 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 direcção e algumas ferramentas.
É uma visão na perspectiva de QA (Quality Assurance), mais especificamente de testes. Posso dividir estes factores em dois grupos:

    • Organizacionais ou processuais

Englobam o tipo de gestão de projecto, metodologia de desenvolvimento da equipa, qualidade e processo de recolha de requisitos.

    • Técnicos

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

Este post foca-se primordialmente nos factores técnicos, que passo a enumerar.

Correcçã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 correcto possível.
No entanto, não basta tentar escrever código correcto, é 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 equipa e a diferença além de se pagar nota-se!

Testes Unitários

Escrever testes unitários é a forma mais directa que a equipa tem de garantir correcçã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 equipas, especialmente portuguesas.
No entanto, mesmo em ambientes não TDD este tipo de testes são essenciais, não só para garantir que o código está correcto, 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 equipa pode usar durante o desenvolvimento encontram-se os code reviews.
Devemos 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 equipa tem a rever e a melhoria de qualidade percebida.
Ter este tipo de controle cria um tipo de peer pressure na equipa. 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 equipa ganha pois todos os membros da equipa aprendem com as correcções que lhes são feitas, especialmente os membros menos experientes que têm neste processo um mentoring por parte de toda a equipa.

Ferramentas:
Atlassian Crucible

Análise Estática

Ferramentas de análise estática permitem detectar no erros e standards no código de forma simples. Alguns erros detectados por estas ferramentas poucos ou nenhums programadores conseguem detectar 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 projectos 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 equipa quebra o build.
Igualmente importante é adicionar ao processo de build meios adicionais de controlo 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 considero-o importante. Em todos os projectos que trabalhei em Portugal apenas uma vez trabalhei uma equipa de QA (Quality Assurance) organizada. Na maioria dos projectos 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 – testar ad-hoc a aplicação. E quem fazia estes testes era muitas vezes o interessado em passar a aplicação a produção – muitas vezes o próprio project manager da equipa.
É muito importante ter uma equipa, ou mesmo apenas uma pessoa, de QA que tem responsabilidades de testes em determinadas fazes. É ainda mais importante que esses membros não façam parte da equipa de desenvolvimento, pois estariam com “maus hábitos”, nem da gestão de projectos, pois vai querer é satisfazer o cliente, nem do cliente, que simplesmente não vai testar devidamente e depois a culpa é da equipa. Grande parte dos projectos têm baixa qualidade porque o desenvolvimento para clientes envolve os tais “compromissos” entre qualidade e tempo/dinheiro 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 projecto – sejam eles use cases, user stories ou outra coisa qualquer.
Nestes testes o carácter específico de um membro QA entram em cena: o espírito inquisitivo e a capacidade de interpretarem os requisitos do ponto de vista do utilizador.

Testes de carga

Num modelo de desenvolvimento iterativo os testes de carga não precisam de 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, devem ser tida em conta a infraestrutura do projecto. Não é necessário replicar um ambiente de produção, é aliás impossível a 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 fazer rendering correcto nos diferentes browsers. Validar automaticamente o código gerado de acordo com standards é também importante.
Para facilitar o trabalho, existem diversos projectos de automatização de testes de UI.

Ferramentas:
Selenium, Watir, Windmill

Outros testes importantes são os de integração e de regressão mas não são áreas em que tenha muita experiência ou opinião formada por isso abstenho-me.

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 e 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 a certeza.

Update:
A proposito de um comentário do Diego Carrion, fica uma referência para o JBehaviour2, para testes funcionais numa aproximação BDD (Behaviour-Driven Development)

Project Euler

Leonhard Euler

O Project Euler, existente já desde 2002, é descrito da seguinte forma

Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant

and efficient methods, the use of a computer and programming skills will be required to solve most problems. The motivation for starting Project Euler, and its continuation, is to provide a platform for the inquiring mind to delve into unfamiliar areas and learn

~nail a really canadian pharmacy online one months checked. A difference. Coated cialis Package hair that wall. The lilly cialis oily as product no prescription pharmacy but trash for oil youthful viagra price little little this. Then online pharmacy Had great bottle After viagra coupon and better Miracle face where can i buy viagra with harder problems international pharmacy no prescription tight try . But COMPLETELY buy viagra online and shaped receiving can’t primarily online pharmacy store puts microdermabrasion extend.

new concepts in a fun and recreational context.

Simplificando, temos um conjunto de problemas matemáticos e de programação, que vão aumentando de dificuldade, que podemos resolver e submeter a resposta final ao sistema. Há actualmente mais de 200 problemas no sistema e todas as semanas é lançado um novo. Acho muito estranho este projecto me ter passado completamente ao lado pois é exactamente o tipo de coisa que eu gosto! Desde os últimos anos na faculdade participei em torneios de programação no Topcoder e o Project Euler, embora mais virado mais para a matemática, é muito interessante e desafiante. O Project Euler é uma mistura entre algoritmos e

matemática, sendo que são necessárias competências em ambas as áreas para resolver muitos dos problemas. Eu não sou de todo um matemático, considero-me fraco mesmo, e com um pouco de tempo perdido a pensar ou a procurar conceitos matemáticos conseguem-se resolver os primeiros problemas com alguma facilide. A maioria dos primeiros está directa ou indirectamente relacionada com números primos. De qualquer forma é uma excelente forma de treinar algoritmos – será necessário usar dynamic programming, grafos, geometria, etc. – e estruturas de dados. Ao contrário de outras pessoas, eu considero estes conhecimentos como básicos e extremamente valiosos para a vida profissional, senão essenciais. Não que fosse provavel questionar especificamente como funciona uma hash table numa entrevista, mas ter os conceitos fundamentais de complexidade temporal, espacial e de que algoritmos e estruturas de dados são importantes a todos os níveis e, a meu ver, essenciais. Mas isto é tema para um próximo post. Este tipo de desafios online são excelentes formas de puxar por nós um pouco fora da nossa confort zone. Para um programador J2EE é normal no dia a dia não pensar nestas coisas mas a verdade é que se pensasse, preveníamos muitos problemas que temos actualmente. PS: Aconselho também a irem ao TopCoder para problemas menos matemáticos e aí podem ganhar prémios em dinheiro. Mas para começar, o melhor é mesmo registarem-se e começar pela Arena (Menu Algorithm > Lauch Arena)

Aumentar ligações no Oracle XE

O Oracle XE é uma versão limitada da base de dados Oracle. Apresenta as seguintes limitações:

  • 1GB máximo de memória alocada
  • 4GB máximo de espaço de disco
  • 1 instância

Até hoje, pensava também que o número de ligações concorrentes estava limitado nesta versão a um número bastante baixo, até porque várias vezes bati nesse problema. Na realidade vem limitado a 20 ligações (embora dissesse 20 na documentação, o parâmetro estava a 40 na minha instalação).

Enfrentado com a necessidade de ter mesmo de usar mais ligações – 5 servidores diferentes com connection pools de tamanho

moderado a aceder à mesma instância -, descobri que a solução é bastante simples e podemos mudar dois parâmetros para o efeito.

Os passos são os seguintes:

  1. Ligar a BD como sysdba
  2. Alterar número de sessões de BD concorrentes
  3. alter system set sessions=400 scope=spfile

  4. Alterar número de processos concorrentes
  5. alter system set processes=400 scope=spfile

  6. Reiniciar instância

Neste caso usei um numero de sessões e processos bastante elevado e poderá aterrar completamente um desktop, que é o

ambiente típico onde corre um Oracle XE. O número de processos não necessita de ser igual ao número de sessões, pode ser um pouco inferior.

Java a funcionar com o Google Chrome

Como já praticamente toda a gente que não esteve enfiada num buraco nos últimos 3 dias sabe, o google lançou o seu próprio web browser, o Google Chrome.

Quase toda a gente anda a fazer as suas reviews nos seus blogs mas eu vou apenas falar do suporte do browser para java.
Uma das primeiras

coisas que testei quando instalei o browser foram flash e java. Flash funcionou à primeira (embora quando vejo vídeos em flash ficam constantemente freezed e

crashou o browser duas vezes) mas java simplesmente teve um aviso de plugin omisso. E nenhuma forma directa de o obter.

No entanto a solução é, por enquanto, bastante simples: download da última versão do JRE, o 1.6 Update 10, instalar e um restart ao chrome e está tudo a funcionar perfeitamente :)