Hoje muitas metodologias ágeis possuem grande parte de seu foco voltado para o teste de aceitação.... uma breve elucidação...
Testes
de Aceitação
Testes de
aceitação visam verificar se o que foi implementado atende corretamente ao
que o cliente esperava, ou seja, validar o sistema do ponto de vista do
cliente. Normalmente, estes testes são realizados através da interface de
usuário, que pode ser, por exemplo, um console textual, uma interface de uma
aplicação local ou uma interface Web. A escrita deste tipo de teste exige mais
do que chamadas de métodos e procedimentos. Para se testar uma funcionalidade é
necessário a simulação das ações de um usuário interagindo com o programa, isto
é, um clique do mouse, uma tecla pressionada, uma opção selecionada, entre
outras ações. Por isso é fundamental a utilização de arcabouços que consigam
abstrair as ações de usuário encapsulando o funcionamento interno das
interfaces para facilitar a escrita e manutenção dos testes de aceitação. Este
é um tipo de teste bem abrangente, pois envolve todas as camadas do sistema,
dependendo da modelagem correta da base de dados, do funcionamento correto dos
módulos internos do sistema, da integração entre eles e da interação do usuário
com a interface. Portanto,escrever bons testes de aceitação que verifiquem
adequadamente todos estes componentes é uma tarefa não-trivial que exige um bom
conhecimento e experiência
Os testes de
aceitação são especificações do comportamento e funcionalidade desejados para
um sistema. Eles nos informam como, para uma determinada estória de usuário ou
caso de uso, o sistema trata determinadas condições e entradas. Conforme
[KOSKELA,2007], um bom teste de aceitação deve ser:
●
Propriedade dos
clientes
●
Escrito em conjunto
com clientes, desenvolvedores e analistas de testes
●
Sobre o O Que
e não sobre o Como.
●
Expresso na
linguagem do domínio do problema
●
Conciso, preciso e
sem ambigüidades
[PRESSMANN, 2002] afirma que
a validação do software ocorre
mediante a execução de uma série
de testes de caixapreta com objetivo de demonstrar a conformidade com os
requisitos. Caso o software seja sob encomenda para um cliente, é efetuado o
teste de aceitação, no qual o cliente realiza a validação do software. Estes
testes realizados pelo cliente podem ser
informalmente conduzidos ou planejados e
sistematicamente executados. Para
[PFLEEGER,2004], o objetivo do teste de aceitação é assegurar ao cliente que o
programa solicitado é o que foi construído.
Para
softwares fechados, que
serão usados por vários clientes,
o autor indica a utilização dos testes
alpha e beta [PRESSMANN, 2002]. Os testes alpha são conduzidosem um ambiente
controlado, onde cliente interage com o software e o desenvolvedor registra os
erros e problemas de uso. Por sua vez, os testes beta consistem da interação do
cliente com o software em um ambiente não controlado, geralmente sem a presença
dos desenvolvedores.Os usuários registram os erros encontrados e relatam estes aos desenvolvedores, que irão efetuar as alterações necessárias e
liberar o produto de software para a base de cliente. Ao final do teste de
aceitação, o cliente informa quais requisitos não foram satisfeitos e quais
devem ser excluídos, revisados ou incluídos [PFLEEGER, 2004]. Segundo
[PRESSMAN, 2002] a validação de um
sistema pode ser definida de muitas maneiras, mas uma definição bem simples,
mas polêmica é que a validação de um sistema é bem sucedida quando o software
funciona de uma maneira razoavelmente esperada pelo cliente. Conforme
[MYERS,1979] um erro acontece quando o programa não funcionar de maneira
satisfatória conforme o esperado pelo usuário final. A validação do software é
realizada por uma série de testes de caixa preta, que verificam a conformidade
com os requisitos [PRESSMAN, 2002]
Para softwares de prateleiras,
também chamados de softwares fechados, são apresentados os testes alpha e beta
[PREESSMAN, 2002]. Os testes alpha são realizados pelo cliente nas instalações
do desenvolvedor, onde o software é utilizado em um ambiente natural, assim o
desenvolvedor pode acompanhar os passos realizados pelo cliente, registrando
erros e problemas de uso. Já o teste
beta é realizado pelos clientes nas suas instalações. Bem ao contrário
dos testes alpha, o teste beta o
desenvolvedor não participa dos testes, assim sendo o teste beta é realizado em um ambiente não
controlado pelo desenvolvedor, o cliente registra os erros e problemas
encontrados e após realizar os testes relata ao desenvolvedor. Frequentemente o
cliente relata funções para serem incorporados
ao sistema. O teste piloto envolve um subgrupo pequeno de usuários, são
escolhidos usuários de modo que suas atividades representem a maioria das
atividades daqueles que utilização o sistema posteriormente. No teste em
paralelo os sistemas desenvolvidos são operados em paralelo com a versão
anterior. Assim os usuários se acostumam gradativamente com o novo sistema, mas
ainda utilizando a versão anterior para duplicar as informações. Adquirindo
este processo de teste os usuários mais céticos adquirem mais confiança no novo
sistema verificando as informações no antigo e o cliente relata todos os
requisitos que não foram satisfeitos, quais devem ser excluídos, revisados ou
incluídos devido à necessidade de modificações [PFLEEGER, 2004].
Nenhum comentário:
Postar um comentário