Saiba mais sobre a etapa de testes na produção de aplicativos – e entenda por que as empresas estão cada vez mais interessadas nela

Por Aline Brandão

Se uma fábrica de pneus não submetesse seus produtos a uma bateria de testes, imagine como aumentaria o número de acidentes de carro. Os automóveis também passam por várias verificações antes de chegarem ao comprador. Textos acadêmicos e literários precisam passar pelas mãos de um revisor antes de serem publicados. Por que seria diferente com softwares? Para o Gerente de Desenvolvimento da 3Elos Segurança de Informação, Luiz Marques, isso é uma característica (ruim) da TI.

“Tradicionalmente os testes são deixados pra segundo plano, feitos de maneira insuficiente – diz.

A 3Elos é uma empresa relativamente jovem, especializada em serviços de segurança de software. Há cerca de 2 anos, a companhia passou a adotar um esquema formal de testes. Os resultados não demoraram a aparecer: os problemas foram descobertos mais rapidamente, a incidência de erros baixou e a qualidade dos produtos finais melhorou muito.

As várias etapas

Avaliações fazem parte de todo o ciclo de desenvolvimento de um software. Antes mesmo da produção do código, existe uma série de testes – chamada de Testes de Verificação – que envolve, entre outras responsabilidades, estudar os requisitos e a modelagem do aplicativo.

Após (ou mesmo durante) a codificação, vem a etapa da revisão de código. É um teste estático: avalia se o código está dentro das normas e padrões estabelecidos pela empresa, se usa as melhores práticas propostas para aquela linguagem e também a complexidade com que foi construído. “A verificação de código serve para ver se o trabalho foi produzido dentro dos padrões, não tem a obrigação de ver se ele realiza o que deveria realizar – explica o sócio-Diretor da RSI, Roberto Murillo.

A revisão de código é a última parte dos testes de verificação. Para realizá-la, os profissionais da área de testes contam com a ajuda de ferramentas específicas, muitas vezes voltadas para uma só linguagem. O processo funciona esclarecendo quais são as estratégias, normas e padrões da instalação, e com isso definindo parâmetros em softwares de teste. Nos resultados, essas ferramentas indicam se o código foi construído de forma ideal.

“Isso vai determinar se a manutenção desse programa será tranqüila, qual será a possibilidade de ele dar problemas e quantos outros testes nós teremos que fazer em cima desse código – diz Murillo.

Validação até o “test-drive”

Outros testes? Nas palavras de Murillo, “você pode ter um código construído da melhor maneira possível, mas que simplesmente não faz o que você quer.” Para isso existe a segunda fase da rotina de testes, a Validação. A esta fase pertencem os testes de unidade, de sistema e a validação funcional.

Testes de unidade podem ser aplicados ao longo do processo de codificação. Estes testes avaliam classes ou módulos do código, “quebrando” o trabalho em partes menores e facilitando a vida de quem está procurando erros. Segundo Luiz Marques, o conceito é bastante popular entre os adeptos do eXtreme Programming e também tem a ver com desenvolvimento orientado a objetos. “Se eu testo cada pedacinho de diversas formas, eu praticamente garanto que aquela parte vai funcionar. Quando você roda o teste em todo o código, a chance de erro diminui, porque você garantiu que aquele terreno estava firme – afirma.

Os testes de sistema servem para avaliar as configurações de sistema exigidas pelo aplicativo e os níveis de stress a que ele é resistente. O produto é testado em diferentes máquinas e sistemas operacionais. Quando o programa está tecnicamente perfeito, ainda há a validação funcional, para garantir que ele cumpre com todas as funções determinadas na verificação de requisitos – ou seja, se ele serve para o que deveria servir. Depois de tudo isso, a última etapa é o teste de “Aceite”: esse é o “test-drive” do programa, quando o cliente confere a homologação (simulação do ambiente de produção do aplicativo).

A bateria de testes também pode estar relacionada com a segurança do software. “A análise de segurança de código é um teste para verificar vulnerabilidades que possam estar relacionadas a falhas de programação – explica o Diretor-Executivo da E-VAL Tecnologia, Luis Gustavo Kiatake. A E-VAL oferece serviços de segurança para instituições financeiras, mas também desenvolve softwares internamente. Por isso, criou uma metodologia de controle de qualidade de seus produtos.

“Na área de qualidade a gente tem uma equipe que faz todos os testes de segurança e outra que cuida da interoperabilidade dos produtos. Um sistema de Internet Banking, por exemplo, vai ser usado em vários navegadores, vários sistemas operacionais, e você precisa garantir que ele vai funcionar para o usuário final – diz.

A área de qualidade da empresa também é responsável por todos os acabamentos finais do produto – inclusive a conferência e manutenção dos manuais. “Durante o desenvolvimento, o produto passa por vários testes de unidade. Quando chega na equipe de qualidade, dificilmente se encontra um erro técnico, que obrigue o produto a voltar. O que acontece mais é o pessoal de qualidade exigir especificações mais documentais, porque o pessoal do desenvolvimento geralmente não gosta muito de documentar... – explica Kiatake, rindo.

Quem é o Analista de Testes?

O profissional da área de testes tem que ter um perfil específico? Luiz Marques acha que não. “Acho que é parecido com o desenvolvedor, um cara detalhista, atento, que gosta de ficar direto no computador. Mas é claro que tem gente que parece ter ‘mão’ para isso. Acho que o desenvolvedor tem um perfil pessoal mais de construção, enquanto o cara que trabalha com testes está disposto a cercar o código por todos os lados em busca de furos – justifica.

Já Roberto Murillo ressalta que dentro da própria área de testes existem perfis profissionais diferentes. “Quem está dentro de verificação de requisitos, por exemplo, tem que ter mais foco em negócios, assim como quem trabalha na validação funcional. Na revisão de código e nos testes de unidade e sistemas, o profissional tem que ser mais da área técnica – explica.

Conscientização

Hoje, as empresas que se preocupam em ter um bom processo de testes podem dedicar de 15 a 20% do total do projeto nessa área. No entanto, a preocupação é bastante recente: começou a tomar corpo em 1999, com o bug do milênio, e ainda tem muito a amadurecer. “Não basta dizer que testou. O seu teste foi bom? O fornecedor precisa mostrar qual é sua metodologia, mas muitas empresas não sabem como avaliar isso. Muitas vezes a preocupação com o cronograma é maior do que com a qualidade – lamenta Kiatake.

“Todo mundo testa tudo o tempo todo na vida. Softwares também, mas os testes de software são subestimados. Teste não aumenta custo; pelo contrário, ele reduz, é um investimento. O problema é que ninguém tem computado os custos em manutenção de um produto ruim, os custos que uma falha de código gera em perda de imagem – diz Murillo.

Para Luiz Marques, o interesse pelos testes é uma evolução natural em toda ciência. “As pessoas vão amadurecendo em relação aos conceitos. Eles aparecem cedo no meio acadêmico, mas por conta de cronogramas, o mercado deixa de lado o que não é visto como essencial. Mas as pessoas já estão vendo que essa pressa tem seu custo: você consegue lançar a versão inicial rapidamente, mas depois gasta para corrigir problemas, sobrecarrega o suporte e fica com a imagem arranhada – afirma.

Matéria original
http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1201

Fonte: TI Master, janeiro 2007