Teste Agile - Guia Rápido

Agileé uma metodologia de desenvolvimento iterativa, em que as atividades de desenvolvimento e teste são simultâneas. O teste não é uma fase separada; A codificação e o teste são feitos de forma interativa e incremental, resultando em um produto final de qualidade, que atende aos requisitos do cliente. Além disso, a integração contínua resulta na remoção precoce de defeitos e, portanto, em economia de tempo, esforço e custos.

Manifesto Ágil

O Manifesto Ágil foi publicado por uma equipe de desenvolvedores de software em 2001, destacando a importância da equipe de desenvolvimento, acomodando as mudanças de requisitos e o envolvimento do cliente.

The Agile Manifesto is −

Estamos descobrindo melhores maneiras de desenvolver software, fazendo isso e ajudando outros a fazê-lo. Por meio deste trabalho, chegamos a valorizar -

• Indivíduos e interações sobre processos e ferramentas.
• software que trabalha sobre uma documentação completa.
• Colaboração com o cliente na negociação do contrato.
• Respondendo à mudança seguindo um plano.

Ou seja, embora haja valor nos itens à direita, valorizamos mais os itens à esquerda.

O que é o Agile Testing?

O Agile Testing é uma prática de teste de software que segue os princípios do desenvolvimento ágil de software.

O Agile Testing envolve todos os membros da equipe do projeto, com especialização especial contribuída por testadores. O teste não é uma fase separada e está entrelaçado com todas as fases de desenvolvimento, como requisitos, design e codificação e geração de casos de teste. O teste ocorre simultaneamente durante o Ciclo de Vida de Desenvolvimento.

Além disso, com testadores participando de todo o Ciclo de Vida de Desenvolvimento em conjunto com membros da equipe multifuncional, a contribuição dos testadores para construir o software de acordo com os requisitos do cliente, com melhor design e código se tornaria possível.

O Agile Testing cobre todos os níveis de teste e todos os tipos de teste.

Teste Agile vs. Teste em Cachoeira

Em uma metodologia de Desenvolvimento em Cachoeira, as atividades do Ciclo de Vida de Desenvolvimento acontecem em fases que são sequenciais. Portanto, o teste é uma fase separada e é iniciado somente após a conclusão da fase de desenvolvimento.

A seguir estão os destaques das diferenças entre o teste ágil e o teste em cascata -

Teste Ágil	Teste em Cachoeira
O teste não é uma fase separada e ocorre simultaneamente com o desenvolvimento.	O teste é uma fase separada. Todos os níveis e tipos de teste podem começar somente após a conclusão do desenvolvimento.
Testadores e desenvolvedores trabalham juntos.	Os testadores trabalham separadamente dos desenvolvedores.
Os testadores estão envolvidos na definição dos requisitos. Isso ajuda no mapeamento de requisitos para os comportamentos no cenário do mundo real e também no enquadramento dos critérios de aceitação. Além disso, os casos de teste de aceitação lógico estariam prontos junto com os requisitos.	Os testadores podem não estar envolvidos na fase de requisitos.
O teste de aceitação é feito após cada iteração e o feedback do cliente é solicitado.	O Teste de Aceitação é feito apenas no final do projeto.
Cada iteração completa seu próprio teste, permitindo que o teste de regressão seja implementado toda vez que novas funções ou lógicas são lançadas.	O teste de regressão pode ser implementado somente após a conclusão do desenvolvimento.
Sem atrasos entre a codificação e o teste.	Atrasos de tempo normais entre a codificação e o teste.
Teste contínuo com níveis de teste sobrepostos.	O teste é uma atividade cronometrada e os níveis de teste não podem se sobrepor.
O teste é uma prática recomendada.	O teste é frequentemente esquecido.

Princípios de teste ágil

Os princípios do teste Agile são -

• Testing moves the project forward- O teste contínuo é a única maneira de garantir o progresso contínuo. O Agile Testing fornece feedback continuamente e o produto final atende às demandas do negócio.

• Testing is not a phase- A equipe ágil testa junto com a equipe de desenvolvimento para garantir que os recursos implementados durante uma determinada iteração sejam realmente executados. O teste não é mantido para uma fase posterior.

• Everyone tests- No teste ágil, toda a equipe, incluindo analistas, desenvolvedores e testadores, testa o aplicativo. Após cada iteração, até mesmo o cliente realiza o Teste de Aceitação do Usuário.

• Shortening Feedback Loops- No Agile Testing, a equipe de negócios conhece o desenvolvimento do produto para cada iteração. Eles estão envolvidos em cada iteração. O feedback contínuo reduz o tempo de resposta do feedback e, portanto, o custo envolvido em consertá-lo é menor.

• Keep the Code Clean- Os defeitos são corrigidos à medida que são levantados na mesma iteração. Isso garante código limpo em qualquer marco de desenvolvimento.

• Lightweight Documentation - Em vez de documentação de teste abrangente, testadores Agile -

  • Use listas de verificação reutilizáveis ​​para sugerir testes.

  • Concentre-se na essência do teste, e não nos detalhes incidentais.

  • Use estilos / ferramentas de documentação leves.

  • Capture ideias de teste em cartas para testes exploratórios.

  • Aproveite documentos para vários fins.

• Leveraging one test artifact for manual and automated tests- O mesmo artefato de script de teste pode ser utilizado para testes manuais e como entrada para testes automatizados. Isso elimina o requisito de documentação de teste manual e, em seguida, um script de teste de automação equivalente.

• “Done Done,” not just done - No Agile, um recurso é dito para ser feito não após o desenvolvimento, mas após o desenvolvimento e teste.

• Test-Last vs. Test Driven- Os casos de teste são escritos junto com os requisitos. Portanto, o desenvolvimento pode ser conduzido por meio de testes. Essa abordagem é chamada de Desenvolvimento Orientado a Testes (TDD) e Desenvolvimento Orientado a Testes de Aceitação (ATDD). Isso contrasta com o teste como última fase do teste em cascata.

Atividades de teste ágil

As atividades de teste do Agile no nível do projeto são -

• Planejamento de liberação (plano de teste)

  • Para cada iteração,

  • Atividades de teste ágil durante uma iteração

• Teste de Regressão

• Atividades de liberação (relacionadas ao teste)

As atividades de teste do Agile durante uma iteração incluem -

• Participar do planejamento de iteração
• Estimando tarefas do ponto de vista do teste
• Escrever casos de teste usando as descrições de recursos
• Teste de Unidade
• Teste de integração
• Teste de recursos
• Correção de defeitos
• Teste de integração
• Teste de aceitação
• Relatório de status sobre o andamento do teste
• Rastreamento de Defeito

Agile é uma metodologia de desenvolvimento iterativa, onde toda a equipe do projeto participa de todas as atividades. Os requisitos evoluem com o progresso das iterações, por meio da colaboração entre o cliente e as equipes auto-organizadas. Como a codificação e o teste são feitos de forma interativa e incremental, durante o curso do desenvolvimento, o produto final seria de qualidade e garantiria os requisitos do cliente.

Cada iteração resulta em um incremento de produto de trabalho integrado e é entregue para Teste de Aceitação do Usuário. O feedback do cliente assim obtido seria uma entrada para as próximas / subsequentes Iterações.

Integração contínua, qualidade contínua

A integração contínua é a chave para o sucesso do desenvolvimento ágil. Integre com frequência, pelo menos diariamente, de forma que você esteja pronto para um lançamento como e quando necessário. Testar em Agile passa a ser um componente essencial de todas as fases do desenvolvimento, garantindo a qualidade contínua do produto. O feedback constante de todos os envolvidos no projeto aumenta a qualidade do produto.

No Agile, a comunicação é dada com extrema importância e as solicitações do cliente são recebidas como e quando necessário. Isso dá a satisfação ao cliente que todos os insumos são considerados e produto de qualidade funcional está disponível durante todo o desenvolvimento.

Metodologias ágeis

Existem várias metodologias ágeis que suportam o desenvolvimento ágil. As metodologias ágeis incluem -

Scrum

Scrum é um método de desenvolvimento ágil que enfatiza a abordagem centrada na equipe. Defende a participação de toda a equipe em todas as atividades de desenvolvimento do projeto.

XP

