AOL 04

Prévia do material em texto

Nesta unidade você verá:
// padrões de projeto   
// teste de software 
// inspeção e revisão de software
Course Outline
1. 
Objetivos
2. 
Padrões de projeto
3. 
Teste de software
4. 
Inspeção e revisão de software
Seção 1 de 4
Objetivos
UNIDADE 3.
Padrões e teste de qualidade de software
Estelamaris Pellissari 
OBJETIVOS DA UNIDADE
· Conhecer os padrões de projeto de software;
· Compreender a importância do teste de software;
· Abordar tipos de testes de software;
· Apresentar ao aluno conceitos de inspeção e revisão de software;
· Compreender os processos de revisão, etapas e os tipos de defeitos de software.
TÓPICOS DE ESTUDO
Clique nos botões para saber mais
Padrões de projeto
–
// Padrões de projeto criacionais
// Padrão de projeto de classe abstrata
// Padrões estruturais
// Padrões comportamentais
Teste de software
–
// Tipos de testes de software
Inspeção e revisão de software
–
// Processo de revisão
// Inspeção
// Etapas 
// Tipos de defeitos encontrados em cada aspecto 
Seção 2 de 4
Padrões de projeto
Na engenharia de software, padrão de projeto é uma solução geral repetível para um problema comumente ocorrido no projeto de software. O padrão de projeto não é um desenho acabado que pode ser transformado diretamente em código, é uma descrição ou modelo de como resolver um problema que pode ser usado em muitas situações diferentes. Em outras palavras, significa desenhar diferentes formas para resolver um mesmo problema.
Padrões de projeto podem acelerar o processo de desenvolvimento, fornecendo paradigmas de desenvolvimento testados e comprovados. O padrão de projeto pode ser útil para consideração de problemas que podem não se tornar visíveis antes da implementação. A sua utilização ajuda a evitar pequenos problemas que podem se tornar grandes em fases mais avançadas do processo de desenvolvimento e melhora o entendimento do código para desenvolvedores e arquitetos familiarizados com os padrões.
O grande problema que temos em padrões de projetos é que, muitas vezes, as pessoas só entendem como aplicar determinadas técnicas de padrão de projeto a certos problemas. No entanto, essas técnicas são difíceis de se aplicar a uma gama maior de problemas. Isso acontece pois os padrões de projeto fornecem soluções gerais, documentadas em um formato que não exige detalhes que estejam ligados a um problema em específico.
Além disso, os padrões permitem que os desenvolvedores se comuniquem melhor, usando nomes bem conhecidos e bem entendidos para interações durante o processo de desenvolvimento de software. Padrões comuns de projeto podem ser melhorados ao longo do tempo, tornando-se mais robustos.
ASSISTA
Para entender melhor sobre Padrões de Projetos, assista o vídeo Design Patterns - Dicionário do Programador, do canal Código Fonte TV. O link se encontra nas referências bibliográficas. 
Fundamental para qualquer ciência ou disciplina de engenharia é um vocabulário comum para expressar seus conceitos, e uma linguagem para relacioná-los juntos. O objetivo dos padrões dentro da comunidade de software é criar um corpo de literatura para ajudar os desenvolvedores de software a resolver problemas recorrentes encontrados em todo o desenvolvimento de software. Os padrões ajudam a criar um idioma compartilhado para comunicar ideias e experiências sobre esses problemas e suas soluções. Codificar formalmente essas soluções e seus relacionamentos nos permite capturar com êxito o conjunto de conhecimentos que define nossa compreensão de boas arquiteturas que atendem às necessidades de seus usuários. Formar uma linguagem padrão comum para transmitir as estruturas e mecanismos de nossas arquiteturas nos permite raciocinar inteligivelmente sobre elas. O foco principal não é tanto na tecnologia quanto na criação de uma cultura para documentar e dar suporte à arquitetura e design de engenharia de som.
PADRÕES DE PROJETO CRIACIONAIS
Os padrões de projeto criacionais servem para desenhar a instanciação de classes. Esse padrão pode ser dividido em padrões criacionais de classes e de objetos. Embora os padrões de classe usem a herança de maneira eficaz no processo de instanciação, os de objetos usam as técnicas de maneira eficaz para realizar o trabalho. 
Todos os padrões criacionais tratam de instanciar objetos da melhor maneira. Exemplo: “Classe Criadora” especial pode tornar o programa mais flexível e geral.
EXEMPLIFICANDO
O padrão de projeto criacional garante que, para uma classe específica, possa existir somente uma única instância, a qual é acessível de forma global e uniforme. Dessa forma, uma classe Singleton irá: 
· Armazenar a única instância existente;
· Garantir que apenas uma instância será criada;
· Prover acesso a tal instância.
Exemplos práticos:
· Um sistema de arquivos, gerenciador de janelas, tabela de salários (ajuste), leitor de teclado, entre outros.
Na Figura 1, é possível visualizar como a classe Singleton é representada.
Figura 1. Exemplo da Classe Singleton.
PADRÃO DE PROJETO DE CLASSE ABSTRATA
Fornece uma interface para criar classes de objetos relacionados ou dependentes sem especificar suas classes concretas. Uma hierarquia que encapsula muitas "plataformas" possíveis e a construção de um conjunto de "produtos". Se uma aplicação for portável, ela precisa encapsular as dependências da plataforma. 
Essas "plataformas" podem incluir: sistema de menus, sistema operacional, banco de dados, etc. Muitas vezes esse encapsulamento não é planejado antecipadamente e muitas instruções com opções para todas as plataformas suportadas atualmente começam a repetir em todo código (Diagrama 1).
Diagrama 1. Exemplo genérico de padrão de projetos de classe abstrata.
PADRÕES ESTRUTURAIS
Este tipo de padrão de projeto é interessante quando se deseja compor objetos em estruturas de árvore para representar hierarquias todo-parte. Permite que clientes tratem objetos individuais e compostos de maneira uniforme.
Eles descrevem como classes e objetos podem ser combinados para formar grandes estruturas. Objetos padrões descrevem como objetos podem ser compostos em grandes estruturas utilizando composição ou inclusão de objetos com outros objetos.
PADRÕES COMPORTAMENTAIS
Este tipo de padrão de projeto descreve padrões de comunicação entre objetos ou classes, caracterizando o modo como classes e objetos interagem e compartilham responsabilidades. Existem situações onde diversos objetos (visualizações) devem representar um outro objeto (dados). 
Funciona da seguinte forma: 
· 1
Define uma relação de dependência, de forma que quando um certo objeto (assunto) tem seu estado modificado, os demais (observadores) são notificados;
· 2
Possibilita baixo acoplamento entre os objetos observadores e o assunto.
Seção 3 de 4
Teste de software
De acordo com Amaral et al., em Metodologias de teste de software, de 2009, devido aos métodos de desenvolvimento e complexidade dos softwares, eles são altamente passiveis a erros. Esses erros podem ocorrer devido a problemas na especificação dos requisitos, na modelagem de negócio, no modo que a funcionalidade deve ser desempenhada, na complexidade do sistema e na mudança de requisitos. Todos os desenvolvedores estão suscetíveis a erros de programação, já que esses sistemas possuem alto grau de complexidade. Para solucionar e evitar tal problemática, existe uma atividade em que se pode avaliar, testar e corrigir tais problemas, denominada teste de software, que é feita de diversas maneiras e usando diversas metodologias, podendo ser vista como uma parcela do processo que garante a qualidade de software.
A atividade de teste de software consiste em uma das etapas do desenvolvimento de um software cujo objetivo primordial é avaliar a possibilidade e a existência de erros no sistema, para que então possam ser solucionados ou evitados futuramente. Essa etapa busca verificar se o sistema se comporta de acordo com o especificado nos requisitos levantados junto ao cliente, reduzindo a probabilidade de erros quando o sistema estiverem produção. 
Neto, em seu artigo "Introdução a testes de software" na revista Engenharia de software magazine, de 2015, declara que o teste de software busca a execução de um determinado sistema para avaliar se alcançou os objetivos propostos, como também se processa corretamente para o seu fim específico. Portanto, o teste de software tem como objetivo principal verificar se o sistema possui falhas, para que elas sejam eliminadas antes da entrega para o cliente.
Durante a década de 70, a ideia dos testes de softwares começava a ser sedimentada, sendo um processo dependente de várias etapas e não só a revisão de códigos de linguagens. Este novo conceito trouxe inúmeros aspectos positivos para o setor de TI, porém não houve redução de custos, já que se testava o software desde o início de seu desenvolvimento. Atualmente, os testes de softwares são mais eficientes e bem estruturados, o que gera menores custos durante a execução.
Ainda na década de 70, esses testes eram executados pelas próprias pessoas que desenvolviam o software, sendo que esse método de validação muitas vezes não era realizado, pois eram executados apenas se houvesse um tempo hábil. Porém, com o passar dos anos, com a alta demanda e concorrência acirrada do mercado, aumentou-se o nível de exigência por qualidade dos softwares e, assim, os testes sofreram inúmeras inovações. Além desse aspecto, sabe-se que a execução dos testes de softwares também influencia na avaliação do grau de qualidade, pois é uma forma de revisão final das especificidades esperadas pelo projeto.
Vale ressaltar que a execução adequada de tal atividade acarreta inúmeros benefícios, como a redução de custos, retrabalhos e o alinhamento da qualidade com a imagem institucional da empresa. Estima-se que defeitos de software tenham custado cerca de US$ 60 bilhões em 2007. Bancos e fabricantes de celulares são os segmentos mais dispostos a evitar tais erros e que mais investem na terceirização deste serviço.
Segundo Amaral et al. na obra já citada, Metodologias de teste de software, nos dias de hoje, o mercado na área de testes de software encontra-se em expansão e evolução. Esses testes devem ser assegurados por normas e por procedimentos escritos, a partir de órgãos certificados e qualificados mundialmente.  Esses órgãos são: o SW-CMM (modelo de maturidade em capacitação), SE-CMM (software de maturidade em capacitação), ISO 15504 (melhoria dos processos de desenvolvimento de software e a determinação da capacidade de processos de uma organização) e o mais conhecido CMMI (modelo de capacidade e maturidade integrado). Especificamente no Brasil, existem os orgãos IBQTS (Instituto Brasileiro de Qualidade em Testes de Software) e CBTS (Certificação Brasileira de Teste de Software).
No Brasil, grande parte das empresas utiliza da norma ISSO 9126 (NBR 13596 - padronização da avaliação da qualidade do software) sendo um certificado de qualidade do processo de software, a qual possui requisitos que garantem que ele mantenha um desempenho positivo conforme as condições esperadas. A norma busca definir sanções de qualidade para o software, avaliar as suas especificações durante o seu desenvolvimento para averiguar se estão sendo cumpridos, descrever as características e atributos do software em desenvolvimento e também verificar se o software desenvolvido possui realmente as especiações esperadas pelo cliente.
Sabe-se que durante a elaboração do software, os defeitos que aparecem podem advir das atividades do próprio programador que o desenvolve. Mesmo que sejam utilizados os métodos e as ferramentas apropriadas, os erros técnicos podem continuar presentes, por isso se faz necessário que haja a realização dos testes de softwares também nas suas etapas de elaboração.
TIPOS DE TESTES DE SOFTWARE
Conforme já mencionado, os erros ou defeitos podem surgir durante as etapas de desenvolvimento do software, por isso se faz necessária a utilização dos mais diversos testes, de acordo com o Quadro 1.
Quadro 1. Tipos de testes para concepção de um software. Fonte: NETO, 2015. (Adaptado).
Assim, durante o desenvolvimento do software, devem-se realizar os testes conforme explicitados no Quadro 1. No Diagrama 2, tem-se exemplificados os testes a serem utilizados em consonância com cada etapa da concepção do projeto.
Diagrama 2. Paralelismo entre as atividades de teste (à direita) e desenvolvimento (à esquerda). Fonte: ROCHA, 2018.
Conforme o Diagrama 2, a etapa de análise de requisitos deve ser associada ao teste de aceitação a partir dos referentes documentos de requisitos. Depois, deve-se realizar o teste de sistema de acordo com as especificações do projeto. Em seguida deve-se realizar o planejamento dos testes de integração a partir do desenho do sistema e, por fim, o teste unitário de acordo com desenho do componente.
A partir da codificação, são utilizadas diferentes técnicas de teste de software para confirmar que ele está sendo executado de maneira correta, ou seja, sem erros e sem que haja possibilidade de defeitos no futuro. Existem diversas técnicas que podem ser aplicadas neste momento e de diferentes formas para validar os aspectos principais do software, as quais são classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. As técnicas de teste existentes são: teste da caixa branca, teste da caixa-preta e o teste da caixa cinza.
O teste da caixa branca utiliza o aspecto interno do programa/sistema, especificamente o código fonte, para avaliar seus componentes como: fluxo dos dados, condição, ciclos, entre outros. Como não há o contato direto com o código do software, valida-se o resultado da compilação e/ou publicação através de um app mobile, um site na internet, um sistema desktop ou um serviço disponibilizado. Para implementá-lo, é preciso verificar o nível de qualidade que se pretende obter do programa.
O teste da caixa preta, ou técnica funcional, difere do anterior pois prioriza os aspectos externos sem levar em consideração o modo de funcionamento do sistema, já que o foco, neste caso, são atividades que o programa deve desempenhar. Para isso, é preciso averiguar se os dados de entrada são compatíveis com os de saída.
Também temos o teste da caixa cinza, que basicamente é a junção dos dois testes anteriormente explicitados. Este teste avalia os aspectos internos e também os externos. Faz-se uma engenharia reversa para analisar o código, para que haja o entendimento dos fatores limitantes e mensagens de erro que possam melhorar a construção de casos de testes (forma comumente utilizada para a definição de testes estruturados de acordo com as melhores práticas). Outras técnicas de teste podem ser utilizadas de acordo com necessidades de negócio ou em relação as restrições tecnológicas, sendo essas técnicas os testes de regressão, carga, usabilidade e de estresse.
A cada inovação do software, é imprescindível que haja a realização do teste de regressão, sendo possível avaliar se determinadas funcionalidades foram modificadas, o que evita que erros antigos que foram eliminados possam retornar com a nova função.
O teste de carga é feito para avaliar quanto o software suporta em questão de dados e de transferências, sem que ocorram erros. Já o teste de usabilidade é como um tipo de avaliação de satisfação do cliente, onde um determinado grupo de pessoas avalia as funcionalidades do sistema, as dificuldades na sua utilização e o que pode ser melhorado. Já o teste de estresse coloca o software na potência máxima de funcionamento para verificar se possui erros quando está nesse estado.  
EXPLICANDO
Existem sistemas críticos que não podem gerar erros em hipótese alguma, como o controle de tráfego aéreo, por exemplo, que compromete a vida da população caso apresente erros. Para esses sistemas, muitas empresas utilizam técnicas e metodologias, sendo elas a: injeção controlada de defeitos (ITool), a UMIL, testes automatizados e funcionais.
Os sistemas críticos utilizam informações através de linguagens de programação e podemser regulados conforme as adversidades. Neste caso, essa regulação é realizada por sensores e as linguagens de informação por equipamentos controladores; a atuação é conduzida por dispositivos atuadores. Caso haja falhas nesses dados, podem ocorrer acidentes irreversíveis e, por conta disso, é imprescindível a utilização de ferramentas e metodologias inovadoras que garantam a segurança. 
O processo de injeção controlada de defeitos e a análise desses defeitos na segurança do sistema é um tipo teste que foca nos defeitos introduzidos no início do desenvolvimento do software. 
Nakawaga e Maldonado, no artigo "ITOOL – Uma Ferramenta para injeção de defeitos de softwares", de 2013, suscitam que a injeção controlada de defeitos é uma técnica que avalia como o sistema se comporta perante eles, através de seus impactos na segurança de sistemas críticos.
A ferramenta denominada ITool foi desenvolvida seguindo os pressupostos da injeção controlada de defeitos, cujo principal objetivo é ajudar nos problemas associados aos sistemas críticos, e funciona através de etapas de teste manipulando condições que confrontam o programa original em relação ao que contém erros.
A ferramenta ITool estabelece quatro tipos de defeitos: entidade (caracteres associados a um defeito) mal-empregada, falta de entidade, entidade espúria e entidade simples incorreta. Estes tipos de defeitos são utilizados como mecanismos para resolução de problemas durante o desenvolvimento do software.
).
A UML (Unified Modeling Language) advém de um código de linguagem especifico associado ao desenvolvimento de sistemas orientados a objetos. Utiliza diagramas que representam o software em especifico, permitindo sua visualização por diferentes pontos. Com a versão 2.0 da UML, é possível utilizar pacotes de perfis.
A UML, quando associada ao padrão IEEE829, tem a funcionalidade de validar requisitos implementados que uniformizam diferentes pontos para geração de casos de testes e até mesmo para casos de testes de uso estendido.
Já está no mercado uma ferramenta de auxílio dos testes que foi baseada nas metodologias explicitadas. Ela possibilita documentação do projeto de teste, seus dados e o detalhamento dos procedimentos, que seguem os seguintes aspectos: 
· 1
1. Identificar a descrição do caso de uso e as suas vias secundarias;
· 2
2. Identificar pré-condições e pós-condições;
· 3
3. Desenvolver especificações de teste conforme cada caso;
· 4
4. Identificar as variáveis operacionais conforme cada caso;
· 5
5. Desenvolver os procedimentos para os testes.
A partir dessas novas metodologias e inovações de testes, Izabel, em sua monografia Testes automatizados no processo de desenvolvimento de softwares, de 2014, afirma que essas automatizações utilizam um software externo (que não faça parte do software que está sendo testado) para o controle da execução dos testes e para que haja um comparativo entre os resultados encontrados com os resultados esperados. Através desse processo, podem-se automatizar algumas tarefas de teste repetitivas ou adicionar novos testes mais específicos, que seriam difíceis de serem realizados manualmente.
Sabe-se que controlar a qualidade de software não é fácil, porém isso pode ser realizado através de métodos ágeis de desenvolvimento de software (programação extrema focada nos testes automatizados). Assim, a programação extrema, ou XP, é eficaz para equipes pequenas e médias que buscam desenvolver softwares com requisitos vagos e que sempre necessitam de alterações. Tal fato está relacionado à necessidade de acompanhamento constante e o continuo ajuste no software.
Os testes automatizados devem começar pelos testes pequenos, que podem ser realizados pelas ferramentas chamadas de arcabouços, como o JSUnit, CSUnit, entre outros. Outro tipo de teste importante é o de aceitação, já que envolve todas as etapas de desenvolvimento do sistema.
Os testes funcionais são caracterizados como o teste da caixa preta, anteriormente explicitado, porém de maneira automatizada. Estes tipos de testes fundamentam-se em duas perspectivas: determinar as funções que o software deve realizar e gerar casos de teste com possibilidade de verificar essas funções. Na verdade, não somente as funções, mas também pode-se testar pequenas partes dos componentes, como por exemplo, uma DLL.
Um exemplo de teste funcional é a ferramenta AFTT (Aspect-based Funcitional Testing Tool) presente em programas Java, a qual oferece suporte a alguns critérios funcionais. Ela disponibiliza uma interface gráfica que permite que o técnico responsável acesse as funcionalidades do software e, assim, os casos de teste podem ser executados e interrompidos conforme necessidade.
Diante de todo o desenvolvimento discursivo, pode-se inferir que o teste de software é uma das atividades mais trabalhosas do processo de desenvolvimento de um sistema em especifico, pois deve ser desenvolvido em diversas etapas e todas elas devem ser testadas para avaliar se o mesmo está dentro das especificações esperadas.
Ainda é preciso enfatizar o custo associado à criação do software, pois depende da criticidade da aplicação a ser desenvolvida, sempre levando em conta que diferentes perspectivas de projeto requerem uma preocupação diferenciada com as atividades de teste. Assim, a realização dos testes não compreende apenas a geração e execução de casos de teste, mas também um bom planejamento, gerenciamento e analise dos resultados.
C
Seção 4 de 4
Inspeção e revisão de software
Segundo Sommerville, em sua obra Engenharia de Software, de 2011, revisões e inspeções são atividades que têm o intuito de controlar o nível de qualidade dos entregáveis de projeto. Essas atividades envolvem um exame do software, de sua documentação e de seus registros de processos, a fim de descobrir erros e omissões e verificar se foram seguidos os padrões de qualidade. Revisões e inspeções são normalmente utilizadas junto com testes de programa, pois são uma parte do processo geral de validação e verificação de software.
No processo de uma revisão, um grupo de pessoas examina o software e a documentação associada em busca de prováveis problemas e não conformidade com padrões. A equipe gera documentos de avaliação do entregável conforme o nível de qualidade foi solicitado e, com isso, toma decisões sobre o entregável.
Essas avaliações de qualidade têm como base documentos que foram produzidos durante o processo de desenvolvimento de software, que são: as especificações de software, projetos ou códigos, modelos de processos, planos de testes, procedimentos de gerenciamento de configuração, padrões de processo e manuais de usuário. A revisão tem como objetivo verificar a consistência e a integridade dos documentos ou código em revisão e atestar que os padrões de qualidade foram seguidos. 
No entanto, as revisões não têm como finalidade apenas validação da conformidade com os padrões. Elas também são úteis em ajudar a descobrir problemas e omissões no software ou em sua documentação de projeto, sendo que as conclusões das revisões são processos de gerenciamento e devem ser formalmente apontadas como parte do processo. Caso sejam encontrados problemas, os revisores devem enviar seus comentários aos autores do software ou ao responsável por corrigir os erros ou as omissões.
As revisões e inspeções têm como objetivo garantir a melhoria da qualidade de software e não avaliar o desempenho dos indivíduos que compunham a equipe de desenvolvimento, sendo um processo público de detecção de erros, em comparação com processos de testes de componente mais privados. 
Precisamente, alguns erros cometidos por indivíduos são revelados a toda a equipe de programação. Mas a fim de garantir que todos os desenvolvedores continuem engajados no processo de revisão, os gerentes de projeto precisam estar atentos às preocupações individuais. É necessário que uma cultura de trabalho seja desenvolvida a fim de fornecer suporte sem procurar os culpados pelos erros descobertos.
PROCESSO DE REVISÃO
Existem muitas variações na modelagemdo processo de revisão, mas normalmente ele é composto de algumas fases.
Uma revisão tem por objetivos:
· Verificar se o artefato produzido satisfaz as especificações elaboradas em fases anteriores;
· Identificar os desvios com relação aos padrões estabelecidos, inclusive fatores que afetem a manutenibilidade;
· Sugerir melhorias;
· Promover a troca de conhecimento entre os participantes;
· Tornar o projeto, como um todo, mais viável.
Revisões estão incluídas no SEI Capability Maturity Model (CMM) como uma área-chave de processo (KPA) de nível 3. O Capability Maturity Model Integration (CMMI), que engloba software, engenharia de sistemas e desenvolvimento integrado de produtos, inclui a revisão como uma área do processo de verificação do produto.
// Características de Revisão
Clique nos botões para saber mais
O processo
–
O processo de revisão é bem estruturado, dividido em fases e com procedimentos a serem realizados em cada fase.
Equipe
–
O número de pessoas envolvidas deve ser pequeno (de 3 a 5). Pessoas possuem papéis definidos na equipe: autor, revisor, etc.
Diretrizes
–
Os participantes devem receber o produto e a documentação associada dias antes da reunião. A reunião tem duração pré-fixada (2 horas).
Saídas
–
Ata ou minuta da reunião e lista de itens a serem corrigidos.
Uma revisão é uma leitura crítica do artefato e de sua documentação. Para isso, são realizadas anotações da seguinte forma:
· Os problemas encontrados;
· Dúvidas e dificuldades de compreensão;
· Possibilidades de melhorias.
Alguns exemplos de artefatos do processo de desenvolvimento de software são:
· Especificações;
· Modelos;
· Projetos;
· Código;
· Casos de teste;
· Processos de desenvolvimento;
· Planos;
· Padrões;
· Arquivos de auxílio para o usuário;
· Documentação para o usuário;
· Teses, dissertações.
Revisão é uma atividade na qual um artefato de software pode ser observado pela equipe do projeto, gerentes, usuários, clientes ou outras partes interessadas. O objetivo da revisão é garantir que o artefato de software esteja em conformidade com suas especificações, além de verificar se seu desenvolvimento está de acordo com os planos, padrões e diretrizes aplicáveis para o projeto.
De acordo com inúmeros autores, a revisão, quando praticada, encontra de 60% a 80% do total dos problemas que podem ser encontrados em todo o ciclo de desenvolvimento. Pode-se economizar aproximadamente 40% do custo total de desenvolvimento quando se praticam revisões.
INSPEÇÃO
De acordo com Sommerville, em sua obra já citada, as inspeções de programa são “revisões em pares” em que os membros da equipe colaboram para encontrar bugs no programa que está sendo desenvolvido. As inspeções podem fazer parte dos processos de verificação e validação de software. Elas complementam os testes, pois não exigem que o programa seja executado. Isso significa que podem ser verificadas versões incompletas do sistema e que representações, tais como modelos UML, podem ser checados.
As inspeções são técnicas estáticas de V&V realizadas sem que seja preciso executar o software. Elas são aplicadas em:
Clique nos botões para saber mais
Podem ser realizadas em todas as etapas do ciclo de vida de desenvolvimento do software.
O conceito de inspeção foi introduzido pela IBM na década de 70 e trata-se de uma técnica formal para revisão visual de artefatos de software para detectar erros, violações de padrões de desenvolvimento e outros problemas. A inspeção é muito rigorosa e os inspetores são treinados em técnicas de inspeção. Essa técnica é aplicada amplamente para revisar código de programa.
O objetivo das inspeções é verificar se o artefato de software satisfaz as especificações estando de acordo com os padrões aplicáveis, identificar desvios e coletar dados de engenharia de software como defeito e esforço.
É importante praticar a técnica de inspeção, pois através dela é possível identificar até 67% do total de defeitos durante o desenvolvimento. Desses defeitos, 82% referem-se a design e código.
O Diagrama 3 a seguir descreve um esquema de inspecionamento em todos os processos que contemplam o desenvolvimento de um sistema de qualidade.
Diagrama 3. Teste de inspeção. Fonte: SOMMERVILLE, 2011. (Adaptado).
Prós e contras da realização de inspeção:
Clique nos botões para saber mais
Prós
–
Processo formal realizado sistematicamente com resultados confiáveis, onde 60% a 90% dos erros de um programa podem ser encontrados em uma única revisão.
Contras
–
Resistência ao uso – pessoal especializado para realizar o procedimento aumenta o custo do projeto.
ETAPAS
Segundo o artigo de Fagan, de 1986, "Advances in software inspections", o processo de inspeção é realizado por uma equipe multidisciplinar que representam os seguintes papéis: 
· Autor: é a pessoa que irá desenvolver o artefato que será inspecionado;
· Moderador: responsável por liderar as atividades de inspeção e reuniões;
· Redator: ele cataloga os defeitos encontrados e as soluções sugeridas durante a inspeção;
· Inspetor: tem a função de encontrar erros no produto/solução.
O quadro a seguir apresenta um comparativo entre a revisão e a inspeção: 
Quadro 2. Revisão e inspeção.
É importante saber que revisão e inspeção são aspectos diferentes com relação aos artefatos utilizados para o desenvolvimento de software, mas que juntos podem minimizar problemas que podem ser encontrados em fases muito avançadas do desenvolvimento de software e que podem trazer custos muito elevados.
TIPOS DE DEFEITOS ENCONTRADOS EM CADA ETAPA DO DESENVOLVIMENTO
A inspeção deve ser realizada em documentos de requisitos e pode revelar inúmeros defeitos. Podemos classificá-los como mostrado a seguir:
Clique nos botões para saber mais
Defeito de omissão
–
Algumas informações necessárias podem ter sido omitidas. Por exemplo: omissão de uma funcionalidade ou da capacidade de desempenho do sistema.
Defeito de artefato incorreto
–
Existem situações em que os artefatos produzidos nas etapas de desenvolvimento de software são contraditórios com o sistema a ser produzido.
Defeito de inconsistência
–
A informação aparece mais de uma vez no artefato e de forma diferente em cada aparição, causando incoerência.  
Defeito de ambiguidade
–
A informação ou até mesmo um artefato pode levar a equipe de desenvolvimento a múltiplas interpretações.
Defeito de informação estranha
–
Uma informação que aparece no artefato e embora esteja relacionada ao domínio, não é necessária para o sistema em questão.
A seguir, veremos exemplos de pontos de inspeção em narrativa de caso de uso
Quadro 3. Modelo de caso de uso revisado.
Os defeitos encontrados no código fonte podem ser classificados em: 
Clique nos botões para saber mais
Interaja com a dinâmica abaixo:
. s
SINTETIZANDO
Nesta unidade, aprendemos o quanto os padrões de software são importantes quando falamos de desenvolvimento de um software e como a falta desses padrões afeta as empresas que produzem. 
Padrões de software servem para evitar problemas recorrentes em seu desenvolvimento e que podem se tornar ainda maiores em fases mais avançadas do processo. Além disso, permitem o reuso de componentes que estão prontos e que funcionam adequadamente em outros projetos. Além disso, os padrões colaboram na qualidade do código, deixando-o mais organizado e com fácil manutenção.
No segundo tópico dessa unidade, tivemos uma introdução sobre teste de software. Testá-los nos permite avaliar e corrigir problemas. É uma fase do controle de qualidade que é executada para garantir que o software está atendendo todos os requisitos esperados e que eles está funcionando de forma adequada.
E, para finalizar, nos últimos tópicos falamos sobre as revisões e inspeções de software, uma atividade que busca evitar que o trabalho seja refeito por conta de atividades malfeitas e erros. As revisões e inspeções buscam garantir a melhoria no processo e, consequentemente, a qualidade de software. Essas duas técnicas podem ser empregadas em todas as fases do software e em todos os artefatos gerados durante odesenvolvimento.
C
REFERÊNCIAS BIBLIOGRÁFICAS
AMARAL D. et. al. Metodologias de teste de software. 11 f. 2009. Monografia - Centro Universitário Fundação Santo André, São Paulo. 2009.
AMARAL, J. R. Ferramenta para geração de caso de teste funcional. 2017. 81 f. Coordenação do Curso de Sistemas de Informação, Universidade Estadual do Mato Grosso do Sul, Mato Grosso do Sul. 2017.
CECHIN, S.; WEBER, T. S.; NETTO, J. C. Arquitetura para injeção de falhas em protocolos de comunicação segura em aplicações críticas. Instituto de Informática – Universidade Federal do Rio Grande do Sul, Rio Grande do Sul. 2016. Disponível em: <http://sbrc2016.ufba.br/downloads/WTF/155154.pdf>. Acesso em: 23 ago. 2019.
DESIGN patterns – Dicionário do programador. Postado por Código Fonte TV (8min. 22.s). Disponível em: <https://www.youtube.com/watch?v=J-lHpiu-Twk>. Acesso em: 20 out. 2019.
DEMILLO, R. A.; MATHUR, A. P.; A grammar-based fault classification scheme and its application to the classification of the errors of TEX. Software Engineering Research Center, Purdue University, West Lafayette. 1995.
DIAS, L. C.; MENNA, R. S. Teste de desempenho a partir de modelos UML para componentes de software. Revista da graduação, Porto Alegre, v.1, n.1. 2008
IZABEL, L. R. P. Testes automatizados no processo de desenvolvimento de softwares. 2014. 65 f. Monografia - Curso de Engenharia Eletrônica e de Computação da Escola Politécnica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2014.
MOLINARI L. Teste de Software – Produzindo sistema melhores e mais confiáveis. 4 ed. São Paulo: Editora Érica, 2012.
NAKAGAWA, E. Y.; MALDONADO, J. C. ITOOL – Uma Ferramenta para injeção de defeitos de softwares. ICMC-USP. Disponível em: <http://www.inf.ufsc.br/sbes99/anais/Sessao-Ferramenta-Completo/18-itool.pdf>. Acesso em: 23 ago. 2019.
NETO, A. C. D. Introdução a testes de software. 2015. Engenharia de software magazine, [s.l.]. [s.d.].  Disponível em: <https://edisciplinas.usp.br/pluginfile.php/3503764/mod_resource/content/3/Introducao_a_Teste_de_Software.pdf>. Acesso em: 23 ago. 2019.
PEIXE, M. Qualidade de software: entenda as técnicas, processos, metodologias e ferramentas de testes. Startupi. 2018. Disponível em: <https://startupi.com.br/2018/10/qualidade-de-software-entenda-as-tecnicas-processos-metodologias-e-ferramentas-de-testes/>. Acesso em: 23 ago. 2019.
PRESSMAN, R. S. Engenharia de Software. 5. ed.  Rio de Janeiro: McGraw-Hill, 2002.
ROCHA, A. C. Introdução a teste de software. STI – Universidade Federal da Paraíba. Disponível em: <http://www.nti.ufpb.br/~caroline/curso/Aula01Curso%20de%20Testes%20de%20Software%20-%20NTI.pdf>. Acesso em: 23 ago. 2019.
SOUZA, K. P.; GASPAROTTO, A. M. S. A importância da atividade de teste no desenvolvimento de software. In: Encontro Nacional de Engenharia de Produção, 31., 2013, Salvador. Anais...Salvador: ENEGEP, 2013.
SILVA, J. S. et. al. O processo de teste de software. Revista Tecnologias em Projeção, vol. 7, n. 2, Brasília, 2016.
SOMMERVILLE, I. Engenharia de Software, 9 ed. Londres: Pearson Education, 2011. 
FAGAN, M.  Advances in Software Inspection. In: BROY, M.; DENERT, E. Pioneers and their contributions to software engineering. Berlim: Springer, 2002.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5 ed. Nova Iorque: McGraw Hill, 2000.