Teste Ágil - Scrum

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 pelas entregas 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 congelamento mais rápido de 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 de negócios 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
  • Identificar automação de teste

Os testadores atualizam o plano de teste com as estimativas de esforço de teste e durações no sprint. Isso garante a provisão de tempo para os testes necessários durante os sprints time-boxed e também a responsabilidade pelo esforço de teste.

Análise de Teste

Quando um sprint começa, enquanto os desenvolvedores realizam a análise da história para design e implementação, os testadores realizam análises de teste para as histórias no backlog do sprint. O testador cria os casos de teste necessários - testes manuais e automatizados.

Testando

Todos os membros da equipe Scrum devem participar do teste.

  • Os desenvolvedores executam os testes de unidade à medida que desenvolvem o código para as histórias de usuário. Os testes de unidade são criados em cada sprint, antes que o código seja escrito. Os casos de teste de unidade são derivados de especificações de design de baixo nível.

  • Os testadores executam recursos funcionais e não funcionais das histórias de usuário.

  • Os testadores orientam os outros membros da equipe scrum com sua experiência em testes, de modo que toda a equipe tenha uma responsabilidade coletiva pela qualidade do produto.

  • No final do sprint, o cliente e / ou usuários finais realizam o Teste de Aceitação do Usuário e fornecem feedback para a equipe scrum. Isso se forma como uma entrada para o próximo sprint.

  • Os resultados dos testes são coletados e mantidos.

Teste de automação

O teste de automação tem grande importância nas equipes Scrum. Os testadores dedicam tempo na criação, execução, monitoramento e manutenção de testes e resultados automatizados. Como as alterações podem ocorrer a qualquer momento em projetos scrum, os testadores precisam acomodar o teste de recursos alterados e também o teste de regressão envolvido. O teste de automação facilita o gerenciamento do esforço de teste associado às mudanças. Os testes automatizados em todos os níveis facilitam a integração contínua. Os testes automatizados são executados com muito mais rapidez do que os testes manuais sem nenhum esforço adicional.

O teste manual se concentra mais em testes exploratórios, vulnerabilidade do produto e previsão de defeitos.

Automação de Atividades de Teste

A automação das atividades de teste reduz a carga de trabalho repetido e resulta em economia de custos. Automatizar

  • Geração de dados de teste
  • Carregamento de dados de teste
  • Construir implantação no ambiente de teste
  • Gerenciamento de ambiente de teste
  • Comparação de saída de dados

Teste de Regressão

Em um sprint, os testadores testam o código que é novo / modificado naquele sprint. No entanto, os testadores também precisam garantir que o código desenvolvido e testado nos sprints anteriores também esteja funcionando com o novo código. Portanto, o teste de regressão é importante no scrum. Os testes de regressão automatizados são executados em integração contínua.

Gerenciamento de configurações

Um sistema de gerenciamento de configuração que usa estruturas automatizadas de construção e teste é usado em projetos Scrum. Isso permite executar análises estáticas e testes de unidade repetidamente conforme o novo código é verificado no Sistema de Gerenciamento de Configuração. Ele também gerencia a integração contínua do novo código com o sistema. Os testes de regressão automatizados são executados durante a integração contínua.

Casos de teste manuais, testes automatizados, dados de teste, planos de teste, estratégia de teste e outros artefatos de teste precisam ser controlados por versão e exigem que as permissões de acesso relevantes sejam garantidas. Isso pode ser feito mantendo os artefatos de teste no sistema de gerenciamento de configuração.

Práticas de teste ágeis

Os testadores em uma equipe Scrum podem seguir as seguintes práticas ágeis -

  • Pairing- Dois membros da equipe sentam-se juntos e trabalham em colaboração. As duas pessoas podem ser dois Testadores ou um Testador e um Desenvolvedor.

  • Incremental Test Design - Os casos de teste são desenvolvidos à medida que os Sprints progridem de forma incremental e as Estórias de usuário são adicionadas.

Agile Metrics

Durante o desenvolvimento do software, a coleta e a análise das métricas ajudam a melhorar o processo e, assim, alcançar melhor produtividade, resultados de qualidade e satisfação do cliente. No desenvolvimento baseado em Scrum, isso é possível e os testadores devem prestar atenção às métricas de que precisam.

Várias métricas são sugeridas para o desenvolvimento do Scrum. As métricas significativas são -

  • Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Um Sprint de sucesso é aquele em que a equipe pode cumprir seu compromisso.

  • Velocity- A velocidade de uma equipe é baseada na quantidade de Story Points que uma equipe ganhou durante um sprint. Os Story Points são a medida das Estórias de Usuário contadas durante a estimativa.

  • Focus Factor - (Velocity / Team’s Work Capacity) / 100. Fator de foco é a porcentagem do esforço da equipe que resulta em histórias concluídas.

  • Estimation Accuracy - (Estimated effort / Actual effort) / 100. A precisão da estimativa é a habilidade da equipe em estimar o esforço com precisão.

  • Sprint Burndown- Trabalho (em Story Points ou em horas) que é Remaining vs. Trabalho que precisa ser remanescente idealmente (conforme a estimativa).

    • Se for mais, significa que a Equipe assumiu mais trabalho do que eles podem fazer.

    • Se for menor, significa que a equipe não estimou com precisão.

  • Defect Count- Número de defeitos em um Sprint. A contagem de defeitos é a quantidade de defeitos no software em relação ao backlog.

  • Severity of Defects- Os defeitos podem ser categorizados como menores, maiores e críticos de acordo com sua gravidade. Os testadores podem definir a categorização.

Retrospectivas de Sprint

Nas Retrospectivas Sprint, todos os membros da equipe participarão. Eles compartilham -

  • As coisas que correram bem
  • Metrics
  • O escopo para melhorias
  • Itens de ação a serem aplicados