A eXtreme Programming é centrada no cliente e se concentra em requisitos em constante mudança. Com lançamentos frequentes e feedback do cliente, o produto final será de qualidade, atendendo aos requisitos do cliente que ficam mais claros durante o processo.

Cristal

O Crystal é baseado em fretamento, entrega cíclica e finalização.

• O fretamento envolve a formação de uma equipe de desenvolvimento, realizando uma análise preliminar de viabilidade, chegando a um plano inicial e a metodologia de desenvolvimento.

• A entrega cíclica com dois ou mais ciclos de entrega concentra-se na fase de desenvolvimento e na entrega final do produto integrado.

• Durante o encerramento, a implantação no ambiente do usuário, análises e reflexões pós-implantação são realizadas.

FDD

O Desenvolvimento Orientado a Recursos (FDD) envolve o projeto e a construção de recursos. A diferença entre o FDD e outras metodologias de desenvolvimento ágil é que os recursos são desenvolvidos em fases curtas e específicas separadamente.

DSDM

O Método de Desenvolvimento Dinâmico de Software (DSDM) é baseado no Rapid Application Development (RAD) e está alinhado com o Agile Framework. O DSDM se concentra na entrega frequente do produto, envolvendo os usuários ativamente e capacitando as equipes para tomar decisões rápidas.

Desenvolvimento Lean de Software

No Lean Software Development, o foco está em eliminar o desperdício e dar valor ao cliente. Isso resulta em rápido desenvolvimento e produto de valor.

Resíduos incluem trabalho parcialmente feito, trabalho irrelevante, recursos que não são usados ​​pelo cliente, defeitos, etc. que aumentam os atrasos na entrega.

o Lean Principles são -

• Eliminar desperdício
• Amplifique a Aprendizagem
• Compromisso de atraso
• Capacite a equipe
• Entregue rápido
• Construir integridade em
• Veja o todo

Kanban

Kanban se concentra no gerenciamento do trabalho com ênfase na entrega just-in-time (JIT), sem sobrecarregar os membros da equipe. As tarefas são exibidas para que todos os participantes vejam e para que os membros da equipe retirem o trabalho de uma fila.

Kanban é baseado em -

• Quadro Kanban (visual e persistente em todo o desenvolvimento)
• Limite de trabalho em andamento (WIP)
• Tempo de espera

Metodologias de teste ágeis

As práticas de teste são bem definidas para cada projeto, seja ágil ou não, para entregar produtos de qualidade. Os princípios de teste tradicionais são frequentemente usados ​​em testes ágeis. Um deles é o Teste Inicial que se concentra em -

• Escrever casos de teste para expressar o comportamento do sistema.

• Prevenção, detecção e remoção de defeitos precoces.

• Garantir que os tipos de teste certos sejam executados no momento certo e como parte do nível de teste certo.

Em todas as metodologias ágeis que discutimos, o teste ágil em si é uma metodologia. Em todas as abordagens, os casos de teste são escritos antes da codificação.

Neste tutorial, vamos nos concentrar no Scrum como a Metodologia de Teste Ágil.

As outras metodologias de teste ágil comumente usadas são -

• Test-Driven Development (TDD) - Test-Driven Development (TDD) é baseado na codificação guiada por testes.

• Acceptance Test-Driven Development (ATDD) - O Desenvolvimento Orientado ao Teste de Aceitação (ATDD) é baseado na comunicação entre os clientes, desenvolvedores e testadores e conduzido por Critérios de Aceitação e Casos de Teste de Aceitação pré-definidos.

• Behavior-Driven Development (BDD) - Em Behavior-Driven Development (BDD), o teste é baseado no comportamento esperado do software que está sendo desenvolvido.

Ciclo de vida de teste ágil

No Scrum, as atividades de teste incluem -

• Contribuir para histórias de usuários com base no comportamento esperado do sistema descrito como casos de teste

• Planejamento de liberação com base no esforço de teste e defeitos

• Sprint Planning com base em histórias de usuários e defeitos

• Execução Sprint com Teste Contínuo

• Teste de regressão após a conclusão do Sprint

• Relatórios de resultados de teste

• Teste de automação

O teste é iterativo e sprints com base conforme representado no diagrama abaixo -

O desenvolvimento ágil é centrado na equipe e os desenvolvedores e testadores participam de todas as atividades de projeto e desenvolvimento. O trabalho em equipe maximiza o sucesso dos testes em projetos Agile.

Uma equipe de Testador em Agile deve participar e contribuir com todas as atividades do projeto e, ao mesmo tempo, deve aproveitar a experiência em testes.

Um testador Agile deve ter habilidades de teste tradicionais. Além disso, o testador Agile precisa -

• Boas habilidades interpessoais.

• Capacidade de agir de forma positiva e voltada para a solução com os membros da equipe e partes interessadas.

• Capacidade de exibir pensamento crítico, voltado para a qualidade e cético sobre o produto.

• Aptidão para ser pró-ativo para adquirir informações ativamente dos stakeholders.

• Habilidades para trabalhar de forma eficaz com clientes e partes interessadas na definição de Estórias de Usuário testáveis, os Critérios de Aceitação.

• Talento para ser um bom membro da equipe trabalhando com desenvolvedores na produção de código de qualidade.

• Usabilidade de habilidades de teste para ter os casos de teste certos no momento certo e no nível certo e executá-los bem durante o sprint.

• Capacidade de avaliar e relatar os resultados dos testes, o progresso dos testes e a qualidade do produto.

• Abertura para responder às mudanças rapidamente, incluindo alteração, adição ou melhoria de casos de teste.

• Potencial para auto-organizar o trabalho.

• Entusiasmo para o crescimento contínuo de habilidades.

• Competência em Automação de Teste, Desenvolvimento Orientado a Testes (TDD), Desenvolvimento Orientado a Testes de Aceitação (ATDD), Desenvolvimento Orientado a Comportamento (BDD) e Testes baseados em experiência.

Papel do testador na equipe ágil

A equipe de teste no Agile participa de todas as atividades de projeto e desenvolvimento para contribuir com o melhor da experiência em teste.

As atividades do Agile Tester incluem -

• Garantir o uso adequado das ferramentas de teste.

• Configurando, usando e gerenciando os ambientes de teste e os dados de teste.

• Orientar outros membros da equipe em aspectos relevantes dos testes.

• Garantir que as tarefas de teste apropriadas sejam agendadas durante o planejamento de release e sprint.

• Compreender, implementar e atualizar a estratégia de teste.

• Colaborar com desenvolvedores, clientes e stakeholders no esclarecimento de requisitos, em termos de testabilidade, consistência e completude.

• Executando os testes certos na hora certa e nos níveis de teste certos.

• Relatar defeitos e trabalhar com a equipe para resolvê-los.

• Medir e relatar a cobertura de teste em todas as dimensões de cobertura aplicáveis.

• Participar de retrospectivas de sprint, sugerindo e implementando melhorias proativamente.

No ciclo de vida ágil, um testador desempenha um papel significativo em -

• Teamwork
• Planejamento de Teste
• Sprint Zero
• Integration
• Práticas de teste ágeis

Trabalho em equipe

No Desenvolvimento Ágil, o trabalho em equipe é fundamental e, portanto, requer o seguinte -

• Collaborative Approach- Trabalhar com membros da equipe multifuncional em Estratégia de Teste, Planejamento de Teste, Especificação de Teste, Execução de Teste, Avaliação de Teste e Relatório de Resultados de Teste. Contribuir com a experiência de teste em conjunto com outras atividades da equipe.

• Self-organizing - Planejar e organizar bem os sprints para atingir as metas de teste, agregando a experiência de outros membros da equipe também.

• Empowerment - Tomar decisões técnicas adequadas para atingir os objetivos da equipe.

• Commitment - Comprometer-se a compreender e avaliar o comportamento e as características do produto, conforme exigido pelos clientes e stakeholders.

• Transparent - Aberto, comunicativo e responsável.

• Credibility- Garantir a credibilidade da estratégia de teste, sua implementação e execução. Manter os clientes e stakeholders informados sobre a estratégia de teste.

• Open to Feedback- Participar de retrospectivas de sprint para aprender com os sucessos e fracassos. Buscar feedback do cliente e agir de forma rápida e adequada para garantir entregas de qualidade.

