Artigo - Validação e Testes de Software

Prévia do material em texto

1. Introdução
2. Conceito de validação e verificação
	A Verificação é uma atividade, a qual envolve a análise de um sistema para certificar se este atende aos requisitos funcionais e não funcionais. Já a Validação, é a certificação de que o sistema atende as necessidades e expectativas do cliente. O processo de Validação e Verificação, não são processos separados e independentes.
3. Tipos de teste de software
Devido aos métodos de desenvolvimento e a complexidade dos softwares, é muito difícil dizer que estejam isentos da presença de erros. Os erros podem ocorrer por causa de problemas na especificação dos requisitos, no modo que a funcionalidade deve ser desempenhada, na complexidade do sistema e na mudança de requisitos. Todos os desenvolvedores estão suscetíveis a erros de programação, ainda mais em sistemas de alto nível de complexidade. Para isso, existe uma atividade em que se pode avaliar, testar e corrigir tais problemas. Este processo é chamado de Teste de Software, no qual é feito de diversas maneiras e usando diversas metodologias e que pode ser visto como uma parcela do processo que garante a qualidade de software. O teste deve ser feito com intenção de descobrir o maior número de erros possíveis, a seguir são apresentados alguns dos testes que podem ser feitos para descobrir e minimizar possíveis erros no software.
3.1 Teste unitário
	O teste unitário tem por objetivo mostrar que cada unidade atende corretamente a sua especificação, é uma forma de se testar unidades individuais de código fonte, essas unidades podem ser métodos, classes, funcionalidades, módulos, etc., depende muito de como é a menor parte do Software que pode ser testado.
3.2 Teste funcional
O teste funcional pode ser manual, realizado de forma automatizada ou uma mistura dos dois, e ele tem por objetivo testar os requisitos funcionais da aplicação, ou seja, verificar se a aplicação está apta a realizar as funções para a qual foi desenvolvida.
3.3 Teste de integração
É a parte do teste de software em que módulos são integrados e testados em grupo, por exemplo, ver se o software consegue acessar um banco de dados ou fazer uma chamada externa a outros sistemas.
3.4 Teste de segurança
O Teste de Segurança visa identificar as falhas de segurança de um software ou ambiente em que está sendo executado para poder avaliar as vulnerabilidades em aplicações e serviços frente a diferentes tipos de ataques de segurança que podem vir a ocorrer, além de sugerir correções ou melhores medidas de segurança.
3.5 Teste de performance
	O teste de performance consiste em avaliar a capacidade de resposta, robustez, disponibilidade, confiabilidade e escalabilidade de uma aplicação, conforme a quantidade de conexões simultâneas, avaliando seu desempenho em alta carga de trabalho e considerando seu comportamento em circunstâncias normais, com o objetivo de garantir que o software não apresente problemas ou indisponibilidade em condições de insuficiência dos recursos computacionais (como memória, processamento ou espaço em disco), quando trabalhando em alta concorrência.
3.6 Teste de aceitação
	O teste de aceitação é a última ação de teste antes da implantação do software. O objetivo do teste de aceitação é verificar se o software está pronto e pode ser usado pelos usuários finais para executar as funções e as tarefas para as quais foi criado. 
