• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
APSI2
 

APSI2

on

  • 3,480 views

 

Statistics

Views

Total Views
3,480
Views on SlideShare
3,444
Embed Views
36

Actions

Likes
0
Downloads
41
Comments
0

1 Embed 36

http://www.techgig.com 36

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    APSI2 APSI2 Presentation Transcript

    • Análise e Projeto de Sistemas II
      Prof.a Márcia Rabello
      marcia@imed.edu.br
    • Perfil do gerente empreendedor
      Empregado (Gerente) vira Empresário (Empreendedor)
    • O ser EMPREENDEDOR
      Empreendedor é o Individuo preparado para
      Identificar oportunidades
      Assumir riscos
      Errar e apreender com os erros (principalmente dos outros)
      Má notícia- O emprego esta sumindo
      Boa notícia - As oportunidades de trabalho não !
      Entretanto, é necessário novas habilidades para aproveitá-las
      3
    • Atitude Empreendedora
      Praticar Networking
      Ser Proativo
      Disposição em assumir riscos calculados
      Postura face a desafios e problemas
      4
    • Atitude- Proativo
      Missão = Tarefa + Objetivo
      Tarefa – “o que fazer?”
      Eficiência - Fazer certo as coisas
      Objetivo – “por que fazer?”
      Eficácia- Fazer as coisas certas
      Exemplo real
      Chefe para Técnico de Informática
      “Leve este CD no cliente e entregue para o chefe das vendas” - Isto é uma tarefa.
      É mais fácil de se cumprida.
      É menos arriscada - Fazendo certinho não dá problema (com o chefe)
      Atitude Empreendedora
      Empregado pergunta - Porque o cliente precisa deste CD? Resposta do Chefe- “O sistema está trava quando tenta “baixar” a nova lista de preços. Ela deverá ser carregada diretamente do CD no Computador do cliente”
      5
    • Você acha certa a afirmativa abaixo?
      “Faça o que o cliente precisa(e não o que ele pede)”
      6
      www.NewtonBragaRosa.com.br - CHA DO EMPREENDEDOR
    • Atitude- Disposição em assumir Riscos Calculados
      Risco
      Se der errado será acusado (pelo chefe, colegas, subordinados etc) de ter ido longe demais...
      Benefício em assumir risco calculado
      Maiores benefícios para si e para a empresa
      Construir relações de longo prazo
      Indicações de novos clientes
      Foco no resultado para cliente, empresa ...
    • Identificamos o empreendedor pelo seu perfil, não pela atividade que exerce
    • Atividade
      Pense numa pessoa que você conhece pessoalmente e considera empreendedora.
      Liste, no mínimo, 5 características empreendedoras que você perceba nela.
    • Características do empreendedor
      Capacidade de assumir riscos
      Aproveitar oportunidades
      Conhecer o ramo
      Saber organizar
      Tomar decisões
      Ser líder
      Ter criatividade
      Ser independente
      10
      Iniciativa
      Autoconfiança
      Necessidade de realizar
      Comprometimento com o que faz
      Manter o otimismo
      Persistência
      Alta capacidade de trabalho
    • Características do empreendedor
      Das qualidades empreendedoras que vimos, quais são aquelas com que nós nascemos?
      Como podemos desenvolver as demais? Para ser um líder ? Gerente ?
      A maioria é comportamento.
      11
    • Que características você tem?
      Para cada uma das características empreendedoras, reflita como elas estão sendo desenvolvidas em você.
      12
    • O gerenciamento de Projetos em TI
    • Importância da Análise
      Manutenção
      Manutenção
      Teste
      Implantação
      Implantação
      Programação
      Programação
      Projeto Físico
      Projeto Lógico
      Desenvolvimento
      com sistemática
      Desenvolvimento
      sem sistemática
    • Imaginando as três caixas
      Análise do Sistema
      Implementação
      e Implantação
      Gerência do Projeto
    • O que é inovação
      Edivandro Carlos Conforto
      PhD Research Candidate
    • Quebra de paradigma
    • Gerenciamento ágil de projeto
    • Exceto atividades de análise, projeto e desenvolvimento propriamente dito, que envolvem metodologias, técnicas e ferramentas de desenvolvimento...
      Ademais em um projeto de sistemas é ação de GERÊNCIA!
    • O que é o PMBOK ?( Project Management BodyofKnowledge )
      Um guia que pretende reunir o conhecimento geral sobre metodologias de gerência de projetos;
      Apresenta “melhores práticas geralmente aceitas” conforme contribuintes de grupos de estudos formados em diversas entidades;
      Fornece uma referência para qualquer profissional interessado na profissão de Gerência de Projetos.
      22
    • Quem deve ocupar o cargo de gerente de projetos ?
      Preferencialmente um profissional ligado a tecnologia da informação ?
      Algo impede que seja um profissional com a mínima vivência em TI ?
    • PMBOK
      Tem como objetivo a melhoria do processo de Gerência de Projetos
      Abrange 9 áreas de conhecimento:
      Gerência de Integração
      Gerência de Escopo
      Gerência de Tempo
      Gerência de Custos
      Gerência de Qualidade
      Gerência de Recursos Humanos
      Gerência de Comunicação
      Gerência de Riscos
      Gerência de Contratação
      Determina ferramentas a serem utilizadas no processo de gerência de projetos
      Define algumas atividades que não trata como Área de Conhecimento (ex: Gerência de Configuração)
    • Ciclo de vida de um projeto
      Pmbok
    • Processo básico
    • PMBOK
      Áreas Núcleo
      GERÊNCIA DA QUALIDADE
      GERÊNCIA DO CUSTO
      GERÊNCIA DO TEMPO
      GERÊNCIA DO ESCOPO
      GERÊNCIA DA INTEGRAÇÃO
      GERÊNCIA DOS
      RECURSOS
      HUMANOS
      GERÊNCIA DA COMUNICAÇÃO
      GERÊNCIA DO RISCO
      GERÊNCIA DAS
      AQUISIÇÕES
      Áreas Facilitadoras
    • PMBOK - Utilização
      Focado em Gerência de Projetos
      Não possui processo de avaliação formal para a organização
      A implementação é feita de forma completa
      Permite estabelecimento de controles
      Identifica pontos fortes do Gerente do Projeto e indiretamente da organização
      Não se tem registro de custos de implementação em organizações
      Pode ser utilizado para verificar processos do fornecedor
      Pode ser utilizado como item de qualificação em concorrências
      Requerido em grandes e pequenas organizações
    • Envolvidos nas fases
    • Conseqüências de uma análise inadequada
        o aumento dos custos
       realização de atividades desnecessárias
       usuários insatisfeitos
       aumento da tarefa de manutenção
    • Gerência do projeto de software
      Tonsig, 2003.
    • Etapas de processos gerenciais
      Tonsig, 2003.
    • “ item de Avaliação da Disciplina”Trabalho individual ou dupla
      Realizar uma síntese sobre o Modelo CMMI, MPSBR, ISO ou TMM.
      Muitos consideram que os modelos de qualidade como por exemplo CMM e CMMI muito caros e ou inadequados para serem implementados em pequenas empresas.
      Procurar dados a respeito.
      Elaborar um documento discutindo o assunto considerando, inclusive, a possibilidade de implementação de um modelo em sua empresa, quais as mudanças necessárias e quais os passos adequados a sua realidade.
    • Situação Atual das Organizações
      Demanda por Melhor Qualidade!
      melhor qualidade inclui:
      menos prazos, custos, defeitos, insatisfações, mais qualidade dos produtos, previsibilidade, produtividade, competitividade, e melhores resultados de negócio (ROI)
    • Situação Atual das Organizações
      Como as empresas de software podem obter a melhoria viável e necessária?
      Melhoria do Processo de Software baseada em Modelos
    • POG - Programação orientadas a gambiarras
    • 37
      A Comunicação... Um problema...
    • O que é Qualidade ?
    • O que é qualidade ?
      “Qualidade consiste em desenvolver, criar e
      fabricar mercadorias mais econômicas, úteis e
      satisfatórias para o comprador”.
      KAORU ISHIKAWA
    • O que é qualidade ?
      “Qualidade é o conjunto de características
      do produto que determinam o grau de
      satisfação que o mesmo proporciona ao
      consumidor”
      ArmanoFeigenbaum
    • O que é qualidade ?
      “A QUALIDADE somente pode ser definida em termos de quem a avalia.”
      DEMING
    • Qualidade de Software
      Visão do produto pela qual qualidade está relacionada a características do produto. (PFLEEGER)
      Alinhamento total entre as especificaçõesaprovadas e o produto concluído.
      Produto final com a menor quantidade de erros possível.
      42
    • O que é qualidade ? Conceitos e tipos de clientes
      “A QUALIDADE é tudo que alguém faz ao longo do processo para garantir que um cliente, interno ou externo à organização, obtenha exatamente aquilo que deseja.” (INTHURN)
      Cliente interno – São aqueles que fazem parte da empresa e, são impactados pelas
      atividades desenvolvidas por ela (funcionários e acionistas)
    • Conceitos e tipos de clientes
      “A QUALIDADE é tudo que alguém faz ao longo
      do processo para garantir que um cliente, interno ou externo à organização, obtenha exatamente aquilo que deseja.” (INTHURN)
      Cliente externo – São pessoas ou organizações que não fazem parte da empresa, mas também são impactadas
      pelas suas atividades (quem compra ou quem fornece)
    • Outras definições ...
      • “QUALIDADE é a aptidão para o uso. Sua avaliação baseia-se no fato de que o produto está apto ao uso e ele continuará assim.” (JURAN)
      • “QUALIDADE não é somente satisfazer o cliente, mas sim seduzi-lo.” (TOM PETERS)
    • Outras definições ...
      “QUALIDADE é produzir conforme foi especificado (atendendo as REAIS necessidades do cliente).”
      PHILIP CROSBY
    • Qualidade e Produtividade
      Qualidade e produtividade são partes integrantes de uma mesma equação. As duas significam satisfação do cliente e o sucesso do negócio.
      DENTON
    • Qualidade e produtividade
      Qualidade e produtividade na produção de serviços estão inter-relacionados, pois o incremento da produtividade e aumento da qualidade dependem:
      • Otimização dos custos de produção;
      • Diminuição de custos de panes e paralisações;
      • Nível de serviço prestado ao cliente (confiabilidade);
      • Rapidez de resposta aos clientes e às pressões externas.
    • Realidade X qualidade
      • Muitos gestores de empresas de software julgavam elevados os custos de ferramentas, metodologias e acesso a recursos de capacitação.
      • Não consideravam o fato de gastar entre 40% e 50% de seus recursos produtivos em retrabalho, conserto de um defeito no software liberado para o mercado que podem chegar a custar até 200 vezes mais que o necessário para identificá-lo e corrigi-lo internamente .
    • Segundo a NBR ISO 9000:2005, “Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos".
    • Maior Produtividade
      QUALIDADE !!
      Ser Competitivo
      Garantir a Sobrevivência
    • Certificação de Qualidade
      Confrontação das práticas de definição de processos e elaboração de produtos com uma Norma ou padrão de modo a se reconhecer a conformidade entre as mesmas.
      Para tal é preciso realizar um processo de avaliação e julgamento de acordo com determinada Norma ou Padrão.
    • Controle de Qualidade
      É a atividade e técnica operacional utilizada para satisfazer os requisitos de qualidade segundo definição da ISO.
      Pode ser realizado através de inspeções, revisões e testes usados durante o ciclo de desenvolvimento para garantir que cada trabalho produzido está de acordo com sua especificação.
    • Garantia de Qualidade
      É uma atividade aplicada ao longo do processo de Engenharia de Software.
      Consiste dos procedimentos, técnicas e ferramentas aplicadas para assegurar que um produto atinge ou excede padrões especificados. Abrange:
      Métodos e ferramentas
      Revisões técnicas formais
      Estratégias de teste
      Controle de Documentação
      Mecanismos de medição e divulgação
    • 55
      Características de Qualidade na Web
      (Olsina, 99)
    • Qualidade na Web (Offut 2002)
      56
      • Segurança
      • Disponibilidade – 24H-7-365D
      • Escalabilidade/Desempenho
      • Prazo de colocação no mercado
      como atender a estas especificações?
    • Melhoria
      Melhoria de Processo de Software, é uma abordagem baseada em processos, para melhoria de uma organização.
      Processos
      Pessoas
      Tecnologias
    • Processo de Software
      É o que as pessoas fazem, utilizando procedimentos, métodos e ferramentas, para adquirir, desenvolver, manter e melhorar software e produtos associados.
    • Melhoria de Processo de Software
      Ações realizadas para alterar os processos de uma organização para que eles satisfaçam de forma mais eficiente os objetivos e necessidades de negócio da organização.
      Uma abordagem para “aprender a trabalhar de forma inteligente para desenvolver e manter melhores sistemas de software, mais barato e em menos tempo”. [adaptado de A.Dorling, SIMPROS 2001]
    • Benefícios da Melhoria doProcesso de Software
    • Qualidade do produto x Processo
      A qualidade do produto de software é altamente determinada pela qualidade do processo de desenvolvimento e de manutenção escolhido para a construção.
      Adaptado de Summerville
    • Premissas da Qualidade
      • Deve estar inserida já nas primeiras fases do ciclo de vida do desenvolvimento de software;
      • Envolvimento de todas as pessoas (desde a alta administração até os técnicos);
      • Treinamento e comunicação;
      • Planejar e estimar prazos.....
      • Gerência de Projetos
      • Estratégias da Tecnologia da Informação
      • Gerenciamento de Custos
      • Gerenciamento de Recursos Humanos
      • Gerenciamento de Riscos
      • Gerenciamento de Aquisições
    • Qualidade e produtividade
      Qualidade e produtividade na produção de serviços estão inter-relacionados, pois o incremento da produtividade e aumento da qualidade dependem:
      Otimização dos custos de produção;
      Diminuição de custos de panes e paralisações;
      Nível de serviço prestado ao cliente (confiabilidade);
      Rapidez de resposta aos clientes e às pressões externas.
    • Qualidade e Produtividade
      Qualidade e produtividade são partes integrantes de uma mesma equação. As duas significam satisfação do cliente e o sucesso do negócio. (DENTON)
      A qualidadedeve ser vista
      com olhos de empreendedor!
      A qualidade de um produto, serviço e processo está boa quando
      os custos estão baixos, a rotatividade da equipe é gerenciada,
      as vendas estão elevadas e crescentes, os clientes são mantidos
      e outros são agregados.
    • A Norma ISO 9000-3
      Grupo
      Atividade
      Estrutura do Sistema de Qualidade
      Responsabilidade do fornecedor, Responsabilidade do comprador, Análise crítica conjunta
      Atividades do Ciclo de Vida
      Análise crítica do contrato, Especificação dos requisitos do comprador, Planejamento do desenvolvimento, Projeto e implementação, Testes e validação, Aceitação, Cópia, Entrega e instalação, Manutenção
      Atividades de Apoio
      Gerenciamento de configuração, Controle de documentos, Registros da QualidadeMedição, Regras e convenções, Aquisição, Produto de Software incluído, Treinamento
      Traz os roteiros para aplicar a ISO 9001 especificamente na área de desenvolvimento, fornecimento e manutenção de Software. Todas as orientações giram em torno de uma "situação contratual", onde uma outra empresa contrata a empresa em questão para desenvolver um produto de Software.
    • A Norma ISO 9000-3 - Utilização
      Possui processo de certificação formal
      Implementação por completo
      Permite melhoria de processos para garantia de qualidade
      Permite estabelecimento de controles
      Identifica pontos fortes da organização assim como oportunidades de melhoria
      Custo pode ser elevado dependendo da implementação
      Há processo de re-certificação
      Pode ser utilizada para verificar processos do fornecedor
      Pode ser utilizado como item de qualificação em concorrências
      Orientações giram em torno de uma "situação contratual"
      Normalmente utilizada em grandes organizações
    • A Norma ISO 12207 - Processos do Ciclo de Vida do Software
      Esta Norma, lançada em 1995, formaliza a arquitetura do Ciclo de Vida do Software. Detalha os diversos processos envolvidos no ciclo de vida do Software e os divide em três classes:
      Fundamentais - Aquisição, Fornecimento, Desenvolvimento, Operação e Manutenção
      Apoio - Documentação, Gerência de Configuração, Garantia de Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria e Resolução de Problemas
      Organizacionais - Gerência, Infra-estrutura, Melhoria e Treinamento
      Descreve com detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de Software
    • Qualidade do Processo
      P
      R
      O
      C
      E
      S
      S
      O
      D
      E
      A
      D
      A
      P
      T
      A
      Ç
      Ã
      O
      Processos Fundamentais
      Processos de Apoio
      Documentação
      Ger. de Configuração
      Garantia de Qualidade
      Verificação
      Validação
      Revisão Conjunta
      Auditoria
      Resolução de Problemas
      Processos Organizacionais
      Infra-estrutura
      Gerência
      Treinamento
      Melhoria
      Aquisição
      Fornecimento
      Desenvolvimento
      Operação
      Manutenção
      ISO/IEC 12207Processos do Ciclo de Vida do Software
      V&V devem ser aplicados durante todo o ciclo de vida do projeto para o efetivo gerenc. De qualidade.
    • VV&T e a norma ISO/IEC 12207
      Verificação
      Verificação do contrato
      Verificação do produto
      Verificação dos requisitos
      Verificação do projeto
      Verificação dos códigos
      Verificação da integração
      Verificação da documentação
      Validação – está relacionada a implementação seguindo um plano de validação
      Preparar os requisitos de testes, casos de testes e especificações para assegurar que os itens refletem os requisitos particulares para o uso do software.
      Teste – no contexto da norma é visto como uma ATIVIDADE e não um processo de VV.
      Teste de desenvolvimento, operação e manutenção
    • A Norma ISO 12207 - Utilização
      Possui processo de certificação formal
      Implementação por completo
      Permite melhoria de processos para garantia de qualidade
      Permite estabelecimento de controles
      Identifica pontos forte da organização assim como oportunidades de melhoria
      Custo pode ser elevado dependendo da implementação
      Há processo de re-certificação
      Pode ser utilizada para verificar processos do fornecedor
      Pode ser utilizada como item de qualificação em concorrências
      Normalmente utilizada em grandes organizações
    • Responda
      A atividade de teste de software no processo de desenvolvimento deve ser aplicada em que momento ?
      Apenas na fase de codificação ?
      Ou em todo o ciclo de vida ?
    • CapabilityMaturityModel - CMM
      É um modelo, desenvolvido pelo SEI para avaliação e melhoria da capacitação das empresas que produzem software. Publicado em 1992.
      Tem como principal objetivo a medição da maturidade de uma organização no que diz respeito ao processo de desenvolvimento de software.
    • Maturidade
      A maturidade dos processos possui grande influência em:
      Metas de custos
      Cronogramas
      Qualidade
    • Organizações Maduras
      Organizações Imaturas
      Papéis e Responsabilidades bem definidos
      Processo improvisado
      Existe Base Histórica
      Não existe base histórica
      É possível julgar a qualidade do produto
      Não há maneira de julgar a qualidade do produto
      A qualidade dos produtos e processos é monitorada
      Qualidade e funcionalidade do produto sacrificadas
      O processo pode ser atualizado
      Não há rigor no processo a ser seguido
      Existe comunicação entre o gerente e seu grupo
      Resolução de crises imediatas
      CMM - Maturidade
    • CMM – Níveis de Maturidade
      Nível CMM
      Descrição
      Inicial
      Processo desorganizado. Poucos processos definidos. Sucesso depende de esforços individuais
      Repetível
      Processos básicos de gerenciamento. Permitem acompanhar custo, cronograma e funcionalidade. Repetir o sucesso usando processos similares.
      Definido
      Todas as atividades de engenharia de processo e de produto estão documentadas, padronizadas e integradas em um processo padrão. Os projetos adaptam o processo padrão.
      Gerenciado
      Medidas detalhadas da qualidade do produto e do processo de desenvolvimento são coletadas. Todos os produtos e processos são controlados quantitativamente.
      Otimizado
      Melhoramento contínuo do processo é conseguido através de “feedback” quantitativo dos processos e pelo uso de tecnologias inovadoras.
      O CMM classifica as organizações em 5 níveis distintos. Do nível 1 (organizações onde não há nenhuma metodologia implantada) até o nível 5 (cada detalhe do processo de desenvolvimento está definido, qualificado, acompanhado e sendo melhorado continuamente).
    • Principais atividades para controle e garantia da qualidade
      Verificação
      Validação
      Testes
    • CMM
      Processo continuamente aprimorado
      • Prevenção de defeitos
      • Gerência de mudançastecnológicas
      • Gerência de mudanças no processo
      Otimizado
      5
      Processo previsível
      Gerenciado
      4
      • Gerênciaquantitativa de processos
      • Gerênciadaqualidade de software
      • Foco no processo
      • Definição do processo
      • Programa de treinamento
      • Administração de software integrada
      • Engenharia de produtos
      • Coordenação entre grupos
      • Revisões
      Processo consistente, padrão
      Definido
      3
      Repetitível
      2
      Processodisciplinado
      • Gerência de requisitos
      • Planejamento de Projetos
      • Acompanhamento de projetos
      • Gerência de subcontratos
      • Garantia de qualidade
      • Gerência de configuração
      Inicial
      1
      CMM - Áreas -Chave de Processo
      São os itens a serem focados pela organização para melhoria do seu processo
    • CMM - Características Comuns e Práticas-Base
      Práticas-Base relacionadas
      Estabelecimento de políticas
      Característica Comum
      Descrição
      Alocação de recursos, definição da estrutura organizacional e devidos treinamentos
      Compromisso de realizar
      Atitudes a serem tomadas pela organização para que o processo se estabeleça
      Capacidade de realizar
      Pré-requisitos que devem existir na organização para implementação do processo
      Estabelecimento de planos, procedimentos, realização do trabalho e tomada de ações corretivas caso necessário
      Atividades realizadas
      Papéis e procedimentos necessários para implementar uma área-chave de processo
      Realização de medições para determinar o estado e a efetividade das atividades realizadas
      Medições e análise
      Necessidade de medir o processo e analisar medições
      Revisão, auditoria e garantia de qualidade
      Implementação com verificação
      Passos para garantir que as atividades são realizadas de acordo com o processo estabelecido
      São itens a serem observados para que se possa verificar a implementação e institucionalização das áreas-chave do processo.
    • CMM - Utilização
      Possui processo de avaliação formal
      É didático e conhecido no mercado empresarial
      Permite implementações por níveis
      Permite melhoria de processos para garantia de qualidade
      Permite estabelecimento de controles
      Identifica pontos forte da organização assim como oportunidades de melhoria
      Custo pode ser elevado dependendo da implementação
      Não há processo de re-certificação, ocorre sempre na do próximo nível
      Pode ser utilizado para verificar processos do fornecedor
      Pode ser utilizado como item de qualificação em concorrências
      Utilizado em grandes organizações com muitos resultados documentados
      Permite certificação somente por níveis
    • Nome
      Nível
      Atividades
      Medição Pessoal
      PSP0
      Registro de Tempo, Registro de Defeitos, Padrão de Tipos de Defeito, Padrão de Codificação, Medida de Tamanho, Proposta de Melhoramento do Processo
      Planejamento Pessoal
      PSP1
      Estimativa de Tamanho, Relatório de Testes, Planejamento de Tarefas, Cronogramas
      Qualidade Pessoal
      PSP2
      Revisões de código, Revisões de projeto, Padrões de projeto
      Processo Cíclico Pessoal
      PSP3
      Desenvolvimento cíclico
      Personal Software Process - PSP
      Criado a partir da necessidade de definição de um modelo mais simples que o CMM voltado para pequenas organizações ou até para um único indivíduo. Possui quatro níveis, cada um com suas características próprias.
    • Personal Software Process - PSP
    • PSP - Utilização
      • Não possui processo de avaliação formal
      • Permite implementações por níveis
      • Permite melhoria de alguns processos para garantia de qualidade
      • Permite estabelecimento de alguns controles
      • Identifica pontos forte do indivíduo assim como oportunidades de melhoria
      • Custo mais reduzido
      • Normalmente utilizado em pequenas organizações
    • ISO 15504
      Constitui-se de um padrão para avaliação do processo de software visando determinar a capacitação da organização. Visa orientar a organização para uma melhoria contínua do processo.
      Inclui um modelo de referência, que serve de base para o processo de avaliação. É um conjunto padronizado de processos fundamentais, que orientam para uma boa engenharia de software. Este modelo é dividido em cinco grandes categorias de processo: Cliente-Fornecedor, Engenharia, Suporte, Gerência e Organização.
      Além dos processos, define também os 6 níveis de capacitação de cada processo, que pode ser incompleto, executado, gerenciado, estabelecido, previsível e otimizado.
    • Descrição
      Adquirir software, Gerenciar necessidades do cliente, Fornecer Software, Operar software, Prover serviço ao cliente
      Processo
      Desenvolver requisitos e o projeto, Implementar o projeto, Integrar e testar o software, Integrar e testar o sistema, manter o sistema e o software
      Cliente - Fornecedor
      Engenharia
      Desenvolver documentação, Desempenhar gerência de configuração, Executar garantia de qualidade, Executar verificação de produtos, Executar validação de produtos, Executar revisões conjuntas, Executar auditorias, Executar resolução de problemas
      Suporte
      Gerenciar o projeto, Gerenciar a qualidade, Gerenciar riscos, Gerenciar subcontratadas
      Gerência
      Construir o negócio, Definir o processo, Melhorar o processo, Prover recursos de treinamento, Prover infra-estrutura organizacional
      Organização
      ISO 15504 - Categorias e Processos
    • ISO 15504 - Níveis de Capacitação
      Processo
      Descrição
      Incompleto
      Não existem produtos de trabalho nem saídas do processo facilmente identificáveis.
      Realizado
      Existe um consenso na organização de que as ações devem ser realizadas. Os produtos existentes são utilizados para atestar o atendimento dos objetivos
      Gerenciado
      O processo produz os produtos de trabalho com qualidade aceitável e dentro do prazo. Isso é feito de forma planejada e controlada. Os produtos estão de acordo com padrões e requisitos.
      Estabelecido
      O processo é realizado e gerenciado usando um processo definido. As pessoas que implementam o processo usam processos aprovados, que são versões adaptadas do processo padrão documentado.
      Predizível
      O processo é realizado de forma consistente, dentro dos limites de controle, para atingir os objetivos. Medidas são coletadas e analizadas. Há entendimento quantitativo da capacitação do processo.
      Otimizado
      A realização do processo é otimizada para atender as necessidades atuais e futuras de negócio. O processo atinge seus objetivos e consegue ser repetido. Existem objetivos quantitativos de eficácia e eficiência. Monitoração constante do processo.
    • ISO 15504
      ProcessosFundamentais
      Processos de Apoio
      Documentação
      Fornecimento
      Aquisição
      Ger. de Configuração
      Ger. NecessidadesCliente
      ServiçosCliente
      Garantia de Qualidade
      TESTES
      Verificação
      Desenvolvimento
      Operação
      Validação
      ISO/IEC 15504SPICE
      Revisão Conjunta
      Auditoria
      Manutenção
      Resolução de Problemas
      Medição prod/ processo
      Processo de Reuso
      ProcessosOrganizacionais
      AlinhamentoOrganizacional
      Ger. de Processos
      Melhoria
      Infra-estrutura
      Ger. Recursos Humanos
    • ISO 15504 - Utilização
      Possui processo de certificação formal
      Ainda não está muito difundido no meio empresarial
      Permite implementações por níveis
      Permite melhoria de processos para garantia de qualidade
      Permite estabelecimento de controles
      Identifica pontos fortes da organização assim como oportunidades de melhoria
      Há processo de re-certificação
      Custo pode ser elevado dependendo da implementação
      Pode ser utilizado para verificar processos do fornecedor
      Não possui grande histórico de utilização com resultados
      Possui manuais para realização de Avaliações
    • Qualidade de Software X CMMI
      88
    • Capability...
      Capacidade?
      Capacitação?
      “Capabilidade”?
      89
      Qualidade que uma pessoa ou coisa tem de possuir para um determinado fim; habilidade, aptidão. (Aurélio)
      ?
      Ato ou efeito de capacitar (-se). (Aurélio)
      CMMI- Tradução correta é modelo de capacidade e maturidade
    • CMMI
      Foi criado para resolver o problema de existirem múltiplos CMM´s
      Sua missão é combinar o SW-CMM (CapabilityMaturityModel for Software
      Cobre as seguintes áreas de conhecimento:
      Engenharia de Sistemas
      Engenharia de Software
      Desenvolvimento integrado de produtos e processos
      Contratação de fornecedores
      Permite implementação Contínua (áreas de processo organizadas por categorias) e implementação por níveis (áreas de processo organizadas por níveis)
      Indica apreciação de fatores da organização (negócio, cultura, legado em processos) para decisão de como fazer a implementação
      Possui Níveis de 0 a 5.
    • Considerações
      Trabalhar com avaliação oferece capacidade para as empresas desenvolverem futuros projetos de uma forma mais adequada.
      CMMI pode ser utilizado independente da metodologia de processo (XP, estruturada, OO) – modelos robustos que trabalham independente da plataforma.
      80% das avaliações ficam nas disciplinas de análise de sistemas e engenharia de software.
      O grande desafio no final é a produtividade e os LUCROS.
      91
    • Pense ...
      O CMMI é apenas para software?
      O CMMI não descreve processo algum, apenas define orientações através de práticas específicas
    • Capability...
      Software processcapability - descreve o intervalo de resultados esperados que podem ser alcançados seguindo-se um processo de software. Um indicador que permite prever os resultados de futuros projetos de software. (SEI)
      93
    • Origem
      “Não há nada de novo no CMMI (i de integration)”
      94
    • Origem
      O SEI estruturou o CMM para contratação de grandes projetos de software
      Hoje, porém, o CMM e o CMMI são utilizados por empresas/organizações de vários tamanhos
      95
    • CMMI – dupla representação
      ContinuousRepresentation
      • Níveis de Capacidade
      • Agrupamento das Áreas de ProcessoporCategoria
      • Avaliaçãodacapacidade das Areas de Processo
      CMMI
      StagedRepresentation
      • 5 níveis (estágios) de Maturidade
      • Agrupamento de Áreas de ProcessoporNível
      • AvaliaçãodaOrganizaçãocomo um todo
      Estágio – para estar no nível 1 basta desenvolver software
      96
    • Comparando as Representações
      Staged
      ML5
      Process Area Capability
      ML4
      0 1 2 3 4 5
      ML3
      ML2
      ML 1
      PA
      PA
      PA
      . . .para um conjunto de áreas
      de processoestabelecidaspela
      organização.
      … paraumaúnicaárea de processoou um conjunto de áreas de processo.
      Fonte: http://www.sei.cmu.edu
    • B
      D
      A
      C
      O foco
      o foco está nos processos, pq a idéia é se tem um processo falho provavelmente terá comprometimento no produto.
      Procedimentos e métodos definindo o relacionamento entre as tarefas e a sua seqüência
      Processo
      Ferramentas e equipamentos que vão apoiar os processos
      Pessoas com habilidades, treinamento e motivação a idéia que se tenha um processo que tenha uma seqüência
      98
      Paulket al. (1995)
    • 99
      Premissa do Gerenciamento do Processo de Software
      A qualidade de um sistema de software é altamente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo
    • Processo em perspectiva
      100
      Este componente permanece na organização!
      Organização
      Tecnologia
      Pessoas
      Processos
      • Maiores determinantes do custo, do prazo de entrega e da qualidade dos produtos
    • Por que o foco está no processo?
      101
      Processo
      Produtos
      Insumos
    • Por que o foco está no processo?
      102
      Processo de software
      Requisitos
      Software
    • Por que o foco está no processo?
      103
      a
      a
      a
      x
      Requisitos
      Software
    • Por que o foco está no processo?
      104
      a
      a
      a
      a
      Software
      Requisitos
      O fato de ter um processo bem definido garante que terá um produto de qualidade?
      • É necessário Análise de mercado, Entendimento dos Requisitos ?..
    • Outros processos da vida diária
      Qualidade total
      Gravar um cd
      Ex. das enfermeiras
      105
    • Considerações
      106
      Quando tudo é importante.... Nada é importante!
      Por isso é necessário seguir um processo
      Deve ser definido
      Implementado
      Documentado
      Estar ‘vivo‘ estar continuamente sendo revisado
      A criatividade é um desafio na implementação de um modelo de qualidade
      O CMMI não define o como fazer e sim o que fazer
      Para migrar de um CMM aconselha-se utilizar o CMMI pode estágios pois a migração será mais direta.
    • CMMI
      O CMMI diz “o que” e não “COMO”
      Supri as limitações do CMM, permitindo a inclusão de novos modelos ao longo do tempo,sempre que surgirem necessidades específicas;
      Implementa melhorias a partir das experiências adquiridas com projetos já implementados;
      Assegura a integridade da norma ISO/IEC 15504 e permite a representaçãocontínua, com áreas independentes do nível de maturidade;
    • Níveis de maturidade
      Formados por um conjunto predefinidos de áreas de processo.
      Como realiza-se a medição
      Verifica-se se os objetivos específicos e genéricos estão sendo atendidos.
    • CMMI - Continuous
      Área de Processo 2
      Área de Processo 1
      Área de Processo 3
      Objetivos Específicos
      Objetivos Genéricos
      Práticas Específicas
      Níveis de Capacidade
      Práticas Genéricas
    • CMMI - Contínuo
      Uma organização pode escolher melhorar o desempenho de um único ponto problemático
    • CMMI - Contínuo
      Process Area Capability
      0 1 2 3 4 5
      PA
      PA
      PA
      Áreas do Processo
      – Metas genéricas (Requeridos)
      » Práticas genéricas (esperados)
      O que uma organização fará para atender aos componentes requeridos.
      – Metas específicas (Requeridos)
      » Práticas específicas (esperados)
      Níveis de Capacidade
    • Exemplo de área de processo e Capacidade
      CAPACIDADE
      • Baseado ISO15504
      • 6 níveis de maturidade
      • onde qualquer área do processo pode ter sua
    • Os níveis de capacidade são Acumuladtivos
    • Área de Processo - Engenharia
      Gerenciamento de requisitos
      Desenvolvimento de requisitos
      Solução técnica
      Integração de produto
      Verificação
      Validação
    • CMMI - Staged
      Nível de Maturidade
      Área de Processo 2
      Área de Processo 1
      Área de Processo 3
      Objetivos Específicos
      Objetivos Genéricos
      Características Comuns
      Implemen
      tação
      Verificação
      Habilidades
      Compromisso
      Práticas Específicas
      Práticas Genéricas
    • Níveis de Maturidade
    • Componentes CMMI - estágios
      Áreas de Processo (PA)
      Metas específicas (SG)
      Práticas específicas (SP)
      Características comuns
      Compromissos(commitment to perform - CO)
      Habilidades (ability to perform - AB)
      Diretivas (directingimplementation – DI)
      Verificações (verifyingimplementation – VE)
      Produtos de trabalho
    • CMMI - Utilização
      Possui processo de avaliação formal
      Permite implementação contínua
      Permite implementações por níveis
      Permite melhoria de processos para garantia de qualidade
      Permite estabelecimento de controles
      Identifica pontos fortes da organização assim como oportunidades de melhoria
      Custo pode ser elevado dependendo da implementação
      Pode ser utilizado para verificar processos do fornecedor
      Utilizado em grandes e pequenas organizações
    • Método de avaliação
      SCAMPI - Standard CMMI Assessment Method for Process Improvement:
      Desenvolvido pelo Software EngineeringInstitute (SEI)
      Métodoquereúneas melhorespráticas
      Métodosamplamenteutilizadospelo SW-CMM e outrosmodelos de melhoria de processos
      Existemcerca de 180 avaliadores SCAMPI no mundo:
      Autorizadospelo SEI a realizaravaliações do CMMI.
    • CMM x Testes
      PAs (Áreas de Processo) relacionadasestritamente a testes:
      VAL – Validação
      VER – Verificação
      Outrasaçõesconcentradasem PAs queenvolvemmais de umaequipe (TreinamentoOrganizacionais, Desenvolvimento de Requisitos, etc.)
    • Áreas de processos relacionadas a teste de software (CMMI x TESTES)
      • Integração do Produto (PI)
      • Verificação (VER)
      • Validação (VAL)
      nível 3
    • Áreas de Processo do modelo CMMI - Nível 3
    • 123
      CMMI
      TSP
      PSP
      Team Software Process &Personal Software Process
    • Resumo (principais conceitos)
      O que é o CMMI?
      Quais os principais componentes do CMMI?
      Para que serve o CMMI?
      Se você fosse responsável pela implementação de um programa de melhoria de processos com base no CMMI:
      Por qual modelo CMMI (disciplinas e representação) optaria?
      Por quê?
      124
    • Questionamentos
      Qual deles escolher?
      Quando utilizar?
      Como utilizar?
    • Resumo
      Compreensão prévia dos processos da organização
      Identificação dos pontos fortes
      Identificação das oportunidades de melhoria
      Estudos dos modelos e Normas disponíveis.
      Identificação de quais se aplicam à organização
      Estimular a equipe para mudanças
      ISO
      SPICE
      CMM
      Melhores práticas
      Processo Padrão
    • Resumo
      Identificação do objetivo da organização
      Certificação/avaliação
      Controle
      Garantia de Qualidade
      Caracterização do estado corrente do processo e do estado que se deseja alcançar
      Definição de um plano de ação
      Processo Padrão
    • Plano de Ação
      Determinar o contexto onde se aplicará a melhoria
      Definir "patrocinadores"
      Montar a infra-estrutura necessária para a realização do processo de melhoria.
      Determinação de prioridades da melhoria
      Planejamento de ações para atingi-la.
      Criação, teste, refino e implementação e de soluções
      Análise e validação das soluções implementadas
      Definição das ações futuras que devem ser propostas.
      Processo Padrão
    • Algumas “dicas”
      • PSP- Organizações de pequeno porte com poucos recursos e que não necessitem de uma certificação/avaliação formal;
      • CMM OU ISO - Organizações de grande porte com possibilidade de alocação de recursos para cuidar dos processos que serão definidos, mesmo que o objetivo não seja a certificação ou avaliação;
      • CMM - É o mais didático se o objetivo for apenas melhoria de processos;
    • Algumas “dicas”
      • PMI - Gerência de Projetos;
      • CMMI ou ISO - Se há necessidade de avaliação ou certificação ;
      • CMMI – Se o objetivo for a melhoria de processos em apenas algumas áreas isoladas, o CMMI é próprio para isso.
      • Se a organização trabalha com soluções sistêmicas
      • desenvolvimento de software e dispositivos de hardware.
    • Algumas dificuldades na área de Qualidade
      • Complexidade dos produtos de software;
      • A engenharia de software ainda não está madura;
      • Inexistência de processos definidos;
      • As pessoas ainda são muito resistentes;
      • Empresas da região precisam conhecer melhor seus processos
      • Não há consenso entre os profissionais sobre o que é qualidade;
      • Restrições quanto a investimentos e recursos...
    • Testes de Software
      Conceitos, Princípios e Modelos
    • Relação com outras Disciplinas
      Engenharia de Software – Metodologias de desenvolvimento de software.
      Engenharia de Requisitos - captura os requisitos do software, que representam uma das bases principais para a identificação dos testes que devem ser executados.
      Análise e Design determina o design adequado para o software. Essa é outra base importante para a identificação dos testes que devem ser executados.
      Fase de Implementação produz builds do software que são validados pela disciplina Teste. Em uma iteração, vários builds são testados, geralmente um por ciclo de teste.
      Gerenciamento planeja o projeto e o trabalho necessário em cada iteração. Descrito em um Plano de Iteração, esse artefato é uma base importante para definir a missão de avaliação correta para o esforço de teste.
      Gerenciamento de Configuração e Mudança controla a mudança dentro da equipe de projeto. O esforço de teste verifica se cada mudança foi efetuada corretamente.
    • Qual o perfil de um Eng. de Testes?
      Conhecimentos de engenharia de software.
      Ciclo de vida
      Especificação
      Projeto
      Teste propriamente dito
      Gerência da qualidade.
      Conhecimentos básicos de programação
      Conhecimentos básicos de banco de dados
      operação e configuração.
      Conhecimentos médios de redes
      configuração, operação, administração, segurança.
    • Perfil pessoal
      Paciência / Perseverança / Organização
      Firmeza de opinião
      Espírito investigador
      Capacidade de trabalhar em equipe
      Diplomacia
      analisador, investigador
      procurar defeitos
      Criativo
      criar novos cenários de teste
      Organizado
      lidar com massas de dados
      seguir o plano de teste
    • Para ser um testador, requer um bom entendimento do processo de desenvolvimento e do produto sendo gerado, além da habilidade de indicar possíveis falhas e erros.
    • Testes de integração
      CMMIx SCRUM
    • Categorias de teste de software - Fonte: Bartié (2002).
    • Esquema de Teste
      Revisões
      Revisões
      Teste estrutural
      Esse plano, deve descrever a funcionalidade do software, os métodos e técnicas que serão utilizados, para que seja formulado um plano de teste a ser seguido durante todo o ciclo de vida do software. exemplo
      Teste funcional
    • Introdução aos testes de software
      O que é testar?
      Encontramos na literatura algumas definições sobre que é a atividade de testar:
      Segundo Myers - “Testar é analisar um programa com a intenção de descobrirerros e defeitos.”
      Testar é exercitar ou simular a operação de um programa ou sistema.
      Testar é confiar que um sistema faz o que se espera que ele faça e não faz o que se espera que não faça.
      Testar é medir a qualidade e funcionalidade de um sistema.
      “O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)
    • Qual o objetivo dos testes?
      O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente estão sendo atendidas
      “Uma pessoa inteligente resolve um problema. Uma pessoa sábia evitá-o”. [Einsten]
    • Erro, Defeito e Falha
      Erro (error): é uma ação humana que produz um resultado incorreto.
      Defeito (fault): A manifestação de um erro no software
      Também conhecido como Bug
      Se executado, o defeito pode causar uma falha
      Falha (Failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado)
      Falha é um evento; defeito é um estado do software, causado por um erro.
    • Erro, Defeito e Falha
    • Confiabilidade do Software x Defeitos
      Pode existir um software livre de defeitos?
      É possível existir softwares confiáveis mas que possuem defeitos?
      Confiabilidade do Software é a probabilidade que o software não causará uma falha no sistema por um tempo especificado, sob condições determinadas.
    • O que provoca erro no software?
      Especificação de requisitos incorreta,
      Mudança de requisitos,
      Projeto inadequado,
      Módulos mal especificados,
      Erros de codificação..
    • Confiabilidade do Software
      Nenhuma falha encontrada = confiança
    • O que é Testes de Software ?
      "É uma estratégia popular para o gerenciamento de risco". (LEWIS, 2004, p. 19)
      O teste de software é usado para:
      verificar se requisitos funcionais e não-funcionais foram devidamente implementados.
    • “Teste é o processo de executar um programa com o intuito de encontrar erros”
      Glenford J. Myers (1979)
    • Fluxo da gestão de defeitos
      Adaptado de Rex Black
    • Porque defeitos ocorrem no software?
      Softwares são escritos por humanos
      As pessoas não conhecem e não dominam tudo;
      As pessoas tem habilidades, mas não são perfeitas;
      As pessoas cometem erros;
      Softwares são desenvolvidos sob crescente pressão para entregá-los em prazos rigorosos
      Sem tempo para checar as atividades realizadas;
      Sistemas podem estar incompletos.
      Se você já escreveu softwares....
    • Vale a pena investir em testes?
      Reduz em 70% o índice de
      re-trabalho de correção de falhas
      Reduz em 50% do tempo de homologação de uma nova versão
      Aumenta em 90% o índice de falhas detectadas antes da entrega
      Aumenta a abrangência dos testes
    • Realidade atual do mercado de software
      Complexidade dos softwares
      Complexidade das equipes
      Cronograma apertado para Desenvolvimento
      Mercado/Cliente/Usuários mais exigentes
      Menos tolerância a falhas
      Menos tolerância aos atrasos das entregas
      Precisamos construir softwares MELHORES
      e mais BARATOS, de forma mais RÁPIDA
    • O custo da não-qualidade
      Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manutenção de software, entre R$ 2,00 e R$ 3,00 são gastos com re-trabalho.
      Não se sabe o percentual de re-trabalho e quanto isso custa
      O software ou parte dele tem de ser refeito
      Não se sabe, através de métricas claras e precisas, quais são as principais áreas de produção que geram re-trabalho
      A empresa não toma iniciativas para corrigir os problemas nas áreas de produção ineficientes
    • Por que testar um software?
      Todo o software visa atender a uma demanda:
      Por questão de Qualidade
      Por questão de Economia
      Por questão de Segurança
      Por questão de Confiabilidade
      Por questão de Negócio
    • O custo da correção dos defeitos
      A regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto.
      Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.
    • Porque testar é necessário?
      Porque é provável que o software possua defeitos;
      Para descobrir a confiabilidade do software;
      Porque falhas podem custar muito caro;
      Demonstrar as conformidades com os requisitos;
      Para assegurar que as necessidades dos usuários estejam sendo atendidas;
      Para reduzir custos;
      Para avaliar a qualidade do software;
    • Não devemos testar:
      Para provar que o software não tem defeitos;
      Apenas porque os testes estão incluídos no plano de projeto;
    • A abordagem tradicional dos testes
      Mostrar que o sistema:
      Faz o que deve fazer
      Não faz o que não deve fazer
      META: Mostrar que o sistema funciona
      CRITÉRIO DE SUCESSO: Sistema em funcionamento correto
      RESULTADO: Sistema com defeitos
    • A melhor abordagem para o testes
      Mostrar que o sistema:
      Faz o que não deve fazer
      Não faz o que deve fazer
      META: Encontrar defeitos
      META: Encontrar defeitos
      RESULTADO: Sistema com menos defeitos
    • O paradoxo do teste
      A proposta do teste é encontrar defeitos
      Encontrado defeitos a confiança é “destruída”
      Proposta do teste: “destruir” a confiança do software
      Proposta do teste: Estabelecer a confiança
      A melhor maneira de estabelecer a confiança é tentar destruí-la.
    • Por que as empresas não testam?
      Software é complexo
      Software é intangível
      Software é altamente modificável
      Teste lida com pessoas
      Há desconhecimento sobre a relação custo x benefício
      Há falta de profissionais especializados
      Há dificuldade em implantar um processo de teste
      Há desconhecimento das técnicas adequadas de teste
      Há desconhecimento de como planejar as atividades
      Só se preocupam com testes no final do projeto
    • Conceitos iniciais
      Para que consigamos entender os conteúdos seguintes, é importante termos um perfeito entendimento dos conceitos abaixo:
      Erro: engano, alguma coisa feita por humanos.
      Defeito: o resultado de um erro.
      Falha: diferença indesejável entre o observado e o esperado.
      Depurar: descobrir e corrigir erros ou defeitos no código.
      Testar: descobrir falhas através da execução do sistema.
      Requisitos: regras de negócio do sistema.
      Testware: todo o conjunto de documentação gerado pelo processo de teste de software.
    • TMM TestMaturityModel
    • TMM - TestMaturityModel
      Modelo de maturidade focado em testes com 5 níveis de maturidade
      Desenvolvido em 1996 por IleneBurnstein no IIT (IllinoisInstituteofTechnology)
    • TMM - TestMaturityModel
      • Criado para complementar o CMMI
      • Define atividades, tarefas e responsabilidades
      • Contém um Modelo de Maturidade e um Modelo de Acessibilidade
      • O TMM possui cinco níveis de maturidade que refletem o grau de maturidade do processo de teste
    • TMM - TestMaturityModel
      Resultados - arquivados com o objetivo de melhoramentos em estágios anteriores.
      - Resultado = sw com baixo risco e pouco esforço de testes
      • Os testes são completamente definidos, bem fundamentados e medidos.
      • Os sw são avaliados a partir de critérios de qualidade por características, como reusabilidade, usabilidade e mantenabilidade.
      • Os testes são completamente integrados ao ciclo de vida do software.
      • Reconhecido em todos os níveis do modelo V.
      Estratégias baseadas nos riscos
      • mostrar que a aplicação não funciona
      Definição clara de um processo de teste.
      Os testes são caóticos, não existe processo definido - OBJETIVO mostrar que funciona
    • TMM – Nível 1
      Nãoháobjetivos de maturidade
      Teste é um processocaótico e desorganizado
      Testesãorealizados de maneiraapósfinalização do código.
    • TMM – Nível 2
      Objetivos de teste e de depuraçãosãoestabelecidos
      Planejamento dos testes
      Institucionalização de métodos e técnicasbásicas de teste
    • TMM – Nível 2
      Realização de objetivos de teste e de depuração:
      Uma equipe de testes deve ser formado, responsável pela definição das metas de teste
      A equipe desenvolve e registra os objetivos dos testes
      A equipe de testes é responsável pela definição das metas de testes
      Os planos de testes devem refletir as metas de testes
    • TMM – Nível 2
      Planejamento dos testes
      Estabelecimento do plano de testes organizacional
      Criação e distribuição de um template para planejamento de testes
      Documentação dos requisitos dos clientes que servirão como entrada no doc. de planejamento de testes
      Ferramentas para apoio a planejamento de testes devem ser avaliadas, recomendadas e utilizadas
    • TMM – Nível 2
      Institucionalização de métodos e técnicasbásicas de teste
      As técnicas devem ser avaliadas e recomendadas
      As políticas institucionais garantem que as técnicas recomendadas são constantemente aplicadas por toda a organização.
    • TMM – Nível 3
      Criação de umafábrica de testes (Ambiente)
      Treinamentostécnicos
      Integração do processo de testes aociclo de desenvolvimento do software
      Início de um processo de gerenciamento de riscos
      Controle e monitoramento do processo de testes
    • TMM – Nível 3
      Estabelecimento de umafábrica de testes
      O grupo de testes é estabelecido, com liderança própria e suporte da gerência do projeto
      Os papéis e responsabilidades são definidos para o grupo
      Seleciona-se engenheiros melhor capacitados, treinados e motivados
      Definição das formas de comunicação com os usuários para atendimento as necessidades do usuário e requisitos
    • TMM – Nível 3
      Programa de treinamentostécnicos
      Organização e criação de um programa de treinamentos
      Estabelecimento de objetivos e planos de treinamento
      Treinamento interno do grupo deve acontecer, as ferramentas e os materiais devem ser disponibilizados
    • TMM – Nível 3
      Integração do processo de testes aociclo de desenvolvimento do software
      A fase de testes deve ser particionada em sub-fases que se conectam
      Uma adapção do modelo em V deve ser desenvolvida e adotada
      Padrões devem ser desenvolvidos para os artefatos gerados pela equipe de testes
      Integração entre as equipes de desenvolvimento e de testes
    • TMM – Nível 3
      Processo de gerenciamento de riscos
      Políticas e estratégias para controle das atividades da equipe de testes
      Medições ligadas ao processo devem ser iniciadas
      Planos de ação que partem das medições são aplicadas na melhoria do processo de testes
    • TMM – Nível 4
      Programasorganizacionais de revisões
      Programa de medições
      Avaliaçãodaqualidade do Software
    • TMM – Nível 4
      Programasorganizacionais de revisões
      Programas de revisão devem ser implantados de maneira organizacional
      A equipe de testes deve participar, junto com a equipe de qualidade da definição de verificações para revisões
      A equipe de qualidade deve definir metas para as revisões
      Equipes devem ser treinadas sobre o processo de revisão
    • TMM – Nível 4
      Criação de um programa de medições
      Políticas organizacionais de medição e análise
      Definição de plano de medição
      Planos de ação provenientes da análise dessas métricas devem ser utilizadas para a melhoria continua do processo de testes
    • TMM – Nível 4
      Avaliaçãodaqualidade do Software
      As metas de qualidade devem ser definidas
      atributos de qualidade,
      equipes de teste de qualidade e a gerência (ISO 9126)
      O processo de testes deve ser moldado de forma a conseguir atingir as metas determinadas no plano de qualidade
    • TMM – Nível 5
      Aplicação de um processo de prevenção de defeitos
      Controle de Qualidade
      Otimização do Processo de Testes
    • TMM – Nível 5
      Aplicação de um processo de prevenção de defeitos
      Formação de uma equipe de prevenção de defeitos
      Os defeitos são identificados e reportados durante todas as fases do ciclo de desenvolvimento
      Mecanismo para análise de causas dos defeitos
      O planos de ação
      envolvem as equipes de desenvolvimento testes e gerência para evitar a repetição dos defeitos
    • TMM – Nível 5
      Controle de Qualidade
      A equipe de testes e equipe de qualidade
      Estabelecem as metas como quantidade de defeitos em cada fase do desenvolvimento
      Tais metas devem ser incorporadas no plano de testes
      O feedback do usuário deve ser colhido para melhoria do software
    • TMM – Nível 5
      Otimização do Processo de Testes
      Ocorre a identificação de práticas que podem ser melhoradas
      Implementar e acompanhar as melhorias
      Avaliação constante das ferramentas de apoio
      Estudo e suporte as mudanças de tecnologias
    • Classificação dos Testes
      Os tipos e técnicas de testes podem ser classificados em:
      Caixa branca: técnica de teste que avalia o comportamento interno do componente de software. Trabalha diretamente sobre o código-fonte.
    • Caixa Branca - estrutural
      Comportamento interno do sw
      Código fonte:
      teste de condição,
      teste de fluxo de dados,
      teste de ciclos
      teste de caminhos lógicos
      Exemplo uso da ferramenta JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou métodos desenvolvidos em Java
      Esta técnica deve ser aplicada pelos desenvolvedores que conhecem bem o código produzido, testes de unidades e integração.
    • Caixa Preta
      Caixa preta: são conduzidos na interface do software, sem preocupação com a estrutura lógica interna do software.
    • Caixa preta – teste funcional
      O que pode ser testado ?
      Um método, função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade.
      é aplicável a todas as fases de teste
      teste de unidade (ou teste unitário),
      teste de integração,
      teste de sistema e aceitação.
      Gera um conjunto de casos de teste (entradas, saídas e critérios de teste).
    • Mitos sobre testes
      Alguns mitos sobre a atividade de testes:
      O testador é inimigo do desenvolvedor
      A equipe pode ser formada pelos desenvolvedores menos qualificados
      Quando estiver tudo pronto, o sistema vai para teste.
    • Visão geral de processos
      Um processo é formado por atividades inter-relacionadas com um objetivo especifico. Possui entradas de dados e produtos, para, através da identificação dos recursos necessários ao processo, transformar estas entradas nos objetivos desejados.
    • Visão geral de processos
    • Processo de teste
      Cenário atual:
      Testes são realizados como uma etapa do processo de desenvolvimento
      Pressões sobre prazos fazem com que o esforço de testes seja reduzido ou até mesmo eliminado
      O objetivo é assegurar que as especificações foram construídas
      Testes são realizados pelos desenvolvedores ou analistas de sistema
      Testes são realizados ao final do desenvolvimento
      Não há garantias de que o software foi testado adequadamente
    • Cenário desejável:
      O teste é tratado como um processo independente, porém altamente integrado ao processo de desenvolvimento
      Os testes são iniciados paralelamente ao processo de desenvolvimento
      Testes realizados por equipes altamente qualificadas e especializadas
    • Pontos de verificação
      Tendo em mãos as planilhas de testes o testador em busca dos erros...
      Albuquerque, et. All.
    • Objetivo do processo de teste
      Permitir o teste de softwares usando pessoal técnico qualificado, ferramentas adequadas e base em metodologia aderente ao processo de desenvolvimento da organização
    • Verificação e Validação
      O processo de teste é dividido em duas grandes áreas:
      Verificação
      Responde se o sistema foi construído
      Validação
      Responde se construímos o sistema correto
    • Modelo V
      A estrutura do modelo V é uma aproximação do processo de testes que pode ser integrada com todo a processo de desenvolvimento. O modelo V representa o desenvolvimento versus o teste.
      O modelo V focaliza-se em testar durante todo o ciclo de desenvolvimento para conseguir uma detecção adiantada dos erros.
    • Modelo V
      Modelagem de Negócios
      Testes de Aceitação
      Verificação
      Análise de Requisitos
      Testes de Sistema
      Validação
      Arquitetura do Sistema
      Testes de Integração
      Testes Unitários
      Design
      Construção
    • Fluxo básico de atividades
    • Principais envolvidos no processo de teste
    • Princípios gerais do teste de software
      Alguns princípios foram sugeridos ao longo dos últimos 40 anos:
      Teste demonstra a presença de defeitos
      Teste exaustivo é impossível
      Teste antecipado (iniciar o quanto antes)
      Agrupamento de defeitos
      Teste depende do contexto
      A ilusão da ausência de erros (deve atender as necessidades dos usuários)
      Fonte: Certificação em Teste FoundationLevelSyllabus – Versão 2007br
    • Principais organizações e institutos envolvidos
      A disseminação dos processos de teste é relativamente nova no Brasil. Algumas organizações/institutos criados estão tendo a missão de profissionalizar a atividade no país.
      ALATS – Associação Latino Americana de Teste de Software
      CBTS – Certificação Brasileira de Teste de Software
      QAI – QualityAssuranceInstitute
      CSTE – CertifiedSoftwareTester
      BSTQB – Brazilian Software Testing Qualifications Board
      CTFL – Certified Tester Foundation Level
      ISEB – Foundation Certificate in Software Testing
      Certificação em teste de software
      Norma IEEE 829
      Define normas e padrões ao processo de teste e qualidade do produto.
      ISO 9126-1 Define as características da qualidade do software
    • A Norma IEEE 829
    • Exercícios de revisão
      Indique se é verdadeiro ou falso:
      a - ( ) O testes devem ser realizados para mostrar a ausência de defeitos.
      b - ( ) Caixa branca são testes baseados em um exame rigoroso do detalhe procedimental. Caminhos lógicos e colaborações entre componentes são testadas.
      c - ( ) O processo de teste deve ser independente do processo de desenvolvimento, porém integrado.
      d - ( ) Testes de software é uma das atividades de Verificação e Validação.
      e - ( ) A equipe de testes pode ser formada por desenvolvedores menos qualificados.
      f - ( ) Um processo é formado por atividades inter-relacionadas com um objetivo especifico. Possui entradas de dados e produtos, para, através da identificação dos recursos necessários ao processo, transformar estas entradas nos objetivos desejados.
    • Considerações
      Teste é um projeto - e como tal deve ser planejado
      Teste é um projeto integrado ao projeto de desenvolvimento
      Testar reduz riscos do negócio
      Não dá para planejar sem saber o tamanho do seu projeto
      O Plano de Teste é o instrumento básico de planejamento de projeto de teste
      Os artefatos devem estar sob gerência da configuração
      Deve ser possível, a partir dos requisitos do negócio, rastrear-se os artefatos de teste
    • Limitação
      Muitas empresas ainda usam o modelo Waterfall, ou modelo cascata, que foca justamente a atividade de teste de software somente no final do modelo, ou seja, caso algum defeito seja encontrado (erros em requisitos, por exemplo) todo ciclo deverá ser inicializado novamente. O teste de software na verdade, foca quase que exclusivamente as atividades de verificação e validação.
    • Estratégia, estágios, tipos e técnicas de teste
    • O que é estratégia de teste?
      Uma estratégia de testes de software descreve a abordagem geral e os objetivos das atividades de teste. Ela deve contemplar os níveis ou fases de teste, os tipos de testes a serem realizados e as técnicas para sua execução. A estratégia de testes de softwares também deve descrever com clareza os critérios para a conclusão dos testes e os critérios de sucesso a serem usados.
    • O que deve conter uma estratégia de teste?
      A estratégia de teste deve responder as perguntas que seguem:
      Quando vamos testar?
      O que vamos testar?
      Como vamos testar?
    • Estratégia de teste - Pressman
    • Estratégia de teste
      Eng. De sistemas – define o papel sosw, análise dos requisitos, função, comportamento, restrições e critério de validação.
      Para desenvolvimento de software o espiral dá voltas para dentro.
      Para os testes as voltas são para fora.
    • Desenvolvimento da estratégia de teste
      Ao elaborar uma estratégia de teste eficiente e eficaz, devemos ter em mente a execução de alguns passos:
      Avaliar os requisitos do sistema.
      Identificar e analisar os riscos para o negócio.
      Analisar as possibilidades de testes para minimizar os riscos.
      Estabelecer os tipos e técnicas de teste a serem realizadas.
      Definir prioridades para os testes.
      Estabelecer quais produtos serão inspecionados ou testados.
    • Dimensões de testes
      Tipos de Teste
      (O que testar?)
      Estrutural
      Funcional
      Técnica de Teste
      (Como testar?)
      Estágios ou Níveis de Teste (Quando testar?)
    • Estágio ou níveis de teste
      Estágios ou níveis de teste é a dimensão do teste que trata do “quando testar”, ou seja, a qual fase do desenvolvimento de software se aplica um determinado tipo de teste. Seguem os quatro estágios ou níveis de teste:
      1: Estágios ou níveis de teste
      Testes Unitários
      Testes de Iteração ou Integração
      Testes de Sistema
      Teste de Aceitação
    • Testes Unitários
      O primeiro nível de teste é o Teste Unitário, que envolve assegurar que cada funcionalidade especificada no desenho do componente tenha sido implementada corretamente neste componente.
      Características deste nível:
      Testes realizados em uma unidade independente do produto.
      Estágio mais baixo da escala de teste.
      Aplicado nos menores componentes de código criados, visando garantir que estes.
      atendem as especificações funcionais e de arquitetura.
      Geralmente realizado pelo desenvolvedor que construiu a unidade.
      Utiliza técnicas de Caixa Branca.
    • Testes de Iteração ou Integração
      Como os componentes são construídos e testados separadamente, ao serem acoplados deve-se verificar se eles interagem corretamente.
      Neste nível os testes não são focados em “o quê” os componentes fazem, mas se eles se comunicam conforme especificado no desenho do sistema.
      Características deste nível:
      Acontece após os Testes Unitários.
      Realizados dentro de um ambiente controlado.
      Geralmente realizado pelo analista de sistema para um módulo ou conjunto de programas.
      Normalmente são seguidos dois métodos de interação:
      Abordagem Top-Down
      Abordagem Bottom-Up
    • Testes de Iteração ou Integração - Abordagem
      Os módulos são integrados movimentando-se de cima para baixo, através da hierarquia de controle, iniciando-se com o módulo de controle principal.
      Funciona bem com desenvolvimento estruturado.
      Identifica problemas no desenho da arquitetura mais cedo.
      Pode necessitar muita infra-estrutura.
    • Testes de Iteração ou Integração - Abordagem
      Abordagem Bottom-Up
      Apropriado para desenvolvimento orientado a objetos.
      Os componentes de intra-estrutura são críticos.
      Só consegue identificar os maiores problemas de arquitetura tardiamente.
    • Testes de Sistema
      Os testes de sistema têm foco no funcionamento do sistema como um todo, para validar a exatidão e a perfeição na execução das funções requeridas.
      Características deste nível:
      Acontece após todos os testes de integração
      Realizado dentro de um ambiente controlado
      Realizado pela equipe de testes
      Envolve testes especializados para validar todos os requisitos funcionais e
      não-funcionais:
      Desempenho
      Volume
      Documentação
      Robustez
    • Tipos de Testes de Sistema
      Os testes de sistema têm foco no funcionamento do sistema como um todo, para validar a exatidão e a perfeição na execução das funções requeridas.
      Entre outros, são realizados os seguintes testes:
      Teste de Funcionalidade
      Teste de Segurança
      Teste de Estresse
      Teste de Desempenho
    • Teste de Aceitação
      Último nível de testes antes da implantação do software em ambiente de produção. Seu objetivo é verificar se o sistema tem condições de ser implantado em produção, com base nos critérios de aceitação.
      Algumas características:
      É de responsabilidade do Cliente.
      Tem a finalidade de validar se o software está apto a entrar em produção e executar as funções ou tarefas a que se propôs.
      Geralmente realizado em ambiente de homologação do Cliente.
      Testes de aceitação são realizados pelo usuário final para capacitá-lo e para validar todos os requisitos.
    • Dimensão 2: Tipos de Teste
      Todo software visa atender uma demanda de qualidade, e para isso deve atender a certos atributos de qualidade como:
      Funções
      Interface
      Características de tempo de resposta e de segurança
      Integridade
      Habilidade de ser instalado e executado em diferentes plataformas
      Habilidade de lidar com muitas requisições simultâneas, Etc.
      Para conseguir isto, diferentes tipos de teste são implementados e executados. Cada tipo de teste tem objetivo e técnica de suporte específicos. Cada técnica de teste foca em testar uma ou mais características ou atributos do objetivo do teste.
    • Características da qualidade
    • Características da qualidade
      A ISO 9126-1 define seis características de qualidade que o software deve atender:
      Funcionalidade: verifica a capacidade do sistema em prover funcionalidades definidas que atendam as necessidades do usuário, quando usado sob determinadas condições preestabelecidas.
      Confiabilidade: o produto de software é capaz de manter seu nível de desempenho, ao longo do tempo, nas condições estabelecidas de utilização.
      Usabilidade: capacidade do software em ser entendido, aprendido e utilizado sob condições estabelecidas de utilização.
      Eficiência: os recursos e os tempos envolvidos são compatíveis com o nível de desempenho requerido pelo software.
      Manutenibilidade: refere-se ao esforço necessário para a realização de alterações específicas no produto de software.
      Portabilidade: facilidade de o software poder ser transferido de um ambiente para outro.
    • Características x Técnicas
      Como dito anteriormente, é possível executar tipos de testes para assegurar que cada característica de qualidade seja atendida.
    • Dimensão 3: Técnicas de teste
      Técnica de teste estrutural
      Utilizada quando o objetivo é garantir que o produto desenvolvido está estruturado e funciona corretamente. Pretende determinar se a tecnologia utilizada foi apropriada e se os componentes montados funcionam como uma unidade coesa.
      Técnica de teste funcional
      Utilizada quando o objetivo é verificar se os requisitos do sistema e as especificações foram atendidas. Envolve a criação de cenários de testes para uso na avaliação das funcionalidades da aplicação, validando se o que foi especificado foi implementado corretamente.
      O teste funcional não está preocupado com o processo ocorre em si, e sim com os resultados do processo.
    • Teste de estresse
      A principal meta do teste de estresse é entender o comportamento do sistema durante condições-limite de execução ou fora da tolerância esperada. Tipicamente envolve a execução do sistema com baixos recursos de hardware e software, ou a concorrência por estes recursos.
    • Teste de estresse
      A principal meta do teste de estresse é entender o comportamento do sistema durante condições-limite de execução ou fora da tolerância esperada.
      Tipicamente envolve a execução do sistema com baixos recursos de hardware e software, ou a concorrência por estes recursos.
    • Teste de estresse
      Objetivos:
      Determinar a que condições-limite de recursos o software é capaz de ser executado.
      Verificar se o sistema é capaz de garantir tempos adequados de resposta sendo executado em condições-limite.
      Verificar se há restrições quanto ao ambiente em que o software vai operar.
      Determinar que volumes de transação, normais e acima dos normais, podem ser processados num período de tempo esperado.
    • Quando usar
      Quando não se sabe quais as condições mínimas de recursos para operacionalização do sistema, sem que haja perdas significativas.
    • Teste de contingência
      A meta principal do teste de contingência é verificar se, após uma falha, a sua recuperação é adequadamente executada, garantindo a continuidade dos serviços.
      Objetivos:
      Manter o backup dos dados
      Armazenar o backup em local seguro
      Documentar os procedimentos de recuperação
      Deixar claro as responsabilidades das pessoas em caso de um desastre
    • Quando usar
      Sempre que a continuidade dos serviços for essencial para o negócio.
      Perdas devem ser estimadas (quanto vou perder por hora?).
      A quantidade de perda potencial estipula a quantidade de esforço que irá ser empregada.
    • Teste de segurança
      A principal meta do teste de segurança é garantir que os dados ou funções de um sistema possam ser acessados apenas por atores autorizados a acessá-las. Todas as formas de ataque de acesso indevido devem ser simuladas.
      Objetivos:
      Garantir que os dados do sistema estão protegidos adequadamente.
      Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados.
      Analisar as ameaças e vulnerabilidades, tanto físicas como lógicas.
      Assegurar que os mecanismos de controle contra acessos indevidos foram corretamente implementados.
    • Quando usar
      Testes básicos de segurança devem ser aplicados a todos os softwares.
      Quando a informação que circula através do software for de importância fundamental para a organização.
    • Teste de performance
      O teste de performance, ou de desempenho como também é conhecido, mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo de resposta do sistema.
      Objetivos:
      Determinar o tempo de resposta das transações.
      Verificar se os critérios de desempenho estabelecidos estão sendo atendidos.
      Identificar pontos de gargalo no sistema.
      Verificar o nível de utilização do hardware e software.
    • Quando usar
      Quando se deseja avaliar o tempo de resposta de uma.
      funcionalidade do sistema ou de todo o sistema.
      Devem ser realizados quando ainda há tempo hábil de serem realizadas correções.
    • Teste de conformidade
      Verificar se a aplicação foi desenvolvida seguindo os padrões, procedimentos e guias da área de processos.
      As metodologias são usadas para aumentar a probabilidade de sucesso do projeto, e portando devem ser testadas.
      Objetivos:
      Verificar se as metodologias de sistema estão sendo seguidas
      Garantir as conformidades aos padrões da empresa
      Avaliar se a documentação do sistema é racional e está completa
    • Quando usar
      Quando se deseja que os padrões sejam seguidos.
      Quando se deseja determinar o nível de seguimento dos padrões.
      Quando se deseja identificar pontos falhos na metodologia.
    • Testes funcionais
      O teste funcional tem por meta verificar se o software executa corretamente suas funções, se a implementação das regras de negócio foi apropriada e se o sistema é capaz de sustentar sua correta execução por um período contínuo de uso.
      Objetivos:
      Assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta.
      Verificar se os requisitos dos usuários estão implementados e se atendem os usuários.
      Verificar se o sistema funciona corretamente após um período contínuo de utilização.
    • Quando usar
      Qualquer sistema deve ser suas funcionalidades testadas.
      Pode ser usado desde a fase de especificação de requisitos até a fase de operação do sistema.
    • Teste de regressão
      Tem como propósito garantir que os defeitos encontrados foram corrigidos e que as correções ou inserções de novos códigos em determinados locais do software não afetaram outras partes inalteradas do produto.
      Objetivos:
      Verificar se as alterações realizadas geraram alguma inconsistência no aplicativo ou em outros sistemas
      Verificar se as funções previamente testadas continuam funcionando após realização de mudanças
      Determinar se a documentação do sistema permanece atual
      Determinar se os dados e as condições de teste permanecem atuais
      Quando usar:
      Quando há o risco de que mudanças em uma parte do
      sistema afetem outras partes inalteradas do sistema.
    • Teste de interconexão
      O teste de interconexão, ou teste integrado como também
      é conhecido, tem como propósito testar as integrações com sistemas externos.
      Objetivos:
      Verificar se os dados que são transferidos de um sistema para o outro estão sendo transferidos corretamente
      Garantir que as ações de integração de um software estão alinhadas com as ações de integração do outro software
      Quando usar:
      Sempre que uma alteração que possui impacto nas funcionalidades integradas for realizada
    • Teste de usabilidade
      O teste de usabilidade verifica a facilidade que o software possui de ser claramente entendido e facilmente operado pelos usuários
      Objetivos:
      Verificar a facilidade de operação do sistema pelo usuário
      Verificar a facilidade de entendimento das funções do sistema pelo usuário, através da utilização de manuais, on-line help, agentes e assistentes eletrônicos, etc.
      Como usar:
      Executar diversas operações do sistema, utilizado a documentação do mesmo.
    • Desenvolvendo a estratégia de testes
      • Teste de funcionalidade
      • Desempenho
      • Interface
      • Stress (carga)
      • Usabilidade
      • Segurança
      Tipos de Teste
      (O que testar?)
      Estrutural
      Funcional
      Técnica de Teste
      (Como testar?)
      • Teste de unidade
      • Teste de integração
      • Teste de sistema
      • Teste de aceitação
      • Teste de regressão
      Estágios ou Níveis de Teste (Quando testar?)
    • Baseando-se nos riscos
      Quanto mais crítico for o software, mais testes terão de ser gastos para a garantia da qualidade do produto. Isso significa dizer que quem define a quantidade de testes é a criticidade do negócio.
      Falhas ou defeitos estão associados a riscos que podem prejudicar o negócio. Existem diversas técnicas para elaborar Análises de Riscos, e conseqüentemente escrever uma Estratégia de Testes.
      Uma das formas de se fazer uma Análise de Riscos é associar o risco a uma característica de qualidade de software.
    • Coleta de falhas
      Ficha de coleta de erros
    • Exercícios de revisão
      1) A MELHOR definição do objetivo do teste de aceitação é:
      a) Garantir que o software entre sem erros na produção
      b) Garantir que o grupo de testes fez um bom trabalho
      c) Executar um teste funcional
      d) Garantir que o software esteja fazendo exatamente aquilo que foi solicitado nos requisitos de negócio
      2) Quais fatores de qualidade deveriam ser usados num software de navegação de uma aeronave?
      a) Confiabilidade, Integridade e Eficiência
      b) Eficiência, Confiabilidade e Correção
      c) Portabilidade, Integridade e Correção
      d) Portabilidade, Testabilidade e Usabilidade
    • TESTES - Princípios básicos para o teste de software - WebApps
      Pressman (2006) apresenta uma abordagem que adota os princípios básicos para o teste de todo software, aplica estratégias e táticas que são recomendadas para sistemas OO.
      Revisar o conteúdo a fim de descobrir erros de grafia, gramática, consistência do conteúdo, representações gráficas, dentre outros;
      Revisar o projeto de navegação para descobrir erros nos links e/ou na permissão de acesso de cada usuário;
      testar cada página focando seu processamento;
      Testar a funcionalidade geral e conteúdo fornecido;
      Testar a compatibilidade da aplicação em diferentes configurações
      diferentes browsers, sistemas operacionais, plataformas de hardware e protocolos de comunicação.
    • Ambientes de testes
    • Ambiente de testes
      infra-estrutura onde o teste será executado
      Configurações de hardware e software,
      Ferramentas de automação,
      Equipe envolvida,
      Aspectos organizacionais,
      Documentação
    • Elementos do Ambiente de testes
      Devem ser considerados no planejamento e deve ser pensada na fase inicial.
      - Deve prever possíveis problemas que poderão ocorrer
    • Ambientes – 3 tipos
      A simulação dos testes deve chegar mais próximo do cenário real possivel
    • Ferramentas essenciais para gestão e automação de testes de software
      A adoção de ferramentas visa dar suporte ao processo de melhoria.
      254
    • 255
      Mantishttp://www.mantisbt.org/
      Ferramenta Open Source.
      Objetivo: Registrar e acompanhar os bugs encontrados em um projeto, desde o seu nascimento até o seu fechamento.
      Fases:
      Confirmação,
      Correção,
      Revisão e o fechamento do bug.
    • Entre as diversas funcionalidades oferecidas pelo Mantis, devemos destacar as seguintes:
      Pode ser executado em qualquer plataforma que suportar PHP/Apache (Windows, Linux, Mac, Solaris, AS400/i5, etc);
      Suporta vários bancos de dados (MySQL, MS SQL, PostgreSQL);
      Suporta múltiplos mecanismos de autenticação (Interna, LDAP, HTTP Basic, ActiveDirectory);
      Traduzido em 68 línguas diferentes (incluindo "portuguese_brazil");
      Criação ilimitada de projetos e relatos de defeitos;
      Controle de acesso e níveis de permissões para os usuários;
      • Ciclo de vida dos defeitos personalizável;
      • Gerador interno de relatórios e gráficos (possibilidade para exportar os dados nos formatos CSV, Excel e Word);
      • Mecanismo para a criação de campos personalizáveis;
      • Notificações por email automáticas ou por meio de RSS Feeds;
      • Integração com ferramentas de controle de versões (Subversion e CVS);
      • Interface Webservice para integração com outras ferramentas;
      256
    • 257
      Criando um novo projeto no Mantis
    • 258
      Registrando um bug no Mantis
    • 259
      Exemplo de bugs
    • TestLink - http://www.teamst.org/
      Por meio do TestLink é possível :
      Criar Test Cases e organizá-los em TestSuites;
      Associar um conjunto de Test Cases a um testador e acompanhar os resultados da execução dos testes;
      Gerar relatórios com diversas métricas para o acompanhamento da execução dos testes;
      Registrar e organizar os requisitos do projeto;
      Associar os Test Cases aos requisitos, visando garantir o rastreamento entre os requisitos ;
      260
    • TestLink - Funcionalidades
      Pode ser executado em qualquer plataforma que suportar PHP/Apache/Mysql;
      Controle de acesso e níveis de permissões por papéis (Líder, Testador, etc);
      Os casos de testes são organizados hierarquicamente em suítes;
      Os casos de testes podem ser classificados por palavras-chave "keyword" para facilitar a pesquisa e organização;
      Criação ilimitada de projetos e casos de testes;
      Os ciclos de testes podem ser priorizados e atribuídos aos testadores;
      Gerador interno de relatórios e gráficos (possibilidade para exportar os dados nos formatos CSV, Excel e Word);
      Integração com ferramentas de gestão de defeitos (Bugzilla, Mantis, Jira);
      261
    • 262
      Criando um novo Test Case
    • 263
      Seleniumhttp://www.openqa.org/selenium/
      Utilizada para criação de testes de regressão automatizados para aplicações WEB;
      Escrito utilizando Java Script e DHTML ;
    • 264
      O TestRunner é a página que gerencia a execução dos testes e exibe o relatório de progresso da execução.
    • Caso de teste escrito em Selenês
      265
    • Automação de testes de performance
      266
    • Razões
      mudança de plataforma das aplicações legadas para a plataforma WEB.
      A migração para a plataforma WEB trouxe novos desafios sob o ponto de vista do planejamento e execução dos testes, tais como:
      Performance, segurança, suportabilidade, usabilidade ...
      267
    • Escrita em Java;
      Pode ser executada em qualquer plataforma que suporte a máquina virtual do Java;
      Facilita todo o processo de criação e depuração dos testes por meio de uma interface gráfica intuitiva
      JMeterhttp://jakarta.apache.org/jmeter/index.html
      268
    • JMeter
      O JMeter oferece recursos para realizar:
      Testes de performance,
      volume e estresse automatizados para aplicações WEB,
      servidores FTP,
      WEB Services,
      Banco de Dados, entre outros.
      269
    • Recursos oferecidos pelo JMeter
      Ferramenta gratuita para Windows;
      Pode ser executado em qualquer plataforma que suporte a máquina virtual do Java;
      Suporta a criação de testes de performance para os protocolos (HTTP, JDBC, FTP, JMS, LDAP, SOAP, entre outros);
      Possibilidade de executar os testes em computadores distribuídos;
      Possibilidade de monitorar a performance de um servidor Apache Tomcat;
      Permite a utilização de pré-processadores e pós-processadores para modificar o comportamento das requisições;
      Suporta diversos tipos de monitores para avaliar a performance da aplicação em teste;
      270
    • Microsoft WEB Application Stress
      O WAS permite que você crie um teste de performance por meio dos seguintes mecanismos:
      Manual: Você deverá inserir manualmente as requisições HTTP (GET, POST, etc) trocadas entre o navegador e o servidor da aplicação WEB;
      Record: Cria o teste automaticamente por meio da gravação das requisições HTTP (GET, POST, etc) trocadas entre o navegador e o servidor da aplicação WEB;
      Log file: Cria o teste automaticamente com base nas informações de um arquivo de log do IIS;
      Content: Cria o teste automaticamente com base na leitura dos arquivos (HTML) e diretórios do site ou aplicação WEB;
      271
      http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en
    • Microsoft WEB Application Stress
      272
      Gravando um teste por meio de um HTTP Proxy
    • Executando o teste
      273
    • Visualizando o resultado geral dos testes
      274
    • Data Generator
      Aplicação WEB Open Source;
      Baseada em JavaScript, PHP andMySQL;
      Principal função é gerar enormes volumes de dados para popular banco de dados de testes;
      Tem grande serventia quando a aplicação é nova e não existem dados nas tabelas do banco de dados para realizar os testes.
      275
    • Data Generator - http://www.generatedata.com/
      276
    • http://getfirebug.com/
      277
      Principal função é editar, depurar e monitorar o conteúdo HTML, CSS e JavaScript utilizados em aplicações WEB.
      Monitora o que está acontecendo por trás da aplicação em teste