• Resilient - Respondendo às mudanças.

Planejamento de Teste

O planejamento de teste deve começar durante o planejamento da versão e atualizar durante cada sprint. O planejamento do teste deve abranger as seguintes tarefas -

• Definir o escopo do teste, a extensão do teste, as metas de teste e sprint.

• Decidir sobre o ambiente de teste, ferramentas de teste, dados de teste e configurações.

• Atribuição de teste de recursos e características.

• Agendamento de tarefas de teste e definição da frequência dos testes.

• Identificar métodos de teste, técnicas, ferramentas e dados de teste.

• Determinar os pré-requisitos, como tarefas anteriores, experiência e treinamento.

• Identificar dependências como funções, código, componentes do sistema, fornecedor, tecnologia, ferramentas, atividades, tarefas, equipes, tipos de teste, níveis de teste e restrições.

• Definir prioridades considerando a importância e dependências do cliente / usuário.

• Chegando no tempo, duração e esforço necessários para o teste.

• Identificar tarefas em cada planejamento de sprint.

Sprint Zero

Sprint Zero envolve atividades de preparação antes do primeiro sprint. Um testador precisa colaborar com a equipe nas seguintes atividades -

• Identificando o escopo
• Dividindo histórias de usuários em sprints
• Criação de arquitetura de sistema
• Ferramentas de planejamento, aquisição e instalação (incluindo ferramentas de teste)
• Criação da estratégia de teste inicial para todos os níveis de teste
• Definição de métricas de teste
• Especificação dos critérios de aceitação, também chamada de definição de "Concluído"
• Definindo critérios de saída
• Criando Scrum Board
• Definir a direção do teste ao longo dos sprints

Integração

No Agile, um produto funcional de qualidade deve estar pronto para lançamento a qualquer momento no ciclo de vida de desenvolvimento. Isso implica integração contínua como parte do desenvolvimento. Um testador Agile precisa oferecer suporte à integração contínua com testes contínuos.

Para fazer isso, um testador precisa -

• Compreenda a estratégia de integração.
• Identifique todas as dependências entre funções e recursos.

Práticas de teste ágeis

Um testador Agile precisa adaptar as práticas Agile para testar em um projeto ágil.

• Pairing- Dois membros da equipe trabalham juntos no mesmo teclado. Enquanto um deles testa, o outro revisa / analisa o teste. Os dois membros da equipe podem ser

  • Um testador e um desenvolvedor

  • Um testador e um analista de negócios

  • Dois testadores

• Incremental Test Design - Os casos de teste são construídos a partir de histórias de usuários, começando com testes simples e passando para testes mais complexos.

• Mind Mapping- Um mapa mental é um diagrama para organizar as informações visualmente. O mapeamento mental pode ser usado como uma ferramenta eficaz em testes Agile, usando o qual as informações sobre as sessões de teste necessárias, estratégias de teste e dados de teste podem ser organizadas.

O status do teste pode ser comunicado -

• Durante as reuniões diárias em pé
• Usando ferramentas de gerenciamento de teste padrão
• Via mensageiros

O status do teste determinado pelo status de aprovação no teste é crucial para decidir se a tarefa está “Concluída”. Concluído significa que todos os testes para a tarefa foram aprovados.

Progresso do Teste

O progresso do teste pode ser rastreado usando -

• Scrum Boards (Agile Task Boards)
• Gráficos Burndown
• Resultados de testes automatizados

O progresso do teste também tem um impacto direto no progresso do desenvolvimento. Isso ocorre porque uma história de usuário pode ser movida paraDonestatus somente após os Critérios de Aceitação serem atingidos. Isso, por sua vez, é decidido pelo Status do Teste, já que os Critérios de Aceitação são julgados por um Status do Teste.

Se houver atrasos ou bloqueios no andamento do teste, toda a equipe discute e trabalha em colaboração para resolver o mesmo.

Em projetos ágeis, as mudanças ocorrem com bastante frequência. Quando muitas mudanças ocorrem, podemos esperar que o Status do Teste, o Progresso do Teste e a Qualidade do Produto evoluam constantemente. Os testadores do Agile precisam obter essas informações para a equipe para que as decisões apropriadas possam ser tomadas no momento certo para permanecer no caminho certo para a conclusão bem-sucedida de cada iteração.

Quando as mudanças acontecem, elas podem afetar os recursos existentes de iterações anteriores. Nesses casos, os testes manuais e automatizados devem ser atualizados para lidar efetivamente com o risco de regressão. O teste de regressão também é necessário.

Qualidade do produto

As métricas de qualidade do produto incluem -

• Testes aprovados / reprovados
• Defeitos encontrados / corrigidos
• Cobertura de teste
• Taxas de aprovação / reprovação no teste
• Taxas de descoberta de defeitos
• Densidade de Defeito

Automatizar a coleta e relatórios de métricas de qualidade do produto ajuda em -

• Manter a transparência.
• Reunir todas as métricas relevantes e necessárias no momento certo.
• Relatórios imediatos sem atrasos na comunicação.
• Permitindo que os testadores se concentrem nos testes.
• Filtragem de uso indevido de métricas.

Para garantir a qualidade geral do produto, a equipe Agile precisa obter feedback do cliente sobre se o produto atende às expectativas do cliente. Isso precisa ser realizado no final de cada iteração, e o feedback será uma entrada para as iterações subsequentes.

Fatores-chave de sucesso

Em projetos Agile, produtos de qualidade podem ser entregues se o teste Agile for bem-sucedido.

Os pontos a seguir devem ser considerados para o sucesso dos testes Agile -

• O teste ágil é baseado em primeiro teste e abordagens de teste contínuo. Portanto, as ferramentas de teste tradicionais, que são construídas com base na abordagem de teste final, podem não ser adequadas. Portanto, ao escolher as ferramentas de teste em projetos Agile, o alinhamento com os testes Agile precisa ser verificado.

• Reduza o tempo total de teste automatizando os testes no início do ciclo de desenvolvimento.

• Os testadores ágeis precisam manter seu ritmo para se alinhar ao cronograma de lançamento de desenvolvimento. Conseqüentemente, o planejamento adequado, o rastreamento e o replanejamento das atividades de teste precisam ser feitos em tempo real, tendo a qualidade do produto como meta.

• O teste manual é responsável por 80% dos testes nos projetos. Portanto, testadores com experiência precisam fazer parte da equipe Agile.

• A participação desses testadores com experiência em todo o ciclo de vida de desenvolvimento faz com que toda a equipe se concentre em produtos de qualidade atendendo às expectativas do cliente.

  • Definindo histórias de usuários enfatizando o comportamento do produto esperado pelos usuários finais.

  • Identificação dos critérios de aceitação no nível da história do usuário / nível da tarefa de acordo com as expectativas do cliente.

  • Estimativa de esforço e duração para atividades de teste.

  • Planejando atividades de teste.

  • Alinhamento com a equipe de desenvolvimento para garantir a produção de código que atenda aos requisitos com um design de teste inicial.

  • Teste primeiro e teste contínuo para garantir que o status concluído seja alcançado, atendendo aos critérios de aceitação no tempo esperado.

  • Garantindo testes em todos os níveis dentro do sprint.

  • Teste de regressão no final de cada sprint.

  • Coletar e analisar métricas do produto que são úteis para o sucesso do projeto.

  • Analisar defeitos para identificar quais precisam ser corrigidos no Sprint atual e quais podem ser adiados para Sprints subsequentes.

  • Focar no que é importante do ponto de vista do cliente.

Lisa Crispin definiu sete fatores-chave para o sucesso do teste Agile -

• Whole Team approach- Nesse tipo de abordagem, os desenvolvedores treinam os testadores e os testadores treinam outros membros da equipe. Isso ajuda a todos a entender cada tarefa no projeto, portanto, a colaboração e a contribuição terão o máximo benefício. A colaboração dos testadores com os clientes também é um fator importante para definir suas expectativas logo no início e traduzir os critérios de aceitação para os necessários para passar no teste.

• Agile Testing Mindset - Os testadores são pró-ativos em melhorar continuamente a qualidade e colaborar constantemente com o resto da equipe.