4. Metodologias de teste
4.1 Testes de caixa-preta, cinza e branca
Testes de caixa preta (black-box) são aqueles que são realizados do ponto de vista do usuário, ou seja, não há acesso por parte do usuário para que possa ser verificada a lógica de negócio implementada na aplicação através do código, nem o estado de recursos externos utilizados pela aplicação, como banco de dados ou arquivos de configuração. Testes deste tipo devem focar nas entradas fornecidas ao programa e nas saídas esperadas. Por exemplo, as entradas devem ser corretamente validadas, de forma a impedir, por exemplo, que em uma aplicação de vendas o usuário informe letras no preço de um produto (um valor que deve ser estritamente numérico). O processo que existe entre a leitura das entradas e a produção das saídas não deve ser considerado, de forma a não influenciar o teste.
Os testes de caixa cinza (grey box) são aqueles realizados por profissionais de qualidade de software dentro de um ambiente de testes, geralmente realizado logo após o desenvolvimento das funcionalidades do software por um ou mais desenvolvedores. O testador se coloca no ponto de vista do usuário, porém possui mais conhecimento do funcionamento da aplicação, sendo capaz de conferir informações em logs de erro e bancos de dados, e adaptar os testes conforme os dados observados. Em muitos casos, uma ou mais aplicações são integradas e trocam informações através de arquivos ou protocolos de comunicação. Diferente de um usuário, o testador grey box sabe como esta integração ocorre, e pode checar os dados que estão sendo enviado e recebidos na rede durante os testes com o intuito de assegurar que a aplicação funciona conforme previsto.
O teste realizado pelo desenvolvedor do software é conhecido como teste de caixa branca (white box). Neste tipo de teste, o testador é o próprio programador, que tem conhecimento das lógicas implementadas e que através de uma ferramenta de depuração (debugging) pode visualizar o estado das variáveis em cada momento da execução do programa e ajustar ou criar estruturas existentes no código de forma a fazer com que a aplicação produza as saídas esperadas. O desenvolvedor tem também acesso irrestrito a todos os recursos externos utilizados pela aplicação. Neste tipo de teste o foco deve ser assegurar que a aplicação trabalhe conforme o planejado e também que possa lidar melhor com situações inesperadas, como erros, bem como tratá-los, seja mostrando uma mensagem ao usuário para que ajuste as entradas fornecidas, seja realizando um processo interno para contornar esta situação e permitir que o usuário continue realizando suas tarefas.
4.2 Teste por amostragem
Muitas aplicações possuem uma gama de possibilidades de dados de entrada e variáveis a serem consideradas. Nestes casos, nem sempre todas as possibilidades podem ser testadas, visto que isto levaria muito tempo, seja em testes manuais ou automatizados. Frente a tal cenário, uma alternativa é a utilização de testes por amostragem. Em testes deste tipo, é usado o conceito estatístico de amostra, onde uma parcela dos casos é utilizada para representar todos os casos possíveis, assim como nas pesquisas eleitorais, por exemplo, uma parcela de alguns milhares de pessoas representa a intenção de voto de toda a população de um país.
Uma das formas de realizar um teste por amostragem durante o desenvolvimento é utilizar a técnica de emparelhamento de variáveis. Esta técnica trabalha com o conceito de que um bug geralmente não é causado pela modificação de um valor em uma variável, mas sim por uma combinação de valor entre 2 ou mais variáveis relacionadas. Neste cenário, basta identificar as variáveis que se deseja testar, e então testá-las com uma ampla gama de combinações, ignorando as demais. Isso ajuda a assegurar um grau de certeza de que a aplicação funciona conforme previsto, e ao mesmo tempo economiza tempo no processo de teste, focando apenas nas variáveis que realmente importam e não em todas.
Um exemplo onde testes deste tipo se aplicam seria uma aplicação de vendas que calcula os impostos de um item para a região onde o comprador reside, considerando o endereço de sua residência. Porém, o que não foi considerado é que nem sempre o comprador deseja receber o produto em sua casa. Caso a venda ocorra para um comprador que reside no Rio Grande do Sul, mas este informar um endereço de entrega em Minas Gerais, os impostos seriam calculados incorretamente. O que causa o erro é a interação entre 2 variáveis: os impostos no estado onde o consumidor reside e o estado do endereço de entrega, que tinha sido anteriormente desconsiderado. Testar a combinação entre estas variáveis seriao suficiente para identificar este bug, sendo que as demais informações sobre o comprador e a mercadoria poderia sem desconsideradas.
Outra forma de realizar testes por amostragem é simplesmente fornecer dados de entrada aleatórios a aplicação. Existe a probabilidade de que, após um determinado número de testes, um erro ocorrerá, e então será possível identificá-lo e corrigí-lo. É importante lembrar que o teste por amostragem não garante que todos os bugs serão encontrados, mas permite calcular um nível de confiança para a análise, ou seja, é possível garantir com certeza matemática que o programa terá uma determinada porcentagem de margem de erro.
4.3 ISO/IEC 9126
O ISO/IEC 9126 é um padrão internacional criado em 1991, e que tem como objetivo definir um modelo de qualidade para desenvolvimento e teste de software. Apesar de não definir na prática como estes testes devem ser realizados, o padrão descreve uma série de características que são essenciais para um software de qualidade.
Funcionalidade: O software possui um conjunto de funções que fazem o que é necessário para atingir o objetivo desejado.
Adequação: as funções foram criadas da forma mais adequada para atingir o objetivo desejado.
Precisão: as funções realizam a tarefa exatamente como descrito na especificação ou planejamento da aplicação.
Interoperabilidade: a aplicação e suas funções interagem de forma correta com um conjunto de sistemas especificados.
Conformidade: as funções da aplicação estão de acordo com normas e leis
Segurança: a aplicação e suas funções foram pensadas de forma a evitar uso ou acesso indevido ou não-autorizado.
Confiabilidade: capacidade do software de manter-se funcionando corretamente durante um determinado período.
Maturidade: frequência de falhas decorrentes de erros de software.
Tolerância a falhas: capacidade do software de fazer o tratamento de erros e continuar mantendo um nível de qualidade/desempenho mesmo quando erros ocorrem
Recuperabilidade: capacidade do software de voltar a seu nível normal de operação após a ocorrência de uma falha.
Usabilidade: esforço exigido do usuário para interagir com a aplicação, fornecendo entradas e recebendo as saídas
Inteligibilidade: compreensão por parte do usuário do conceito lógico e aplicabilidade da aplicação.
Apreensibilidade: esforço por parte do usuário para aprender a utilizar a aplicação.
Comportamento em relação ao tempo: tempo que a aplicação leva para fornecer respostas aos comandos do usuário.
Comportamento em relação aos recursos: quantidade de recursos utilizada pela aplicação e a influência que isso tem na experiência do usuário com a mesma.
Portabilidade: capacidade de adaptar uma aplicação para funcionar em múltiplas plataformas e tipos de hardware.
Adaptabilidade: capacidade de adaptar o software para funcionar em outro ambiente sem que seja necessário utilizar softwares adicionais ou meios externos para tal.
Conformidade: se o software segue as normas e padrões definidos para portabilidade
Capacidade para substituir: capacidade do software de substituir outro software que realize tarefa semelhante
Capacidade de instalação: facilidade em instalar o software
Coexistência: capacidade do software de coexistir com outras aplicações no mesmo ambiente
Manutenibilidade:
Modificabilidade: facilidade para fazer melhorias ou correções no software
Estabilidade: ocorrência de efeitos adversos inesperados causados por modificações
Testabilidade: esforço necessário para testar o software.
5. Automação de testes 
Atualmente, com o aumento da complexidade das aplicações e sua presença muitas vezes simultânea em diversas plataforma tornou o processo de testes algo ainda mais relevante. Porém, em muitos casos este pode ser longo, repetitivo e exigir a análise de diversos cenários e variáveis, o que aumenta o risco de falhas e equívocos por parte de um testador humano. Desta forma, muitas empresas de software estão optando por automatizar seus processos de teste através do uso de diversas ferramentas.
5.1 Vantagens e desvantagens
A principal vantagem da automação de testes e evitar falhas humanas. Ao longo de um processo minucioso e repetitivo, podem ocorrer equívocos por parte de um testador humano, que pode acidentalmente negligenciar determinado tipo de teste, ou realizá-lo de forma incorreta. Outra vantagem é o tempo de execução. Por ser executado por uma máquina, em muitos casos o teste será muito mais rápido do que quando executado por um humano. Além disso, um processo automático pode gerar, após seu término, um relatório das atividades realizadas, de forma que desenvolvedores e gestores possam acompanhar a eficácia dos testes.
Uma desvantagem pode ser o tempo necessário para implantar ou desenvolver uma ferramenta de automação de testes. Nisso inclui-se a infraestrutura de hardware (como um servidor específico para testes) e software (ferramentas de testes) necessários, bem como a parte humana (um testador treinado para escrever os testes), visto que a automação não descarta a necessidade de interação humana. Caso o software desenvolvido possua um conjunto pequeno de funcionalidades, em muitos casos pode-se optar por testá-lo manualmente.
5.2 Ferramentas utilizadas
Entre as ferramentas de automação de testes mais populares é a Selenium, um projeto open-source de servidor de automação de testes criado em 2004. Através deste servidor, é possível comunicar-se com o browser para executar testes automatizados em aplicações web, definindo em um script de teste ações a serem realizadas, como navegar até uma página, interagir com seus elementos ou fechá-la. A Selenium pode ser utilizada com aplicações criadas em linguagens como Java, JavaScript e C#, e usualmente é instalado um plugin em uma IDE (NetBeans ou Eclipse, por exemplo) para utilizá-la.
No contexto da linguagem Java, o framework de testes mais utilizado é o JUnit, segundo uma pesquisa realizada em 2013 com 10000 projetos hospedados no GitHub, serviço online de repositórios. Por ser um framework, ele permite a criação de classes e métodos dentro do projeto Java que são dedicadas a realização testes unitários. Durante a execução dos testes, os métodos contidos nestas classes são automaticamente executados.
Outra ferramenta semelhante é o Jenkins, que pode ser utilizada para automatizar qualquer tarefa relacionada ao desenvolvimento do software, como compilação (building), implantação no servidor, controle de versão e testes. O Jenkins suporta uma série de plugins, muitos dos quais são dedicados a realização de testes unitários e que geram relatórios de teste após a execução.
6. Desenvolvimento baseado em testes (TDD)
	Test Driven Development (TDD) ou em português Desenvolvimento baseado em testes é uma técnica de desenvolvimento de software que se relaciona com o conceito de verificação e validação.
 6.1 Funcionamento
		Desenvolvimento baseado em testes requer que os desenvolvedores criem testes de unidade automatizados que definam requisitos em código antes de escrever o código da aplicação. Os testes contêm asserções que podem ser verdadeiras ou falsas. Após as mesmas serem consideradas verdadeiras depois da sua execução, os testes confirmam o comportamento correto, permitindo aos desenvolvedores evoluir e refatorar o código, ou seja, o TDD se baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade e, então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis.
