A verificação e validação fazem parte do processo de teste?

9

Com base em muitas fontes, não acredito que a definição simples de que o objetivo do teste seja encontrar o maior número possível de bugs - testamos para garantir que funcione ou não. Por exemplo, followint são objetivos do formulário de teste ISTQB:

Determine que (produtos de software) atendem aos requisitos especificados (acho que é a verificação)
Demonstrar que (produtos de software) são adequados ao objetivo (acho que é validação)
Detectar defeitos

Concordo que o teste é verificação, validação e detecção de defeitos. Isso está correto?

testing theory verification

— João V
fonte

11

A primeira coisa que os livros sobre testes dizem é que "o teste não é o processo de mostrar que o software funciona corretamente. É o processo de encontrar defeitos". E que os livros trazem inúmeras razões para definir testes como esse. Portanto, a verificação é o processo de descobrir onde o software não atende aos requisitos.

— SuperMay

De acordo com a definição, a verificação garante que os requisitos foram atendidos. Na verdade, os livros definem o teste como um processo de medir a qualidade do software. Portanto, se você está verificando se o sistema está funcionando (positivo) com a intenção de ver se funciona, ele não está testando porque você não procura bugs? :) Na Wikipedia: Teste técnicas incluem, mas não estão limitados a, o processo de execução de um programa ou aplicativo com a intenção de encontrar bugs de software

— John V

Acho que a melhor maneira de identificar os limites da palavra teste é pensar em testar uma hipótese; nesse caso, você está tentando testar se não há falácias ou imprecisões na hipótese, isso não é o mesmo que verificar sua utilidade ou validando sua aplicabilidade, esse é apenas um caso de identificação de todo o escopo de comportamento, independentemente da finalidade.

— Jimmy Hoffa

Tem um bônus "boa pergunta" :)

— Andrew

1

Eu acho que você acertou exatamente.

Verificação e validação são coisas diferentes e, de fato, são bem definidas. Embora eu não goste muito do documento, a ISO 9000ff é altamente relevante para o controle de qualidade e define a Verificação como comparando um produto com seus requisitos e a Validação como verificando se ele realmente atende às necessidades do cliente / usuário e todos sabemos que isso pode ser diferente. .
Ambos podem ser feitos através de testes. A verificação levaria a testes gerados nos requisitos do formulário. A validação leva ao teste realizado pelos testes sem referência direta aos requisitos. Eu acho que isso geralmente é chamado de teste exploratório. Obviamente, isso deve ser feito por pessoas com um entendimento real das necessidades reais dos usuários, para que os testes alfa e beta de usuários reais sejam opções óbvias.
Em uma base teórica, acho que alguém poderia argumentar que qualquer coisa coberta pelos dois primeiros não é um bug e, portanto, encontrar erros como um objetivo separado não faz sentido. Mas acho que há coisas que você realmente não pode verificar ou validar. Por exemplo, segurança: como você valida ou verifica se um sistema de software é seguro contra ataques? Em vez disso, você tenta encontrar vulnerabilidades. Esta pesquisa não verifica ou valida nada se não encontrar problemas, mas encontra erros se for bem-sucedida.

— Jens Schauder
fonte

O problema é que muitas fontes mencionam que a verificação é apenas estática, enquanto a validação é dinâmica. É muito confuso. O que seria um teste funcional então? Gostaria de dizer verificiation dinâmica ..

— John V

11

Quais fontes usam essa definição de verificação e validação? Por outro lado, não conheço nenhuma definição clara e geralmente concordada sobre qualquer coisa que termine em -test. Então, eu realmente não sei o que é um teste funcional para você.

— Jens Schauder

Bem, por exemplo, a ISO 12207 restringe os testes apenas como um processo de validação.

— John V

3

Da Wikipedia: "... Em outras palavras, a validação garante que o produto atenda às necessidades do usuário e que as especificações estejam corretas em primeiro lugar , enquanto a verificação garante que o produto foi construído de acordo com os requisitos e as especificações de design A validação garante que "você construiu a coisa certa". A verificação garante que "você construiu a coisa certa". A validação confirma que o produto, conforme fornecido, cumprirá o uso pretendido. "

Você não pode testar as necessidades do usuário e verificar se as especificações estavam corretas por código. Portanto, a validação não é feita pelo teste.

A verificação supõe que seus requisitos e design estejam corretos, para que você possa testá-lo escrevendo código (teste).

— Mert Akcakaya
fonte

Eu não concordo - o teste não é apenas um código de teste, também há testes de documentação etc. programa por sua execução e investigação, se é isso que o usuário deseja ou não.

— John V

Na verdade você está certo. O processo de teste também inclui testes de aceitação, mas eu falei sobre testes de unidade, integração e sistema. Se pensarmos no processo de teste como um todo, a verificação e a validação serão feitas pelo teste.

— Mert Akcakaya #

1

Para o mundo real, o teste é a verificação e validação do software que atende aos requisitos do software (comercial / funcional / não funcional). O objetivo destes é determinar se o software é adequado para a finalidade. Qualquer comportamento que não atenda aos requisitos do aplicativo é um defeito - cuja gravidade precisará ser ponderada antes de determinar se o software é adequado para a finalidade.