• Automate Regression Testing- Design para testabilidade e desenvolvimento de condução com testes. Comece de forma simples e permita que a equipe escolha as ferramentas. Esteja pronto para fornecer conselhos.

• Provide and Obtain Feedback- Como esse é um valor fundamental do Agile, toda a equipe deve estar aberta para feedback. Como os testadores são provedores de feedback especializados, precisam se concentrar nas informações relevantes e necessárias. Em troca, ao obter feedback, deve-se acomodar as mudanças e testes dos casos de teste.

• Build a Foundation of Core Agile Practices - Foco em testes ao lado de codificação, integração contínua, ambientes de teste colaborativos, trabalhando de forma incremental, aceitação de mudanças, mantendo a sinergia.

• Collaborate with Customers - Obter exemplos, entendendo e verificando o mapeamento de requisitos para o comportamento do produto, configurando Critérios de Aceitação, obtendo feedback.

• Look at the Big Picture - Impulsione o desenvolvimento com testes e exemplos voltados para os negócios, usando dados de teste do mundo real e pensando sobre os impactos em outras áreas.

Neste capítulo, veremos alguns atributos significativos do Teste Ágil.

Benefícios do teste ágil

Os benefícios do teste Agile são -

• A satisfação do cliente através de um produto totalmente testado de forma rápida e contínua e buscando o feedback do cliente

• Clientes, desenvolvedores e testadores interagem continuamente uns com os outros, reduzindo assim o tempo de ciclo.

• Os testadores ágeis participam da definição de requisitos, contribuindo com sua experiência em testes para focar no que é viável.

• Os testadores ágeis participam da estimativa, avaliando o esforço e o tempo de teste.

• Projeto de teste inicial refletindo os critérios de aceitação.

• Requisitos de teste consolidados por toda a equipe, evitando inconvenientes.

• Foco constante na qualidade do produto por toda a equipe.

• Definição de Done O status que reflete a aprovação nos testes garante que o requisito seja atendido.

• Feedback contínuo sobre atrasos ou bloqueios para que a resolução possa ser feita imediatamente com esforço de toda a equipe.

• Respostas rápidas às mudanças de requisitos e acomodação em breve.

• Teste de regressão conduzido por integração contínua.

• Sem atrasos entre o desenvolvimento e o teste. teste primeiro, as abordagens de teste contínuo são seguidas.

• Teste de automação implementado no início do ciclo de vida de desenvolvimento, reduzindo assim o tempo total de teste e esforço.

Melhores práticas em testes ágeis

Siga as melhores práticas fornecidas abaixo -

• Inclusão de testadores com experiência em todos os tipos de testes em todos os níveis.

• Testadores participando da definição dos requisitos, colaborando com os clientes no comportamento esperado do produto.

• Testadores compartilhando feedback continuamente com os desenvolvedores e clientes.

• Teste primeiro as abordagens de teste contínuo para se alinhar ao trabalho de desenvolvimento.

• Acompanhar o status do teste e o progresso do teste pronta e constantemente com foco na entrega de produtos de qualidade.

• Teste de automação no início do ciclo de vida de desenvolvimento para reduzir o tempo do ciclo.

• Para realizar o teste de regressão, aproveite o teste de automação como uma forma eficaz.

Desafios em testes ágeis

Os seguintes desafios existem no teste Agile -

• A falta de compreensão da abordagem Agile e suas limitações por parte do Negócio e da Administração pode levar a expectativas inatingíveis.

• O Agile segue a abordagem de toda a equipe, mas nem todos conhecem os fundamentos das Práticas de Teste. Os testadores são aconselhados a treinar os outros, mas no cenário real pode ser impraticável com Sprints (Iterações) time-boxed.

• O Test First Approach requer que os Desenvolvedores baseiem a codificação no Feedback do Testador, mas em cenários reais, os Desenvolvedores estão mais acostumados a basear a codificação nos Requisitos provenientes do Cliente ou da Empresa.

• A responsabilidade pelo produto de qualidade é de toda a equipe ágil, mas nos estágios iniciais, os desenvolvedores podem não se concentrar na qualidade, pois estão mais no modo de implementação.

• A integração contínua exige um teste de regressão que requer um esforço considerável, mesmo que tenha de ser automatizado.

• Os testadores podem ser adaptáveis ​​a mudanças com a mentalidade Agile, mas acomodar as Mudanças de Teste e Testes resultantes pode ser impraticável de definir para terminar durante a Sprint.

• A automação antecipada é recomendada para que o esforço e o tempo do teste manual possam ser reduzidos. Mas, no cenário real, chegar aos Testes que podem ser automatizados e automatizá-los exige Tempo e Esforço.

Diretrizes de teste ágil

Use as seguintes diretrizes ao realizar o teste ágil.

• Participe do planejamento de liberação para identificar as atividades de teste necessárias e apresentar a versão inicial do plano de teste.

• Participe da sessão de estimativa para chegar ao esforço e à duração do teste, de modo que as atividades de teste sejam acomodadas nas iterações.

• Participe da definição da história do usuário para chegar aos casos de teste de aceitação.

• Participe de todas as reuniões de planejamento do Sprint para entender o escopo e atualizar o plano de teste.

• Colaborar continuamente com a equipe de desenvolvimento durante a Sprint para fazer do Teste e da Codificação um sucesso dentro da Sprint.

• Participe de reuniões diárias de stand-up e transmita atrasos de teste ou bloqueios, se houver, para receber resolução imediata.

• Rastreie e relate o status do teste, o progresso do teste e a qualidade do produto regularmente.

• Esteja pronto para acomodar mudanças, respondendo com modificações em casos de teste, dados de teste.

• Participe das Retrospectivas Sprint para entender e contribuir com as Melhores Práticas e Lições Aprendidas.

• Colabore na obtenção de feedback do cliente em cada Sprint.

Como no caso do Teste Tradicional, o Teste Ágil também precisa cobrir todos os Níveis de Teste.

• Teste de Unidade
• Teste de integração
• Teste de Sistema
• Testes de aceitação do usuário

Teste de Unidade

• Feito junto com a codificação, pelo desenvolvedor
• Apoiado pelo testador que escreve casos de teste garantindo 100% de cobertura de design
• Casos de teste de unidade e resultados de teste de unidade precisam ser revistos
• Os principais defeitos não resolvidos (de acordo com a prioridade e gravidade) não são deixados
• Todos os testes de unidade são automatizados

Teste de integração

• Feito junto com a Integração Contínua conforme o progresso dos Sprints
• Feito no final, depois que todos os Sprints forem concluídos
• Todos os requisitos funcionais são testados
• Todas as interfaces entre as unidades são testadas
• Todos os defeitos são relatados
• Os testes são automatizados sempre que possível

Teste de Sistema

• Feito conforme o desenvolvimento avança
• Histórias de usuários, recursos e funções são testados
• Teste feito em ambiente de produção
• Os testes de qualidade são executados (desempenho, confiabilidade, etc.)
• Defeitos são relatados
• Os testes são automatizados sempre que possível

Testes de aceitação do usuário

• Feito no final de cada Sprint e no final do projeto

• Feito pelo cliente. O feedback é recebido pela equipe

• O feedback será uma entrada para Sprints subsequentes

• As histórias de usuário em uma Sprint são pré-verificadas para serem testadas e estão com critérios de aceitação definidos

Tipos de teste

• Testes de componentes (testes de unidade)
• Testes funcionais (testes de histórias de usuários)
• Testes não funcionais (desempenho, carga, estresse, etc.)
• Testes de aptidão

Os testes podem ser totalmente manuais, totalmente automatizados, combinação de manual e automatizado ou manual com suporte de ferramentas.

Programação de suporte e testes de crítica de produto

Os testes podem ser para -

• Supporting Development (Support Programming) - Testes de programação de suporte são usados ​​pelos programadores.

  • Para decidir sobre qual código eles precisam escrever para realizar um determinado comportamento de um sistema

  • Quais testes precisam ser executados após a codificação para garantir que o novo código não atrapalhe o restante dos comportamentos do sistema

• Verification only (Critique Product) - Os testes de crítica do produto são usados ​​para descobrir inadequações no produto acabado

Testes de enfrentamento de negócios e tecnologia

Para decidir quais testes devem ser realizados quando, você precisa determinar se um teste é -

