Teste de Software Material Apoio AOL 1

Prévia do material em texto

Fundamentos de teste de software
Ao tratar do desenvolvimento de software, certamente vamos nos atentar a um requisito fundamental: os testes de validação. Porém o que podemos entender sobre teste? Segundo Sommerville (2011, p. 144), o teste tem a função de mostrar as funcionalidades de um programa e encontrar possíveis falhas no momento anterior ao seu uso. No momento em que o software é testado, o programa é executado, e os resultados almejados visam a encontrar erros ou informações de requisitos não funcionais pertencentes a ele.
Quando tratamos do nível de importância atribuído aos testes de software, e o seu impacto à qualidade, é necessária certa cautela. O desenvolvimento de sistemas de software requer um conjunto de ações ligadas à criação, na qual possíveis erros humanos poderão ficar em evidência. As falhas tendem a surgir no início do processo, pois os objetivos determinados podem estar erroneamente especificados, além de erros posteriores nas etapas de projeção e de desenvolvimento. Estas possibilidades fazem com que o desenvolvimento de software esteja ligado à garantia de sua qualidade (PRESSMAN, 1995, p.786).
É importante frisar que as atividades ligadas aos testes de software são consideradas elementos críticos da garantia de qualidade e simbolizam a análise mais recente de especificação, projeção e codificação. Tais ações vêm sendo propagadas graças ao crescente aumento do software na condição de componente de sistema e aos custos ligados aos erros de software. Normalmente, o projeto total em teste dispende de uma porcentagem relevante do esforço de uma organização de software. Só para citar um exemplo, uma atividade ligada a teste de software em sistemas relacionados à vida humana (um controle de voo, por exemplo), pode demandar um custo, muitas vezes, de três a cinco vezes maior em comparação à outras áreas de engenharia de software (PRESSMAN, 1995, p. 787).
Ao longo desta unidade, nós observaremos e discutiremos as características essenciais relacionadas às atividades de teste e as metodologias direcionadas ao projeto de casos de teste. Estas características estabelecem os objetivos presentes nos testes de software. Importante ressaltar que o projeto de casos de testes acaba se concentrando em uma série de métodos para o desenvolvimento de casos que consigam suprir os objetivos gerais estabelecidos pelas atividades de teste.
Para compreendermos como uma atividade de software se forma, é preciso levar em consideração o ponto de vista da engenharia de software, que analisa atividades como “anomalias”, de acordo com Pressman (1995, p.787), ao longo das etapas ligadas à definição e ao desenvolvimento realizadas anteriormente. Profissionais de engenharia normalmente tentam criar o software, a partir de um pensamento abstrato em uma implantação tangível. A partir daí, aparecem as etapas de testes e o aspecto curioso pode ser observado. O engenheiro ou engenheira desenvolverá um conjunto de casos de teste com a intenção de destruir o software construído. Na prática, as atividades de teste é um procedimento mais “destrutivo” do que “construtivo”.
O pensamento que devemos ter em relação ao desenvolvimento de software é que a atividade de teste exige descartar e superar uma série de conflitos que possam surgir no momento em que as falhas são observadas. Para evidenciar esta ideia, Beizer (1990 apud PRESSMAN, 1995, p. 428) diz que existe uma falsa conceituação de que se profissionais de programação fossem de fato muito bons não haveria a necessidade de buscar bugs.
Quando observamos os objetivos da atividade de teste, Myers (1990 apud PRESSMAN, 1995, p. 788) define um conjunto de normas que servem de objetivos. 
A primeira norma determina que a atividade de teste deve ser vista como um processo capaz de executar um programa com o objetivo de encontrar erros.
Na visão de Sommerville (2011, p. 145), este processo de teste visa também expor tanto a profissionais de desenvolvimento quanto a clientes que o produto software consegue atender suas solicitações. Vale ressaltar que para os softwares considerados “customizados” haverá ao menos um teste destinado a cada requisito, pertencente ao documento de requisitos. No caso dos chamados softwares “genéricos”, haverá testes para todos os aspectos do sistema, além das combinações estabelecidas, inseridas ao release do produto. Estes são exemplos de testes de validação, pelos quais o sistema é executado de maneira adequada, adotando uma série de casos de teste que simbolizam a utilização prevista pelo sistema.
Outra regra considera que um bom caso de teste apresenta probabilidade elevada de expor uma falha, mesmo que ainda não tenha sido revelada. Sommerville (2011, p. 144) frisa ainda que cabe ao teste de software observar possibilidades do software de se apresentar de forma incorreta e distinta das especificações definidas. Cabe aos testes de defeito eliminar os comportamentos inadequados do sistema. 
Na Figura 1, podemos observar as diferenças entre os testes de validação e de defeitos. Para ficar mais elucidativo, Sommerville (2011, p.145) traz o exemplo da caixa preta. Como funciona? O sistema se caracteriza por aceitar entradas através de uma série de entradas do tipo “I”, e criar saídas dentro de uma série de saídas do tipo “O”. Importante frisar que determinadas saídas se encontram equivocadas: elas fazem parte do grupo “Oe”, criadas pelo sistema respondendo a entradas estabelecidas no grupo “Ie”.
É importante deixar claro que a prioridade visualizada nos testes de defeitos é buscar as entradas estabelecidas no conjunto Ie, porque elas expõem questões relacionadas ao sistema. Os testes de validação, por sua vez, adotam testes com entradas mais adequadas que se encontram fora do Ie, que se caracterizam por estimular o sistema a criar adequadamente as saídas.
Estes objetivos (regras) apontam uma alteração robusta do ponto de vista. Eles indicam que um teste bem-sucedido não é aquele em que nenhuma falha é visualizada, e sim aquele que desenvolva testes que busquem, de maneira sistemática, as classes distintas de falhas em período e com esforço mínimos.
Caso a atividade de teste for direcionada com êxito, ela descobrirá os erros presentes no software. Outra vantagem em relação à atividade de teste indica que as funções de software estão sendo executadas, levando em consideração as especificações estabelecidas, com as quais os requisitos de desempenho são cumpridos, mesmo que aparentemente. Vale frisar também que os dados compilados, no momento em que a atividade de teste surte algum efeito, possibilitam a indicação de confiabilidade e de qualidade de software de maneira geral. Porém, estas atividades, assim como já tratamos, não podem esconder a presença dos bugs, ou seja, precisam apresentar os erros do software caso eles estejam presentes.
Outro aspecto que devemos frisar é o fato do teste fazer parte de um extenso processo de verificação e validação (V&V), que tem o objetivo de verificar se o software em desenvolvimento consegue atender às suas especificações e disponibilizar a funcionalidade aguardada por quem usará o software.
Esse processo começa no momento em que as solicitações estão disponíveis, e se mantém em todas as etapas do processo de desenvolvimento.
A verificação visa checar se o software consegue suprir as suas necessidades funcionais e não funcionais. Para Sommerville (2011, p. 145) a validação é um processo mais generalista, cuja função é assegurar que o software consiga suprir as necessidades de clientes. A validação é fundamental, pois as especificações de requisitos nem sempre suprem as demandas dos usuários do sistema.
EXPLICANDO
 Os processos de verificação e de validação têm o objetivo de determinar um nível de confiança garantindo que o software atenderá seus propósitos. O sistema precisa ser, dentre outros aspectos, das expectativas dos usuários.