Os defeitos de baixa severidade provavelmente não são um impedimento para a passagem do software para um uso do tipo de produção. A severidade alta pode exigir uma correção para ser produzida. No mundo real, todos os softwares apresentam defeitos, alguns são problemas de codificação e outros, por falta de requisitos - o que pode não ser testado porque você não pode testar requisitos desconhecidos.

— adam f
fonte

1

Existem muitas definições de verificação e validação. Muitas pessoas até usam a tag V&V para agrupar ambas em uma única atividade. O objetivo é garantir que o software faça as coisas certas e as coisas certas. Se é para verificar a conformidade com os requisitos ou tentar encontrar bugs, não é essencial nesse nível.

O teste é uma das muitas técnicas para verificação e validação, e não o contrário. A revisão de código é outra e a verificação formal, com provas matemáticas ainda outra.

No entanto, o teste deve ser realizado com o objetivo de encontrar bugs, não com o objetivo de verificar a conformidade com os requisitos.

A principal diferença está na mente do testador. É muito mais fácil criar um caso de teste mostrando que o software funciona como planejado (verificação de conformidade), do que criar um caso de teste mostrando que o software falha (localizando bugs).

Um grande testador é apaixonado por quebrar um software, não por exercitá-lo de maneira segura.

— mouviciel
fonte

obrigado, mas também não testamos para mostrar que os requisitos foram atendidos? Garantimos que o software funcione (atenda às especificações) e tentemos encontrar defeitos. Portanto, não se trata apenas de encontrar bugs. Lembro-me de um livro dizendo que o principal objetivo do teste é medir a qualidade, e não procurar bugs. Quanto ao seu primeiro ponto, a revisão de código, a prova de matemática, etc. também estão testando e é chamada de estática.

— John V

Defeitos ou bugs existem em contraste com os requisitos. A natureza do trabalho é idêntica. É apenas uma diferença na maneira de pensar do testador para melhorar sua eficiência. Quanto ao meu primeiro ponto, existem muitas definições de todos os termos usados na validação de software (e um primeiro passo ao ingressar em uma equipe é obter o dialeto local nessa equipe), mas a maioria das pessoas concorda que o teste é apenas uma dinâmica técnica. o teste estático é um oxímoro ou se refere a uma técnica diferente, não muito longe da revisão, em que o código é executado na mente do "testador" e não no computador.

— Mouviciel 4/10/12

mouviciel: oxímoro? Acho que não, teste estático significa verificar possíveis defeitos sem execução, o que é totalmente possível (problemas de requisitos, falhas de design ...). Não é o mesmo para verificar requisitos e verificar se há bugs: você deve testar se um campo pode conter o valor int32. Isso está testando que funciona. Então você pode tentar entrar valores mais elevados, que está testando para bugs ..

— John V

1

Vamos ver isso do ponto de vista prático. Para teste, você precisa definir casos de teste. Normalmente, você define casos de teste de acordo com os requisitos especificados, e eles devem abranger casos de "dia feliz" e "casos extremos" - especialmente os últimos geralmente são definidos com a intenção de interromper o software. Quando alguns de seus testes falham, eles mostram bugs / defeitos. Quando você tem uma quantidade razoável de casos de teste para cada requisito e todos os testes são aprovados, pode não ter provado totalmente que todos os requisitos foram atendidos, mas você aumentou a probabilidade de fazer isso e fez alguma verificação.

Portanto, para essa parte da pergunta, encontrar bugs e verificação pode ser apenas dois lados do mesmo processo:

testes falham: defeitos encontrados
testes são aprovados: verificação feita (pelo menos até certo ponto, se você fornecer testes suficientes e certos)

Em relação à validação: como apontado pelo @Mert, a validação pode ser feita através de testes de aceitação, mas não por outras formas de teste. Portanto, o teste em geral não causa validação, apenas quando realizado como teste de aceitação, por alguns dos usuários em potencial.

— Doc Brown
fonte

0

Tudo depende da sua definição de "verificação". Por exemplo, a verificação formal geralmente não é algo feita por uma equipe de controle de qualidade, mas é uma responsabilidade dos desenvolvedores. Quase ninguém faz a verificação formal por causa do alto custo associado (lacuna de conhecimento e recursos necessários).

— Joeri Sebrechts
fonte

0

O teste de software não é o mesmo que o controle de qualidade. Você entendeu direito. No geral, os testes de software incluem muitos estágios (fumaça, unidade, regressão, integração, aceitação pelo usuário etc.).

Portanto, garantir que o software funcione de acordo com os requisitos é o principal objetivo do controle de qualidade (especialista em garantia da qualidade - conhecido como o chamado testador há alguns anos). No entanto, não é apenas um teste . O controle de qualidade garante que um conjunto adequado de processos para executar a verificação da qualidade do produto em questão esteja em vigor ou, pelo menos, seja levado para a fase de design do projeto.

Portanto, o ideal é que você espere que seu controle de qualidade verifique o aplicativo em relação ao conjunto de requisitos e não tente testá-lo quebrando o software e encontrando defeitos.

— Yusubov
fonte

O controle de qualidade NÃO é apenas um teste. QA lida com a qualidade dos processos de desenvolvimento ..

— John V

O controle de qualidade verifica o aplicativo em relação ao conjunto de requisitos.

— Yusubov 04/10