• Negócios, ou
• Enfrentando Tecnologia

Testes de enfrentamento de negócios

Um teste é um teste voltado para os negócios se responder às perguntas emolduradas com palavras do domínio dos negócios. Estes são compreendidos pelos especialistas de negócios e interessam a eles para que o comportamento do sistema possa ser explicado no cenário em tempo real.

Testes de enfrentamento de tecnologia

Um teste é um teste voltado para a tecnologia se responder às perguntas emolduradas com palavras do domínio da tecnologia. Os programadores entendem o que precisa ser implementado com base nos esclarecimentos sobre tecnologia.

Esses dois aspectos dos tipos de teste podem ser visualizados usando os Quadrantes de Teste Agile definidos por Brian Marick.

Quadrantes de teste ágil

Combinando os dois aspectos dos Tipos de Teste, os seguintes Quadrantes de Teste Ágil são derivados por Brian Marick -

Os Quadrantes de Testes Ágeis fornecem uma taxonomia útil para ajudar as equipes a identificar, planejar e executar os testes necessários.

• Quadrant Q1- Nível da unidade, Tecnologia e suporte aos desenvolvedores. Os testes de unidade pertencem a este quadrante. Esses testes podem ser testes automatizados.

• Quadrant Q2- Nível de sistema, contato comercial e comportamento de produto em conformidade. Os testes funcionais pertencem a este quadrante. Esses testes são manuais ou automatizados.

• Quadrant Q3- Nível de aceitação do sistema ou do usuário, atendimento ao negócio e foco em cenários em tempo real. Os testes de aceitação do usuário pertencem a este quadrante. Esses testes são manuais.

• Quadrant Q4- Nível de Aceitação do Sistema ou Operacional, Enfrentamento da Tecnologia e Foco em Testes de Desempenho, Carga, Estresse, Manutenibilidade, Escalabilidade. Ferramentas especiais podem ser usadas para esses testes junto com os testes de automação.

Combinando estes, os Quadrantes de Teste Ágil que refletem What-Testing-When pode ser visualizado da seguinte forma -

Defensores do Scrum Whole Team Approach, no sentido de que cada membro da equipe deve participar de todas as atividades do projeto. A equipe Scrum é auto-organizada com responsabilidade pelos resultados do projeto. A tomada de decisões é deixada para a equipe, resultando em ações apropriadas tomadas no momento certo, sem atrasos. Essa abordagem também incentiva o uso adequado do talento da equipe, em vez de se restringir a uma atividade. Os testadores também participam de todas as atividades de projeto e desenvolvimento, contribuindo com sua experiência em testes.

Toda a equipe trabalha junto na Estratégia de Teste, Planejamento de Teste, Especificação de Teste, Execução de Teste, Avaliação de Teste e Relatório de Resultados de Teste.

Criação colaborativa de histórias de usuários

Os testadores participam da criação da história do usuário. Os testadores contribuem com suas idéias sobre o possível comportamento do sistema. Isso ajuda o cliente e / ou usuário final a entender o sistema no ambiente real e, assim, obter clareza sobre o que realmente desejam como resultado. Isso resulta em um congelamento mais rápido dos requisitos e também reduz a probabilidade de mudanças nos requisitos posteriormente.

Os testadores também apresentam os Critérios de Aceitação para cada cenário acordado pelo cliente.

Os testadores contribuem para a criação de histórias de usuário testáveis.

Planejamento de Liberação

O planejamento da liberação é feito para todo o projeto. No entanto, o framework Scrum envolve a tomada de decisão iterativa, pois mais informações são obtidas no devido curso da execução dos sprints. Portanto, a sessão de Planejamento de Release no início do projeto não precisa produzir um plano de release detalhado para todo o projeto. Ele pode ser atualizado continuamente, conforme informações relevantes estiverem disponíveis.

Todo final de sprint não precisa ter um release. Um lançamento pode ser após um grupo de sprints. O principal critério de uma liberação é entregar valor comercial ao cliente. A equipe decide sobre a duração do sprint com o planejamento da liberação como entrada.

O planejamento de lançamento é a base da abordagem e plano de teste para lançamento. Os testadores estimam o esforço do teste e planejam o teste para a versão. Quando os planos de lançamento mudam, os testadores devem lidar com as mudanças, obter uma base de teste adequada considerando um contexto maior de lançamento. Os testadores também fornecem esforço de teste que é necessário no final de todos os sprints.

Sprint Planning

O planejamento do Sprint é feito no início de cada Sprint. A lista de pendências da sprint é criada com as histórias de usuário obtidas da lista de pendências do produto para implementação naquela sprint em particular.

Os testadores devem -

• Determine a testabilidade das histórias de usuário selecionadas para o sprint
• Crie testes de aceitação
• Defina os níveis de teste
• Identify test automation

Testers update the test plan with the estimates for testing effort and durations in the sprint. This ensures provision of time for required testing during the time-boxed sprints and also accountability of the testing effort.

Test Analysis

When a sprint begins, as the developers carry on story analysis for design and implementation, testers perform test analysis for the stories in the sprint backlog. Tester create the required test cases – both manual and automated tests.

Testing

All the members of the Scrum team should participate in testing.

• The developers execute the unit tests as they develop code for the user stories. Unit Tests are created in every sprint, before the code is written. The unit test cases are derived from low level design specifications.

• The testers perform functional and non-functional features of the user stories.

• The testers mentor the other members in the scrum team with their expertise in testing so that the entire team will have a collective accountability for the quality of the product.

• At the end of the sprint, customer and/or end users carry out User Acceptance Testing and provide feedback to the scrum team. This forms as an input to the next sprint.

• Test results are collected and maintained.

Automation Testing

Automation testing is given high importance in Scrum teams. The testers devote time in creating, executing, monitoring and maintaining of automated tests and results. As changes can occur any time in scrum projects, testers need to accommodate testing of changed features and also the regression testing involved. Automation testing facilitates managing of test effort associated with the changes. Automated tests at all levels facilitate achieving continuous integration. Automated tests run much faster than manual tests at no additional effort.

The manual testing focuses more on exploratory testing, product vulnerability, predicting defects.

Automation of Testing Activities

Automation of testing activities reduces the burden of repeated work and result in cost savings. Automate

• Test Data Generation
• Test Data Loading
• Build Deployment into Test Environment
• Test Environment Management
• Data Output Comparison

Regression Testing

In a sprint, testers test the code that is new / modified in that sprint. However, testers also need to ensure that the code developed and tested in the earlier sprints also is working along with the new code. Hence Regression testing is given importance in scrum. Automated regression tests are run in continuous integration.

Configuration Management

A Configuration management system that uses automated build and test frameworks is used in Scrum projects. This allows to run static analysis and unit tests repeatedly as new code is checked into the Configuration Management System. It also manages continuous integration of the new code with the system. Automated Regression Tests are run during Continuous Integration.

Manual Test Cases, Automated Tests, Test Data, Test Plans, Test Strategy and other Testing Artifacts need to be Version Controlled and require relevant Access Permissions to be ensured. This can be accomplished by maintaining the Testing Artifacts in the Configuration Management System.

Agile Testing Practices

Testers in a Scrum Team can follow the following Agile Practices −

• Pairing − Two Team Members sit together and work collaboratively. The two people can be two Testers or one Tester and one Developer.

• Incremental Test Design − Test Cases are developed as the Sprints progress incrementally and User Stories are added up.

Agile Metrics

During software development, collection and analysis of metrics help in improving the process and thereby achieving better productivity, quality deliverables and customer satisfaction. In Scrum based development, this is possible and the testers have to pay attention to the metrics that they need to.

Several metrics are suggested for Scrum development. The significant metrics are −

• Ratio of Successful Sprints − (Number of successful Sprints / Total number of Sprints) * 100. A Successful Sprint is one in which the Team could meet its commitment.

• Velocity − A team’s Velocity is based on the amount of Story Points a team earned during a sprint. Story Points are the measure of the User Stories counted during estimation.

• Focus Factor − (Velocity / Team’s Work Capacity) / 100. Focus Factor is the percentage of the team’s effort that results in finished stories.

• Estimation Accuracy − (Estimated effort / Actual effort) / 100. Estimation Accuracy is the Team’s ability in estimating the effort accurately.

