CTFL-AT

Colaboração do cliente acima de seguir um plano

Responder a mudanças acima de seguir um plano

Indivíduos e iterações acima de processos e ferramentas

Software funcionando acima de documentação abrangente

Aumento da comunicação e colaboração

Aumenta a habilidade do dono do produto nas técnicas do desenvolvimento

Elaboração de documentação detalhada

Transferência de conhecimento do desenvolvedor para o dono do produto

Ajudar a visualizar o backlog do produto

Ajudar a visualizar o workflow

Contribuir com o radiador de informação

Ajudar a limitar o trabalho em progresso

O código

O backlog do produto

A qualidade do produto

A velocidade com a qual as estórias são completadas

De toda a equipe

Do desenvolvedor

Do testador

Do dono do produto

Simplicidade e motivação

Indivíduos e interações

Software funcionando e documentação mínima

Entrega frequente e colaboração com o cliente

Permitir à equipe coordenar o trabalho e comunicar incidentes

Dar ciência ao scrum master sobre quaisquer incidentes

Comunicar o progresso ao cliente

Implementar melhoria contínua para o próximo trabalho

Ajudar o dono do produto a articular as estórias do usuário na forma de exemplos e testes

Atualizar o progresso do projeto nos quadros de informações

Ajudar o dono do projeto na priorização do backlog

Trabalhar com a equipe para automatização dos testes

O gerente do projeto

O gerente funcional

O dono do produto

A equipe

XP

Scrum

Waterfall

Kanban

Programação em pares

Revisão

Modelo V

Nenhuma das anteriores

O backlog da iteração

O backlog do produto

O gráfico de velocidade

O gráfico burndown da iteração

Trazer temas relacionados com testes. Todos os outros tópicos serão abordados por diferentes participantes

Como observador, assegurando que a reunião segue as regras de retrospectivas e valores ágeis

Fornecer feedback e sugestões sobre todas as atividades realizadas pela equipe durante o sprint

Só participar de uma retrospectiva caso tenha algum feedback e sugestões relacionadas às atividades realizadas pela equipe durante o sprint

O testador informa que a tela para a estória do usuário precisa ser uma única página, para reduzir o esforço de automação

O testador informa que a usabilidade é mais importante que o desempenho

O testador informa que os critérios de aceitação de desempenho devem ser padronizados para o máximo de 1 segundo para armazenamento de dados

O testador informa que a estória precisa seguir critérios de aceitação para ser testável

Deve haver mais ênfase no teste de unidade no futuro, para melhorar a qualidade global

O processo de compilação é manual e leva muito tempo. Pesquisa e implementação de um framework deve ser feita

Tester X está sofrendo para encontrar defeitos. Treinamento sobre modelagem de testes é necessário para este recurso

Suítes de teste de regressão estão demorando muito para ser executadas. Necessária a avaliação dos testes, para eliminar testes desnecessários ou redundantes

Ajuda a construir software que muda regularmente, incluindo testes e implantação, de forma automatizada

Permite versões novas do software estarem disponíveis, com frequência, para testadores e partes interessadas

Ajuda a detectar novos defeitos de integração precoce e facilita a sua análise

Garante que os testes de compilações são feitos manualmente, pois isso gera resultados mais confiáveis que testes automatizados

Produz uma lista de testes de aceitação para estórias de usuários

Ajuda a quebrar estórias de usuário em tarefas menores e mais detalhadas

Estima tarefas de testes geradas por novas funcionalidades para esta iteração

Suporta o esclarecimento das estórias de usuários para garantir que elas são testáveis

Um artefato que o testador deve revisar e assinar antes de começar a testar

Um artefato usado apenas para detalhar os requisitos funcionais do sistema

Um artefato documentado por representante da área de negócio para ajudar os desenvolvedores e testadores a entenderem os requisitos do sistema

Um artefato escrito em colaboração por desenvolvedores, testadores e os representantes da área de negócio para capturar os requisitos

Testadores escrevem planos de teste detalhados, para que todos os membros da equipe possam compreender o que será testado a cada iteração

Testadores estão fortemente envolvidos na criação de casos de teste automatizados, que então são utilizados para verificar a aplicação dos requisitos

Testadores executam testes exploratórios, a fim de encontrar defeitos importantes rapidamente

Testadores colaboram com desenvolvedores a entender melhor o que precisa ser testado

Para falar com o dono do produto

Para falar com o scrum master

Para o burndown da iteração

Para o plano de release

INVEST

