O documento aborda a garantia da qualidade de software, enfatizando a importância da verificação e validação (vv&t) em todo o processo de desenvolvimento para assegurar que o produto atenda aos requisitos funcionais e de desempenho. Destaca-se a diferença entre verificação, que assegura a conformidade com especificações, e validação, que verifica se o produto atende às necessidades do cliente. O texto também menciona o modelo de qualidade de software em 'u' e a importância de realizar testes em fases iniciais para evitar altos custos de correção posteriores.

1. Garantia da qualidade, verificação e validação

2.  Qualidade de Software
 Corretitude
 Confiabilidade
 Testabilidade
Conformidade com requisitos funcionais
e de desempenho, padrões de desenvolvimento
documentados e características
implícitas esperadas de todo software
profissionalmente desenvolvido.

3.  Garantia de Qualidade de Software
 Conjunto de atividades técnicas aplicadas
durante todo o processo de
desenvolvimento
 Objetivo
 Garantir que tanto o processo de desenvolvimento
quanto o produto de software atinjam os níveis de
qualidade especificados
 VV&T – Verificação, Validação e Teste

4. Garantia da qualidade, verificação e validação
Para garantir a qualidade do produto ou do serviço, além da fase de testes,
devem ser aplicados processos em todo o andamento do projeto. Os processos
são um conjunto de atividades, ações e tarefas realizadas para garantir a
qualidade final do software.
Nesse contexto, quando se inicia a elaboração de um projeto, é importante
aplicar processos que ajudem a validar a qualidade, dentro do escopo
estabelecido.

5. Garantia da qualidade, verificação e validação
Algumas atividades comuns são:
● especificação de software: elencar os requisitos funcionais e não funcionais do software, com base nas
operações a serem definidas;
● projeto e desenvolvimento do software: desenvolver um software que atenda aos requisitos, dentro do
escopo;
● validação de software: verificar se o software faz o que o cliente deseja;
● evolução do software: modificações no software, para que possa evoluir e atender às necessidades do
cliente.
Todas essas ações devem ser assistidas pelos processos de qualidade, para garantir que o
produto está dentro dos critérios mínimos de um produto bom o suficiente para a entrega.

6.  Validação: Assegurar que o produto final corresponda
aos requisitos do usuário
 Verificação: Assegurar consistência, completitude e
corretitude do produto em cada fase e entre fases
consecutivas do ciclo de vida do software
 Teste: Examina o comportamento do produto por meio
de sua execução
Estamos construindo o produto certo?
Estamos construindo corretamente o produto?

7.  Defeito Erro Falha
 Defeito: deficiência mecânica ou algorítmica
que, se ativada, pode levar a uma
falha
 Erro: item de informação ou estado de
execução inconsistente
 Falha: evento notável em que o sistema
viola suas especificações

8. Garantia da qualidade, verificação e validação
Figura 2.5 - Qualidade baseada em processos
Fonte: Sommerville (2011, p. 458).

9. Garantia da qualidade, verificação e validação
Entenda que não basta apenas ter processos que garantam a qualidade, pois o próprio
processo a ser gerido deve ter qualidade.
Nesse sentido, a qualidade de um processo corresponde ao nível de aceitação na produção
dos softwares. Se o processo for aplicado de modo incorreto ou ineficaz, bem como as
medições e os critérios de qualidade, podemos afirmar que a equipe não está efetuando a
verificação e a validação da qualidade nem medindo os processos.

10. Garantia da qualidade, verificação e validação
Por que é necessário medir, verificar e validar os processos? De acordo com Park (1996), há
quatro razões para que essas ações sejam efetuadas nos processos de software:
●Caracterizar: esforço para obter conhecimento de processos, produtos, recursos e ambientes, e
estabelecer linhas de base para comparações com avaliações futuras.
●Avaliar: para determinar o status com relação aos planos.
●Prever: entender as relações entre os processos e produtos, criando modelos dessas relações. Exemplo:
valores observados para prever alguns atributos podem ser utilizados para prever outros.
●Melhorar: identificar etapas, causas-raiz do problema, ineficiência e outras oportunidades de melhoria
da qualidade do produto e desempenho do processo (PARK, 1996, p. 3).

11. Garantia da qualidade, verificação e validação
Segundo Koscianski e Soares (2007, p. 332), “as técnicas de verificação e validação são
fundamentais para identificar se um software possui defeitos e se está de acordo com o
especificado”. Assim, as atividades relacionadas à verificação e à validação da qualidade do
software asseguram que ele atenda aos requisitos elencados.
Essas atividades envolvem os processos de revisão dos requisitos, da análise e do projeto do
software, associados às inspeções do código, até se chegar aos testes.