• Sprint Burndown − Work (in Story Points or in hours) that is Remaining Vs. Work that needs to be Remaining ideally (as per the Estimation).

  • If it is more, then it means that the Team has taken up more Work than they can do.

  • If it is less, then it means the Team did not Estimate accurately.

• Defect Count − Number of defects in a Sprint. Defect count is the amount of defects in the software as against the backlog.

• Severity of Defects − Defects can be categorized as minor, major and critical as per their severity. Testers can define the categorization.

Sprint Retrospectives

In Sprint Retrospectives, all the team members will participate. They share −

• The things that went well
• Metrics
• The scope for improvements
• Action items to apply

In Agile Testing, the commonly used Testing methods are from the traditional practices and are aligned to the principle – Test Early. The Test Cases are written before the code is written. The emphasis is on defect prevention, detection, and removal running the right test types at the right time and at right level.

Neste capítulo, você obterá uma compreensão dos métodos -

• Desenvolvimento Orientado a Testes (TDD)
• Desenvolvimento orientado para teste de aceitação (ATDD)
• Desenvolvimento orientado para o comportamento (BDD)

Desenvolvimento Orientado a Testes

No método Test Driven Development (TDD), o código é desenvolvido com base na abordagem Testfirst dirigida por casos de teste automatizados. Um caso de teste é escrito primeiro a falhar, o código é desenvolvido com base nisso para garantir que o teste seja aprovado. O método é repetido, a refatoração é feita por meio do desenvolvimento do código.

O TDD pode ser entendido com a ajuda das seguintes etapas -

• Step 1 - Escreva um caso de teste para refletir o comportamento esperado da funcionalidade do código que precisa ser escrito.

• Step 2- Faça o teste. O teste falha porque o código ainda não foi desenvolvido.

• Step 3 - Desenvolver código com base no caso de teste.

• Step 4- Execute o teste novamente. Desta vez, o teste deve passar enquanto a funcionalidade é codificada. Repita a Etapa (3) e a Etapa (4) até que o teste seja aprovado.

• Step 5 - Refatore o código.

• Step 6 - Execute o teste novamente para garantir que ele seja aprovado.

Repetir Step 1 – Step 6adicionar casos de teste para adicionar funcionalidade. Os testes adicionados e os testes anteriores são executados sempre para garantir que o código esteja sendo executado conforme o esperado. Para tornar esse processo rápido, os testes são automatizados.

Os testes podem ser em nível de unidade, integração ou sistema. A comunicação constante entre testadores e desenvolvedores precisa ser garantida.

Desenvolvimento orientado para teste de aceitação

No método ATDD (Acceptance Test Driven Development), o código é desenvolvido com base na abordagem de teste inicial dirigida por Casos de Teste de Aceitação. O foco está nos critérios de aceitação e nos Casos de Teste de Aceitação escritos pelos testadores durante a Criação da História do Usuário em colaboração com o cliente, usuários finais e partes interessadas relevantes.

• Step 1 - Escreva casos de teste de aceitação junto com histórias de usuário em colaboração com o cliente e usuários.

• Step 2 - Defina os critérios de aceitação associados.

• Step 3 - Desenvolver código com base nos testes de aceitação e critérios de aceitação.

• Step 4 - Execute os testes de aceitação para garantir que o código está sendo executado conforme o esperado.

• Step 5- Automatize os testes de aceitação. RepetirStep 3 – Step 5 até que todas as histórias de usuário na iteração sejam implementadas.

• Step 6 - Automatize os testes de regressão.

• Step 7 - Execute os testes de regressão automatizados para garantir a regressão contínua.

Desenvolvimento orientado para o comportamento (BDD)

O Behavior Driven Development (BDD) é semelhante ao Test Driven Development (TDD), e o foco está em testar o código para garantir o comportamento esperado do sistema.

No BDD, uma linguagem como o inglês é usada para que faça sentido para os usuários, testadores e desenvolvedores. Isso garante -

• Comunicação contínua entre os usuários, testadores e desenvolvedores.
• Transparência no que está sendo desenvolvido e testado.

Técnicas de teste de teste tradicional também podem ser usadas em testes Agile. Além disso, técnicas e terminologias de teste específicas do Agile são usadas nos projetos do Agile.

Base de Teste

Em projetos ágeis, o backlog do produto substitui os documentos de especificação de requisitos. O conteúdo do backlog do produto normalmente são histórias de usuários. Os requisitos não funcionais também são atendidos nas histórias de usuários. Portanto, a base de teste em projetos Agile é a história do usuário.

Para garantir o teste de qualidade, o seguinte também pode ser considerado adicionalmente como base de teste -

• Experiência de iterações anteriores do mesmo projeto ou projetos anteriores.
• Funções existentes, arquitetura, design, código e características de qualidade do sistema.
• Dados de defeito dos projetos atuais e anteriores.
• Feedback do cliente.
• Documentação do usuário.

Definição de Feito

A Definição de Concluído (DoD) é o critério usado em projetos Agile para garantir a conclusão de uma atividade no backlog do Sprint. O DoD pode variar de uma equipe Scrum para outra, mas deve ser consistente dentro de uma equipe.

DoD é uma lista de verificação de atividades necessárias que garantem a implementação de funções e recursos em uma história de usuário, juntamente com os requisitos não funcionais que fazem parte da história de usuário. Uma história de usuário atinge o estágio Concluído depois que todos os itens da lista de verificação do DoD são cumpridos. Um DoD é compartilhado pela equipe.

Um DoD típico para uma história de usuário pode conter -

• Critérios Detalhados de Aceitação Testável
• Critérios para garantir a consistência da História do Usuário com as outras na Iteração
• Critérios específicos relacionados ao produto
• Aspectos de comportamento funcional
• Características não funcionais
• Interfaces
• Requisitos de dados de teste
• Cobertura de teste
• Refactoring
• Requisitos de revisão e aprovação

Além do DoD para histórias de usuários, o DoD também é necessário -

• em todos os níveis de teste
• para cada característica
• para cada iteração
• para lançamento

Informação de Teste

Um testador precisa ter as seguintes informações de teste -

• Histórias de usuários que precisam ser testadas
• Critérios de aceitação associados
• Interfaces do sistema
• Ambiente onde se espera que o sistema funcione
• Disponibilidade de ferramentas
• Cobertura de teste
• DoD

Em projetos Agile, como o teste não é uma atividade sequencial e os testadores devem trabalhar em um modo colaborativo, é responsabilidade do testador -

• Obtenha continuamente as informações de teste necessárias.
• Identifique as lacunas de informação que afetam o teste.
• Resolva as lacunas de forma colaborativa com outros membros da equipe.
• Decida quando um nível de teste é alcançado.
• Garantir que os testes apropriados sejam executados em momentos relevantes.

Projeto de teste funcional e não funcional

Em projetos Agile, as técnicas de teste tradicionais podem ser usadas, mas o foco está no teste inicial. Os casos de teste precisam estar implementados antes do início da implementação.

Para design de teste funcional, os testadores e desenvolvedores podem usar as técnicas tradicionais de design de teste Black Box, como -

• Particionamento equivalente
• Análise de valor limite
• Tabelas de Decisão
• Estado de transição
• Árvore de Classe

Para o design de teste não funcional, como os requisitos não funcionais também fazem parte de cada história de usuário, as técnicas de design de teste de caixa preta só podem ser usadas para projetar os casos de teste relevantes.

Teste Exploratório

Em projetos ágeis, o tempo costuma ser o fator de limitação para a análise e o design do teste. Nesses casos, as técnicas de teste exploratório podem ser combinadas com as técnicas de teste tradicionais.

O Teste Exploratório (TE) é definido como aprendizagem simultânea, design de teste e execução de teste. No Teste Exploratório, o testador controla ativamente o design dos testes à medida que são realizados e usa as informações obtidas durante o teste para criar novos e melhores testes.

O teste exploratório é útil para acomodar mudanças em projetos Agile.

Teste baseado em risco

O teste baseado em risco é um teste baseado no risco de falha e mitiga os riscos usando técnicas de design de teste.

Um risco de qualidade do produto pode ser definido como um problema potencial com a qualidade do produto. Os riscos de qualidade do produto incluem -

