Professora: Jenifer Vieira

Disciplina Engenharia de Software I

UNIDADE I

Verificação e Validação

1

Compreender diferenças entre verificação e

validação de software.

Importância do processo de verificação e

validação.

Revisões.

Inspeções.

Exercícios de Fixação.

Objetivos

2

Quais foram os

maiores

desafios?

Alguém já testou algum software?

3

As falhas causam prejuízos financeiros

As falhas causam a perda de confiança do

cliente

Quais motivações para realização de Teste?

4

.....

Teste é um processo

caro

Dificuldade em

implantar um processo

de teste

Desconhecem

a relação

custo/benefício

Só se preocupam

com teste na fase

final do projeto

Desconhecem

técnicas de teste

adequadas

Mas... por que algumas empresas não testam?

5

Processo composto de

atividades que asseguram que o

software cumpra com suas

especificações e atenda as

necessidades dos usuários.

Processo de Verificação e Validação – V&V

6

Objetivo:

Assegurar que o software cumpra as suas especificações

e atenda às necessidades dos usuário/cliente.

Quando acontece:

Ao longo do processo de desenvolvimento.

Requisitos.

Inspeções de Código.

Teste de Produto.

Processo de Verificação e Validação – V&V

7

De acordo com Boehm (1979)

Verificação

“Estamos construindo corretamente o produto ?”

O software está de acordo com suas especificações.

Validação

“Estamos construindo o produto correto?”

O sistema atende às expectativas do cliente/usuário.

As especificações do software nem sempre estão de acordo com as expectativas dos usuários.

Verificação e Validação – V&V

8

Verificação se preocupa com a construção correta do software,

analisando se o programa atende a sua especificação.

Validação se destina a mostrar que o

programa realiza o que o usuário

necessita, o que foi solicitado.

Processo de Verificação e Validação – V&V

9

Descobrir defeitos em um sistema.

Avaliar se o sistema é útil.

Avaliar se o sistema pode ser utilizado em

determinadas situações operacionais.

Quais os objetivos da V & V?

10

Modelo em V

11

Modelo em V

12

Projeto prematuro de Testes:

Ao projetar testes, problemas são encontrados;

Problemas encontrados cedo são baratos de corrigir;

Problemas mais significativos são encontrados primeiro;

Não há trabalho adicional;

Projeto de testes pode impactar os requisitos!

Modelo em V

13

Modelo em V

14

Modelo em V

15

Dentre as 10 áreas de conhecimento, “Verificação e Validação” está presente na Qualidade de Software, na sub-área de Processo de Gerência de Qualidade.

Se existe a Garantia de Qualidade de SW, é porque

existiu um esforço da Verificação e Validação. Avaliar produtos (finais ou intermediários) de software ao

longo de todo o ciclo de produtos. Garantir que os requisitos de software atendam aos

usuários.

Verificação e Validação – SWEBOK (Software Engineering Body of Knowledge)

16

Dentre os 7 níveis do modelo, a Verificação e Validação estão localizados no nível D (4 Nível de maturidade), chamado Largamente Definido.

Verificação: “Confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto reflete apropriadamente os requisitos específicos.”

Validação: “Conformar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente par qual foi desenvolvido.”

Verificação e Validação – MPS.BR

17

Dentre os 5 níveis do modelo, a Verificação e Validação estão localizados no nível 3 nível de maturidade, chamado Definido.

Verificação: “KPA – Assegurar que os produtos de trabalho selecionados satisfazem seus requisitos especificados.”

Validação: “KPA – Demonstrar que o produto ou componentes do produto satisfazem seu uso pretendido quando colocado no ambiente pretendido.”

Verificação e Validação – CMMI

18

Uma revisão é uma leitura crítica do artefato e

de sua documentação, anotando:

os problemas encontrados.

dúvidas e dificuldades de compreensão.

possibilidades de melhorias.

Técnicas de V& V - Revisão

19

Atividade na qual um

artefato de software pode

ser observado pela equipe

do projeto, gerentes,

usuários, clientes ou outras

partes interessadas.

Revisão

20

Garantir que o artefato de software esteja em

conformidade com suas especificações.

Verificar se seu desenvolvimento esta de acordo

com os planos, padrões e diretrizes aplicáveis

para o projeto.

Objetivo da Revisão

21

Segundo vários autores a revisão quando é

praticada encontra de 60% a 80% do total dos

problemas encontrados

Yourdon diz que se economiza aproximadamente

40% do custo total de desenvolvimento quando

se pratica revisões.

Por que fazer Revisões?

22

Revisão pelo próprio autor(desktop checking).

Revisão por colega (peer review).