12. Garantia da qualidade, verificação e validação
Ademais, devemos salientar que a verificação de um software não é igual à validação dele,
visto que, conforme expõe Santos (2012, on-line), “a verificação é uma atividade que envolve a
análise de um sistema para certificar se este atende aos requisitos funcionais e não funcionais.
Já a validação é a certificação de que o sistema atende às necessidades e expectativas do
cliente”.

13. Garantia da qualidade, verificação e validação
Os dois tipos de testes, verificação e validação, são fundamentais para garantir a qualidade do
software. A verificação vai além de apenas apontar se o software está em conformidade com
as especificações, pois analisa se o software faz o que o cliente espera que ele faça.
A validação, por sua vez, é essencial para identificar problemas e pontos de melhoria, visto
que, nem sempre, as necessidades ou os desejos dos clientes são apresentados nos
requisitos.

14. Garantia da qualidade, verificação e validação
Portanto, o objetivo final dos processos de verificação e validação é estabelecer a confiança de
que o software está “pronto para seu propósito”. Isso significa que o sistema deve ser bom o
suficiente para seu intuito. “O nível de confiança exigido depende do propósito do sistema, das
expectativas dos usuários do sistema e do atual ambiente de marketing” (SOMMERVILLE,
2011, p. 145).

16. Modelo de qualidade de software em “U”

17. Modelo de qualidade de software em “U”
A verificação e a validação da qualidade do software estão associadas a
diversas fases do processo de desenvolvimento; cada fase pode estar
relacionada a uma verificação ou uma validação, mas, geralmente, as duas
técnicas não são aplicadas em uma mesma fase.
Bartié (2002) propôs o modelo de qualidade de software em U, que enumera
as fases do projeto e associa essas fases a um tipo de teste, verificação ou
validação. Esse modelo é denominado “em U” devido à forma como as fases
são dispostas no diagrama e separadas pelos testes de verificação e validação.

18. Visão do modelo de processo de qualidade de software em “U”
Fonte: Bartié (2002, p. 36).
Modelo de qualidade de software em “U”

19. Modelo de qualidade de software em “U”
De acordo com Bartié (2002, p. 35),
o objetivo do processo de qualidade é garantir que durante o ciclo de
desenvolvimento o software produza efetivamente todos os produtos previstos
na metodologia empregada e que o aplicativo que está sendo construído esteja
adequado com os requisitos documentados.
Os testes de verificação visam garantir o processo de engenharia do software,
enquanto os testes de validação estão focados na garantia da qualidade do
produto de software.

20. Modelo de qualidade de software em “U”
Nas fases de teste de verificação, o software está em desenvolvimento e ainda
não foi entregue.
Por sua vez, os itens associados à validação estão mais relacionados à entrega
final, ou seja, mais próximos do resultado final.
Outro ponto a ser analisado é a ordem numérica, pois Bartié (2002) separa a
fases em oito: as quatro primeiras estão no quadrante da verificação e as
demais estão no quadrante da validação.

21. Modelo de qualidade de software em “U”
Você pode estar se perguntando: no caso de o projeto já estar na fase 6, mas
sofrer alguma modificação que o faça voltar para a fase 2, os processos se
cruzam? No cenário apresentado, o teste de validação é interrompido e uma
nova fase de verificação entra em vigor.

22. Modelo de qualidade de software em “U”
Se os passos apresentados forem seguidos e se forem aplicados os testes
adequados, podemos assegurar que a qualidade está garantida, mesmo em
um cenário difícil.
Ressaltamos que, no cotidiano, é complicado uma empresa seguir essas fases
e testes, devido aos prazos, custos ou a outros contratempos, mas, se o
objetivo for obter um produto de qualidade, o teste e o processo são válidos

23. Formas básicas de um teste

24. Formas básicas de um teste
Para garantir a qualidade do software, é preciso aplicar processos,
como os testes de verificação e validação. As formas básicas de um
teste são aplicadas em dois momentos, sendo que a primeira fase
corresponde à coleta de informações e ao planejamento da arquitetura
do software.
Nessa fase, os esforços estão centrados em criar um perfeito
entendimento das regras do negócio que devem ser aplicadas no
software a ser construído

