Diferença entre teste de aceitação e teste funcional?

Qual é a diferença real entre testes de aceitação e testes funcionais?

Quais são os destaques ou objetivos de cada um? Em todos os lugares que leio, eles são ambiguamente semelhantes.

No meu mundo, usamos os termos da seguinte maneira:

teste funcional : esta é uma atividade de verificação ; criamos um produto que funcione corretamente? O software atende aos requisitos de negócios?

Para esse tipo de teste, temos casos de teste que cobrem todos os cenários possíveis em que podemos pensar, mesmo que seja improvável que exista "no mundo real". Ao fazer esse tipo de teste, buscamos uma cobertura máxima de código. Usamos qualquer ambiente de teste que possamos pegar no momento, não precisa ser do tipo "produção", desde que seja utilizável.

teste de aceitação : esta é uma atividade de validação ; nós construímos a coisa certa? É disso que o cliente realmente precisa?

Isso geralmente é feito em cooperação com o cliente ou por um proxy interno do cliente (proprietário do produto). Para esse tipo de teste, usamos casos de teste que cobrem os cenários típicos nos quais esperamos que o software seja usado. Esse teste deve ser realizado em um ambiente "semelhante à produção", em hardware igual ou próximo ao que o cliente utilizará. É quando testamos nossas "ilidades":

• Confiabilidade, disponibilidade : validado por meio de um teste de estresse.

• Escalabilidade : validada através de um teste de carga.

• Usabilidade : Validado por meio de uma inspeção e demonstração ao cliente. A interface do usuário está configurada ao seu gosto? Colocamos a marca do cliente nos lugares certos? Temos todos os campos / telas solicitados?

• Segurança (também conhecida como segurança, apenas para se encaixar) : validada por demonstração. Às vezes, um cliente contrata uma empresa externa para fazer uma auditoria de segurança e / ou testes de intrusão.

• Manutenção : Validado através da demonstração de como forneceremos atualizações / patches de software.

• Configurabilidade : validado através da demonstração de como o cliente pode modificar o sistema para atender às suas necessidades.

Isso não é de forma alguma padrão, e não acho que exista uma definição "padrão", como demonstram as respostas conflitantes aqui. O mais importante para sua organização é que você defina esses termos com precisão e cumpra-os.

Eu gosto da resposta de Patrick Cuff. O que eu gosto de acrescentar é a distinção entre um nível de teste e um tipo de teste que, para mim, era um abridor de olhos.

níveis de teste

É fácil explicar o nível de teste usando o modelo V , um exemplo: Cada nível de teste tem seu nível de desenvolvimento correspondente . Tem uma característica de tempo típica, eles são executados em determinada fase do ciclo de vida do desenvolvimento.

1. teste de componente / unidade => verificação do projeto detalhado
2. teste de integração componente / unidade => verificação do design global
3. teste do sistema => verificação de requisitos do sistema
4. teste de integração de sistemas => verificação de requisitos do sistema
5. teste de aceitação => validando requisitos do usuário

tipos de teste

Um tipo de teste é uma característica, ele se concentra em um objetivo de teste específico. Os tipos de teste enfatizam seus aspectos de qualidade, também conhecidos como aspectos técnicos ou não funcionais. Os tipos de teste podem ser executados em qualquer nível de teste . Eu gosto de usar como tipos de teste as características de qualidade mencionadas na ISO / IEC 25010: 2011.

1. teste funcional
2. teste de confiabilidade
3. teste de performance
4. teste de operabilidade
5. teste de segurança
6. teste de compatibilidade
7. teste de manutenção
8. teste de transferibilidade

Para torná-lo completo. Há também algo chamado teste de regressão . Essa é uma classificação extra ao lado do nível e tipo de teste . Um teste de regressão é um teste que você deseja repetir porque toca em algo crítico no seu produto. Na verdade, é um subconjunto de testes que você definiu para cada nível de teste . Se houver uma pequena correção de bug no seu produto, nem sempre você terá tempo para repetir todos os testes. O teste de regressão é uma resposta para isso.

A diferença está entre testar o problema e a solução. O software é uma solução para um problema, ambos podem ser testados.

O teste funcional confirma que o software executa uma função dentro dos limites de como você resolveu o problema. Isso é parte integrante do desenvolvimento de software, comparável ao teste realizado no produto produzido em massa antes de sair da fábrica. Um teste funcional verifica se o produto realmente funciona como você (o desenvolvedor) pensa.

Testes de aceitação verificam se o produto realmente resolve o problema que foi feito para resolver. Isso pode ser feito melhor pelo usuário (cliente), por exemplo, executando suas tarefas com as quais o software auxilia. Se o software passar neste teste do mundo real, será aceito substituir a solução anterior. Às vezes, esse teste de aceitação pode ser feito corretamente na produção, especialmente se você tiver clientes anônimos (por exemplo, um site). Assim, um novo recurso será aceito somente após dias ou semanas de uso.

Teste funcional - teste o produto, verificando se ele possui as qualidades que você projetou ou construiu (funções, velocidade, erros, consistência etc.)

Teste de aceitação - teste o produto em seu contexto, isso requer (simulação de) interação humana, teste se ele tem o efeito desejado no (s) problema (s) original (is).

