Transferir como PDF, PPTX
Carregado porRodrigo Oliveira, Msc, PMP
Agile testing
O documento apresenta as informações pessoais e acadêmicas de um profissional com experiência em desenvolvimento de software e gestão de projetos. Resume os principais pontos dos métodos ágeis, como comunicação, entregas incrementais e foco no cliente. Também descreve os papéis e cerimônias do Scrum, como Sprint Planning, Daily Meeting e Sprint Retrospective.
Agile testing
- 2. Quem sou eu? Alguémque quer ajudar! Casado desde 2002, pai de 4 filhos! Trabalho com Desenvolvimento e Qualidade de Software desde 1993 Técnico em processamento de dados – 1994 Bacharel em Ciências da Computação – 2005 Especialista em Gestão de Negócios – 2007 MBA em Gestão de Projetos – 2009 Project Management Professional (PMP) pelo PMI desde 2009 Certified Brazilian Tester pela ALATS desde 2008 Mestre em Engenharia e Gestão de Sistemas e Processos – 2017
- 3. Objetivo dos métodoságeis A proposta de desenvolvimento ágil possui ênfase nos seguintes pontos: • Comunicação • Trabalho em equipe • Flexibilidade • Entregas incrementais • Comprometimento e Atitude
- 4. Benefícios Os principais benefíciosdos métodos ágeis são: • Entregas constantes para melhor feedback do cliente. • Melhor postura em casos de mudanças de requisitos. • Colaboração entre todos os envolvidos no projeto. • Foco na funcionalidade para o cliente e não em documentação interna. • Times multidisciplinares e auto organizado.
- 5. Algumas empresas queusam… Muitas empresas atualmente usam métodos ágeis, tais como:
- 6. Sucesso de projetosno mundo São considerados como de sucesso, pelo relatório, aqueles que terminaram dentro do prazo e do orçamento previstos e atenderam aos requisitos dos usuários. 14% 42% 57% 49% 29% 9% 0% 10% 20% 30% 40% 50% 60% Waterfall Agile Wartefall x Agile: Sucesso em Em Projetos Sucesso Desafio Fracasso
- 7. Principais pontos deatenção • Processo (gestão e papéis) • Estimativas • Artefatos do projeto • Arquitetura • Qualidade
- 9. Manifesto ágil dodesenvolvimento de software • Indivíduos e interações mais que processos e ferramentas • Software em funcionamento mais que documentação abrangente • Colaboração com o cliente mais que negociação de contratos • Responder a mudanças mais que seguir um plano • Tem 12 princípios: http://www.manifestoagil.com.br/principios.html • Criado por:
- 10. Visão Geral (baseadono Scrum)
- 11.
- 12.
- 13. Processo baseado noPDCA Plan DoCheck Act
- 15. Dono do Produto(Product Owner) • Responsável pela visão do que se deseja construir e transmitir esta visão para a equipe. • Entrega histórias de usuário detalhadas para o time de desenvolvimento (pode ter uma equipe por trás para auxiliá-lo, mas somente o PO responde à duvidas). • Prioriza os itens do backlog durante a reunião de planejamento do Sprint (mas não é de sua responsabilidade dizer quanto pode ser feito em um Sprint). • Exemplos de PO´s: Especialista em negócio, pessoas que conhecem do que precisa ser feito
- 16. Scrum Master • Responsávelpor disseminar os conhecimentos da metodologia ágil para a equipe (pode ser exercido pelo Escritório de Projetos). • Responsável por auxiliar na resolução do impedimento caso haja algum impedimento que o time de desenvolvimento não consiga resolver. • Responder ao Escritório de Projetos sobre os andamentos dos projetos. • Exemplos de SM´s: Líderes técnicos, gerentes de projeto, etc.
- 17. Time de Desenvolvimento •O time deve ter características multidisciplinares e auto organizado para uma melhor produtividade, composto ao menos por: Líder Técnico (1 pessoa) • Responsável por impedimentos para que os desenvolvedores e testes consigam trabalhar. Pode ficar responsável por algumas tarefas durante a Sprint. Desenvolvedores • Responsáveis pelas construções das funcionalidades priorizadas na Sprint. Tester • Responsável pela bateria de testes durante a Sprint.
- 18. Time de altodesempenho (Conhecimentos) • Importante que o nível da equipe seja equilibrado, entre perfis sênior, pleno e júnior (ou estagiários). • Primordial que a equipe possua ao menos um perfil sênior (no caso o líder técnico) e que haja uma pessoa sênior ou pleno para cada perfil júnior ou estagiário). 1 Profissional 2 Profissionais 3 Profissionais
- 20.
- 21. Pré-Game (Pre Game) Objetivo •Definir as caracteristicas do projeto, além de levantar as principais funcionalidades do produto. Tempo da cerimônia • Máximo de 1 mês. Pontos importantes • Auxilia no levantamento das principais funcionalidades para os primeiros sprints. • Define as características do projeto (times, tempo do sprints, definição de pronto, etc). • As principais histórias devem ser detalhadas pelo PO, para início das Sprints.
- 22. Contagem do Ponto deFunção ou story points Estimativas • A estimativa de custo pode ser feita por APF ou Story Points. • Ocorre durante a fase de Pré-Game, após o levantamento das principais histórias de usuário pelo PO. Realização do TAP Levantamento das Principais Histórias de Usuário
- 23. Planejamento da Sprint(Sprint Planning) Sprint Sprint Review Sprint Retrospective Features Delivered Product Backlog Sprint Backlog Daily Meeting Pre Game
- 24. Planejamento da Sprint(Sprint Planning) Objetivo • Planejar o que será realizado na sprint de acordo com o priorizado pelo PO e com a capacidade da equipe. Tempo da cerimônia • 1 dia por semana da sprint. Benefícios • A equipe auxilia no detalhamento de tarefas a serem executadas. • A equipe é quem estima a quantidade de horas por tarefa criada. • Oportunidade de analisar o período da sprint para planejá-la acertivamente (feriados, impedimentos, etc).
- 25. Estimativa de esforçocom Planning Poker • Prática que ajuda na estimativa de uma história de usuário através de sua complexidade (não em horas). • Baseado na sequência Fibonnaci para representar esta complexidade (onde são escolhidos 10 números). 1, 2, 3, 5, 8, 13, 21, 40, 100, ?
- 26. Iniciando o PlanningPoker • O Planning Poker deve acontecer durante a Sprint Planning. • Para cada projeto, deve ser selecionado uma história de complexidade 2. • A partir desta história, deve-se basear na estimativa por comparação: se a história C possui complexidade 2, qual a complexidade de uma outra história? História C História D História E História B História A
- 27. Jogando o PlanningPoker • A partir de uma história priorizada pelo dono do produto, o líder do projeto questiona qual a sua estimativa. • O time escolhe a estimativa, mas ainda não a revelam. • Ao sinal, toda equipe mostra a estimativa ao mesmo tempo. 5 13 5 5 13 5
- 28. Jogando o PlanningPoker (continuação) • Havendo divergências, quem colocou os maiores e menores valores explicam os motivos. • Após a discussão, o time escolhe a estimativa novamente. • Caso a divergência persista, deve-se fazer novamente as explicações. 5 5 5 5 5 5
- 29. Velocidade do Time •As complexidades informadas são usadas para medir a velocidade do time, que é a medida de produtividade de cada Sprint. • Ao longo do projeto, a velocidade tende a ter um valor estável, tendo-se a média de velocidade que o time consegue entregar a cada Sprint. • Esta velocidade tende a alterar a cada equipe e/ou projeto. • Tem ficar atento à variabilidade da velocidade de entrega. Ter uma média X não quer dizer que se entrega X em todos os sprints. 0 10 20 30 40 50 1 2 3 4 5 6 7 8 9
- 30.
- 31. Sprint Objetivo • Todo operíodo onde determinadas funcionalidades serão construídas para a geração de um entregável e onde as demais cerimônias serão executadas (as demais estão inclusas nesta cerimônia). Tempo da cerimônia • 1 a 4 semanas (ideal que seja 3 semanas). Pontos importantes • Após a definição dos itens a serem trabalhados na Sprint, o ideal é que os mesmo não devem ser alterados durante a Sprint.
- 32. Sprint Pontos importantes (continuação) •Em raras exceções, a aprovação da mudança deve ser negociada com o PO e a mudança não deve impactar o tempo da Sprint. • A Sprint não tem o seu tempo estendido para a conclusão da entrega. • Caso aconteça, os itens não finalizados devem retornar para o Product Backlog, porém, se for essencial a entrega, é aceitável uma extensão em até 20% da Sprint.
- 33. Gráfico de Burndown(Burndown Chart) 1Semana 2 3 4 • Mostra a quantidade de trabalho restante em uma Sprint ao longo do tempo. • É uma forma visual e rápida de enxergar o status da Sprint. • Tem como objetivo apresentar a quantidade de trabalho restante em comparação ao trabalho que foi planejado.
- 34.
- 35. Reunião Diária (DailyMeeting ou Stand Up Meeting) Objetivo • Sincronizar a equipe com os acontecimentos e avanços da sprint, através das perguntas: O que você fez? O que você pretende fazer? Existe algum impedimento para sua atividade? Tempo da cerimônia • 15 minutos por dia em pé (para não durar mais que o necessário). Benefícios • Troca de informações entre a equipe para facilitar a execução da tarefa. • Antecipar (ou minimizar) qualquer impedimento de uma tarefa.
- 36. Revisão da Sprint(Sprint Review) Sprint Sprint Retrospective Features Delivered Product Backlog Sprint Planning Sprint Backlog Daily Meeting Pre Game
- 37. Revisão da Sprint(Sprint Review) Objetivo • Demonstrar informalmente os resultados obtidos durante a sprint para o PO e demais envolvidos para aceitação da entrega. Tempo da cerimônia • Geralmente 1 hora de apresentação para cada semana da sprint. Benefícios • Demonstrar a todos envolvidos as funcionalidades criadas. • Obter feedback do PO e envolvidos para possíveis melhorias.
- 38. Retrospectiva da Sprint(Sprint Retrospective) Sprint Sprint Review Sprint Retrospective Features Delivered Product Backlog Sprint Planning Sprint Backlog Daily Meeting Pre Game
- 39. Retrospectiva da Sprint(Sprint Retrospective) Objetivo • Discussão entre a equipe para avaliar acertos e falhas da sprint, para melhoria de processos, ferramentas, pessoas e definição de “Pronto”. Tempo da cerimônia • Geralmente 45 minutos de reunião para cada semana da sprint. Benefícios • Possibilidade de melhorar o processo a cada nova sprint.
- 40. Premissas para oSucesso • É ideal que não haja mudança no PO e na equipe do projeto, uma vez que esta mudança gera perda de informações (lembrando que o uso de documentação é minimizado). • O PO deve estar disponível sempre que possível, para tirar as dúvidas da equipe durante a construção de uma funcionalidade. • A equipe deve possuir todas as habilidades possíveis para desenvolver o projeto. • O time deve estar junto fisicamente durante todo projeto para não haver perdas na comunicação.
- 42. Processo Ágil Sprint Atual ~5 artefatos Processoproposto • Um único time conhece e acompanha todo o processo de desenvolvimento de uma funcionalidade (não há necessidade de criar documentações para repasse). • Foco da comunicação é através de conversas (inclusive com PO). • Caso necessário, demais artefatos podem ser criados para auxiliar na comunicação. • Foco no eficácia fazer a coisa certa • Atitude, comprometimento, disciplina fatores chaves de sucesso do projeto Product Backlog ~2 artefatos
- 43. Artefatos Esperados Dono doProduto • História de Usuário • As funcionalidades desejadas são escritas em um formato texto, tentando responder o que se deseja atingir, os benefícios da funcionalidade e suas regras. Todas com uma visão de negócio e não técnica. • Esboço de Interface • Em algumas ocasiões, quando o usuário já possui uma visão de como deve ser disposta algumas funcionalidades, o uso de esboços juntamente com a história do usuário pode ser benéfica.
- 44. Artefatos Esperados (continuação) Desenvolvedor •Teste Unitário • É importante construir os testes unitários para atender as regras da funcionalidade, para que sejam atendidas durante a construção (e auxiliar em posteriores manutenções). • 100% do código fonte deve ser coberto com teste • Testes integrados entre classes • Código Fonte • O principal artefato da sprint, que é o responsável por “dar vida” a funcionalidade.
- 45. Tester • Plano eCaso de Teste • Criação dos roteiros de testes a serem executados para garantir que uma funcionalidade funcione conforme esperado e com qualidade. • Automação de Teste • Uma vez que os testes manuais estejam estabilizados, deve haver a construção de testes automatizados, visando uma qualidade contínua da funcionalidade. Artefatos Esperados (continuação)
- 46. Definição de “Ready”(PO para Time Dev.) • Definição com o PO do que o time considera como uma história de usuário pronta para ser desenvolvida. • Caso não esteja de acordo com as definições, o Time de Desenvolvimento não é obrigado a aceitar uma história de usuário para desenvolver.
- 47. Definição de “Pronto”(Time Dev. para PO) • Definir os artefatos necessários para a construção de um projeto (pode variar de um projeto para outro). • Uma tarefa só pode ser considerada como pronta, se todos os artefatos tiverem sido construídos, além de atingir os critérios de aceitação de cada história. • Durante o Pré-Game, Planejamento de Sprint ou em uma Retrospectiva de Sprint estes artefatos podem ser definidos/melhorados.
- 48.
- 49.
- 50.
- 51. Outros Métodos ágeis: Visualizaro fluxo de trabalho Limitar o WIP Medir e Gerenciar o fluxo Tornar as políticas explícitas Implementar mecanismos de feedback Melhorar colaborativamente utilizando modelos e método científico
- 52.
- 53.
- 54.
- 55.
- 57.
- 58. DevOps • Alguns pontosimportantes: • Automatizar processos de desenvolvimento • Executar testes a cada mudança no código • Implantar Feature Toggles • Infraestrutura como código
- 59. DevOps • Alguns pontosimportantes: • Cultura: Colaboração; Fim das divisões; Relação saudável entre as áreas; Mudança de comportamento • Automação: Deploy; Controle; Monitoração; Gerência de configuração; Orquestração • Avaliação: Métricas; Medições; Performance; Logs e integração • Compartilhamento: O feedback é tudo; Boa comunicação entre a equipe
- 60.
- 61.
- 63. Práticas Ágeis Práticas Ágeisde Requisitos (Requirements) • Visão do Produto (Product Vision / Vision Statement) • Product Backlog • Histórias de Usuário (User Stories) • Injeção de Funcionalidades (Feature Injection) • Casos de Uso (Use Cases) • Cenários de Uso (Usage Scenarios) • Personas • Poker do Planejamento (Planning Poker) • Priorização de Requisitos (Requirement Prioritization) • Mapeamento de Estórias de Usuário (User Story Mapping) • Business Canvas / Lean Canvas
- 64. Práticas Ágeis Práticas Ágeisde Design • Architectural Spikes / Spike Solutions • DDD – Domain Driven Design • Design Emergente/Evolutivo (Emergent/Evolutionary Design) • Cartões CRC (CRC Cards) • Design by Contract Wiki • Metáfora do Sistema (System Metaphor)
- 65. Práticas Ágeis Práticas Ágeisde Desenvolvimento (Construction) • Padrões de Codificação (Coding Style / Coding Guidelines / Coding Standard) • TDD – Test Driven Development • BDD – Behavior Driven Development • Programação em Par (Pair-Programming / Pairing) • Refactoring • Código Coletivo (Collective Code Ownership) • Build Automatizado (Daily Builds / Automated Builds / Ten-Minute Builds) • Integração Contínua (Continuous Integration) • Revisão de Código (Code Reviews / Peer Reviews) • Controle de Versão (Source Control / Version Control) • Entregas Frequentes (Frequent Delivery / Frequent Releases) • Código Limpo (Clean Code)
- 66. Práticas Ágeis Práticas Ágeisde Processo (Process) • Iterações (Timeboxing / Fixed Sprints / Fixed Iteration Length) • Planejamento de Releases (Release Planning) • Planejamento de Iterações (Iteration Planning / Planning Game / Sprint Planning) • Sprint Backlog • Quadro de Tarefas (Task Board/ Kanban Board) • Limite do Trabalho em Progresso (WIP Limits) • Classes de Serviço (Classes of Service) • Tempo de Ciclo (Lead time / Cycle Time) • Definição de Pronto (Definition of Done / Done Done) • Reunião Diária (Daily Stand-up Meeting / Daily Scrum) • Velocidade (Velocity) • Reunião de Demonstração ou Revisão (Sprint Review / Iteration Demo) • Mapa de Cadeia de Valor (Value Stream Mapping) • Análise de Causa Raiz (Root Cause Analysis / 5 Whys) • Burn Down Charts / Burn Up Charts • Cumulative Flow Charts (Gráficos de Fluxo Cumulativo) • Gestão à Vista (Big Visible Charts / Information Radiators) • Retrospectivas (Retrospective / Reflection Workshop) • Backlog de Melhorias (Improvements Backlog)
- 67. Práticas Ágeis Práticas Ágeisde Organização (Organization) • Times Pequenos (Small Team) • Times Cross-Funcionais (Cross-Functional Team) • Equipes Auto-organizadas (Self-Organizing Team / Scrum Team) • Ambiente de Trabalho Compartilhado (Colocated Team / Sitting Together / Common Workspace) • Cliente Interno / Dono do Produto (On-Site Customer / Product Owner) • Scrum Master • Ritmo Sustentável (Sustainable Pace) • Mude as Pessoas de Lugar (Move People Around) • Scrum of Scrums • Comunidades de Prática (Communities of Practices)
- 68. Práticas Ágeis Práticas Ágeisde Aprendizado • Coding Dojos • Mob Programming • Clubes de Livro (Book Clubs) • Palestras da Equipe para a Equipe (Brown Bag Seminars) • Biblioteca Rica à Disposição (Livros, Screencasts, Áudio-livros, Contas no SafariBooks) • Participação em Eventos (Alta cobertura de eventos)
- 69. Práticas Ágeis Práticas deGestão Ágil • Contratação com Participação do Time (team helps on hiring) • Reuniões de Feedback 360 Graus / Pesquisas 360 Graus • Reuniões One-on-ones (one-on-ones meetings) • Índice da Felicidade (happiness index) • Definição de Metas (goal setting) • Gemba walks • Poker da Delegação (Delegation poker) • Quadros de Autoridade (Authority boards) • ROTI – Retorno sobre o Tempo Investido (Return on Time Invested) • Resolução de Problemas com A3 • Hackathon (FedEx Days, ShipIt Days, Explorations Days) • Percentual de Tempo para Aprendizado (SlackTime) • Impedimentos Visíveis.
- 71. Manifesto ágil doteste de software • Testar por todas as etapas mais que testar somente no final • Prevenir defeitos mais que encontrar defeitos • Testar o entendimento mais que checar funcionalidades • Construir o melhor Sistema mais que quebrar o Sistema • Time responsável pela qualidade mais responsabilidade dos testers
- 72. Manifesto ágil doteste de software
- 73. Manifesto ágil doteste de software
- 74. Quadrante dos testeságeis
- 75. Práticas Ágeis -Testes • Testes Unitários (Unit Testing) • Testes de Fumaça (Smoke Testing / Build Verification Test) • Testes de Integração (Integration Testing) • Testes de Sistema (System Testing) • Testes Exploratórios (Exploratory Testing) • Testes de Aceitação (Storytesting / Acceptance Criteria / Acceptance Testing)
- 76. Processo de testesWatefall • É feita toda a codificação para posteriormente ser realizado os testes e estabilização do software. • Com isto, há a probabilidade da codificação ter gerado uma enorme quantidade de erros que só serão vistos posteriormente.
- 77. Processo Testes Ágeis •Com entregas incrementais, as construções ocorrem mais rapidamente e o teste ocorre em paralelo. • Com esta entrega mais rápida, o trabalho de estabilização ocorre de forma menos traumática e mais efetiva.
- 78. Estabilização de umarelease Especificação de Teste Unitário Planejamento + Especificação de Caso de Teste Execução de Teste Manual + Automação de Teste Codificação + Correção de Defeitos Histórias de Usuário+ Esboços de Interface • O tester é responsável por planejar, executar os testes manuais e automatizar os testes durante a Sprint. • O controle de qualidade é feito durante a Sprint pelo tester. • A correção de defeitos encontrada pelo tester é feita durante a Sprint.
- 79. Bugs encontrados forada Sprint • Caso algum bug seja encontrado após a conclusão da Sprint que esta funcionalidade pertença, as seguintes ações podem ser tomadas: • Se o bug for fácil de corrigir, deve ser corrigido na Sprint atual. • Se o bug não for trivial e não bloqueador, deve ser inserido no Product Backlog Gera débito técnico • Se o bug for bloqueador, deve ser adicionado na Sprint atual e outro item da Sprint atual deve ser removida.
- 80. Desenvolvimento ágil desoftware (ou de qualquer outra coisa) é essencialmente: Melhoria contínua Sistema Toyota de Produção
- 81. Para melhorar temque medir!
- 82. • SIX SIGMAé uma forma de medir! • Metodologia que fornece abordagem de medição orientada a dados para melhoria contínua de processos • Busca satisfação do cliente • Objetivos: • Mover o produto/atributos de serviço para dentro dos limites especificados pelo cliente • Reduzir a variação no processo (causa de defeitos) Medir como?
- 83. • O conceitoestatístico, primeiramente, considera que o comportamento do processo segue a distribuição normal de probabilidades; • Baseado nesta premissa, busca-se reduzir gradativamente a variabilidade de um processo até que se atinja um fator de 99,99966% de sucesso ou seja 3,4 PPM (Seis vezes o desvio padrão); Como funciona Seis Sigma?
- 84. • A tabelaabaixo apresenta os Limites de Especificação vs. Defeitos para Distribuição com Deslocamento • Se considerarmos uma variação da média µ = ± 1,5 σ, o que é bastante comum na vida real, teremos o gráfico da Figura: Tabela Limites de Especificação vs. Defeitos para Distribuição com Deslocamento de ± 1,5 Como funciona Seis Sigma?
- 85. Quatro Sigma (99,38%conforme) Seis Sigma (99,99966% conforme) Sete horas de falta de energia elétrica por mês Uma hora de falta de energia elétrica a cada 34 anos 5.000 operações cirúrgicas incorretas por semana 1,7 operação cirúrgica incorreta por semana 3.000 falhas a cada 300.000 viagens Uma falha para cada 300.000 viagens Quinze minutos de fornecimento de água não potável por dia Um minuto de fornecimento de água não potável a cada sete meses. 1 erro a cada 30 páginas 1 erro / todos os livros de uma pequena biblioteca Benefícios do Seis Sigma
- 86. • No 6S,qualidade não tem a ver com conformidade com resoluções internas ou normas; • Qualidade Potencial - Qualidade Atual = Perda; • Qualidade diretamente ligada com o nível sigma; • Para avaliar qualidade do software usando Six Sigma, deve-se considerar que: • Cada clique é uma oportunidade de se gerar defeito • Um clique dispara entradas, saídas, transações, processamentos, armazenamentos internos e externos • Casos de teste são considerados como sendo as oportunidades de defeito Seis Sigma para Software
- 87.
- 88. Referências Nº Título Autor(es)Ano 1 Agile Estimating and Planning Mike Cohn 2005 2 Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin 2008 3 Working Effectively with Legacy Code Michael Feathers 2004 4 Refactoring: Improving the Design of Existing Code Martin Fowler, et al. 1999 5 The Art of Unit Testing: With Examples in .Net Roy Osherove 2009 6 Agile Software Development, Principles, Patterns, and Practices Robert C. Martin 2002 7 The Pragmatic Programmer: From Journeyman to Master Andrew Hunt, David Thomas 1999 8 Kanban: Successful Evolutionary Change for Your Technology Business David J. Anderson 2010 9 Succeeding with Agile: Software Development Using Scrum Mike Cohn 2009 10 Growing Object-Oriented Software, Guided by Tests Steve Freeman, Nat Pryce 2009
- 89.