SURE

GROOM

DEEP

Pode haver um risco de perda de independência de testes para organizações que introduzem ágil

Testadores independentes vão encontrar mais defeitos que os desenvolvedores

Testes independentes podem ser introduzidos ao final de um sprint

A equipe de teste independente pode ser parte de outra equipe

Automatizar testes e mantê-los

Orientar e treinar outros membros da equipe

Produzir e atualizar gráficos de burndown

Participar das atividades de análise de código

A TDD é uma abordagem ‘teste-primeiro’ para desenvolver testes automatizados reutilizáveis

O ciclo TDD é usado continuamente até que o produto de software seja liberado

TDD ajuda a manter código para esforços de manutenção futuros

O resultado de TDD são classes de teste, utilizado pelo desenvolvedor para desenvolver casos de teste

A carga de trabalho da equipe aumenta a cada sprint

Como os testes decrescem em função do tamanho do backlog

O número de testes unitários automatizados é maior que o número de testes automatizados para níveis maiores de teste

O número de testes automatizados aumenta a cada sprint

Ao comunicar idéias de teste, o testador pode se referir ao quadrante de teste correspondente, para que o resto da equipe compreenda melhor o objetivo do teste

O testador pode usar os tipos de testes descritos nos quadrantes como uma métrica de cobertura. Quanto mais testes abrangidos em cada quadrante, maior será a cobertura do teste

A equipe deve escolher um número de testes esperados de cada quadrante, e o testador deve projetar e executar esses testes para garantir que todos os níveis e tipos de testes foram executados

O testador pode usar os quadrantes durante a análise de risco, com os quadrantes de nível inferior representando um risco menor para o cliente

1

2

3

4

1

2

3

4

Burndown

Logs de automação

O quadro ágil de tarefas mostrando estórias do usuário e progresso da tarefa

Ferramentas de monitoramento de defeitos

Um gráfico mostrando quais membros da equipe estão trabalhando mais, e quais estão sob estresse

Um gráfico que mostra o progresso de cada estória de usuário, e quando elas provavelmente serão concluídas

Um gráfico que mostra a quantidade de trabalho a ser feito, versus o tempo alocado para a iteração

Um gráfico que mostra quais defeitos foram consertados, e quais provavelmente serão

Scrum

XP

Programação Discreta

Desenvolvimento Orientado a Testes

Q1: nível de unidade, orientado à tecnologia; Q2: nível de sistema, orientado a negócios;

Q2: nível de sistema, orientado a negócios; Q3: nível de sistema ou de aceitação do usuário, voltado para negócios;

Q3: nível de sistema ou de aceitação do usuário, voltado para negócios; Q4: nível sistema ou aceitação operacional, voltado para tecnologia;

Q2: nível de sistema, orientado a negócio; Q4: nível sistema ou aceitação operacional, voltado para tecnologia;

Como o tamanho da estimativa do desenvolvedor e do cliente coincidiram, a equipe pode ter certeza que esta estimativa é boa, e deve passar para a próxima estória de usuário

A equipe deve manter uma conversa para entender por que os testadores sentiram que esta estória de usuário resultará em mais trabalho. Outra rodada de sessão de planning poker deve ocorrer após a discussão

Porque o cliente é dono do sistema, no final, deve se tomar a sua estimativa como correta quando há conflito

As sessões de ‘planning poker’ devem continuar até que todos os pontos da estória sejam coincidentes entre clientes, desenvolvedores e testadores

Todos os casos de teste foram executados

A probabilidade de falhas restantes foi reduzida a um nível que pode ser aceito pelo cliente

A cobertura de teste alcançada é considerada suficiente. O limite de cobertura é justificado pela complexidade da funcionalidade, sua implementação e seus riscos envolvidos

A iteração/sprint terminou

Teste de Transição de Estado - testar os seguintes estados: navegação, logado, seleção, aquisição, confirmação e sair

Tabela de Decisão - testar as seguintes condições: usuário conectado; ao menos um item no carrinho; compra confirmada; financiamento aprovado; com a ação resultante de: item despachado

Teste de Análise de Valor Limite - testar as seguintes entradas: 0, 5, 6, 10, 11

Teste por Caso de Uso - Ator: cliente; Pré-requisitos: cliente faz logon, seleciona e compra itens; Pós-condições: itens são enviados

Englobam a aprendizagem, modelagem de teste e execução, simultaneamente

Eliminam a necessidade de testadores prepararem idéias de teste antes de sua execução

