1 Novembro de 2007 link consulting / apresentação CTT Experiência, Metodologia e Ferramentas
Sumário Enquadramento e panorama actual Visão do serviço de testes Percepção vs. Realidade Investir em Qualidade Factores Críticos de Sucesso Experiência da Link: evolução histórica e projectos de referência Modelo V de testes Estrutura de equipa Metodologia e ciclo de vida de testes Tipos e técnicas de teste Ferramentas e testware Link Artefactos, templates e outputs Modelo financeiro 3 Desafios TI/SI - Missão crítica de negócios TIME to Componentes Riscos Testes to MARKET... exigem abordagem de testes estruturada!! 4
Visões de testes de software Conceito tradicional de testes Executar testes abrangentes e exaustivos Testar total e completamente o sistema Produzir evidências de tudo Mas o que significa testar completamente? Testar todo o sistema? Testar todas as linhas de código envolvidas? Testar todos os caminhos e desvios possíveis? Não achar mais erros? Finalizar o Plano de Testes? etc Percepção (e realidade!) de que o software não é bem testado Não é utilizada uma metodologia clara Insuficientes automatismos Poucas ou nenhumas ferramentas de suporte 5 Origem dos erros Erros no projecto de desenvolvimento levantamento de requisitos planeamento do projecto especificação dos programas desenvolvimento de código introdução de dados Requisitos 56% Projecto 27% Erros no projecto de testes detecção de erros correcção dos erros execução de testes homologação e aprovação 10% 7% Outros Construção Source: Gartner Group Existirão sempre erros na produção Quanto mais tarde a sua detecção, maior o custo 6
Qual o custo dos erros Custo médio m dos erros por fase US$ 500 US$ 1500 US$ 200 US$ 100 US$ 5 US$ 50 Levantamento Desenho Construção Teste Unitário. Teste Integrado Produção Source: P.Coffe (PC Week) 7 Falhas e remoção de defeitos Nos projectos de sistemas críticos : Mainframe : 40% dos projectos falham Client-Server : 70% dos projectos falham 30% 70% Client-Server 40% 60% Mainframe 70% da remoção de defeitos ocorre no Ambiente de Testes 30% ocorre no ambiente de Produção 30% 70% Produção Testes 8
Qual o ROI da Qualidade? (1) Exemplo em que a factura mensal de comunicações possui um erro de arredondamento de 0,01 Qual o custo para a empresa? Se o número de clientes for de 10.000.000 (número de contas/mês): - Prejuízo mensal = 100.000,00 / mês Durante quanto tempo? O cliente não vai reclamar estará a pagar menos! - 6 meses? ( 600.000) - 12 meses? ( 1.200.000) E se o erro estiver no cálculo do valor de cada chamada?!! 9 Qual o ROI da Qualidade? (2) Exemplo de uma cobrança a indevida de uma tarifa bancária recebida pelo cliente Qual o custo para a empresa? Imediato custo do atendimento da reclamação custo operacional do estorno Potencial custo imagem / marketing negativo (word-of-mouth) Perder o cliente Redução de investimentos Redução de receitas futuras Processos judiciais/indemnizações Quanto vale um cliente?!! 10
Os testes acrescentam valor ao negócio Os utilizadores e key users podem executar o seu trabalho Utilizador TI/SI fornecem soluções de qualidade para o negócio T.I./S.I. Negócio Software O Software Suporta correctamente o negócio 11 Solução: especialistas em testes As possibilidades de teste são muitas e tendem para o infinito mas o orçamento e o prazo de entrega do projecto são limitados Qual a solução? Abordar os testes como um projecto planear Prioritizar os requisitos e as funcionalidades Reproduzir a realidade do negócio e dos utilizadores Abordar os testes como uma actividade de gestão de riscos Esta missão deve ser confiada a Especialistas 12
Visão do serviço de testes de software Gestão de Testes Centro de Competência de Testes Gestão: Estrutura/Organização Documentos Relatórios SLA s Experiência Execução: Processos Metodologia Ferramentas Pessoas Experiência 13 Fases de awareness Fase 4 Disciplina tendente à testabilidade e à redução do esforço o de teste O que o teste pode e não pode fazer Como produzir software testável Reduzir o esforço o de teste O trabalho começa a na especificação Fase 3 O objectivo não é provar que não funciona, mas reduzir o risco de não funcionar o suficiente Controlo de qualidade Tem em conta a estatística stica O objectivo é a confiança a educada nas capacidades do software Fase 2 Provar que o software não funciona É a perspectiva do auditor trabalhar contra o programador Encontrar casos rebuscados Non-stop Fase 1 Provar que o software funciona Indecidível # testes Muitos testes maior probabilidade falhas Non-stop 14
Panorama tradicional Orçamentos curtos ou pouco elásticos fazem cortar o que parece intangível durante o processo usualmente o controlo de Qualidade / Testes Uma parte importante dos processos nascem coxos logo ao nível da definição e especificação de requisitos. E o problema depois ampliase inúmeros problemas no desenvolvimento, levam à descontinuação dos projectos, que não chegam a entrar em produção entram em produção com erros ou com funcionamento desadequado face às necessidades e objectivos entram em produção funcionalmente imaturos Desculpa usual Cortei nos testes para cumprir o prazo e orçamento 15 Quando devem começar os testes? Os testes devem ser iniciados o mais cedo possível no ciclo de vida O que se pode perder Os testes serão deficientes Tempos de teste longos Tempos de bug-fixing longos O que se ganha Reduz os custos de fecho Reduz os custos de manutenção, em particular a evolutiva Reduz a pouca produtividade dos utilizadores Reduz os erros de introdução de dados O planeamento e design dos testes pode expor faltas ou falhas Quanto mais cedo se detectar menor o impacto 16
Investimento ou custo Custo Projecto Custo Qualidade Custo Desenvolvimento Custo Conformidade Custo Não Conformidade Re - revisões Re-testes Custo de Decteção de Defeitos Revisões - Problemas - Requisitos - Modelação - Planos de Teste Scripts de Teste Inspecção de Código Testes (iniciais) Auditoria Custo de Prevenção de Defeitos Metodologia Formação Ferramentas Políticas Procedimentos Planeamento Análise Métricas Relatório Qualidade Correcção - código - documentação Reestruturação Redistribução Atrasos Falhas em produção Quanto maior o investimento na prevenção de defeitos, menor será o custo com não conformidades. Um projecto de software dimensiona-se se tanto pela vertente de desenvolvimento, como pela de testes (custo, tempo, recursos) 17 O cliente poupa quando não gasta em testes? Será que colocando a responsabilidade exclusivamente no fornecedor do sistema, o cliente está a poupar? O fornecedor deve fornecer uma solução com qualidade! Se tem erros, mesmo em produção, o fornecedor deve resolvê-los! Muitas vezes, o que acontece não é controlável pelo cliente Muitos erros são detectados em produção, com impacto no negócio do cliente A equipa do cliente (key users) é intensamente envolvida nos testes custos adicionais Os custos de manutenção são mais elevados As falhas/inconsistências não detectadas nas especificações podem ser consideradas alterações/ajustes manutenção evolutiva No final do prazo de garantia, os custos aumentam manutenção correctiva 18
Porquê dar esta responsabilidade a terceiros Na área da construção civil, a fiscalização é realizada por empresas distintas das que efectuaram a construção Muitas vezes a abordagem da empresa que desenvolve está muito restringida Orçamento limitado Prazo rígido Perfil da equipa O know-how em testes não é fácil de adquirir Metodologia, experiência, ferramentas A análise custo/benefício tende a pender para o lado do custo Se o erro for detectado, logo se corrige! 19 Factores Críticos de Sucesso Test Code tão sério s como a programação Componentes loosely coupled Estrutura do software testável Ambiente de testes separável/divis vel/divisível Tudo tem que ser stubbable Fáceis de compreender e de mudar Experiência nos Testes Maintainable Tests Equipas que acreditam na melhoria contínua nua Só requerem modificação se as especificações mudarem Testes Robustos Equipa de QA disposta a partilhar testes Cooperação vs. rivalidade 20
Experiência em testes desde 1999 A área de testes, surge no Brasil no inicio de 1999 quando uma equipa de consultores da Link foi prestar serviços especializados de Qualidade e Engenharia para a Telesp Celular (em São Paulo) no apoio ao lançamento do Baby Pós-Pago P2K Revenue Assurance SMP-Serviço Móvel Pessoal APOLO GSM Vivo Business Simulation 1999 2000 2002 2003 21 2004 2006 2007 1999: Startup do Baby da Telesp Celular. Equipas de consultores até 2002 2000: Implementação do sistema pós-pago P2K da Vivo 2001: Criada a empresa Aitec do Brasil 2002: Inicio de projectos com equipas mistas portuguesas e brasileiras 2003: Regras SMP (Serviço Móvel Pessoal) - Vivo 2004: Projecto APOLO: Migração/Unificação sistema pré-pago da Vivo 2006: Implementação GSM Vivo 2007: Business Simulation Principais projectos de testes Startup do Sistema Pré-pago Baby - Telesp Celular (Abril 1999) Implementação do sistema de pós-pago P2K da Convergys - Telesp Celular (Maio 2000) Manutenção do sistema Pré-pago PPS - Telesp Celular (Junho 1999/Outubro 2005) Migração do sistema pré-pago ATS - Global Telecom (Março 2002 a Outubro 2002) Implementação regras SMP (Serviço Móvel Pessoal) Vivo (Abril 2003) Projecto APOLO: Migração/Unificação sistema pré-pago - Vivo (Novembro 2004 a Março 2007) Projecto ATENA: Migração/Unificação sistema pós-pago Vivo (Agosto 2005 a Março 2007) Projecto Implementação GSM Vivo (Outubro 2006 a Fevereiro 2007) Projecto CLM : Customer Lifecycle Management Vivo (Desde Maio 2005) Business Simulation Vivo (desde Outubro 2006) 22
Certificações ISTQB -International Software Testing Qualifications Board Certificação internacional na área de Testes de Software ISO 9001 Sistema de Gestão da Qualidade, NP EN ISO 9001:2000, certificada pela EIC para desenvolver serviços integrados de sistemas, desenvolver soluções e consultoria NATO e UEO Acreditação pela ANS (Agência Nacional de Segurança) para trabalhar com material classificado do governo português, NATO e UEO até ao nível Secreto Certificação para exercer actividades na indústria de armamento 23 Modelo V de testes Start-Up Projecto Aceitação Sistema Requisitos Utilizador 1 8 Testes Aceitação Requisitos Software 2 7 Testes Sistema Arquitectura 3 6 Testes Integração Código 4 5 Testes Unitários 24
Estrutura da equipa Cliente Testes Desenvolvimento Pontos Situação Períodicos Gestor Projecto Cliente Key User 1 Key User n Gestor Projecto Testes Test Designer Gestor Projecto Desenv. Responsável Técnico Pontos Situação Períodicos Admin. Redes/DBA Responsável Técnico Progress Reports Tester 1 Tester n Prog. 1 Prog. n Factor crítico de sucesso Entrosamento entre as equipas: Testes Desenvolvimento key users do cliente 25 Características principais da metodologia Abordagem iterativa Em cada iteração são adicionados novos e refinados Re-working dos testes (tal como o software ) Não existem testes fechados Ferramentas de suporte Automatização dos testes Reutilização de testware Foco muito grande nos testes de regressão Foco na gestão de 2 aspectos essenciais do plano Iteração: qual a iteração e avaliação da mesma Fase dos testes: integração, sistema, aceitação 26
Coverage e métricas Métricas chave Suportadas pela metodologia e best practices da Link Baseiam-se nos conceitos de Coverage e Qualidade Test-Coverage Testar a completude: Quão completos estão os testes? Cobertura dos casos de testes expressa em termos de Requirement based - verificação de Use Cases Code based - Cobertura do código executável Qualidade Medida de fiabilidade, estabilidade, performance do target-of-test Resulta da avaliação dos testes e da análise dos defeitos detectados 27 Iteração É essencial saber em que iteração dos testes o projecto se encontra ligado à fase em que o projecto de desenvolvimento se encontra A experiência em testes assume um papel importante nesta definição Em cada iteração são adicionados novos testes e refinados outros Re-working dos testes (tal como o software) Medir a completude test coverage Número de iterações Acompanha a evolução do projecto de desenvolvimento Fase de Elaboração: 2 iterações previstas 1ª iteração até entrega da primeira versão das especificações 2ª iteração até aprovação das especificações Fases de Construção e Transição: n-iterações Avaliação da completude dos testes Deadlines de projecto Decisão conjunta dos stakeholders 28
Ciclo de vida dos testes Iteração X Iteração X + 1 Especific ação Requisitos Análise&Design Implementação Planear projecto Iteração X + 2 O ciclo de vida não pode existir de forma isolada do projecto de desenvolvimento A abordagem iterativa dá muita importância aos testes de regressão Em cada iteração, existe um ciclo de teste 29 Ciclo de Vida - Modelo Planear testes Design dos testes Implementação dos testes Execução dos testes na fase de Integração [Refazer testes] Avaliar testes Execução dos testes na fase de Testes Sistema [Refazer testes] 30
Ciclo de vida Planear os testes Guidelines Testes Test Designer Planear Testes Plano Testes Modelo Use Cases Especificações Suplementares Plano projecto desenvolvimento Identificar a informação de projecto existente Enumerar os Requisitos de Testes (alto nível) Recomendar e descrever as estratégias de teste a serem utilizadas Plano de projecto de testes recursos necessários, estimativa de esforço, calendarização Enumerar os deliverables do projecto de testes 31 Ciclo de vida Design testes Modelo Dados Arquitectura Sistema Casos Teste Guidelines Testes Test Designer Design Testes Procedimentos Teste Plano Testes Especificações Suplementares Use Case Modelo Workload Identificar, descrever e elaborar o modelo de testes Casos e procedimentos de teste Modelo de workload Revisão e avaliação do test-coverage 32
Ciclo de vida Implementação testes Casos Teste Test Designer Implementação Testes Scripts Teste Procedimentos Teste Casos Teste Procedimentos Teste (actualizados) Arquitectura Sistema Designer Modelo Dados Programador Design e Implementação de Testes sub- sistemas e componentes Testes de sub- sistemas e componentes Implementação dos casos de teste Elaboração/configuração de testware Interacção com equipa de desenvolvimento 33 Ciclo de vida Executar testes / fase Integração Programador Integrar Sub-sistemas Corrigir Defeitos Scripts Teste Target Software Componente (corrigido) Pedido CorrecçãoAltera ãoalteração Tester Executar Testes (integração) Executados nas várias iterações, até que todo o sistema (definido para a iteração) esteja correctamente integrado Avaliar a execução dos testes Recover dos testes não concluídos com sucesso Investigar os resultados inesperados 34
Ciclo de vida Executar testes / fase Sistema Programador Integrar Sub-sistemas Corrigir Defeitos Sistema Integrado (corrigido) Componente (corrigido) Scripts Teste Target Software Pedido CorrecçãoAltera ãoalteração Tester Executar Testes (sistema) Testar as funcionalidades como um todo Forte utilização dos testes de regressão Avaliar a execução dos testes Recover dos testes não concluídos com sucesso Investigar os resultados inesperados 35 Ciclo de vida Avaliar testes Pedido Alteração Test Designer Avaliar Testes Relatório AvaliaçãoTestes Avaliar as medidas quantificáveis dos resultados dos testes Test-case Coverage Code Coverage Determinar a qualidade do software target Análise qualitativa dos defeitos Determinar a qualidade do processo de teste 36
Prioridade dos testes Alta Probabilidade Nível 2 - Laranja Nível 1 - Vermelho Análise da prioridade baseada no conhecimento e estudo dos processos de negócio Nível 4 - Azul Nível 3 - Amarelo Baixa Baixo Impacto Alto 37 Metodologia Tipos de teste O modelo usado considera os seguintes tipos de teste Funcionais Ciclo de negócio Integridade User Interface Segurança e Acessos Load & Stress Volume Failover e Recovery Configuração & Instalação O plano de projecto define, entre outros aspectos: Qual os tipos de teste com maior ênfase O peso de cada um nas várias fases de teste (Integração,Sistema,Aceitação) 38
Metodologia Tipos e técnicas A metodologia fornece linhas orientadoras para a escolha de requisitos Número de casos de teste por requisito Técnicas para obter casos de teste Para cada tipo de teste a metodologia indica Aspectos a considerar/ truques Critérios rios de Completude Técnicas de teste a usar Objectivo dos testes 39 Metodologia exemplo testes Ciclo de Negócio Objectivo Deve emular as actividades efectuadas pelo sistema ao longo do tempo. Deve ser identificado um período (ex: 1 mês, 1 ano, etc.); as transacções e actividades que irão ocorrer nesse mesmo período, deverão ser executadas e testadas. Isto inclui todos os ciclos diários, semanais, mensais e eventos que são date sensitive. Objectivo: Assegurar que o target e processos background funcionam de acordo com os modelos e processos de negócio definidos. Técnica Os testes devem simular diversos ciclos de negócio através da execução do seguinte: Os testes usados para testar as funcionalidades, devem alterados/adaptados para aumentar o número de items que cada uma das funções executa, no sentido de simular diferentes utilizadores ao longo de um período de tempo; Todas as funções sensíveis ao tempo ou datas devem ser executadas usando datas ou períodos de tempo, válidos e inválidos; Todas as funções que ocorrem periodicamente devem ser executadas no tempo apropriado; Os testes devem incluir dados válidos e inválidos, para verificar o seguinte: Resultado esperado quando se usam dados válidos; São mostradas mensagens de erro/warning quando os dados são inválidos Cada regra de negócio é correctamente aplicada Critério Completude Todos os testes foram executados Todos os defeitos foram addressed Considerações Especiais Datas de sistema e eventos podem requerer actividades de suporte adicionais; É necessário o Business Model para identificar os requisitos e procedimentos de teste; 40
Metodologia exemplo testes Volume Objectivo Objectivo: Verificar que o target funciona adequadamente nos seguintes cenários de grande volume de dados: Máximo número de clientes ligados, todos a efectuarem o mesmo processo de negócio worst case por um período extenso; O tamanho máximo da base de dados foi atingido e múltiplas queries/transacções são executadas simultaneamente Técnica Usar os testes desenvolvidos para os de Performance e Load; Devem ser usados múltiplos clientes, quer correndo os mesmos testes ou testes complementares, para produzir a transacção worst case de volume pot um período extenso; A sgbd deve ser configurada para o tamanho máximo (ex: escalada ou preenchida com dados representativos) e com múltiplos clientes a correr queries ou transacções simultaneamente por períodos extensos. Critério Completude Todos os testes planeados são executados e condições limite específicas são atingidas/excedidas sem que o software falhe; Considerações Especiais Que período de tempo deve ser considerado como aceitável para condições de grande volume? 41 Metodologia casos de teste Implementação do conceito de Classe de teste Associada a área funcional /vertente Para cada Use Case/Requisito, os casos possuem a seguinte informação: Identificador; Tipo de teste; Classe de teste; Nome do caso/procedimento de teste; Conjunto de inputs /passos do teste; Condições de execução; Resultados esperados Pelo menos 2 casos de teste para cada um dos requisitos Teste positivo demonstrar que o requisito foi conseguido Teste negativo demonstrar que o requisito só é conseguido sob as condições desejadas 42
Exemplos casos de teste automatizados 43 Exemplos casos de teste funcionais 44
Metodologia testes aceitação A metodologia Link considera os seguintes testes de aceitação Aceitação formal Aceitação informal ou testes Alfa Testes Beta (muito pouca experiência ) Testes de aceitação formal Esforço de gestão elevado Extensão dos testes de sistema (mesmo cuidado e detalhe) Podem ser quase todos automatizados Testes de aceitação informal ou testes Alfa As funcionalidades e processos de negócio a testar estão identificadas e documentadas, mas não existem casos de teste particulares a executar O tester individual é que define o que fazer É frequentemente feito pela organização do cliente 45 Experiência em ferramentas Experiência considerável em 2 suites de referência do mercado Quality Center - HP/Mercury Interactive CARS Compuware Rational Quality Management - IBM Ferramentas e testware desenvolvido e adaptado pela Link Ferramentas Tracking Defeitos: GO-Gestor Gestor Ocorrências Gestão Global de Testes: LTM Link Test Manager Construção de casos de teste: QCTemplate Gerador de massa de testes: GenBir Scripts Simulador processamento: gerar_fatura.sh Simulador processamento: processa_chamadas.sh 46
Artefactos e templates Artefactos Plano de testes Guidelines de teste Modelo de workload Casos e procedimentos de teste Scripts de teste e testware Report de alteração/correcção Relatório de avaliação de testes Templates de requisitos Use Case (incluindo casos de teste associados aos cenários) Requisitos de Software Requisitos Stakeholders Plano Gestão Requisitos Especificações suplementares 47 Modelo financeiro (1) Modelo Time&Material Resulta de um acordo com o cliente Dimensão e estrutura da equipa de testes Duração do serviço São realizadas avaliações periódicas do modelo no arranque no final da 1ª fase (aprovação das especificações) No início da fase de transição Vantagens Foco no trabalho em equipa (cliente e desenvolvimento) Flexibilidade no modelo de trabalho Desvantagens Algumas ineficiências na ocupação da equipa 48
Modelo financeiro (2) Modelo de Fases 2 fases associadas às iterações 1ª fase até ao final da fase de Elaboração Fecho/aceitação das especificações do projecto de desenvolvimento Consiste 2 iterações 2ª fase até ao final da fase de Transição Aceitação do sistema, entrada em produção e fecho do projecto N-iterações Custo misto 1ª fase: custo fixo, dimensionado em fase de proposta 2ª fase: modelo de time&material, dimensionado e estruturado no final da 1ª fase Vantagens Parte do custo é fixo Foco no conceito de iteração abordagem mais disciplinada Suporta as habituais ineficiências existentes na fase de Elaboração Desvantagens Foco no conceito de iteração menor flexibilidade 49 Modelo financeiro (3) Modelo de Iterações O custo está associado ao número de iterações Existem 2 fases, cada uma com características acordadas com o cliente antes de cada uma delas Estrutura e dimensão da equipa Test guidelines Cada fase pode possuir várias iterações Em cada fase, o custo da iteração é fixo O conceito de iteração é rígido Vantagens Custo associado à qualidade do software-target Desvantagens Se a qualidade do software for má ou muito má, os custos são superiores 50
Contactos Nuno Camacho Silva nuno.c.silva@link.pt 213100074 51