Revisões Progressiva.

Formas para realizar uma Revisão

23

O autor lê e anota todos os problemas encontrados para, depois, removê-los.

Inconvenientes:

o autor tende a “ler o que acha que está escrito e não o que está de fato escrito”.

erros de entendimento não são observáveis.

sujeito à síndrome da “ideia fixa”.

Revisão pelo próprio autor(desktop checking)

24

Um dos colegas do autor lê e anota todos os

problemas encontrados.

formulário para anotações.

ninguém deve ficar ofendido com as anotações.

o que está em jogo é a qualidade do artefato!

Revisão por colega (peer review)

25

Seleciona-se um conjunto de colegas que farão a

revisão.

cada um com uma determinada especialidade.

cada colega lê e anota todos os problemas encontrados

dentro de sua especialidade.

a seguir passa a diante para o próximo colega da lista.

Revisões progressivas

26

Simplicidade.

Eficácia.

apesar de informais, revisões tendem a encontrar um número significativo de problemas.

quando feitas por pessoas treinadas em aspectos formais (prova da corretude) podem ser muito mais eficazes.

Eficiência

em uma única revisão identifica-se uma quantidade grande de problemas.

Baixo custo

algumas coisas podem ser automatizadas.

Realização de Revisões - Prós

27

Informalidade

a qualidade da revisão depende excessivamente dos revisores (proficiência, cultura?)

Dificuldade em determinar a confiabilidade da revisão

qual é a percentagem dos problemas existentes que tendem a ser encontrados?

qual a gravidade dos problemas encontrados?

Confiabilidade depende do rigor adotado pelo revisor

frequentemente não é repetível (ambíguo)

a falta de treinamento dos revisores amplifica os problemas decorrentes da informalidade

Realização das Revisões - Contras

28

1920 - Inspeção do produto: Teve origem na linha de montagem. Os produtos intermediários e o produto final são examinados para se detectarem defeitos.

1976 – Inspeção de Software

Técnicas de V& V - Inspeções

29

Inspeção de Fagan é o mais influente trabalho sobre inspeção.

Quase um sinônimo de Inspeção.

Fagan tem sido usado por diferentes indústrias e em diferentes

artefatos de software.

É formada por seis etapas.

Inspeção de software é um tipo particular de revisão que possui um processo de detecção de defeitos bem definido.

De forma resumida, o processo de inspeção envolve o planejamento da inspeção, indivíduos (representantes do cliente, da empresa desenvolvedora e consultores) revisando um determinado artefato, um encontro em equipe para discutir e registrar os defeitos.

Inspeções - História

30

Verificar se o artefato de software satisfaz as

especificações e está de acordo com os padrões

aplicáveis.

Identificar desvios.

Coletar dados de engenharia de software como

defeito e esforço.

Objetivos das Inspeções

31

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 ...

Exemplos de artefatos

32

67% do total de defeitos durante o

desenvolvimento são detectados na Inspeção.

82% de todos os defeitos achados durante a

inspeção referem-se a design e código.

Por que fazer Inspeção?

33

Uma única sessão de inspeção pode encontrar um número considerável de erros.

Versões incompletas do sistema podem ser inspecionadas sem nenhum custo adicional.

Pode considerar padrões de qualidade mais amplos de um programa como conformidade com padrões, portabilidade e facilidade de manutenção.

Por que fazer Inspeção?

34

Mais de 60% dos erros de um programa podem ser encontrados usando inspeções informais (Fagan, 1986).

Uma abordagem mais formal pode encontrar até 90% dos erros (Mills, et al., 1987).

Tempo e custo gasto no processo de inspeção é recuperado com a diminuição das atividades de debugging.

Por que fazer Inspeção?

35

Processo formal realizado por uma equipe a partir

de um checklist de defeitos pré-definido.

Objetivo: inspecionar cada linha de código a

procura de defeitos ou não cumprimento de

padrões.

Inspeção de Programa

36

Prós

processo formal realizado sistematicamente com resultados confiáveis.

de 60% a 90% dos erros de um programa podem ser encontrados em um única revisão.

Contras

Resistência ao uso – pessoal especializado aumenta o custo do projeto.

Realização de Inspeções

37

São ferramentas que processam o código fonte do

programa e chamam a atenção do verificador para

anomalias, como seções não utilizadas e variáveis não

inicializadas/utilizadas.

Amplamente utilizadas pelas equipes de inspeção.

Analisadores automáticos de programas

38

Equipe pode se focar mais na verificação manual da funcionalidade / algoritmo.

O uso da ferramenta resulta em completude e consistência.

Economiza esforço.