Quando combinados com outras estratégias de teste, produzem os melhores resultados

Para executá-los, testadores precisam de alta compreensão do sistema

Definir os critérios de saída

Realizar análise de risco de qualidade

Garantir que o código liberado nessa iteração tenha atingido o nível de cobertura planejado

Especificar a definição de ‘pronto’

Isso é normal em uma equipe ágil, que trabalha com pouca documentação e abraça as mudanças

Houve falha no planejamento da sprint, quando se deveria ter planejado “onde” (ambientes) o teste seria realizado

Houve falha no planejamento do backlog do produto, a partir do qual é possível prever a necessidade de ambiente de teste

Houve falha de relato no quadro Kanban, local adequado para se planejar o ambiente de teste necessário para as sprints

Mostrar os parâmetros de configuração de software de acordo com o servidor que será instalado

Permitir exclusivamente o armazenamento do código-fonte e seu controle de versão

Permitir a virtualização de servidores, agilizando a preparação do ambiente

Serem utilizados não só para armazenar código-fonte e testes automatizados, mas também os testes manuais e outros produtos do trabalho de teste

Cenário I não é o melhor caminho, porque em testes exploratórios, modelagem e execução de teste acontecem ao mesmo tempo, mas são guiados por uma Carta de teste que inclui atores, condições de teste, dados de teste etc. Os resultados dos testes também são documentados e orientarão o próximo teste.

Cenário II é a melhor maneira porque neste caso, os testadores tẽm conhecimento da estória do usuário, o que irá ajudá-los a atuarem com as condições de teste e idéias. A equipe está usando sessões de testes exploratórios por tempo determinado. A equipe está orientada a documentar as condições de testes, dados, informações do usuário, e resultados no log de teste. Problemas são registrados em uma ferramenta de rastreamento de defeitos, assim como qualquer outra técnica de teste.

Cenário III não é o melhor caminho, porque isso poderia estar descrevendo testes de aceitação do sistema, mas não testes exploratórios.

Cenário IV não é o melhor caminho, porque a documentação é necessária para testes exploratórios, e testadores devem registrar as idéias e resultados dos testes. Os resultados dos testes são usados para guiar testes exploratórios futuros.

Permite às equipes construírem um conhecimento baseado em ferramentas e técnicas de desenvolvimento e testes

Fornece resposta rápida sobre a qualidade da construção e detalhes sobre as mudanças de código

Fornece visibilidade sobre o estado atual do aplicativo, especialmente com equipes distribuídas

Gera e carrega grandes volumes e combinações de dados, para usar nos testes

O testador deve notificar a equipe que estão planejando trabalhar horas extras durante os dois próximos sprints, a fim de atualizar a estrutura de automação de teste existente e scripts para apoiar o novo navegador, de modo a não atrapalhar o plano de sprint existente

O testador irá notificar a equipe do problema. A análise de risco é feita, e a equipe decide que testes de regressão deverão ser executados no novo navegador, em adição aos já suportados. O testador irá atualizar o plano de sprint adicionando tarefas para modificar o framework de automação ou os scripts

O testador faz algumas pesquisas e conclui que o risco é baixo para quaisquer novos defeitos a serem introduzidos no novo navegador que já não tenham sido encontrados nos navegadores suportados. O testador continua com o plano de sprint existente e não faz alterações no framework de automação ou nos scripts

O testador vai parar o que estão fazendo, projetar testes específicos de compatibilidade do novo navegador, e comunicar à equipe que quaisquer outros trabalhos de teste terão de ser empurrados para o sprint seguinte

O cliente aprende logo o desenvolvimento, na medida em que é capaz de manipular o sistema

A especialização torna as tarefas mais simples e, consequentemente, facilita o desenvolvimento

A especialização não impõe a necessidade, de quem está executando uma tarefa, de pensar em que está fazendo, basta fazer

O foco na execução torna o processo determinístico, para que a especificação seja corretamente transformada em software

Valoriza o desenvolvimento test-last

Depende da técnica de teste baseada em defeitos

Desenvolve teste incremental baseado em cenários

Utiliza processo de teste dirigido a planos

A satisfação do cliente deve ser priorizada através da entrega contínua

Conversas face a face são preferíveis dentro de uma equipe de desenvolvimento

Simplicidade é essencial

Mudanças nos requisitos devem ser evitadas

RUP

Waterfall

Scrum

Kanban

Na retrospectiva da iteração

No Scrum dos Scrums

Na implantação do release