A resposta é opinião. Trabalhei em muitos projetos, sendo testmanager e issuemanager e todos os diferentes papéis e as descrições em vários livros diferem, então aqui está minha variação:

teste funcional: pegue os requisitos de negócios e teste tudo de bom e completo do ponto de vista funcional.

teste de aceitação: o cliente "pagador" faz o teste que gosta de fazer para poder aceitar o produto entregue. Depende do cliente, mas geralmente os testes não são tão completos quanto os testes funcionais, especialmente se for um projeto interno, porque as partes interessadas revisam e confiam nos resultados dos testes realizados nas fases anteriores.

Como eu disse, esse é o meu ponto de vista e experiência. O teste funcional é sistemático e o teste de aceitação é o departamento de negócios que está testando a coisa.

1. Público. O teste funcional é garantir aos membros da equipe que produz o software que eles fazem o que esperam. O teste de aceitação é garantir ao consumidor que ele atende às suas necessidades.

2. Escopo. O teste funcional apenas testa a funcionalidade de um componente por vez. O teste de aceitação cobre qualquer aspecto do produto que seja importante para o consumidor o suficiente para ser testado antes da aceitação do software (ou seja, qualquer coisa que valha o tempo ou dinheiro necessário para testá-lo para determinar sua aceitabilidade).

O software pode passar nos testes funcionais, nos testes de integração e nos testes do sistema; apenas para falhar nos testes de aceitação quando o cliente descobre que os recursos simplesmente não atendem às suas necessidades. Isso normalmente implica que alguém estragou as especificações. O software também pode falhar em alguns testes funcionais, mas passa no teste de aceitação porque o cliente está disposto a lidar com alguns bugs funcionais, desde que o software faça as coisas essenciais que eles precisam de maneira aceitável (o software beta geralmente é aceito por um subconjunto de usuários antes dele é completamente funcional).

Teste Funcional: Aplicação de dados de teste derivados dos requisitos funcionais especificados, sem considerar a estrutura final do programa. Também conhecido como teste de caixa preta.

Teste de aceitação: Teste formal realizado para determinar se um sistema atende ou não aos seus critérios de aceitação - permite que um usuário final determine se aceita ou não o sistema.

Na minha opinião, a principal diferença é quem diz se os testes são bem-sucedidos ou falham.

Um teste funcional testa se o sistema atende a requisitos predefinidos. É realizado e verificado pelas pessoas responsáveis ​​pelo desenvolvimento do sistema.

Um teste de aceitação é assinado pelos usuários. O ideal é que os usuários digam o que desejam testar, mas, na prática, é provável que o teste funcione porque os usuários não investem tempo suficiente. Observe que essa visão é dos usuários corporativos que trato com outros conjuntos de usuários, por exemplo, aviação e outros fatores críticos de segurança podem não ter essa diferença,

Teste de aceitação :

... é realizado um teste de caixa preta em um sistema (por exemplo, software, muitas peças mecânicas fabricadas ou lotes de produtos químicos) antes de sua entrega.

Embora isso continue dizendo:

Também é conhecido como teste funcional, teste de caixa preta, aceitação de versão, teste de controle de qualidade, teste de aplicativos, teste de confiança, teste final, teste de validação ou teste de aceitação de fábrica.

com uma marca de "citação necessária".

Teste funcional (que realmente redireciona para o Teste do Sistema):

conduzido em um sistema completo e integrado para avaliar a conformidade do sistema com os requisitos especificados. O teste do sistema se enquadra no escopo do teste de caixa preta e, como tal, não requer conhecimento do design interno do código ou da lógica.

Portanto, a partir dessa definição, eles são praticamente a mesma coisa.

Na minha experiência, o teste de aceitação geralmente é um subconjunto dos testes funcionais e é usado no processo formal de assinatura pelo cliente, enquanto os testes funcionais / do sistema são aqueles executados pelo departamento de desenvolvedor / controle de qualidade.

A relação entre os dois: Teste de aceitação geralmente inclui testes funcionais, mas pode incluir testes adicionais. Por exemplo, verificando os requisitos de rotulagem / documentação.

Teste funcional é quando o produto em teste é colocado em um ambiente de teste que pode produzir uma variedade de estímulos (dentro do escopo do teste) que o ambiente de destino normalmente produz ou mesmo além, enquanto examina a resposta do dispositivo em teste.

Para um produto físico (não software), existem dois tipos principais de testes de aceitação : testes de design e testes de fabricação. Os testes de projeto geralmente usam um grande número de amostras de produtos, que passaram no teste de fabricação. Consumidores diferentes podem testar o design de maneiras diferentes.

Os testes de aceitação são referidos como verificação quando o design é testado com relação às especificações do produto, e os testes de aceitação são referidos como validação, quando o produto é colocado no ambiente real do consumidor.

O teste de aceitação é apenas um teste realizado pelo cliente e inclui outros tipos de teste:

• Teste funcional: "este botão não funciona"
• Teste não funcional: "esta página funciona, mas é muito lenta"

Para testes funcionais versus testes não funcionais (seus subtipos) - veja minha resposta a esta pergunta do SO .

Eles são a mesma coisa.

O teste de aceitação é realizado no sistema concluído o mais idêntico possível ao ambiente real de produção / implementação antes que o sistema seja implantado ou entregue.

Você pode realizar testes de aceitação de maneira automatizada ou manual.