• Riscos funcionais
• Riscos de desempenho não funcionais
• Riscos de usabilidade não funcional

A análise de risco deve ser feita para avaliar a probabilidade (probabilidade) e o impacto de cada risco. Então, os riscos são priorizados -

• Altos riscos requerem testes extensivos
• Riscos baixos requerem apenas testes cursivos

Os testes são elaborados usando técnicas de teste apropriadas com base no nível de risco e na característica de risco de cada risco. Os testes são executados para mitigar os riscos.

Testes de ajuste

Os testes de ajuste são testes de aceitação automatizados. As ferramentas Fit e FitNesse podem ser usadas para automatizar testes de aceitação.

FIT usa JUnit, mas estende a funcionalidade de teste. As tabelas HTML são usadas para exibir os casos de teste. Fixture é uma classe Java por trás da tabela HTML. O fixture pega o conteúdo da tabela HTML e executa os casos de teste no projeto que está sendo testado.

O Plano de Teste é preparado no momento do Release Planning e revisado a cada Sprint Planning. O Plano de Teste atua como um guia para o processo de teste para ter a cobertura completa do teste.

Os conteúdos típicos de um plano de teste são -

• Estratégia de Teste
• Ambiente de teste
• Cobertura de teste
• Escopo do teste
• Esforço de teste e cronograma
• Ferramentas de teste

Em projetos ágeis, todos os membros da equipe são responsáveis ​​pela qualidade do produto. Portanto, todos participam do planejamento do teste também.

A responsabilidade dos testadores é fornecer a direção necessária e orientar o restante da equipe com sua experiência em testes.

Histórias de usuários

As histórias de usuários não são produtos de trabalho de teste em princípio. Porém, em Projetos Ágeis, os testadores participam da Criação de Estórias de Usuário. Os testadores escrevem histórias de usuários que agregam valor ao cliente e abrangem diferentes comportamentos possíveis do sistema.

Os testadores também garantem que todas as Estórias de Usuário são testáveis ​​e garantem os Critérios de Aceitação.

Testes Manuais e Automatizados

Durante a primeira execução do teste, testes manuais são usados. Eles incluem -

• Testes Unitários
• Testes de Integração
• Testes Funcionais
• Testes Não Funcionais
• Testes de aptidão

Os testes são então automatizados para execuções subsequentes.

Dentro Test Driven Development, Os testes de unidade são escritos primeiro a falhar, o código é desenvolvido e testado para garantir a aprovação dos testes.

Dentro Acceptance Test Driven Development, Os testes de aceitação são escritos primeiro a falhar, o código é desenvolvido e testado para garantir a aprovação dos testes.

Em outros métodos de desenvolvimento, os testadores colaboram com o resto da equipe para garantir a cobertura do teste.

Em todos os tipos de métodos, a integração contínua ocorre, o que inclui testes de integração contínua.

A equipe pode decidir quando e quais testes serão automatizados. Mesmo que a automação dos testes exija esforço e tempo, os testes automatizados resultantes reduzem significativamente o esforço e o tempo de teste repetitivo durante as iterações do Projeto Ágil. Isso, por sua vez, facilita que a equipe preste mais atenção às outras atividades necessárias, como novas histórias de usuários, mudanças, etc.

Dentro Scrum, as iterações são limitadas no tempo. Portanto, se um teste de história de usuário não pode ser concluído em um determinado Sprint, o testador pode relatar na reunião diária que a história de usuário não pode atingir o status Done dentro daquele Sprint e, portanto, precisa ser mantida pendente para o próximo Sprint.

Resultado dos testes

Como a maioria dos Testes em Projetos Ágeis é automatizada, as Ferramentas geram os Logs de Resultados de Teste necessários. Os testadores revisam os registros de resultados do teste. Os resultados do teste precisam ser mantidos para cada sprint / release.

Um resumo de teste também pode ser preparado contendo -

• Escopo de teste (o que foi testado e o que não foi testado)
• Análise de defeito junto com a análise de causa raiz, se possível
• Status de teste de regressão após correção de defeitos
• Problemas e a resolução correspondente
• Problemas pendentes, se houver
• Quaisquer modificações necessárias na Estratégia de Teste
• Test Metrics

Relatórios de métricas de teste

Em projetos ágeis, as métricas de teste incluem o seguinte para cada Sprint -

• Esforço de Teste
• Precisão de estimativa de teste
• Cobertura de teste
• Cobertura de teste automatizado
• Nº de defeitos
• Taxa de defeitos (número de defeitos por ponto da história do usuário)
• Gravidade do defeito
• Hora de corrigir um defeito no mesmo Sprint (custa 24x mais para consertar um bug que escapa do sprint atual)
• Nº de defeitos corrigidos no mesmo Sprint
• Conclusão do Teste de Aceitação pelo Cliente na Sprint

Revisão de Sprint e Relatórios Retrospectivos

Os testadores também contribuem com os relatórios de revisão e retrospectiva da sprint. Os conteúdos típicos são -

• Test Metrics
• Resultados da revisão dos registros de resultados de teste
• O que deu certo e o que pode ser melhorado do ponto de vista do teste
• Melhores Práticas
• Lições aprendidas
• Issues
• Feedback do cliente

As atividades de teste ágil podem ser gerenciadas de forma eficaz usando os conceitos de Kanban. Os itens a seguir garantem que o teste seja concluído a tempo em uma iteração / sprint e, portanto, enfoque na entrega de produto de qualidade.

• As histórias de usuário testáveis ​​e dimensionadas de maneira eficaz resultam em desenvolvimento e teste dentro dos limites de tempo especificados.

• O limite WIP (Work-In-Progress) permite focar em um número limitado de histórias de usuário por vez.

• Quadro Kanban que representa o fluxo de trabalho visualmente, ajuda a rastrear as atividades de teste e gargalos, se houver.

• O conceito de colaboração da equipe Kanban permite a resolução de gargalos à medida que são identificados, sem tempo de espera.

• A preparação de Casos de Teste antecipadamente, mantendo o conjunto de testes conforme o desenvolvimento avança e obtendo Feedback do Cliente ajuda a eliminar Defeitos dentro da iteração / sprint.

• A Definição de Concluído (DoD) é considerada Concluída no sentido de que uma História atinge um estado de conclusão somente depois que o teste também é concluído.

Atividades de teste em desenvolvimento de produto

No desenvolvimento de produtos, as liberações podem ser rastreadas com recurso de quadro Kanban. Recursos para uma determinada liberação são atribuídos ao quadro Kanban de Recursos que rastreia o status de desenvolvimento de recursos visualmente.

Os recursos em uma versão são divididos em histórias e desenvolvidos dentro da versão usando uma abordagem ágil.

As seguintes atividades de teste Agile garantem entrega de qualidade em cada versão e no final de todas as versões também -

• Os testadores participam da criação da história do usuário e, assim, garantem -

  • Todos os comportamentos possíveis do Sistema são capturados por meio das Estórias de Usuário e dos Requisitos Não Funcionais que fazem parte das Estórias de Usuário.

  • As histórias do usuário são testáveis.

  • O tamanho das Estórias de Usuário permite que o Desenvolvimento e o Teste sejam concluídos (Concluído) dentro da Iteração.

• Quadro Kanban de Tarefa Visual -

  • Descreve o status e o andamento das Tarefas

  • Gargalos são identificados imediatamente à medida que ocorrem

  • Facilita a medição do tempo de ciclo que pode então ser otimizado

• A Colaboração em Equipe ajuda em -

  • Responsabilidade de toda a equipe pelo produto de qualidade

  • Resolução de gargalos à medida que ocorrem, economizando tempo de espera

  • Contribuição de cada expertise em todas as atividades

• Integração Contínua que se concentra no Teste de Integração Contínua

• Automação de testes para economizar tempo e esforço de teste

• Prevenção de Defeitos com Casos de Teste escritos anteriormente para Desenvolvimento e orientação dos Desenvolvedores sobre o que é antecipado por diferentes comportamentos do Sistema -

  • Limite de WIP para se concentrar em um número limitado de histórias de usuários por vez

• Testes Contínuos conforme o desenvolvimento avança, para garantir Correções de Defeitos na Iteração -

  • Garantir a cobertura de teste

  • Mantenha a contagem de defeitos abertos baixa