Na revisão da iteração

1 e 2

2 e 3

3 e 4

4 e 1

1 e 3

1 e 2

1 e 4

2 e 3

Ao final de cada sprint, a equipe deve realizar um sprint review meeting para verificar o que foi feito e, então, partir para uma nova sprint

A cada dia pode-se avaliar o andamento das atividades, contando as que estão por fazer e as terminadas, o que produz o diagrama dual-line burndown

O product backlog apresenta requisitos de baixo nível, voltados para as necessidades diretas dos clientes e desenvolvedores

O scrum master é a pessoa responsável pelo projeto em si, tendo que, como principal atribuição, indicar quais são os requisitos mais importantes a serem tratados em cada sprint

Focar nas práticas de engenharia

Focar na documentação formal do software

Ser um método iterativo e incremental

Exigir o planejamento do projeto, de acordo com as práticas do PMBOK

Time coeso

Refatoração

Integração contínua

Ritmo sustentável

Comunicação - simplicidade - feedback - coragem

Planejamento - metáfora - refactoring - testes

Feedback constante - abordagem incremental - encorajamento - colaboração

Colaboração - integração contínua - cliente presente - abordagem incremental

Conceitualmente, aceitando as mudanças provavelmente irá reduzir as solicitações de mudanças

Para dar aos clientes uma vantagem competitiva

Equipes auto-organizadas podem se adaptar às mudanças quase instantaneamente

Kaizen

Gerenciar o projeto

Ser a principal ligação com o cliente

Medir e relatar o progresso ao gerente sênior

Manter a equipe focada nos princípios ágeis

4 a 12

Depende do tamanho do projeto

3 a 9

Qualquer número que entregue valor máximo ao cliente

Qualquer um cujo trabalho pode ser afetado pelo produto do projeto

Qualquer um que está comprometido e não meramente envolvido

Qualquer um com interesse no resultado do projeto

Qualquer um que se engaje com o projeto de qualquer forma

Uma característica complexa

Um nó

Uma extensão da iteração

Uma característica raiz

Criando os casos de teste primeiro, assim salvando tempo do projeto

Software deve ser escrito no contexto de como ele será aceito e validado

Desenvolvedores devem ser aqueles que criam os testes que seu software deve passar

Software livre de erro é possível se os testes são construídos apropriadamente e o código é estritamente escrito para passar nesses testes

Inexistente

Apenas suficiente

Completa, mas não exaustiva

Suficiente para alguém completar o seu trabalho, se você partir inesperadamente

Todas as mudanças de código passam por ‘check-in’ e testadas a cada dia

A equipe compartilha uma única base de código

O cliente recebe todo o desenvolvimento em tempo real

Todo o código deve ser integrado assim que esteja com uma característica completa

Sprint

Ciclo

Velocidade

Lançamento

Programadores XP trabalham em pares

Encoraja os programadores a assumirem um pouco mais de pontos de estória

Pratica iterações mais curtas que em outras metodologias

Encoraja a equipe a fazer coisas ‘uma vez, e somente uma vez’

Do SM, à medida que o trabalho é completado

Do cliente, à medida que o trabalho é aceito

Do testador, à medida que o trabalho é verificado

Da equipe, à medida que o trabalho progride

A equipe escolhe os itens de mais alto valor para o cliente

A equipe tenta bloquear o escopo do produto

A equipe tipicamente não entrega nenhum valor para o cliente

A equipe tem uma retrospectiva para discutir outras iterações do lançamento

Deming

Scrum

Kaizen

Kanban

Dependentes

Compreensivas

Negociáveis

De alto valor

Os membros da equipe virem radiadores de informações

Os membros da equipe tenham tanta privacidade quanto possível

Os membros da equipe fiquem frente a frente

Os membros da equipe formem pequenos grupos

Analisar o lançamento e determinar o que poderia ser melhorado

Prover uma oportunidade para a equipe se reorganizar

Explorar formas para adicionar mais valor para o cliente

Melhorar futuras iterações

A pessoa ou par que fez o código

A equipe

O dono do produto (PO)

O SM

É um evento negativo incerto

Deve ser quantificado para ser entendido

Pode ser representado em um backlog ajustado a risco

Valor deve ser avaliado contra risco

Do SM

Do PO

Da equipe

Do escritório de gerenciamento do projeto (PMO)

Produtos de trabalho de desenvolvimento

Produtos de trabalho orientados a negócios

Produtos de trabalho de teste

Produtos de trabalho de gestão