Encontra defeitos que não são possíveis de serem encontrados manualmente.

Realização de análise automatizada - Vantagens

39

Podem ser utilizadas em todas as fases do processo de desenvolvimento do software.

Ferramentas para análise automática do código ou documentos podem ser utilizadas.

Verificação podem ser auxiliadas pela utilização de métodos formais.

Inspeções de Software

40

Em geral produtos de trabalho devem ser

inspecionados por:

Participantes

41

O autor de algum documento antecessor.

Pares do autor do produto inspecionado.

Alguém que usará o produto inspecionado como

entrada para outro produto de trabalho.

Em uma inspeção, cada um dos participantes recebe um ou mais papeis e responsabilidades.

Os papeis de uma inspeção tipicamente são distribuídos em

Participantes

42

Autor.

Moderador.

Leitor.

Escritor.

Inspetor.

Coordenador das Inspeções.

Autor

Papeis

43

Criador ou mantenedor do produto de trabalho a ser

inspecionado.

Solicita ao Coordenador das Inspeções um Moderador.

Entrega o produto de trabalho e documentos

associados aos participantes.

Identifica junto ao moderador os outros participantes

da inspeção.

Esclarece as dúvidas relativas ao produto a ser

inspecionado.

Determina o tempo de preparação para a inspeção.

Moderador

Papeis

44

Usa o checklist de moderador para auxiliar nas

inspeções.

Planeja o cronograma com o autor e lidera a inspeção.

Identifica junto ao autor os outros participantes da

inspeção.

Revisa o tempo de preparação definido pelo autor.

Determina o status do produto de trabalho.

Entrega o sumário completo da inspeção ao

Coordenador das Inspeções.

É o Facilitador da Inspeção.

Leitor

Papeis

45

Faz a leitura de partes no produto de trabalho

inspecionado, de maneira a fazer com que o time de

inspeção apresente comentários, não-conformidades

ou questionamentos.

Escritor

Papeis

46

Registra e classifica as não-conformidades

encontradas durante a inspeção.

Inspector

Examina o produto de trabalho antes da reunião de

inspeção para encontrar defeitos e desvios.

Registra o tempo de preparação.

Participa da reunião de inspeção para identificar

defeitos, desvios e sugerir melhorias.

Coordenador das Inspeções

Papeis

47

Responsável pelas métricas de inspeção do projeto.

Mantém os registros das inspeções conduzidas e dados

do sumário de cada inspeção.

Gera relatórios de inspeção.

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

48

Mas antes de iniciar é essencial:

Especificação completa do código disponibilizada.

Membros da equipe familiarizados com padrões

organizacionais.

Versão atualizada e compilada do código tenha sido

distribuída entre a equipe de revisores.

Processo de Inspeção de Software

49

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

50

Planejamento

Selecionar a equipe de inspeção.

Organizar uma sala de reunião.

Assegurar que o material a ser inspecionado e suas

especificações estejam completos.

Processo de Inspeção de Software

51

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

52

Visão Geral

Programa a ser inspecionado é apresentado a equipe

de inspeção.

Autor do código descreve o que o programa se destina

a fazer.

Processo de Inspeção de Software

53

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

54

Preparação Individual

Cada membro da equipe estuda a especificação e o

programa.

Membros procuram e anotam defeitos encontrados.

Processo de Inspeção de Software

55

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

56

Reunião de Inspeção

Deve ser uma reunião curta e não deve ultrapassar duas

horas.

Deve enfocar a detecção de defeitos, conformidadade

aos padrões e programação de baixa qualidade.

A equipe não deve sugerir como corrigir os defeitos e

nem recomendar mudanças em outros componentes.

Checklists podem ser utilizados.

Processo de Inspeção de Software

57

Checklists

Devem ser desenvolvidas por cada organização e

devem ter como base padrões e práticas locais.

Exemplos de checagens:

Defeitos de entrada/saída

Todas as variáveis de entrada são utilizadas?

Todas as variáveis de saída têm um valor associado?

Entradas inesperadas podem fazer com que os dados sejam

corrompidos?

Defeitos de gerenciamento de exceções

Todas as possíveis condições de erro foram.

levadas em conta?

Processo de Inspeção de Software

58

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

59

Retrabalho

Autor do programa faz as mudanças para

corrigir os problemas identificados.

Processo de Inspeção de Software

60

Planejamento Visão Geral Preparação Individual

Reunião de Inspeção

Retrabalho

Acompanhamento

Processo de Inspeção de Software

61

Acompanhamento

Moderador deve decidir se uma nova inspeção de

código completa deve ser realizada.

Caso não seja necessário então o programa é liberado