Exploração de história

Exploração de história é a comunicação dentro de uma equipe ágil para explorar a compreensão da história quando o product owner passa uma história para aceitação para desenvolvimento.

O proprietário do produto cria a história com base na funcionalidade esperada pelo sistema. Os desenvolvedores exploram mais cada história antes de marcá-la como pronta para aceitação. Os testadores também participam da comunicação da perspectiva do teste para torná-la o mais testável possível.

A finalização da história é baseada na comunicação constante e contínua entre o Product Owner, os Desenvolvedores e os Testadores.

Estimativa

A estimativa acontece no Planejamento de Release e em cada Planejamento de Iteração.

No planejamento de lançamento, os testadores fornecem -

• Informações sobre quais atividades de teste são necessárias
• Estimativa de esforço para o mesmo

No planejamento da iteração, os testadores contribuem para decidir quais e quantas histórias podem ser incluídas em uma iteração. A decisão depende do esforço de teste e da estimativa do cronograma de teste. A estimativa da história também reflete a estimativa do teste.

No Kanban, o Pronto-Pronto é realizado apenas quando uma história é desenvolvida, testada e marcada como completa, sem defeitos.

Conseqüentemente, a estimativa de teste desempenha um papel importante na estimativa de histórias.

Planejamento de História

O planejamento da história começa depois que uma história foi estimada e atribuída à Iteração atual.

O planejamento da história inclui as seguintes tarefas de teste -

• Prepare os dados de teste
• Estender testes de aceitação
• Execute testes manuais
• Conduzir sessões de teste exploratório
• Automatize testes de integração contínua

Além dessas tarefas de teste, outras tarefas também podem ser necessárias, como -

• Teste de performance
• Teste de Regressão
• Atualizações de testes de integração contínua relacionados

Progressão da história

O Story Progression revela testes adicionais que são necessários como resultado da comunicação contínua entre os desenvolvedores e testadores. Em situações em que os desenvolvedores precisam de mais clareza na implementação, os testadores realizam testes exploratórios.

O teste contínuo é executado durante a progressão da história e inclui o teste de integração contínua. Toda a equipe participa das atividades de teste.

Aceitação de história

A aceitação da história ocorre quando a história atinge o estado Pronto-Pronto. ou seja, a história é desenvolvida, testada e sinalizada como completa.

O teste de história é considerado concluído quando todos os testes relevantes para a aprovação da história ou nível de automação de teste são atendidos.

Em projetos ágeis, os testadores são responsáveis ​​pelas seguintes tarefas diárias -

• Apoiar os desenvolvedores na codificação, com esclarecimentos sobre o comportamento esperado do sistema.

• Ajude os desenvolvedores na criação de testes de unidade eficazes e eficientes.

• Desenvolva scripts de automação.

• Integre ferramentas / scripts de teste de automação com integração contínua para teste de regressão.

Para uma implementação rápida e eficaz dessas tarefas, um sistema de Integração Contínua (CI) que suporta CI de Código e componentes de teste é usado na maioria dos projetos Agile.

Os testadores e desenvolvedores em projetos ágeis podem se beneficiar de várias ferramentas para gerenciar sessões de teste e para criar e enviar relatórios de defeitos. Além de ferramentas especializadas para testes ágeis, as equipes ágeis também podem se beneficiar das ferramentas de automação e gerenciamento de testes.

Note - Soluções de gravação e reprodução, último teste, peso pesado e automação de teste não são ágeis como -

• O fluxo de trabalho test-last incentivado por tais ferramentas não funciona para equipes Agile.

• Os scripts impossíveis de manter criados com tais ferramentas tornam-se um impedimento para a mudança

• Essas ferramentas especializadas criam a necessidade de especialistas em automação de teste e, assim, promovem silos

As ferramentas amplamente utilizadas são -

S.No.	Ferramenta e finalidade
1	Hudson CI Framework
2	Selenium Teste Funcional - Integrado com Hudson
3	CruiseControl CI Framework
4	Junit Teste de Unidade Java
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Cobertura de teste de Java
7	Jester Java - Teste de mutação / Seeding de erro automatizado
8	Gretel Ferramenta de monitoramento de cobertura de teste Java
9	TestCocoon C / C ++ ou C # - reduz a quantidade de testes ao encontrar testes redundantes e encontrar código morto
10	JAZZ Java - Branch, Node e Defuse Coverage e implementa uma GUI, planejadores de teste, instrumentação dinâmica e um analisador de teste
11	Ant Java - Build de automação
12	Nant .Net - Build de automação
13	Bonfire Add-on Agile Testing para JIRA

Ferramentas de automação de testes ágeis

Suporte eficaz a ferramentas de automação de teste Agile -

• Automação de teste inicial usando uma abordagem de teste primeiro.

• Escrever código de automação de teste usando linguagens reais, linguagens específicas de domínio.

• Focando no comportamento esperado do sistema.

• Separando a essência do Teste dos detalhes de implementação, tornando-o independente da Tecnologia.

• Fomentando a colaboração.

Testes de unidade automatizados (usando Junit ou NUnit) dão suporte à abordagem de teste primeiro para codificação. Esses são testes de caixa-branca e garantem que o design seja sólido e que não haja defeitos. Esses testes são criados por desenvolvedores com suporte de testadores e podem ser independentes da funcionalidade necessária. Isso resulta na entrega de um produto que pode não atender aos requisitos do cliente e, portanto, sem valor comercial.

Essa preocupação é abordada automatizando os testes de aceitação que são escritos com a colaboração do cliente, outras partes interessadas, testadores e desenvolvedores. Os testes de aceitação automatizados são escritos pelos clientes ou proprietários de produtos / analistas de negócios refletindo o comportamento esperado do produto. O envolvimento dos desenvolvedores garante a produção de código de acordo com os requisitos. No entanto, se o teste for focado apenas na aceitação, o código resultante pode permanecer não extensível.

Portanto, os Testes de Unidade Automatizados e os Testes de Aceitação Automatizados são complementares e ambos são necessários no Desenvolvimento Ágil.

As ferramentas e estruturas ágeis que suportam o teste de aceitação automatizada são:

• Fit
• Fitnesse
• Concordion
• Ruby
• Cucumber

Em forma

Ward Cunningham desenvolveu a ferramenta Fit que pode ser usada para Automação de Teste de Aceitação. O ajuste permite -

• Clientes ou proprietários de produtos para dar exemplos de comportamento de produtos usando Microsoft Word e Microsoft Excel

• Programadores para transformar facilmente esses exemplos em testes automatizados.

Fit 1.1 suporta Java e .NET.

FitNesse

FitNesse é um wiki, que é um estilo de servidor web que permite a qualquer visitante fazer qualquer edição, incluindo a alteração de páginas existentes e a criação de novas páginas. Uma linguagem de marcação simples permite criar cabeçalhos facilmente, colocar o texto em negrito, sublinhado e itálico, criar listas com marcadores e fazer outros tipos de formatação simples.

Na FitNesse, a automação do teste de aceitação é a seguinte -

• Testes expressos como tabelas de dados de entrada e dados de saída esperados.

• Use FitNesse para colocar a tabela de teste na página que você pode editar.

  • Como alternativa, coloque a tabela de teste no Microsoft Excel, copie para a área de transferência e use o Spreadsheet to FitNesse comando para que o FitNesse formate sua tabela corretamente

• Execute o teste

• Você obtém os resultados do teste pela codificação de cores das células na mesa de teste

  • as células verdes representam que os valores esperados são obtidos

  • glóbulos vermelhos representam que um valor diferente do que você esperava foi obtido

  • células amarelas representam que uma exceção foi lançada

Pepino

Cucumber é uma ferramenta baseada no framework Behavior Driven Development (BDD). Os principais recursos são -

• É usado para escrever testes de aceitação para aplicativos da web.

• Permite a automação da validação funcional em um formato facilmente legível e compreensível, como o inglês simples.

• Foi implementado em Ruby e posteriormente estendido para o framework Java. Ambos apóiam Junit.

• Suporta outras linguagens como Perl, PHP, Python, .Net etc.

• Pode ser usado junto com Selenium, Watir, Capybara, etc.