O que significa verificar software
A verificação de software é o conjunto de verificações destinado a determinar se um produto ou resultado de engenharia está em conformidade com os requisitos e as especificações aplicáveis. A pergunta prática é: «foi construído de acordo com o que foi definido?». No enquadramento de engenharia de sistemas da NASA, a verificação compara o produto com os seus requisitos ou especificações; a mesma distinção também ajuda a compreender programas, componentes e entregáveis de software. NASA: verificação de produto
A verificação não é uma atividade única, necessariamente realizada no final. Pode ser aplicada a diferentes entregáveis durante o desenvolvimento: uma especificação pode ser analisada em relação a necessidades previamente acordadas, um projeto em relação aos requisitos e uma implementação em relação ao projeto ou a critérios técnicos. A referência deve ser explícita: sem um requisito identificável, não é possível indicar com clareza que condição foi verificada. A sequência concreta depende do projeto e não deve ser confundida com uma receita universal.
Verificar também não equivale a declarar que todo o software é correto, seguro ou útil em qualquer situação. Uma verificação fornece evidências sobre um âmbito definido, com critérios e condições determinados. Por exemplo, analisar um cálculo específico não demonstra automaticamente que todas as funções, versões, entradas ou ambientes se comportem de forma adequada.
O que pode ser verificado
Os objetos de verificação podem incluir requisitos, projeto, código executável, componentes integrados e documentação associada, desde que existam critérios aplicáveis para os comparar. A página da NASA descreve a verificação de um produto final como uma verificação de conformidade com requisitos ou especificações e salienta a importância de manter uma configuração de referência controlada. A mesma lógica aplica-se ao âmbito: cada afirmação deve identificar o elemento e a versão analisados. NASA: verificação de produto
Num exemplo simples, um requisito poderia indicar que uma aplicação deve calcular um total a partir de quantidades e preços. A verificação pode confirmar se a fórmula implementada corresponde à regra especificada e se, nos casos analisados, o resultado coincide com o esperado. Se a própria regra estiver mal formulada — por exemplo, se omitir um desconto necessário na utilização real —, o programa pode estar em conformidade com ela e, ainda assim, não satisfazer a necessidade. Essa diferença explica por que motivo verificação e validação não devem ser tratadas como sinónimos.
A documentação também é importante, pois define o que se considera conforme e regista a atividade realizada. Um plano de verificação e validação pode registar responsabilidades, documentos aplicáveis, métodos e matrizes que relacionem requisitos com evidências. O esquema publicado pela NASA inclui secções distintas para métodos de verificação e validação, implementação e matrizes de requisitos. A rastreabilidade ajuda a localizar cobertura e lacunas, mas uma matriz completa não prova, por si só, que cada resultado esteja correto. NASA: esquema do plano de verificação e validação
Como se realiza: revisão, análise e testes
A verificação pode reunir diferentes formas de análise. Uma revisão humana compara documentos ou alterações com critérios definidos; uma análise pode procurar propriedades ou inconsistências sem executar o programa; e um teste observa o comportamento do software ao executá-lo sob condições selecionadas. As informações do NIST sobre as suas atividades de formação em verificação e validação de software destacam a documentação de evidências e a utilização de técnicas dos dois tipos, embora os exemplos se concentrem em folhas de cálculo de laboratórios e não constituam uma lista exaustiva para todos os projetos. NIST: formação em verificação e validação de software
Um exemplo de verificação face a uma especificação
Suponhamos que uma especificação exige que um sistema rejeite um pedido quando falta um campo obrigatório. Uma revisão poderia confirmar que o requisito está definido e que o projeto contempla esse caso; um teste poderia enviar um pedido incompleto e comparar a resposta observada com o resultado esperado. Cada método responde a uma pergunta diferente: a revisão examina artefactos e raciocínios, enquanto o teste observa um comportamento com entradas e condições específicas.
Os testes não analisam todas as entradas possíveis apenas por serem executados. O resultado depende dos casos selecionados, da versão testada e do ambiente utilizado. Assim, «passou nos testes» significa que não foi detetada qualquer discrepância nas verificações realizadas, e não que a ausência de defeitos tenha sido demonstrada. As evidências são mais fáceis de interpretar quando se preserva a relação entre requisito, critério de aceitação, caso executado, resultado e versão do produto.
Uma prática útil de registo
Para que outra pessoa compreenda o que foi verificado, é útil registar o elemento e a versão analisados, o requisito associado, o método aplicado, as condições relevantes e o resultado. Quando os controlos ou as auditorias são importantes, esse registo permite explicar o âmbito e analisar alterações posteriores. O NIST apresenta a documentação de evidências e a avaliação contínua do software como objetivos dos seus recursos de formação para laboratórios; o conteúdo específico de cada registo deve ser adequado ao contexto. NIST: formação em verificação e validação de software
Verificação e validação respondem a perguntas diferentes
A verificação pergunta se o produto está em conformidade com os requisitos ou especificações definidos. A validação pergunta se o produto satisfaz a utilização prevista e as necessidades relevantes no contexto em que será utilizado. A NASA exprime a diferença através de duas perguntas: se o produto foi realizado corretamente em relação ao que foi especificado e se corresponde ao que o cliente pretendia no ambiente de utilização. NASA: verificação de produto
| Aspeto | Verificação | Validação |
|---|---|---|
| Pergunta central | O produto está em conformidade com os requisitos ou especificações? | O produto é adequado à utilização prevista e às necessidades do cliente? |
| Referência | Requisitos, especificações e documentação aplicáveis | Intenção de utilização e contexto do cliente ou utilizador |
| Exemplo ilustrativo | Confirmar que um cálculo implementa a fórmula especificada | Avaliar se esse cálculo resolve a tarefa que o utilizador precisa de realizar |
A tabela resume a distinção de propósito descrita pela NASA; não implica que cada atividade utilize um método exclusivo, nem que exista uma fronteira rígida entre técnicas. NASA: verificação de produto
Consideremos uma aplicação que calcula o custo de um envio. Se a especificação disser que deve somar uma tarifa base e uma sobretaxa, verificar esse cálculo é verificação. Perguntar se a aplicação contempla as necessidades reais — por exemplo, se o fluxo permite indicar o destino e o tipo de entrega oferecido pelo serviço — pertence à validação. A primeira verificação pode ser satisfatória enquanto a segunda revela que a solução definida não serve a utilização esperada.
Por isso, não basta dizer que um produto «foi verificado» sem especificar a referência e o âmbito. A validação também não substitui todas as verificações face às especificações: ambas as perspetivas podem ser necessárias e complementares. Os processos descritos pela NASA distinguem os seus objetivos, embora reconheçam que algumas atividades podem parecer semelhantes na prática. A designação depende da pergunta que se pretende responder, não apenas de a atividade se chamar teste ou revisão.
Que evidências deixa e como interpretá-las
As evidências podem consistir em resultados de testes, observações de revisões, análises documentadas ou matrizes que associem requisitos a verificações. Nem todas estas evidências demonstram o mesmo: um resultado de execução sustenta uma observação para determinadas entradas e um ambiente concreto; uma revisão pode documentar que um artefacto foi avaliado segundo critérios. A conclusão não deve exceder as evidências nem estender-se a versões ou condições que não foram analisadas.
A rastreabilidade ajuda a acompanhar a ligação entre um requisito e a atividade destinada a verificá-lo. O esquema de planeamento da NASA propõe uma matriz de verificação de requisitos e uma matriz de validação, além de documentar métodos e atividades. Trata-se de uma estrutura para organizar evidências, não de uma garantia automática de que os requisitos estão bem formulados, são completos ou refletem as necessidades dos utilizadores. NASA: esquema do plano de verificação e validação
Por exemplo, se uma regra de cálculo for alterada, saber que requisitos, componentes e casos de verificação lhe estão associados permite analisar o impacto da mudança. No entanto, uma ligação documental pode estar desatualizada ou não abranger um comportamento importante. A gestão de versões e a análise das evidências continuam a ser necessárias; uma lista de caixas assinaladas só é útil se descrever atividades reais, resultados interpretáveis e o artefacto correto.
Limites, confusões e aplicação prática
A verificação é uma prática delimitada, não uma prova matemática de perfeição. Podem permanecer defeitos porque certos casos não foram analisados, os critérios estavam incompletos ou o ambiente real difere do utilizado. Também é possível cumprir literalmente uma especificação que não representa bem a necessidade. Por isso, uma declaração responsável identifica o que foi analisado, com que referência e em que condições, em vez de afirmar que o software está isento de erros.
Em projetos de risco elevado ou sujeitos a requisitos de controlo, a independência da revisão pode ser relevante. O glossário do NIST descreve a verificação e validação independentes como revisão, análise e testes realizados por uma terceira parte objetiva para examinar tanto a definição dos requisitos como a implementação das funções e dos requisitos de segurança. Esta descrição corresponde a IV&V; não significa que todos os projetos precisem necessariamente de uma equipa externa nem que a independência elimine os limites de cobertura. NIST: glossário de verificação e validação independentes
Para interpretar uma afirmação de verificação ou planear uma verificação, estas perguntas ajudam a concretizar o seu âmbito:
- Que produto, componente, documento e versão foram analisados?
- Face a que requisito, especificação ou critério foi feita a comparação?
- Que método foi aplicado e em que condições?
- Que evidências foram registadas e que casos não abrangem?
- A questão era a conformidade com o que foi especificado ou a adequação à utilização prevista?
A norma ISO/IEC/IEEE 12207 oferece um enquadramento de processos do ciclo de vida do software, mas as fontes reunidas para este artigo não incluem o texto oficial da norma. Por isso, este glossário não atribui requisitos concretos a essa norma nem apresenta uma receita normativa. As orientações aqui expostas baseiam-se sobretudo na documentação da NASA sobre verificação e validação de produtos e nos recursos do NIST sobre evidências e IV&V; as técnicas específicas devem ser escolhidas em função do sistema, dos seus riscos e das obrigações aplicáveis. NASA: verificação de produto NIST: IV&V