A tarefa de executar testes de
maneira manual está sujeita a fatores inerentes ao ser humano tais como
capacidade de concentração, humor, memória, saúde física e etc. Através de uma
analogia com a revolução industrial pode-se aprender com a história que o ato
de seguir roteiros de checagens e ações repetitivas é um processo que é
comprovadamente executado de maneira mais eficiente por máquinas. Por outro
lado o ato de planejar, analisar e explorar são tarefas que requerem raciocínio
e habilidades humanas. Assim sendo a automação de testes de software pode
encarregar-se dos roteiros de testes repetitivos e liberar o profissional para
que o mesmo possa pensar em situações de testes nunca antes investigadas. Além
do mais certos tipos de testes só podem ser executados de maneira efetiva se
forem automatizados, este é o caso de testes de volume, performance e carga aos
quais se submete um software qualquer com o intuito de se obter informações
para as seguintes perguntas:
● Qual a quantidade máxima de usuários
simultâneos suportados pelo sistema?
● Qual o volume máximo de dados
suportados pelo sistema?
● Qual o tempo de carregamento das
páginas relacionadas ao fluxo de compra?
A automação de teste de software é
atualmente a principal maneira para proporcionar a entrega de produtos mais
confiáveis em menor tempo [Myers 2004; Fewster 1999; Dustin 2002], e consiste
em repassar para o computador tarefas de teste de software que seriam
realizadas manualmente, sendo feitas por meio do uso de ferramentas de
automação de teste. A automação do teste consiste em repassar para o computador
tarefas de teste de software que seriam realizadas manualmente, sendo feita
geralmente por meio do uso de ferramentas de automação de teste. Testes manuais
consistem no desenvolvedor ou até mesmo o próprio usuário final utilizar o
sistema a fim de encontrar anomalias no funcionamento do software. É o tipo de
teste menos eficiente, pois dificilmente uma pessoa conseguiria testar
exaustivamente um sistema de forma que não restassem possibilidades possíveis
para falha. [BERNARDO, 2008] afirma que
a execução manual de um caso de teste é rápida e efetiva, mas a execução e repetição
de um vasto conjunto de testes manualmente é uma tarefa muito dispendiosa e
cansativa. Mesmo constatada tal fragilidade em relação à cobertura, testes
manuais ainda utilizados pela facilidade de aplicação, já que basta utilizar o
sistema como se estivesse em ambiente de produção, simulando algumas entradas e
registrando os resultados obtidos [ERDOGMUS, 2005].
Na opinião de [PFLEEGER, 2006] o
teste de regressão identifica novas falhas que podem ter sido introduzidas
enquanto as falhas atuais são corrigidas Já, para[ MYERS,2004] testes de
regressão são executados depois de realizada uma melhoria funcional ou uma
reparação em um programa, afirma ainda que são testes geralmente realizados re
executando-se um subconjunto de casos de testes no programa, e que sua
importância se dá em fuões tendem a ser muito mais propensas a acrescentar
erros do que a codificação original do programa. Segundo [PRESSMAN, 2002] teste
de regressão é a atividade que auxilia a garantir que mudanças no software não
introduzem comportamento não intencional ou erros adicionais. A partir desta
automação testes de regressão são realizados para verificar se manutenções
realizadas no sistema introduziram efeitos colaterais indesejáveis [PRESSMAN,
2002]. Os testes de regressão automatizados, além de diminuir drasticamente o tempo
total de execução do teste, viabilizam uma cobertura que, de outra forma, não
poderia ser realizada em tempo compatível com a necessidade do mercado atual.
A utilização de ferramentas de teste
é fundamental para o sucesso do projeto, no entanto, a tarefa de definição de
scripts de teste eficazes necessita de profissional qualificado. Além de
qualificação para definição do domínio dos testes, é necessário ainda domínio
da ferramenta utilizada e tempo para configuração de cada teste, assim como
análise dos resultados obtidos versusresultados esperados. A combinação desses
fatores é o fator complicador para aplicação de testes automatizados.Os custos
de testes de regressão, por exemplo, foram drasticamente reduzidos, bastando
para sua execução apenas rodar novamente os mesmos programas de teste. Como um
exemplo desta mudança, [HARROLD,2000] afirmava que testes de regressão consomem
até um terço do custo total de um software. Isto não faz sentido se levarmos em
consideração um processo automatizado de testes. Além disto, um processo de
testes onde apenas os testes de
regressão consomem um tempo tão grande do projeto podem não valer a pena serem
testados levando-se em consideração fatores econômicos do projeto.
Nenhum comentário:
Postar um comentário