25. Formas básicas de um teste
Ainda em relação à primeira fase, Bartié (2002, p. 36) afirma que,
nesse momento, não existem componentes tecnológicos, mas sim
documentos que especificam o comportamento a ser assimilado pelo
software a ser construído, como se estivéssemos criando uma grande
maquete do projeto de software – é nesse primeiro momento que uma
forma básica de teste destaca-se: os testes de verificação.

26. Formas básicas de um teste
Esses testes são aplicados sobre as modelagens e os diagramas,
elaborados para compreender se o software a ser desenvolvido está
sendo desenvolvido de acordo com os requisitos levantados.
Por sua vez, a segunda fase está associada a um produto acabado ou
protótipo e, nesse caso, já é possível interagir com o software
desenvolvido. Nessa fase, já existe um componente computacional, que
também pode ser um módulo completo ou apenas algumas
funcionalidades.

27. Formas básicas de um teste
De acordo com Bartié (2002, p. 36), na segunda fase
devemos aplicar um conjunto de testes que avaliam a qualidade do
produto de software desenvolvido em relação aos requisitos
identificados nas fases anteriores – é neste momento que a outra forma
básica de teste aparece: os testes de validação.

28. Formas básicas de um teste
Esse tipo de teste é muito importante para se atingir a qualidade do
produto, visto que pode ser feito junto ao cliente, a fim de coletar os
dados diretamente mediante a interação dele com o software
desenvolvido.
Portanto, essas duas formas básicas de teste de qualidade de software,
verificação e validação, identificam se o projeto está seguindo o escopo
e se o que foi entregue está dentro do esperado.

29. Teste = verificação + validação

30. Teste = verificação + validação
Quando o assunto é a qualidade de software, há vários testes que,
juntos, proporcionam um resultado satisfatório.
Como já evidenciado em nossas aulas, um bom teste une a verificação e
a validação do software, mas, infelizmente, algumas empresas aplicam
apenas os testes de validação, quando, na verdade, a verificação inicial
do andamento do projeto pode ser crucial.

31. Teste = verificação + validação
Os maiores erros de um software são cometidos nos processos iniciais
de seu desenvolvimento, devido à falta de verificação, o que gera um
custo elevado para consertar as falhas identificadas na fase de teste de
validação.
Isso porque a quantidade de erros e falhas pode crescer
exponencialmente a cada novo teste de validação.

32. Teste = verificação + validação
Segundo Bartié (2002, p. 37), apesar de ser muito positivo o fato de
algumas empresas construírem ambientes para a realização dos testes
de validação, estas não estão dirigindo seus esforços para as fases
iniciais do processo de software, portanto, os custos de correções
dessas organizações e o número de incidência de erros nos softwares
desenvolvidos serão muito altos nas fases de testes de validação.

33. Teste = verificação + validação
Com base nesse contexto, podemos afirmar que os testes de verificação
e validação se complementam, logo, uma empresa desenvolvedora de
software não pode pensar, de forma alguma, que essas atividades são
redundantes.
Cada tipo de teste tem determinadas funções, assim, tem naturezas e
objetivos distintos, mas ambos fortalecem a detecção de erros e
aumentam a qualidade do software final.

34. Teste = verificação + validação
Corroborando, Bartié (2002, p. 37) afirma que “um bom processo de
qualidade de software deverá potencializar essas duas formas de testes
de modo que os esforços sejam minimizados e os resultados sejam os
mais positivos possíveis”.
Portanto, um teste de qualidade eficiente une os dois tipos de testes,
que são complementares e, mesmo com funções distintas, buscam o
mesmo objetivo: a qualidade do software.

35. Testes de verificação

36. Testes de verificação
Os processos de testes de verificação do projeto de software podem ser
compreendidos como processos de auditoria de atividades e avaliação de
documentos durante as fases iniciais do projeto.
As verificações podem ser feitas em tudo que deriva do produto principal, como
código-fonte, documentos, manuais, gráficos, dentre outros elementos gerados
em cada fase inicial.
Com base no modelo de qualidade de software em U, essas fases iniciais estão
ilustradas:

37. Testes de verificação
Etapas dos testes de verificação
Fonte: Bartié (2002, p. 38).

38. Testes de verificação
você pode estar se perguntando: por que efetuar o teste de verificação nessas
etapas? Para se evitar dúvidas e assuntos mal compreendidos e que podem
migrar para as próximas fases.
O resultado é uma redução nos níveis de retrabalho, uma vez que esses
defeitos não passam para as etapas de construção do software.