6.2 Vantagens e desvantagens
	Podemos destacar entre outras vantagens do TDD um melhor entendimento dos requisitos, já que primeiramente vamos escrever o teste que irá aceitar ou não a implementação, outra vantagem é que será um código mais limpo, melhorado, já que temos claramente uma etapa de refatoração, além de ter um melhor desenvolvimento dos métodos, já que escrevemos testes a nível unitário e implementamos também a esse nível.
Dentre aspossíveis desvantagens, a equipe de testes e desenvolvimento deve estar alinhada para que não haja sobreposição de testes, pois existe uma curva de aprendizado para os desenvolvedores, já que eles escrevem o teste e devem policiar sua execução, outra desvantagem é que deve ser gerada uma base de testes que pode onerar a execução de builds e deixar o processo mais lento.
7. Conclusão
Referências:
Use a cabeça - Desenvolvimento de software (livro)
BLAIN, Tyner. "SOFTWARE TESTING SERIES: PAIRWISE TESTING". Disponível em: <http://tynerblain.com/blog/2006/03/18/software-testing-series-pairwise-testing/>. Acesso em: 17/03/2018
RUGGIERI, Ruggero. "Análise sobre a ISO 9126 – NBR 13596". Disponível em: <https://www.tiespecialistas.com.br/2016/10/analise-sobre-iso-9126-nbr-13596/>. Acesso em: 17/03/2018
ISO - International Organization for Standardization. "ISO/IEC 9126-1:2001". Disponível em: <https://www.iso.org/standard/22749.html>. Acesso em: 17/03/2018
SEHLHORST, Scott. "Teste inteligente, não árduo – Parte 01". Disponível em: <https://imasters.com.br/desenvolvimento/teste-inteligente-nao-arduo-parte-01/>. Acesso em: 17/03/2018
WEISS, Tal. “We Analyzed 30,000 GitHub Projects - Here Are The Top 100 Libraries in Java, JS and Ruby”. Disponível em: <https://blog.takipi.com/we-analyzed-30000-github-projects-here-are-the-top-100-libraries-in-java-js-and-ruby/>. Acesso em: 17/03/2018
REGINATTO, Naise. "Por que automatizar testes de software?". Disponível em: <http://www.softdesign.com.br/blog/por-que-automatizar-testes-de-software/>. Acesso em: 18/03/2018
ANDERSON, Brian. "Best Automation Testing Tools for 2018 (Top 10 reviews)". Disponível em: <https://medium.com/@briananderson2209/best-automation-testing-tools-for-2018-top-10-reviews-8a4a19f664d2>. Acesso em: 18/03/2018
JENKINS. "Jenkins Automation Server". Disponível em: <https://github.com/jenkinsci/jenkins>. Acesso em: 18/03/2018
SELENIUM. "Selenium Web Browser Automation". Disponível em: <https://www.seleniumhq.org/>. Acesso em: 18/03/2018
JUNIT. "JUnit - About". Disponível em: <https://junit.org/junit4/>. Acesso em: 18/03/2018