A finalidade do software está relacionada ao seu nível de confiança, necessário para um software ser utilizado no sistema, atingir as expectativas de usuários, que já seacostumaram, de certa maneira, aos erros presentes no sistema, porém, com o amadurecimento do software, esperam que sejam realizados testes mais completos nas versões posteriores. É importante deixar claro que, no momento em que um sistema passa a ser comercializado, cabe a quem o vende considerar os produtos concorrentes, o preço de mercado e os prazos adequados de entrega (SOMMERVILLE, 2011, p. 146). Dentro de uma área mais competitiva, uma organização empresarial pode lançar produtos antes de serem testados e depurados.
O processo de verificação e validação (V&V) inclui inspeções e revisões responsáveis por avaliar e observar, dentre outros aspectos, os atributos do sistema. Podemos considerar estes aspectos como as chamadas técnicas “estáticas’” de V&V, que se caracterizam pelo fato do usuário não ter a necessidade de executar o software para analisá-lo. A Figura 2 apresenta as inspeções e testes de software que auxiliam o V&V em estágios distintos do processo de software; as setas apontam os estágios do processo, no qual as técnicas podem ser empregadas.
É preciso compreender que as inspeções se concentram no código-fonte de um sistema, principalmente;entretanto, seus requisitos ou modelos de projeto, de fato, podem ser inspecionados. Ao ser inspecionado o sistema, cabe ao usuário adotar todo o seu conhecimento sobre ele e a linguagem de programação adequada para observar os possíveis erros.
Segundo Sommerville (2011, p. 147), podemos observar basicamente três vantagens ou benefícios de utilizar a inspeção de software em relação aos testes:
No momento em que os testes são realizados, possivelmente alguns erros poderão impedir a visualização de outros erros. Isso gera algumas dúvidas, pois no momento em que um erro indicar uma saída inesperada, o usuário não terá certeza se as distorções posteriores serão provenientes de um erro novo ou efeitos do erro original. Sabendo que a inspeção consiste em um processo estático – não há a necessidade, por parte do usuário, de se preocupar com possíveis interações entre as falhas encontradas. Certamente, a conclusão a que chegamos é de que uma única sessão de inspeção é capaz de encontrar diversas falhas dentro de um sistema;
Existe a possibilidade das versões incompletas de um sistema serem inspecionadas sem o acréscimo de custos. Como isto funciona de fato? Caso um programa se encontre incompleto, é preciso criar mecanismos de testes específicos para realizar as análises das partes que se encontram disponíveis.
Além de ter a função de encontrar falhas em um programa, uma inspeção se caracteriza por levar em consideração outros requisitos de qualidade inerentes a um programa, como a portabilidade e a manutenibilidade (SOMMERVILLE, 2011, p.147). É possível que a usuária ou usuário encontre algum tipo de ineficiência que dificulte a manutenção e a atualização do sistema.
Vale ressaltar um aspecto importante: as inspeções não substituem os testes de software tradicionais. As inspeções não são adequadas, por exemplo, para encontrar falhas oriundas de interações realizadas em partes diferentes de um programa. Outro ponto é o fato da dificuldade em formar uma equipe de inspeção dentro de uma organização empresarial, já que normalmente as pessoas da equipe ocupam também a função de desenvolver softwares. 
A Figura 3 apresenta um modelo do processo de testes. Os casos de teste são conceituados como especificações presentes nas entradas do teste e da saída prevista pelo sistema. Além disso, é possível obter uma declaração dos componentes que estão sendo testados. É possível verificar que os dados de teste representam as entradas geradas para a realização dos testes no sistema, porém a execução destes testes pode ocorrer de forma automatizada. Os resultados previstos serão os resultados alcançados de forma automatizada, o que dispensa a busca por falhas na execução dos testes.
Outro aspecto que devemos mencionar se refere ao fluxo de informação da atividade que adota um padrão, conforme se visualiza na Figura 4.
Duas classes de entrada são disponibilizadas durante os processos de teste: a primeira classe trata da configuração de software, que insere uma especificação de requisitos de software, especificação do projeto, além do código-fonte; a segunda classe simboliza uma configuração de teste que se caracteriza por inserir um plano e um procedimento referente aos testes, além das ferramentas que serão empregadas e seus casos de testes com os resultados almejados. Uma configuração de teste é compreendida como um subconjunto pertencente à configuração de um software (PRESSMAN, 1995, p. 789).
DICA
Os testes são executados e os resultados analisados, ou seja, os resultados alcançados com os testes são relacionados aos resultados aguardados. No momento em que os dados com erros são expostos, é necessário dar início ao processo de depuração.
O processo de depuração trata da imprevisibilidade no processo de teste. Para se ter uma ideia, uma possível falha que indique um nível de discrepância entre os resultados desejados e os reais pode levar um tempo considerável para ser identificado e solucionado. Isso indica afirmar que a incerteza característica do processo de depuração torna a atividade de teste mais complexa e com a programação menos confiável.
No momento em que os resultados de testes forem agrupados e analisados, a apresentação de softwares com um nível mais elevado de qualidade e confiança começa a ser mais frequente. Quando a presença de falhas graves, que influenciam a alteração de projetos, passarem a ser cotidiano, certamente os níveis de confiança e qualidade será serão questionados, e automaticamente alguns testes adicionais serão recomendados. Por sua vez, se as funções designadas aos softwares forem executadas de maneira adequada, e as falhas visualizadas serem de fácil correção, é possível se chegar basicamente a duas conclusões, conforme Pressman (1995, p. 790): os níveis de qualidade e de confiança do software são adequados ou aceitáveis; ou os testes não são apropriados para descobrir falhas mais complexas.
Precisamos ter em mente, como regra geral, que, se a atividade de teste não encontrar nenhuma falha, é de se concluir que a configuração de teste não foi devidamente elaborada, e que os erros serão expostos pelo usuário e solucionados por quem desenvolve no momento da manutenção, quando normalmente os custos se elevam.
Precisamos ter em mente, como regra geral, que, se a atividade de teste não encontrar nenhuma falha, é de se concluir que a configuração de teste não foi devidamente elaborada, e que os erros serão expostos pelo usuário e solucionados por quem desenvolve no momento da manutenção, quando normalmente os custos se elevam.
Os resultados que foram se acumulando ao longo da atividade de teste também podem ser analisados de uma maneira mais formalizada. Os tipos de confiabilidade do software normalmente utilizam dados que representam o percentual de falhas para evitar uma ocorrência destes mesmos erros no futuro. Na Figura 1 observamos que cada círculo simboliza uma mudança com alto grau de complexidade.
Quando se fala em desenvolvimento de software, não podemos esquecer de mencionar o projeto de casos de testes. O projeto de teste de software pode ser visto como um desafio, assim como o projeto elaborado inicialmente do próprio produto. Entretanto, assim como já visualizamos, as atividades de testes são tratadas por boa parte de profissionais de engenharia de software como uma espécie de análise tardia ao criar casos com resultados previsíveis e de baixa garantia de totalidade. As atividades de teste visam projetar, dentre outros aspectos, testes com elevada capacidade de descoberta de erros em tempo e com esforço mínimos.
Houve uma época em que uma diversidade de técnicas de projeto de casos de teste se transformou em um software. Essas técnicas disponibilizam a profissionais de desenvolvimento uma abordagem mais sistemática dos testes, o que significa dizer que elas oferecem uma metodologia que auxilia a integridade do teste e permitealta chance de expor as falhas encontradas no software.
Segundo Pressman (1995, p. 791), independentemente do produto ou serviço projetado pelo engenheiro ou engenheira de software, as duas formas de testá-lo são: tendo conhecimento da função determinada que precise realizar o produto ou serviço, sobre o qual os testes podem ser executados para comprovar que cada função é feita operacionalmente; e conhecendo como funciona internamente um produto, permitindo que os testes sejam realizados para assegurar que a operação interna do produto apresente um comportamento adequado às suas especificações.
Neste contexto, vamos nos deparar com duas conceituações referentes à abordagem de teste: o teste de caixa preta e o teste de caixa branca. Vamos tratar de cada um deles.
Levando em consideração um software inserido no computador, o termo “teste de caixa preta” trata dos testes feitos dentro das interfaces de um software. Este teste tem o objetivo de localizar possíveis erros, porém, além desta funcionalidade, ele é empregado para comprovar que as funções atribuídas aos softwares são operacionais, ou seja, a entrada é aceita de maneira adequada assim como a saída produzida corretamente, além de garantir a integridade das informações de origem externa. Este modelo de teste, contudo, não precisa necessariamente a estrutura lógica interna do software que venha a ser adotada.
No que se refere ao teste de caixa branca, ela se baseia em uma série de detalhes no procedimento. São testados os caminhos lógicos por meio do software, disponibilizando casos de teste que colocam à prova grupos específicos de condições ou laços (PRESSMAN, 1995, p. 792).
Em um primeiro momento, a impressão que fica é de que um teste de caixa branca, se executado com cautela, pode gerar a totalidade de programas correta, ou seja, basta que sejam definidos os caminhos lógicos, desenvolver os casos de teste, testá-los e analisar os resultados alcançados, gerando casos de testes para colocar a lógica do programa em uma prova exaustiva. Tudo certo? Infelizmente não, pois os testes exaustivos revelam problemas logísticos. Isso ocorre porque a quantidade de caminhos logísticos possíveis pode ser extensa, mesmo para programas de menor porte.
A Figura 5 representa um projeto procedimental correspondente a um programa Pascal, que contém 100 linhas disponibilizando um laço único, que pode ser realizado no máximo 20 vezes. Isto indica que algo próximo de 10¹4 caminhos pode ser, de fato, realizado (PRESSMAN, 1995, p. 792). É essencial, porém, que o teste de caixa branca não seja visto como algo pouco usual, pois uma quantidade restrita de caminhos lógicos essenciais pode ser escolhida. As estruturas de dados importantes podem ser avaliadas levando em consideração a validade, e os atributos presentes nos testes de caixa branca ou preta tendem a ser combinadas, visando disponibilizar uma abordagem que torne a interface validada com o software e assegure, de maneira seletiva, e que o funcionamento interno esteja plenamente adequado.
Desenvolvimento de software e teste de software
Você já parou para analisar o que significa um projeto e como ele é constituído? Um projeto é formado por um conjunto de procedimentos constituídos por uma série de atividades executadas de forma organizada. Normalmente, um projeto trata da criação de um produto ou serviço. Se associarmos este conceito ao desenvolvimento de um software, perceberemos que este produto é intangível e que apresenta uma série de variações complexas, o que dificulta sua criação e qualificação.
Neste contexto, é essencial a inclusão de temas que tratem da engenharia no que diz respeito ao desenvolvimento de software, pois ela permite a uma gestora ou gestor conseguir fortalecer as práticas para desenvolver um produto de software que atenda algumas normas de qualidade, abrangendo basicamente três áreas essenciais: as técnicas adotadas, as ferramentas e os procedimentos.
Um processo relacionado ao de desenvolvimento de software é definido como uma série de atividades padronizadas e organizadas, que estabelecem, desenvolvem, avaliam e mantêm um software. Por sua vez, objetiva, dentre outros aspectos, determinar as atividades a serem realizadas, o momento em que elas serão executadas, quem irá realizar estas tarefas e qual o nível de padronização adotado ao longo do desenvolvimento de um software.
É possível visualizar uma variedade de processos de desenvolvimento de software, porém existem algumas atividades consideradas fundamentais à boa parte dos processos disponíveis.
A primeira atividade a ser realizada é de levantamento de requisitos, que tem como objetivo ter uma noção geral do problema, a partir do qual profissionais e usuários vão compartilhar visões para a solução do problema encontrado. Neste cenário, profissionais e clientes irão atuar de maneira conjunta para coletar e dar prioridade às necessidades ou requisitos dos próximos usuários do software no futuro.
Além disso, é preciso perceber que o levantamento de requisitos é fundamental, também, porque trata de uma atividade essencial: o retorno de investimentos no projeto. Diversos projetos são descartados por conta do baixo levantamento de requisitos adotado, o que indica a atuação deficiente dos membros da equipe que não apresentaram um tempo necessário para executar essa fase do projeto, além de não entender as reais demandas dos clientes levando em consideração o sistema criado.
Você pode se questionar: por que as necessidades de clientes são tão importantes? É preciso entender, por exemplo, que estamos tratando de um sistema de informações com o objetivo de automatizar alguns processos de negócios dentro de uma empresa. 
Você pode se questionar: por que as necessidades de clientes são tão importantes? É preciso entender, por exemplo, que estamos tratando de um sistema de informações com o objetivo de automatizar alguns processos de negócios dentro de uma empresa. 
Esses procedimentos precisam estar alinhados com as outras tarefas para que as atividades do processo de desenvolvimento estejam de acordo com as necessidades reais de clientes.
A fase seguinte consiste na análise de requisitos, também conhecida como especificação de requisitos. Mas o que seria esta “especificação”? É neste momento que profissionais irão avaliar detalhadamente os dados coletados na fase anterior e começar a desenvolver modelos que simbolizem o sistema de software que será desenvolvido. Compreender de maneira total os requisitos de software é essencial para um desenvolvimento de software bem feito. Segundo Pressman (1995, p. 231), não importa se um programa é bem projetado ou codificado se ele for mal avaliado ou especificado, pois isso trará uma série de problemas a quem o desenvolve.
A missão de avaliar os requisitos consiste em um trabalho que envolve quatro ações básicas: o processo de busca, o refinamento, a modelagem e a especificação. O escopo de software é melhorado constantemente nos seus detalhes. Neste contexto, os modelos de fluxo de informação, além do controle requisitado, são criados, e as soluções opcionais são avaliadas e inseridas a diversos componentes do software. Esta atividade é responsável por desenvolver uma estratégia de resolução e não o método que será utilizado, ou seja, primeiro se identifica as necessidades de clientes, e só depois se pensa na metodologia adequada para solucionar esta questão.
CONTEXTUALIZANDO
Analisar requisitos permite ao engenheiro ou engenheira de sistemas especificar a função e o comportamento do software, apontando a interface do software aliado a outros componentes do sistema, e definir quais as limitações impostas ao projeto adotado.
Existe a crença de que analisar e especificar requisitos consiste em uma tarefa simples. Porém não é; há uma série de situações que tornam esta atividade extremamente complexa. Para Pressman (1995, p. 231), a comunicação extensa, as possibilidades de interpretações erradas e a ambiguidade são algumas situações que podem tornar a análise de requisitos mais complexa.
Diante destecenário, qual a barreira para analisar os requisitos? O que geralmente acontece é que as equipes responsáveis pelo desenvolvimento direcionam seus trabalhos para solucionar os problemas de softwares sem ao menos entenderem quais são os problemas em questão. É nesta etapa que se realiza o processo que tratamos na seção anterior: o V&V (validação e verificação) dos modelos desenvolvidos, antes da solução do problema em si. A validação visa garantir que o sistema de software consiga suprir as necessidades efetivas de clientes. A verificação observa se os modelos desenvolvidos na análise estão de acordo com as mesmas necessidades.
Quem desenvolve, assim como clientes, exerce uma função ativa na avaliação e especificação dos requisitos, ou seja, cabe a clientes, por exemplo, a função de reformular um conceito referente à função e a performance de software de maneira detalhada. Já o papel da desenvolvedora ou desenvolvedor é agir como uma espécie de pesquisadora ou pesquisador, questionando e apresentando soluções para os problemas (PRESSMAN, 1995, p. 231).
A análise de requisitos de software, para uma melhor conceituação, pode ser divida em cinco subáreas. Segundo Pressman (1995, p. 232), elas são: identificação de problema, avaliação e síntese, modelagem, especificação e revisão. No início, a analista ou o analista normalmente estuda a especificação do sistema, além do plano de projeto de software. Vale ressaltar que é essencial compreender a atuação do software dentro de um cenário sistêmico e reavaliar o escopo de software utilizado para criar expectativas de planejamento. Em seguida, é necessário definir o nível de comunicação com a tarefa de análise, visando assegurar a identificação do problema.
Analistas precisarão manter contato com a equipe técnica da organização assim como a equipe responsável pelo desenvolvimento de software. Cabe à gerente ou ao gerente de projeto exercer a função de coordenar para simplificar a abertura dos caminhos comunicativos e às analistas ou aos analistas a função de identificar os componentes que apresentam problemas reconhecidos por clientes (PRESSMAN, 1995, p. 233).
O resumo de análise e resolução de questões é a maior área de esforço seguinte. Normalmente, analistas conseguem analisar o conteúdo e o fluxo informacional, além de estabelecerem as funções e o comportamento do software, definirem os aspectos de interface e visualizarem limitações presentes no projeto. De acordo com Pressman (1995, p. 233), cada atividade dessas tem a função de descrever o problema de forma que a solução geral seja sintetizada.
Chegamos à etapa na qual é possível visualizar como o sistema irá funcionar internamente, visando atender os requisitos de clientes. É o passo inicial para realizar o desenvolvimento de qualquer produto ou sistemas ligados à engenharia. 
Nesta etapa, devemos levar em consideração alguns aspectos essenciais, tais como a arquitetura do sistema, a linguagem de programação adotada, as características do sistema gerenciador de banco de dados (SGBD) utilizado, entre outros.
É no projeto que a descrição computacional é apresentada e o usuário fica sabendo o que o software deverá realizar, lembrando que esta descrição deve estar alinhada com a descrição executada na análise de requisitos. Ao utilizar um dentre um conjunto de métodos existentes, esta fase é capaz de produzir os chamados projetos de dados, arquitetural e o procedimental. Vamos visualizar cada um deles.
Segundo Pressman (1995, p. 416), o projeto de dados é capaz de transformar o modelo de domínio de informação, desenvolvido durante a avaliação das estruturas de dados, que serão solicitadas, para a implementação do software. Já o projeto da arquitetura se caracteriza pela distribuição das classes de objetos ligados ao sistema presente em subsistemas e componentes, que são partilhados através dos recursos de hardware apresentados. Por sua vez, o projeto procedimental altera os elementos estruturais em uma descrição procedimental do software. Nesta situação, o código-fonte é desenvolvido e as atividades de teste são utilizadas para a integração e a validação do software.
Na Figura 6, visualizaremos o fluxo de informações realizado ao longo da etapa técnica do processo referente à engenharia de software. A etapa do projeto é abastecida pelos requisitos do software que são indicados por modelos comportamentais, entre outros.
Segundo Pressman (1995, p. 415), o objetivo de qualquer projetista é criar modelos ou simbolizar qualquer um que seja desenvolvido posteriormente. Vale ressaltar que o procedimento pelo qual o modelo é criado é fruto de uma combinação que envolve alguns aspectos, como:
Intuição e análise com base na experiência de desenvolver entidades parecidas;
Princípios que norteiam a forma pela qual o modelo é desenvolvido;
Critérios que permitam que a qualidade seja avaliada;
Interação que leve a uma representação do projeto final.
O projeto de software muda de forma contínua assim que novos métodos e análises mais assertivas vão se desenvolvendo. Vale frisar que o projeto de software ainda vem em um estágio inicial de evolução, portanto ainda falta uma metodologia mais definida.
O projeto de software pode ser inserido independentemente do paradigma de desenvolvimento utilizado. Ao dar início aos requisitos de software, já avaliados e especificados, Pressman (1995, p. 416) afirma que o projeto consiste na primeira atividade técnica exigida para o desenvolvimento e a análise de um software, ou seja, cada atividade vai alterar informações de maneira que o resultado será um software de computador validado.
Os conceitos relacionados à engenharia de software abrangem tarefas relacionadas à criação de software, dos requisitos, até o gerenciamento do sistema instalado. Dentro deste contexto, a fase considerada mais crítica neste processo se refere à implementação do sistema, que é responsável por criar uma versão executável do software. Segundo Sommerville (2011, p. 135), a implementação aborda o desenvolvimento de programas, independentemente do nível de linguagens de programação utilizado.
Nesta fase, o sistema será codificado, levando em consideração a descrição computacional da etapa do projeto, inserido em outra linguagem, na qual é permitido compilar e gerar o código executável, visando o desenvolvimento do software. Vale ressaltar, por exemplo, que, em um processo de desenvolvimento orientado a objetos, o processo de implementação ocorre quando se definem as classes de objetos do sistema e se adotam linguagens de programação, como Java.
As ferramentas de software e bibliotecas de classes existentes para acelerar a execução podem ser adotadas na fase da implementação. O uso da ferramenta CASE, por exemplo, auxilia na dinamização do processo de desenvolvimento.
De acordo com Sommerville (2011, p. 136), determinados aspectos referentes à implementação são essenciais para a engenharia de software, e que geralmente não são abordados em textos de programação. São eles:
REÚSO
GERENCIAMENTO DE CONFIGURAÇÃO
DESENVOLVIMENTO HOST-TARGET
Os softwares mais modernos são formados através do reúso de elementos existentes ou por conta dos sistemas. No momento em que um software for desenvolvido, é preciso utilizar, de maneira extensiva, os códigos já existentes;
Quando tratamos de implementação, é preciso falar de projeto orientado a objeto. A fase de projeto orientado a objeto detalhado (Object-Oriented Design – OOD) é parecido com os projetos de detalhes que utilizam qualquer metodologia de projeto de software. As interfaces normalmente são descritas de forma detalhada, assim como as estruturas de dados, que são mais refinadas e específicas. Neste contexto, os algoritmos são descritos para cada unidade de programa utilizando conceitos de projetos essenciais (PRESSMAN, 1995, p. 546).
O projeto detalhado se diferencia do projeto orientado a objeto, pois ele pode ser inserido de maneira recursiva a qualquer momento. A definição recursiva da estratégia de solução é fundamental para alcançar um nível de projeto e abstraçãode dados, no qual os detalhes referentes à implementação possam ser de fato derivados.
Várias atividades de testes são realizadas com o intuito de validar o produto de software. Isso ocorre quando testes são executados a cada funcionalidade pertencente aos modelos, considerando a especificação realizada na etapa de projeto. O relatório de testes é o resultado mais imediato, pois apresenta um conjunto de informações importantes sobre as falhas visualizadas no sistema além da sua performance em diversos. Ao término da atividade, diversos módulos do sistema são integrados, o que vai desencadear no produto de software.
Normalmente, um sistema de software disponibilizado comercialmente atinge três níveis ou estágios de testes, sobre os quais trataremos com maior detalhamento nas seções posteriores. São eles:
Testes em desenvolvimento
Testes de release
Testes de usuário
Se observarmos o processo de teste, na prática, veremos que ele normalmente adota uma mescla de testes manuais e automatizados. Segundo Sommerville (2011, p. 147), o teste manual se caracteriza pelo fato do avaliador ou avaliadora executar o programa utilizando um conjunto de dados de teste e comparar os resultados obtidos com as suas previsões, a quem cabe verificar e informar as possíveis distorções aos desenvolvedores do programa. Já os testes automatizados se caracterizam pelo fato dos testes estarem codificados em programas executados toda vez que houver testes realizados em sistemas em desenvolvimento.
Geralmente, o teste automatizado é realizado de maneira mais rápida em relação ao manual, principalmente quando se tratam de testes de regressão, nos quais testes anteriores são executados novamente com o intuito de verificar se as mudanças no programa não inseriram novos bugs.
Vale ressaltar que a utilização de testes automatizados tem sido constante ao longo do tempo. Porém, mesmo com sua extensidade, os testes jamais poderão ser automatizados na sua totalidade, pois estas modalidades de testes se limitam a verificar se um programa realiza aquilo que é proposto, ou seja, é impossível utilizar esta modalidade de teste, por exemplo, para verificar se um programa apresenta efeitos colaterais indesejados (SOMMERVILLE, 2011, p. 147).
Níveis de teste
Os testes são inseridos em destinos diferentes, em estágios distintos ou em níveis que exigem certo esforço de trabalho. Normalmente, esses níveis se diferenciam por conta destas funções, que são habilitadas de maneira mais efetiva para conduzir e projetar testes, nos quais as técnicas utilizadas são mais apropriadas para testes de cada nível. Diante disso, é essencial garantir um equilíbrio que seja mantido em esforços de trabalho diferentes. Nas subseções a seguir, verificaremos os principais níveis de testes adotados e os seus aspectos fundamentais.
TESTE DE DESENVOLVIMENTO
Quando tratamos de níveis (estágios) de testes, de imediato é preciso falar sobre o teste do desenvolvedor. Esta modalidade de teste se caracteriza por incluir todas as atividades de testes executadas pela equipe responsável pelo desenvolvimento do sistema. 
Quando tratamos de níveis (estágios) de testes, de imediato é preciso falar sobre o teste do desenvolvedor. Esta modalidade de teste se caracteriza por incluir todas as atividades de testes executadas pela equipe responsável pelo desenvolvimento do sistema. 
Normalmente, o responsável pelo teste do software é o próprio programador ou programadora que o criou, apesar das exceções. Determinados processos de desenvolvimento adotam programadores-testadores de maneira pareada, para os quais cada programador apresenta um testador relacionado para criar testes e auxiliar no processo. Em relação aos sistemas críticos, é preciso adotar um procedimento mais formalizado por uma equipe de testes independente atuando em uma equipe responsável pelo desenvolvimento, que cuidará do desenvolvimento de testes realizados e pela manutenção dos seus resultados. 
Segundo Sommerville (2011, p. 148), ao longo do desenvolvimento, o teste pode ser executado basicamente em níveis de detalhamento: testes unitário, de componentes e de sistema. Verificaremos cada um deles. 
TESTE UNITÁRIO
O teste unitário é o primeiro nível, e se caracteriza pelo fato dos elementos de programa ou até mesmo as classes de objetos serem avaliadas de maneira individualizada. Esta modalidade de teste foca na verificação da funcionalidade dos objetos ou da metodologia adotada.
No momento em que se testa as classes de objeto é preciso planejar os testes para suprir as características do objeto. Neste contexto, é necessário que o usuário teste todas as operações que estão relacionadas ao objeto, além de estabelecer e observar os valores de todos os atributos ligados ao objeto, e, por fim, inserir o objeto em todas as possibilidades de estado, simulando as possíveis situações que causam as suas alterações.
Recomenda-se, sempre que possível, automatizar os testes unitários. A explicação para isto vem do fato de que, na automatização, é possível utilizar um framework de automação de teste, com o objetivo de redigir e realizar testes dentro do seu programa. Os frameworks destinados aos testes unitários disponibilizam classes de teste gerais, as quais o usuário pode aumentar para desenvolver casos de teste mais exclusivos. Diante deste cenário, é possível realizar os testes implementados e informar sobre o status (o sucesso ou o fracasso) dos testes executados.
Uma série completa de testes geralmente pode ser realizada em segundos. Sendo assim, existe a possibilidade de executar os testes toda vez que o programa sofrer algum tipo de alteração.
Para Sommerville (2011, p. 149), um teste automatizado consiste basicamente em três partes: a da configuração, na qual o usuário dá início ao sistema com o caso de teste, indicando as entradas e saídas previstas; a chamada, que se caracteriza pelo fato do usuário chamar o objeto ou o método que será testado; e a afirmação, em que o usuário estabelece comparações do resultado da chamada com o resultado previsto, ou seja, se a afirmação analisada for considerada verdadeira, podemos considerar o teste bem-sucedido. Caso contrário, o teste será considerado falho.
Outro detalhe fundamental quando tratamos de testes unitários é a escolha de casos de teste unitário. Normalmente o teste envolve custos elevados e demanda tempo extenso, por isso é essencial que o usuário selecione casos efetivos de teste unitário. O termo “efetivo”, em relação a testes unitários, representa duas coisas: que é preciso verificar primeiramente se os casos de teste estão sendo utilizados da maneira esperada, o que consequentemente fará com que o componente teste o que, se espera dele; e que se houverem falhas nos componentes, estes precisarão ser apresentados por casos de teste.
É preciso, então, redigir dois modelos de casos de teste: um que represente o funcionamento habitual do programa do componente; e outro que tenha como referência os testes de experiência, dos quais aparecem problemas mais cotidianos. É necessário utilizar entradas atípicas para analisar se eles são processados adequadamente e que não causam falhas ao componente. Existem duas maneiras eficazes para auxiliar o usuário a selecionar os casos de teste mais adequados. São elas:
Teste de partição
Teste com base em diretrizes
Podemos considerar como normal o fato dos dados de entrada e os resultados alcançados nos de saída de um software serem inseridos em classes diferentes, mesmo apresentando características comuns. Normalmente, os programas apresentam um comportamento suscetível à comparação a todos os componentes pertencentes a uma classe. 
TESTE DE COMPONENTES
Outra subdivisão dos testes de desenvolvimento consiste nos chamados “testes de componentes”, nos quais diversas unidades individuais passam a ser integradas para desenvolver elementos compostos de diversos objetos que interagem. 
Outra subdivisão dos testes de desenvolvimento consiste nos chamados “testes de componentes”, nos quais diversas unidades individuais passam a ser integradaspara desenvolver elementos compostos de diversos objetos que interagem.
Sommerville (2011, p. 151) traz um exemplo que ilustra bem a execução deste teste: vamos imaginar um sistema de estação meteorológica, no qual o componente responsável pela reconfiguração adiciona objetos que tratam de cada aspecto relacionado à reconfiguração. O usuário consegue ter acesso à funcionalidade dos objetos através da interface de componente estabelecida. Os testes de componentes compostos precisam estar centrados em apresentar o comportamento da interface de componente, que deve estar alinhado a sua especificação, lembrando que o usuário pode assumir que os testes unitários aplicados nos objetos individuais já foram finalizados dentro do componente.
Certamente você pode deduzir que existe uma variedade de interfaces entre os componentes de programa. A primeira interface que podemos tratar são as interfaces de parâmetro, em que as referências de dados ou funções são transmitidas entre os componentes. É possível observar também a interface de memória compartilhada, na qual um bloco de memória é partilhado entre componentes, sendo que os dados são inseridos na memória através de um subsistema e podendo ser recuperado por outros. 
Também não podemos deixar de citar as interfaces de procedimento, nas quais um componente encapsula uma série de processos, que podem posteriormente ser chamados por outros componentes. 
Por fim, temos a interface de passagem de mensagem, em que um componente faz a requisição de serviço de outro enviando-lhe uma mensagem. Lembrando que uma mensagem de retorno abrange resultados da execução de um serviço. 
Diversas interfaces podem gerar diferentes tipos de erros de interface, que são as formas mais comuns de erros em sistemas complexos. Os erros podem ser provenientes, por exemplo, do mau uso da interface, no qual um componente chamador chama outro e comete uma falha na utilização da sua interface. 
Outro erro é o mau-entendimento de interface, em que um componente chamador não conhece as especificações de interface do outro componente e realiza suposições, por vezes, errôneas sobre a performance do componente que foi chamado. Por fim, temos os erros de timing, que são cometidos em sistemas full time (em tempo real) que utilizam uma memória partilhada ou até mesmo uma interface de troca de mensagens. 
TESTE DE SISTEMA
Ao longo do seu desenvolvimento, o teste de sistema envolverá a integração de componentes visando a criar uma versão sistêmica e, posteriormente, o chamado “teste do sistema integrado”. Esta modalidade de teste analisa se existe compatibilidade entre os componentes, se há uma interação adequada entre eles e se conseguem transferir dados assertivos em momento propício através de suas interfaces. 
No momento da realização do teste de sistema, por exemplo, pode haver uma integração dos componentes reusáveis criados separadamente e os chamados “sistemas de prateleira”, juntamente com os componentes desenvolvidos recentemente. Nesta condição, o sistema completo será testado. Outro aspecto importante é que, nesta fase, os componentes criados por membros distintos do grupo poderão ser de fato integrados.
EXPLICANDO
O teste de sistema pode ser considerado um processo coletivo. Em algumas organizações empresariais, o teste de sistema pode gerar uma equipe independente, sem necessariamente ocorrer a inserção de projetistas e programadores.
Pensemos o seguinte: no momento em que o usuário do sistema integra componentes com o objetivo de desenvolver um sistema, ele consegue adquirir um comportamento emergente. Isso indica que certos componentes da funcionalidade do sistema só ficam evidentes quando disponibilizados juntos. Este comportamento pode ser projetado e necessita ser testado. Além disso, é necessário que testes sejam desenvolvidos para analisar se o sistema esteja se limitando a realizar somente aquilo que supostamente deve fazer.
Um questionamento pode ser realizado diante deste contexto: qual o momento ideal para finalizar os testes no sistema? Em boa parte dos sistemas é extremamente complexo saber quanto é fundamental o teste de sistema e qual o melhor momento para finalizar os testes. Não é possível realizar testes exaustivos, dos quais cada sequência executável do programa seja de fato testada. Nestas condições, os testes necessitam ser baseados dentro de um subconjunto viável de casos de teste. 
TESTE DE RELEASE
Um segundo estágio de teste de software é o teste de release, que, segundo Sommerville (2011, p. 157), consiste no ato de testar um release privativo de um sistema para ser utilizado fora da equipe de desenvolvimento, ou seja, o que normalmente é para clientes e usuários.
Um segundo estágio de teste de software é o teste de release, que, segundo Sommerville (2011, p. 157), consiste no ato de testar um release privativo de um sistema para ser utilizado fora da equipe de desenvolvimento, ou seja, o que normalmente é para clientes e usuários.
Dentro de um projeto mais complexo, geralmente ele pode servir para outras equipes que desenvolvem sistemas relacionados. Basicamente, existem duas distinções importantes entre os testes de release e os testes de sistema ao longo do processo de desenvolvimento: primeiramente, a equipe responsável pelo teste de release é aquela que não esteve presente no processo de desenvolvimento do sistema. A segunda distinção é que os testes de sistema realizados pela equipe de desenvolvimento são centralizados na busca por bugs no sistema, os chamados “testes de defeitos”. Isso indica que o objetivo do teste de release é analisar se o sistema consegue suprir os seus requisitos e se ele é bom para o uso externo. 
O processo de teste de release visa persuadir o fornecedor sobre a qualidade do sistema. Se isto de fato for uma condição verdadeira, o sistema pode ser apresentado como um produto ou até mesmo disponibilizado a clientes, desde que ofereça níveis de funcionalidade, desempenho e confiança determinados. 
TESTES BASEADOS EM REQUISITOS
Os requisitos precisam ser testáveis, ou seja, o requisito precisa ser redigido de tal maneira que um teste seja planejado para ele. Nesta condição, o indivíduo responsável pelos testes irá observar se o requisito foi de fato atendido. Os testes que se baseiam em requisitos, portanto, são considerados uma abordagem sistemática destinada aos projetos de casos de teste, de que o usuário considera cada requisito e cria uma série de testes para eles.
Vamos pensar em um exemplo prático de requisitos considerando o trabalho de um mecânico de automóveis dentro de uma oficina, preocupado com a verificação de um ruído proveniente do motor de um veículo. Se o carro apresenta um histórico de falha e necessita, por exemplo, de um lubrificante especial, é preciso redigir um relatório de aviso a ser emitido ao usuário do sistema geral oficina. Se o usuário do sistema ignorar o aviso, é preciso que ele justifique o motivo pelo qual esse aviso foi ignorado.
Para observar se esses requisitos foram de fato atendidos, é preciso elaborar uma sequência de testes. No nosso exemplo, é preciso de imediato definir alguma alteração na sua performance diante do tipo de lubrificante utilizado. Caso existam alterações, os relatórios precisam ser emitidos em forma de avisos ao usuário do sistema geral da oficina, para que ele forneça um diagnóstico ao cliente final.
A que conclusão podemos chegar? É perceber que testar um requisito não se trata apenas de escrever um único teste. Geralmente, é preciso redigir diversos testes para assegurar a cobertura dos requisitos, em que é preciso manter registros de rastreabilidade dos testes que se baseiam em requisitos, que unem os testes aos requisitos específicos.
TESTE DE CENÁRIO
Podemos entender que o teste de cenário é uma abordagem de teste de release no qual o usuário idealiza cenários para auxiliarem no desenvolvimento de casos de teste direcionados ao sistema.
Cenários devem ser realistas, e usuários reais do sistema devem sercapazes de se relacionar com eles. Um teste de cenário deve, dentre outros aspectos, estabelecer uma relação entre os stakeholders e acreditar na importância do sistema ser aprovado no teste. Estes testes precisam ser de fácil avaliação e, na ocorrência de problemas com o sistema, a equipe responsável precisa identificá-los. 
Caso um usuário se encontre na posição de testador de release, é necessário observar a forma como o sistema se comporta quando são introduzidas as entradas diferentes. O usuário pode cometer erros de maneira deliberada, porém esses procedimentos verificarão a resposta do sistema às suas falhas. É preciso que o usuário relate qualquer problema que venha a surgir, inclusive problemas ligados ao desempenho. Havendo lentidão no sistema, a forma de utilizá-lo será diferenciada.
TESTE DE DESEMPENHO
Com a integração total do sistema existe a possibilidade de testá-lo para propriedades emergentes, isto é, o desempenho e a confiabilidade estabelecida. É importante salientar que os testes de desempenho são projetados para garantir que o sistema processe as atividades destinadas a ela. Assim como ocorre na execução de outros testes, os testes de desempenho normalmente demonstram que o sistema consegue atender os seus requisitos, no que se refere à localização de problemas e falhas no sistema. 
Segundo Sommerville (2011, p. 159), para comprovar se os requisitos de desempenho estão sendo atendidos, será necessário, por exemplo, desenvolver um perfil operacional. Trata-se de uma série de testes que indicam a combinação efetiva de trabalho manipulado pelo sistema. A maneira mais eficiente de encontrar os defeitos é projetando testes até os limites sistêmicos. É o que denominamos dentro dos testes de desempenho como “estressar o sistema” ao realizar demandas que se encontrem além dos limites de projeto do software.
Este “teste de estresse” normalmente apresenta uma dupla funcionalidade: primeiro, é testar o comportamento de falha do sistema. Vale ressaltar que as circunstâncias podem aparecer através de uma combinação esporádica de situações, em que a carga exercida sobre o sistema ultrapassa a carga prevista. Diante deste cenário, é essencial que os erros do sistema não corrompam os dados ou causem perdas de serviços do usuário.
A outra função é causar certo nível de “estresse” ao sistema para apresentar defeitos que geralmente não são revelados. Mesmo que existam argumentos que defendam que estes defeitos normalmente não são suscetíveis às falhas no sistema, podem surgir combinações em que o teste de estresse possa ser replicado.
Para o entendimento de Sommerville (2011, p. 159), os testes de estresse são importantes para sistemas distribuídos que se baseiam em redes de processadores. 
Esses sistemas geralmente entram em um processo de degradação grave quando se encontram carregados, a rede se sobrecarrega com dados que os processos precisam trocar, e estes processos vão se tornando mais lentos no momento em que aguardam os dados solicitados de outros processos. Cabe aos testes de estresse auxiliar na descoberta do início da degradação, para que o usuário consiga adicionar controles ao sistema para não aceitar operações além do limite estabelecido. 
TESTE DE USUÁRIO
O teste de usuário é considerado um estágio em que usuários ou clientes disponibilizam entradas e conselhos sobre o teste de sistema.
Ele é fundamental, mesmo que a sua atuação ocorra em sistemas abrangentes ou até mesmo quando os testes de release tenham ocorrido. Isso ocorre por conta das interferências no ambiente corporativo do usuário que impactam, por exemplo, a confiabilidade e o desempenho de um sistema.
O desenvolvedor de sistemas, neste contexto, não consegue replicar o ambiente de trabalho do sistema, já que os testes no ambiente do desenvolvedor são artificiais. Os testes de usuário são subdivididos em:
TESTE ALFA
TESTE BETA
TESTE DE ACEITAÇÃO
Pelo qual os usuários do software atuam em paralelo com a equipe de desenvolvimento para realizar testes no software dentro do local do desenvolvedor;
Nos testes alfa, os usuários e os desenvolvedores atuam conjuntamente para realizar testes em um sistema desenvolvido. Isso indica que os usuários conseguem reconhecer os problemas que normalmente passam despercebidos para a equipe de testes de desenvolvimento. Os desenvolvedores atuam somente por meio de requisitos, porém, por diversas vezes, estes requisitos acabam não refletindo os fatores que afetam a utilização do software. Nesta condição, os usuários conseguem disponibilizar informações referentes às práticas que colaboram com o projeto de testes, mais próximas da realidade. 
Os testes alfa são constantemente utilizados no desenvolvimento de produtos de software, além de auxiliarem a redução do risco de alterações inesperadas neles que interfiram nos negócios. Porém, os testes alfa podem ser adotados no momento em que o software customizado será desenvolvido. 
Já no teste beta vamos observar que o mesmo acontece quando um release antecipado de um sistema de software fica disponível a clientes-usuários para que seja avaliado. Este tipo de teste é adotado em produtos de software utilizados em vários ambientes, ao contrário dos sistemas customizados. É praticamente inviável para quem desenvolve produtos conseguir conhecer e replicar os ambientes nos quais o software pode ser utilizado.
O teste beta é fundamental para verificar os problemas que envolvem a interação entre o software e os aspectos do ambiente no qual este produto é utilizado. Podemos considerá-lo como um tipo de marketing, pelo qual clientes conseguem aprender sobre o funcionamento do sistema e o que pode ser feito por ele.
Por fim, há o teste de aceitação, que, segundo Sommerville (2011, p. 160), é a parte considerada no desenvolvimento de sistemas mais customizados, que normalmente ocorre depois do teste de release. Ele aborda o teste formal de um sistema através de um usuário para verificar a sua aceitação. A aceitação, dentro de uma organização corporativa, por exemplo, designa o pagamento que deve ser realizado pelo sistema. Existem algumas etapas inerentes ao processo de teste de aceitação, como na Figura 7.
A fase da definição de critérios de aceitação ocorre no início do processo, antes da assinatura do contrato do sistema. O teste de aceitação adota critérios inerentes ao contrato do sistema e que são definidos entre o cliente-usuário e o desenvolvedor. Um detalhe que não devemos deixar de tratar é o fato de que na prática pode ser complexo escolher estes critérios na fase inicial do processo, pois os requisitos detalhados muitas vezes não estão disponíveis, além das possíveis alterações que estes requisitos sofrem ao longo do processo de desenvolvimento.
Ao planejar os testes de aceitação a serem implantados, é preciso levar em consideração alguns aspectos, como recursos e tempo, para realizar os testes de aceitação e definir uma espécie de cronograma para a realização deles. Cabe ao teste de aceitação debater sobre o atendimento dos requisitos solicitados, a ordem de teste dos aspectos do sistema, definir os riscos aos quais o processo de testes está sujeito e verificar uma forma de mitigar estes riscos.
Sobre o ato de derivar testes de aceitação, é preciso entender que, à medida que os testes de aceitação são definidos, eles serão planejados para analisar a existência ou não de um sistema aceitável. Os testes de aceitação visam a atestar aspectos funcionais e não funcionais pertencentes ao sistema disponibilizando a cobertura total dos requisitos de sistema, mesmo que na prática seja difícil definir os critérios de aceitação.
Para executar testes de aceitação, é preciso compreender que esta ação deve ocorrer dentro de um ambiente real em que o sistema será usado, porém algumas vezes isso é inviável. 
Sendo assim, um ambiente de testes de usuário é configurado para realizar esses testes. Vale frisar que automatizar esse processo é algo complexo, pois parte dos testes de aceitação envolve testes de interações utilizando usuários finais e o sistema.Outro aspecto importante se refere à negociação dos resultados de teste que trata das possibilidades de se encontrar ou não qualquer falha no sistema. Caso não for possível identificar qualquer possibilidade de erros no sistema, o teste de aceitação estará completo e pronto para a entrega. Entretanto, o que normalmente ocorre é encontrar problemas. Sendo assim, cabe ao desenvolvedor e o cliente estabelecer negociações para definir o status do sistema e disponibilizá-lo ao público ou não. 
Por fim temos o processo de aceite ou rejeição do sistema. Nesta fase, desenvolvedores e clientes se unem para decidir se o sistema será ou não aceito. Caso se confirme que o sistema não é bom o suficiente, será necessário elevar o nível de desenvolvimento para resolver os problemas visualizados. Ao concluir esta etapa, a fase de testes de aceitação é repetida.