39. Testes de verificação
Segundo Bartié (2002), a principal característica dos testes de verificação é o
fato de eles não envolverem o processamento de softwares.
“Na verdade, essas atividades antecedem a criação do aplicativo, exatamente
para garantir que todas as decisões e definições estabelecidas foram
adequadamente entendidas e aceitas pelos diversos grupos que integrarão o
processo de desenvolvimento” (BARTIÉ, 2002, p. 38).

40. Testes de verificação
No momento de levantar e definir os requisitos e as tecnologias a serem
utilizadas, diversas ações devem ser aplicadas, para garantir a qualidade do
material nas etapas de desenvolvimento. Assim, esse material deve ser
revisado e auditado, para atender à qualidade do software entregue.
Na verificação, o software ainda não será utilizado, pois, nessa etapa, há as
fases de modelagem e compreensão do projeto, logo, são utilizadas somente
as documentações envolvidas nas fases iniciais do projeto.

41. Testes de validação

42. Testes de validação
Os testes de validação correspondem aos processos de avaliação do produto
final junto ao cliente, sendo avaliados componentes isolados, módulos ou o
sistema completo.
Com esses testes, o objetivo é avaliar a conformidade do software, com base
nos requisitos e nas especificações levantadas nas etapas iniciais do projeto, a
fim de verificar se o produto atendeu ao esperado.

43. Testes de validação
Assim, conforme expõe Bartié (2002),
os testes serão baseados no comportamento do software, segundo diversas
condições que serão simuladas, para que sejam comparados com as
especificações produzidas pela área de negócios.
Na maioria dos casos, esses testes expõem mais sintomas do que
propriamente erros, ou seja, a maioria dos defeitos de um software não se
apresenta na forma mais explícita, como uma interrupção do processamento
ou uma não-execução de uma funcionalidade, os resultados do processamento
dos softwares serão os principais pontos de validação (BARTIÉ, 2002, p. 39).

44. Testes de validação
Os testes de validação acontecem nas fases finais, como demonstra o modelo
de qualidade de software em U.

45. Testes de validação
No decorrer do desenvolvimento do software, determinadas categorias de
testes devem ser aplicadas, por meio de ferramentas, técnicas ou abordagens,
para verificar ou validar o software.
Algumas atividades, como planejamento, modelagem, execução e coleta de
dados dos testes, devem ocorrer em paralelo ao desenvolvimento ou à
implementação do software

46. Testes de validação
Assim como a verificação, para ser aplicada, a validação também deve seguir
alguns estágios, como:
●Testes em componentes executáveis isolados recém-criados e alterados.
●Testes de interface entre componentes à medida que eles vão sendo
integrados.
●Testes em sistemas ou módulos completos.
●Aceite de um sistema ou módulos pelos clientes e usuários (BARTIÉ, 2002, p.
39).

47. Testes de validação
Durante o processo de validação, podem ser aplicados os testes de validação,
como caixa-branca, caixa-preta, performance, interação, interface, usabilidade,
funcionalidade, segurança, dentre outros.
A partir da validação do software, é possível gerar documentos que podem ser
utilizados em conjunto com uma auditoria de sistemas, que confronta os testes
de validação efetuados na época do desenvolvimento e verifica se, no
momento atual, está tudo correto.

48. Testes de validação
Ambos os testes, verificação e validação, são essenciais para um software
bem-sucedido, pois todas as fases são controladas e planejadas, desde o início
até o fim.
Desse modo, todos os envolvidos podem ter uma melhor compreensão acerca
do andamento do software em cada fase, para que haja o mais alto nível de
qualidade.

49.  A maior parte é de origem humana
 São gerados na comunicação e na
transformação de informações
 Continuam presentes nos diversos produtos de software
produzidos e liberados (10 defeitos a cada 1000 linhas de
código)
 A maioria encontra-se em partes do código raramente
executadas

50.  Principal causa: tradução incorreta de informações
 Quanto antes a presença do defeito for revelada, menor o custo
de correção do defeito e maior a probabilidade de corrigi-lo
corretamente
 Solução: introduzir atividades de VV&T ao longo de todo o
ciclo de desenvolvimento

51.  Teste
 Depuração
Processo de executacao de um programa com
o objetivo de revelar a presença de erros.
Conseqüência não previsível do teste. Após revelada a
presença do erro, este deve ser encontrado e corrigido.
Contribuem para aumentar a confiança de que o software
desempenha as funções especificadas.