pelo moderador e aprovado.

Processo de Inspeção de Software

62

Item Revisão Inspeção

Objetivos Avalia a conformidade

com as especificações

Garante a integridade

Detectar e identificar defeitos

Documentação dos defeitos

Verificar resolução

Qualificação dos

participantes

Experts técnicos

Membros da equipe

Inspetores formalmente treinados

Poder decisório A equipe de Revisão pede à

liderança da equipe de

Projeto ou Gerência para

levar as recomendações

adiante

A equipe declara informa o resultado (Aceite/

Re-trabalho/Verificação/ Re-inspeção)

Comparação entre Revisão e Inspeção

63

Através da Revisão e Inspeção busca-se revelar as

falhas do software antes do mesmo entrar no

ambiente de produção, minimizando e otimizando

os custos com manutenção. A utilização de

abordagens baseadas em testes busca aumentar a

qualidade do software.

Conclusão

64

Questão 01) Julgue as afirmativas. Justifique sua resposta.

1.1 Testes devem ser realizados para mostrar a inexistência

de defeitos.

1.2 O processo de verificação e validação deve ser

independente do processo de desenvolvimento, porém

integrado.

1.3 Verificação e validação são técnicas de teste.

1.4 A equipe de teste pode ser formada por profissionais

menos experientes e qualificados.

Atividade

65

Softex http://www.softex.br/

TestExpert http://www.testexpert.com.br/

Associação Brasileira de Melhoria em Tecnologia da Informação http://www.abramti.org.br/

Qualidade de Software http://qualidadesoftware.org.br/

Qualidade de Software http://qualidade-de-software.blogspot.com/

Sites Recomendados - Brasileiros

66

Certificação Brasileira de Teste de Software (CBTS) http://www.alats.org.br/Default.aspx?tabid=198

Brazilian Software Testing Qualification Board http://www.bstqb.org.br/

Instituto Brasileiro de Qualidade em Testes de Software http://www.ibqts.com.br/

Certified Software Quality Analyst (CSQA) http://www.softwarecertifications.org/

Software Quality Engineer Certification CSQE http://www.asq.org/certification/software-quality-engineer/index.html

ISEB Foundation Certificate in Software Testing http://www.bcs.org/server.php?show=nav.7179

Sites Recomendados - Certificações

67

ISEB Practitioner Certificate in Software Testing http://www.bcs.org/server.php?show=nav.6956

The Certified Software Tester (CSTE) http://www.softwarecertifications.org/

Certified Test Manager (CTM) http://www.testinginstitute.com/ctm.php

Certified Software Test Professional (CSTP) http://www.testinginstitute.com/cstp.php

American Software Testing Qualifications Board http://www.astqb.org/

Sites Recomendados - Certificações

68

StickyMinds Software Quality & Test http://www.stickyminds.com/

Software Test & Performance Magazine http://www.stpmag.com/

SDTimes Magazine http://www.sdtimes.com/index.html

The Rational Edge http://www-128.ibm.com/developerworks/rational/rationaledge/

Professional Tester Magazine http://www.professionaltester.com/

Free Software Magazine for the Free Software World http://www.freesoftwaremagazine.com/

Sites Recomendados - Revistas

69

Software QA Testing and Test Tool Resources http://www.aptest.com/resources.html

Web Site Test Tools and Site Management Tools http://www.softwareqatest.com/qatweb1.html

Open Source Software Testing Tools, News and Discussion http://opensourcetesting.org/

Open Source Testing Tools in Java http://java-source.net/open-source/testing-tools

Software QA and Testing Resource Center http://www.softwareqatest.com/qattls1.html

Sites Recomendados - Ferramentas

70

Questão 01) Com o objetivo de realizar uma inspeção de

programa, escolha uma ferramenta de programação que

você conheça e gere um checklist de erros comuns (não de

sintaxe) a serem buscados em um programa durante o

processo de inspeção.

71

Atividade

Questão 02) É comum durante o desenvolvimento de

sistemas, realizar os testes até que o orçamento

destinado aos testes termine. Então, o sistema é

entregue aos clientes. Discuta a ética desta

abordagem.

72

Atividade

SOMMERVILLE, Ian. Engenharia de Software. São Paulo:

Addisson-Wesley, 2007.

PRESSMAN, Roger S. Engenharia de Software. São Paulo:

Makron Books, 2006.

CRAIG, R.D. Systematic Software Testing. New York: Artech

House, 2002.

Jeff Tian. Software Quality Engineering - Testing, Quality

Assurance, and Quantifiable Improvement. IEEE Computer

Society. John Wiley & Sons, Inc. 2005.

Referências

73