1 Orientações iniciais Dê preferência ao uso de uma conexão de banda larga O evento não fará uso do vídeo (webcam), somente slides e áudio Se necessário, ajuste o idioma da sala na barra de ferramentas superior O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas Você pode mandar suas perguntas pelo chat ao longo da apresentação A apresentação será gravada e o vídeo publicado posteriormente Para aqueles que possuem certificação PMP, o evento vale 1 PDU Acompanhe-nos nas redes sociais
FATTO Consultoria e Sistemas Missão: Ajudar nossos clientes a planejar e controlar melhor seus projetos de software. Consultoria e Treinamento em Medição, Estimativas e Requisitos de Software: Análise de Pontos de Função (IFPUG, NESMA, COSMIC) Estimativas de projetos de software Engenharia de Requisitos Medição e auditoria em medição de software Análises de produtividade em projetos de software O livro mais vendido de APF no país foi escrito por nós Formou ~25% de especialistas certificados pelo IFPUG no Brasil Representante do Scope Project Sizing Software Aumenta seu nível de governança nas medições funcionais e na gestão dos ativos de software FATTO Consultoria e Sistemas - www.fattocs.com.br 2
TESTE DE SOFTWARE: UMA VISÃO TRADICIONAL E ÁGIL Instrutor: Marcelo Nascimento Costa, MSc marcelo.costa@fattocs.com.br Sejam Todos Bem-Vindos 3 FATTO Consultoria e Sistemas - www.fattocs.com.br
4 Custo do defeito
5 Efeitos Colaterais do Defeito O Custo do defeito Insatisfação do cliente Perda de imagem perante o mercado Perda de oportunidades de novos negócios
Teste de Software Processo de executar um programa ou sistema com o objetivo de revelar a presença de falhas; ou, falhando nesse objetivo, aumentar a confiança sobre o programa
Teste de Software Não ocorrência de falha: Software é de alta Qualidade? OU Teste é de baixa Qualidade?
Processo de Testes de Software Tradicional Objetivo: Organizar o conjunto de atividades a serem realizadas durante os testes Composto de: Atividades, papéis, critérios de entrada/saída, artefatos Benefícios: Melhor alocação dos recursos definidos para o projeto Gerenciamento da equipe de teste Atividades: Planejar os Testes Executar os Testes Controlar os Testes e Analisar seus Resultados
Processo de Planejamento dos Testes 1. Planejar Testes Sub-processo de Planejamento dos Testes Gerente de Teste Plano de Teste Especificação de Projeto de Teste Especificação de Caso de Teste Especificação de Procedimento de Teste Projetista de Teste 2. Projetar Testes 3.Especificar Casos de Teste 4.Definir Procedimentos de Teste
Sub-Processo de Execução dos Testes Sub-processo de Execução dos Testes Testador Especificação de Procedimento de Teste 5. Executar Testes Log de Teste Relatório de Incidente de Teste Gerente de Teste 6. Analisar Resultados dos Testes Relatório de Resumo dos Testes
Manifesto Ágil Quebra de paradigma Indivíduos e interações entre eles, ao invés de processos e ferramentas. Software funcionando ao invés de documentação detalhada. Colaboração com os clientes ao invés de documentação e contratos. Adaptação a mudanças ao invés de seguir um plano inicial.
Teste Ágil vs. Cascata FATTO Consultoria e Sistemas - www.fattocs.com.br
Como funcionam os Testes Àgeis Abordagem Whole Team Equipe única Codificação e Testes são um único Processo Feedback e Colaboração Práticas TDD/BDD/ATDD Desenvolvedores Test-infected Testar não é a última coisa a fazer no projeto. É a primeira! E deve continuar por todo o projeto
Papel do Testador Ágil (1) Mudança de Paradigma O Analista de Teste passa a ser proativo Revisar, clarificar estórias de usuários Participação no levantamento dos requisitos com o usuário Participar de definições de Arquitetura do Sistema Estimar as atividades de teste durante o planejamento
Papel do Testador Ágil (2) Mudança de Paradigma Automatizar testes funcionais Testes de IU Suporte aos testes unitários e de integração Planejar e executar testes de regressão, performance e usabilidade e segurança Feedback contínuo sobre a qualidade do projeto.
Evolução dos Testes Manuais para os Testes Ágeis Foco em Automação Abordagem Tradicional Abordagem Ágil FATTO Consultoria e Sistemas - www.fattocs.com.br [Qualister, Pirâmide da automação de teste, 2010]
Quadrante de Testes Ágeis Foco RNs Foco UAT Foco TDD Foco RNFs FATTO Consultoria e Sistemas - www.fattocs.com.br (Brian Marick,2010)
Como o Google Testa Software*? Possui uma área conhecida como Engineering Productivity (Área de Testes) O Testador participa do mesmo processo de admissão do desenvolvedor Os engenheiros de testes têm a mesma velocidade de carreira de um desenvolvedor Qualidade não é responsabilidade apenas do Engenheiro de testes, todos que desenvolvem tem a responsabilidade Focam na qualidade das features das entregas contra a quantidade de features entregadas * Extraído do livro How Google Tests Software?
19 Lema Principal de Testes do Google Qualidade não é igual a teste. Qualidade é obtida reunindo desenvolvimento e testes, misturando até um ser indistiguível de outro
Papéis do Google Engenheiro de software (SE): possui o papel tradicional do desenvolvedor. Escreve o código em si e escreve código de teste, incluindo TDD. Engenheiro de Software em Teste (SET): é um papel de desenvolvedor também, exceto que o foco está na testabilidade e infraestrutura geral de teste. Refatora o código para tornar mais testável e escreve frameworks de teste unitário. Compartilha o código base mas focando sempre em melhoria da qualidade. Engenheiro de Teste (TE): Está relacionado ao SET mas com outro foco. Utiliza a criação de testes automatizados pensando nos cenários de uso e até mesmo no comportamento do usuário. Orientam o trabalho dos papéis acima.
Resumo do Processo no Google O Engenheiro de software é responsável pela codificação das features, TDD, testes de unidade, e por trabalhar com o SET para escrever testes que exercitem o código. Engenheiro de Software em Teste (SET) são desenvolvedores que fornecem apoio a testes. Desenvolvem frameworks simulando o ambiente atual, como stubs, mocks e gerenciam os check-ins de código. O Engenheiro de Teste (TE) executa os testes orientados ao usuário após a execução dos testes do SET e do SE. Realiza um double check das primeiras fases de testes. No caso de bugs mais raros, o TE parte para testar requisitos não-funcionais como segurança, localização, acessibilidade, assim por diante.
22 Conclusões O paradigma de testes ágeis existe na literatura há mais de 10 anos, porém no cenário brasileiro poucas empresas o utilizam A maioria das empresas executa bastante testes porém na maioria das vezes em um abordagem adhoc e/ou manual A migração para uma abordagem automatizada e com uma visão mais ágil pode ser um grande ganho para as empresas pelo aumento da velocidade no processo de garantia da qualidade dos projetos e manutenção do software. A automação não é uma solução rápida e barata pois requer implantação, treinamento e coaching para a utilização de ferramentas de forma produtiva