52.  Fundamental em todos os ramos de engenharia
 Software: produto da Engenharia de Software
 Atividade essencial para ascensão ao nível 3 do Modelo
CMM/SEI
 Atividade relevante para avaliação da
característica funcionalidade
(ISO 9126,14598-5)

53.  Inexistência de erro:
 Software é de alta qualidade?
 Conjunto de casos de teste T é de baixa qualidade?
?
D P
X
T
Objetivo: revelar a presença de erros

54.  Defeitos e erros não revelados
 Falhas se manifestam durante a utilização pelos usuários
 Erros devem ser corrigidos durante a manutenção
 Alto custo

55.  Falhas graves
 Qualidade e confiabilidade suspeitas
 Modificação do projeto
 Novos testes
 Erros de fácil correção
 Funções aparentemente funcionam bem
 Qualidade e confiabilidade aceitáveis
 Testes inadequados para revelar a presença de erros graves
 Novos testes

56.  Limitações
 Não existe um algoritmo de teste de propósito geral para provar a
corretitude de um programa
 Em geral, é indecidível se dois caminhos de um mesmo
programa ou de diferentes programas computam a mesma função
 É indecidível se existe um dado de entrada que leve à
execução de um dado caminho de um programa; isto é, é
indecidível se um dado caminho é executável ou não

57. 15
Atividades de
Teste
Configuração
de Software
Configuração
de Teste
Avaliação
Resultados
de Teste
Resultados
Esperados
Dados
da Taxa
de Erros
Modelo de
Confiabilidade
Erros
Depuração
Correções
Confiabilidade
Prevista

58.  Fases de Teste
 Teste de Unidade
 Identificar erros de lógica e de implementação em cada módulo do
software, separadamente
 Teste de Integração
 Identificar erros associados às interfaces entre os
módulos do software
 Teste de Sistema
 Verificar se as funções estão de acordo com a especificação e se todos os
elementos do sistema combinam-se adequadamente

59.  Etapas do Teste
 Planejamento
 Projeto de casos de teste
 Execução do programa com os casos de teste
 Análise de resultados

60.  Caso de teste
 Especificação de uma entrada para o programa e a
correspondente saída esperada
 Entrada: conjunto de dados necessários para uma execução do
programa
 Saída esperada: resultado de uma execução do programa
 Um bom caso de teste tem alta probabilidade de revelar um erro
ainda não descoberto

61.  Projeto de casos de teste
 O projeto de casos de teste pode ser tão difícil quanto o projeto do
próprio produto a ser testado
 Poucos programadores/analistas gostam de teste e, menos ainda, do
projeto de casos de teste
 O projeto de casos de teste é um dos melhores mecanismos para a
prevenção de defeitos
 O projeto de casos de teste é tão eficaz em identificar erros quanto a
execução dos casos de teste projetados

62.  Técnica Funcional
 Requisitos funcionais do software
 Critério Particionamento em Classes de Equivalência
 Técnica Estrutural
 Estrutura interna do programa
 Critérios Baseados em Fluxo de Dados
 Técnica Baseada em Erros
 Erros mais freqüentes cometidos durante o processo de
desenvolvimento de software
 Critério Análise de Mutantes

63.  Ferramentas de Teste
 Contribuem para reduzir as falhas produzidas pela intervenção
humana
 Aumento da qualidade e produtividade da atividade de teste
 Aumento da confiabilidade do software
 Facilitam a condução de estudos comparativos entre critérios
Para a aplicação efetiva de um critério de teste faz-se necessário o uso de
ferramentas automatizadas que apóiem a aplicação desse critério.

64.  Critérios Estruturais: Fluxo de Dados
 Asset, Proteste – programas em Pascal
 xSuds – programas em C, C++ e Cobol
 Poke-Tool – programas em C, Cobol e Fortran
 Critérios Baseados em Mutação
 Mothra – programas em Fortran
 Proteum – programas em C (unidade)
 Proteum/IM – programas em C (integração)
 Proteum/RS – especificações

65.  xSuds (Software Understanding &
Diagnosis System)
 xAtac: teste
 xSlice: depuração
 xVue: manutenção
 xProf: melhoria de performance
 xDiff: comparação de código
Estado da Arte X Estado da Prática

66.  Baseia-se na especificação do software para derivar os
requisitos de teste
 Aborda o software de um ponto de vista macroscópico
 Envolve dois passos principais:
 Identificar as funções que o software deve realizar
(especificação dos requisitos)
 Criar casos de teste capazes de checar se essas funções estão sendo
