O teste de software não é algo novo, mas, mesmo assim, ainda hoje, empresas preferem desenvolver sistemas sem uma metodologia com base em qualidade, veja a incoerência, quando se compra um carro, este passou por diversos testes, quando é fabricado um brinquedo, este também passa por testes, para saber que a tinta não é prejudicial às crianças, que os olhos não vão sair na boca da criança e assim por diante, e todos querem produtos de qualidade, então, por que isso não é aplicado ao Software?
A desculpa de não se testar o software, é que teste custa caro, mas Pressman já apresentou em seu Livro de Engenharia de Software que o custo do defeito é progressivo, ou seja, encontrar o defeito na fase de engenharia de requisitos custa 1 enquanto encontrar o defeito durante a fase de uso custa 100 vezes mais, então utilizar o teste, reduz custo e não aumenta.
Neste artigo, não adentraremos a fundo em todos os tipos de testes, mas vamos percorrer alguns e descrever ferramentas que possibilitem a realização destes testes, também será apresentado sempre a importância do tipo de teste apresentado para produto final.
Nas indústrias qualidade é algo percorrido há tempos, diversas metodologias surgiram, sempre com o objetivo de melhorar a qualidade ao mesmo tempo em que reduz custo, pois o custo do defeito pode ser desastroso, não só para as finanças, mas também para o nome da empresa, há diversos exemplos de defeitos que poderia ser citado aqui, mas um dos mais conhecidos e desastrosos é o incidente que ocorreu na década de 80, mais especificamente entre junho de 85 a janeiro de 87, o Therac-25, dispositivo computadorizado para tratamento por radiação para câncer, teve diversos equipamentos ministrando doses elevadas a pacientes, pelo menos 6 pacientes tiveram doses elevadas e alguns foram mortos outros incapacitados. O FDA (Food and Drug Administration) investigou o caso e descobriu um programa mal documentado, sem especificação e nem plano de testes, Frank Houston da FDA escreveu em 85 "Uma quantidade significativa de software para sistemas críticos para a vida vêm de pequenas empresas, especialmente na indústria de equipamentos médicos; empresas que enquadram no perfil daquelas que resistem aos princípios tanto da segurança de sistemas quanto da engenharia de software ou os desconhecem", notem a importância da qualidade do software?
Já se imaginou sendo você o paciente em tratamento em um equipamento com software que não foi testado adequadamente e os testes serão realizados quando você estiver sendo atendido?
Segundo Bastos et. al. Há três dimensões de qualidade que precisam ser consideradas:
Confiança: O sistema é resistente a falhas durante a execução, isto é, não entra em loop, não interrompe a execução por falta de recursos, etc.
Funcionalidade: o sistema se comporta conforme o esperado e definido em seus requisitos.
Performance: o sistema tem um tempo de resposta adequado e aceitável, mesmo quando submetido a um volume de processamento próximo de situações reais ou de pico?
E para atender as três dimensões, o desenvolvedor e o analista, tem uma nova tarefa, desenvolver com foco em qualidade, alem das dimensões, a equipe de análise e desenvolvimento pode fazer uso do tão conhecido ciclo PDCA: Planejar, Executar, Verificar, Agir.
Figura 1: Ciclo PDCA
Na etapa de planejamento, iniciamos com os requisitos, uma forma de melhorar o levantamento de requisitos, é dividir em partes menores, ao invés de os requisitos de todo o sistema, dividisse em partes entregáveis, e elicita-se os requisitos a ser entregue, os requisitos devem ser inspecionados e aprovados pelo cliente, para garantir que o que foi entendido é o que o cliente realmente deseja.
É possível aqui, a utilização de metodologias ágeis, desta forma o cliente participa ativamente do processo de desenvolvimento, corrigindo-se mais rápido ainda os defeitos.
Métodos ágeis são adaptativos ao invés de preditivos. Com os métodos tradicionais, o processo de software é planejado em detalhes por um longo período de tempo. Isso funciona bem se não houver grandes mudanças, o domínio da aplicação e as tecnologias de software sejam bem compreendidos pela equipe de desenvolvimento. Os métodos ágeis foram desenvolvidos para se adaptar as mudanças [Fowler 2000].
Mas por que as metodologias ágeis funcionam para os requisitos?
Funcionam, pois os requisitos devem refletir as necessidades do cliente, e como nas metodologias ágeis os clientes participam e recebem rapidamente produtos, é mais rápido a validação se o que foi desenvolvido esta em acordo com o que o cliente realmente precisava, aqui entra uma das premissas do manifesto ágil indivíduos e interações é mais importante que processos e ferramentas, ou seja, as interações têm importância para o desenvolvimento.
Métodos ágeis são orientados às pessoas ao invés de processos. Eles confiam na experiência das pessoas, na competência e na colaboração direta, do que em rigor dos processos centrados em documentos, para produzir software de alta qualidade [Fowler 2000].
O FDD é um dos métodos ágeis que podem ser utilizados na etapa de requisitos, ele funciona de forma simples e prática. Para saber mais sobre FDD Veja: https://www.devmedia.com.br/introducao-ao-fdd-feature-driven-development/27971
FDD é composto por cinco processos sequenciais. Os três primeiros são
Executados no início do projeto e os dois últimos durante cada iteração [Fowler 2000].
- Desenvolvimento de um modelo geral;
- Construção de uma lista de funcionalidades;
- Planejamento por funcionalidade;
- Projeto por funcionalidade;
- Desenvolvimento por funcionalidade.
Aqui temos os processos que podem ser utilizados na fase de requisitos: Um plano por funcionalidade, assim, pensamos nas funcionalidades a serem entregues ao cliente, como não é possível entregar tudo de uma só vez, dividi-se as funcionalidades que é possível desenvolver em um ciclo de desenvolvimento e inicia a fase de desenvolvimento por funcionalidade.
Depois de planejar a funcionalidade e definir o que será desenvolvido, é ai que entra uma das fases mais complexas, algumas metodologias podem ser utilizadas, como TDD, mas não será tratado aqui de metodologia para teste, que pode ser visto em: https://www.devmedia.com.br/tdd-fundamentos-do-desenvolvimento-orientado-a-testes/28151
Mas ao desenvolver, pode-se fazer testes antes ou depois de codificar, independente da metodologia utilizada, a utilização de um framework de teste unitário auxilia o processo de teste de codificação, aqui não se deve confundir o teste unitário com o debug do programa.
O teste unitário, serve para validar a menor porção do código, ou seja, a unidade, existem diversos frameworks para as mais diversas linguagens, basta procurar os frameworks Xunits, para testes unitários em Java veja : https://www.devmedia.com.br/introducao-ao-desenvolvimento-guiado-por-teste-tdd-com-junit/26559 e para testes unitários em PHP veja: https://www.devmedia.com.br/qualidade-em-desenvolvimento-web-php-com-teste-unitario/27550
O importante aqui é que os testes depois de desenvolvidos, pode ser utilizado diversas vezes, já que ele testa a funcionalidade, então, mesmo refatorando o código, é possível utilizar o mesmo teste, garantindo que não ocorreu uma regressão de funcionalidade durante as melhorias ou as integrações de módulos, assim, conforme Silveira et. al. “O teste de unidade ajuda o desenvolvedor a garantir a qualidade interna do código, dando feedback sobre o design dos módulos e permitindo uma manutenção com menor custo”.
Mas mesmo com os testes unitários, saber utilizar um bom debuger ainda é necessário.
Segundo Horstman "os depuradores ajudam a localizar erros deixando você acompanhar a execução de um programa. Você pode parar e reiniciar o seu programa e ver conteúdos de variáveis sempre que o seu programa tiver parado temporariamente. A cada parada, você pode escolher quais variáveis inspecionar e quantos passos do programa executar até a próxima parada. "
Normalmente os ambientes de desenvolvimento possuem depuradores, é importante para qualquer desenvolvedor aprender a utilizar os recursos dos depuradores e, desta forma, possibilitando a analise do comportamento das variáveis e funcionalidades.
É neste ponto que o desenvolvedor pergunta: utilizei uma boa metodologia para a analise, o cliente participa ativamente, criei os testes unitários e utilizei um bom debuger, então meu programa não tem erros?
Queria eu, poder afirmar que sim, mas não é verdadeiro, mesmo com todos estes passos, existem erros de usabilidade, erros de desempenho entre outros, mas vamos nos fixar agora em dois tipos de testes, que são importantes no processo de desenvolvimento o teste de performance e o teste de segurança.
Não tratarei como disse no inicio todos os tipos de testes, mas como já cobrimos uma parte da codificação, agora é importante saber se o que desenvolvemos vai rodar quando o cliente tiver 10, 20 ou 1000 usuários ao mesmo tempo no sistema, garantindo a disponibilidade do sistema em produção.
Muitas vezes vemos o sistema funcionando totalmente adequado e perfeito em nossa máquina de desenvolvimento, testamos exaustivamente e esta tudo funcionando perfeitamente bem, mas ao colocar em produção, o cliente fala: O sistema esta lento, demora muito, não da para utilizar este sistema pois é lento...
E por que isto ocorre?
Por que durante a fase de desenvolvimento e teste, a quantidade de pessoas utilizando o sistema é menor do que em produção. Então é interessante realizar testes de performances no sistema. Uma das melhores ferramentas para automatizar testes de performances e teste de carga de banco de dados é o Jmeter, que é um software livre criado pela Apache Foundation e que permite a realização de diversos testes, com uma vantagem, basta você realizar o processo uma vez, gravando os passos e programas a quantidade de vezes que deseja que o Jmeter realize o processo e quantos usuários que deseja que ele simule, pronto, ele pode realizar o teste de forma automatizada, claro que ele possui diversos outros recursos. Para criar um teste básico, este artigo apresenta o passo a passo de forma simples e prática: https://www.devmedia.com.br/usando-o-jmeter-para-teste-de-performance/32087
E por ultimo, os testes de segurança, a norma NBR/ISO/IEC 27002 indica que um dos pilares da segurança é a confiabilidade, o mesmo é indicado por bastos em seu livro de teste de software, isto demonstra a importância de se ter um sistema confiável, para garantir a confiabilidade os testes de segurança são de extrema importância.
Parte da confiabilidade já foi testada durante os testes unitários e os debugers, mas é importante garantir a segurança final do produto, evitando-se assim problemas de SQL Injections, Buffer de overflow etc.
Para testar SQL Injection e XSS, existe um plugin do Firefox chamado XSS-Me e SQL Injection ME que pode ser utilizado para realizar estes testes, alem destes há o https://www.owasp.org/index.php/WebScarab_Getting_Started do projeto Owasp e o Webgoat do mesmo projeto https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project.
Para scaneamento existe diversas, entre eles o paros, um software livre para a tarefa http://www.parosproxy.org/index.shtml e por ultimo e ainda mais importante o OpenVas que busca por vulnerabilidades em um sistema.
Em posse destas ferramentas, é possível melhorar a qualidade só software, e o tempo perdido no processo de teste é pequeno, visto que após a automação dos testes, ele pode ser executado diversas vezes de forma automática.
Conclusão
Neste artigo, foi apresentado teoria e técnicas de teste, de forma básica, mas concisa, com foco em processos práticos, a fim de apresentar aos novos desenvolvedores o caminho para um desenvolvimento com maior qualidade.
Referencial
- BARTIÉ, Alexandre. Garantia da Qualidade de Software: As melhores práticas de engenharia de Software aplicadas a sua empresa. São Paulo: Campus, 2002.
- BASTOS, Anderson; et. al. Base de conhecimento em teste de software. São Paulo: Martins Fontes, 2007.
- HORSTMANN, Cay. Conceitos de Computação com o essencial de C++. Porto Alegre:Bookman, 2005.
SILVEIRA, Paulo; et. al. Introdução à Arquitetura e Design de Software: uma visão sobre a plataforma Java. São Paulo: Campus, 2013.