executadas corretamente

67.  Problema
 Dificuldade em quantificar a atividade de teste: não se pode garantir
que partes essenciais ou críticas do software foram executadas
 Dificuldade de automatização
 Critérios da Técnica Funcional
 Particionamento em Classes de Equivalência
 Análise do Valor Limite
 Grafo de Causa-Efeito

68.  Baseada no conhecimento da estrutura interna
(implementação) do programa
 Teste dos detalhes procedimentais
 A maioria dos critérios dessa técnica utiliza uma
representação de programa conhecida como grafo de
programa ou grafo de fluxo de controle

69.  Grafo de Programa
 Nós: blocos “indivisíveis”
 Não existe desvio para o meio do bloco
 Uma vez que o primeiro comando do bloco é executado, os demais
comandos são executados seqüencialmente
 Arestas ou Arcos: representam o fluxo de controle entre os
nós

70. /* 01 */ {
/* 01 */ char achar;
/* 01 */ int length, valid_id;
/* 01 */ length = 0;
/* 01 */ printf (“Identificador: “);
/* 01 */ achar = fgetc (stdin);
/* 03 */ achar = fgetc (stdin);
/* 04 */ while (achar != 'n')
/* 05 */ {
Identifier.c (função main)
01
02
03
/* 01 */ valid_id = valid_s(achar); 04
/* 01 */ if (valid_id)
/* 02 */ length = 1;
05 08
/* 05 */ if (!(valid_f(achar))) 06 09 10
/*
/*
/*
06
07
07
*/
*/
*/
valid_id = 0;
length++;
achar = fgetc (stdin); 07 11
/* 07 */ }
/* 08 */ if (valid_id && (length >= 1) && (length < 6) )
/* 09 */ printf (“Validon“);
/* 10 */ else
/* 10 */ printf (“Invalidon“);
/* 11 */ }

71. Grafo de Programa
 Detalhes considerados
 nó
 arco
 caminho
 simples (2,3,4,5,6,7)
 completo
(1,2,3,4,5,6,7,4,8,9,11)
 fluxo de controle
Grafo de Programa do identifier
Gerado pela View-Graph

72.  Os requisitos de teste são derivados a partir dos erros mais
freqüentes cometidos durante o processo de desenvolvimento
do software
 Critérios da Técnica Baseada em Erros
 Semeadura de Erros
 Teste de Mutação
 Análise de Mutantes (unidade)
 Mutação de Interface (integração)

73.  Hipótese do Programador Competente
 Efeito de Acoplamento
Programadores experientes escrevem programas corretos ou muito
próximos do correto.
Casos de teste capazes de revelar erros simples são tão sensíveis que,
implicitamente, também são capazes de revelar erros mais complexos.

74.  Passos da Análise de Mutantes
1- Geração de Mutantes
Para modelar os desvios sintáticos mais comuns,
operadores de mutação são aplicados a um programa,
transformando-o em programas similares: mutantes.
Mutante
s
P1
Pn
P3
P2
P4
Operadore
s de
Mutação
P
Program
a em
Teste

75. Seleção dos operadores de mutação
Abrangente
Capaz de modelar a maior parte dos erros
Pequena cardinalidade
Problemas de custo
Quanto maior o número de operadores
utilizados, maior o número de mutantes gerados

76. Técnica de Análise de Mutantes, um "Mutante
Gerado pelo Operador OLAN" refere-se a uma versão
modificada do programa original onde um operador
lógico foi substituído por um operador aritmético.
O operador OLAN (Logical AND to Arithmetic AND)
altera a operação lógica "&&" (E lógico) para a
operação aritmética "*" (multiplicação).

77. Técnica de teste de mutação em engenharia
de software, um "Mutante Gerado pelo
Operador ORRN" refere-se a uma versão
modificada do programa original onde um
operador relacional foi substituído por outro
operador relacional.

78. O operador ORRN (Operador Relacional
Substituído por Outro Operador Relacional)
altera comparações relacionais no código para
introduzir possíveis defeitos e, assim, avaliar a
eficácia dos casos de teste em detectar erros.

79.  Exemplo de Mutantes
Mutante Gerado pelo Operador ORRN
if (valid_id && (length >= 1) && (length <= 6) )
printf ("Validon");
else
printf ("Invalidon");
Mutante Gerado pelo Operador OLAN
if (valid_id * (length >= 1) && (length < 6) )
printf ("Validon");
else
printf ("Invalidon");