Panorama sobre testes de software no framework SAFe

testing-safe-linkedin

Introdução

De forma geral, testes de software no framework SAFe podem ser organizados em dois níveis a fim de adequar todos os trabalhos de qualidade e teste de software: Time (Team) e Programa (Program).

Nível de Time

Pelo SAFe o nível de time possui um Time Ágil (Agile Team) que são indivíduos que tem a autonomia de definir, construir e testar soluções com a visão de Built-in Quality.
Os times utilizam práticas ágeis de frameworks como Scrum, Kanban e XP. Este último (XP) possui práticas de teste que não podem ser negligenciadas pelo time, como testar primeiro (Test First) e teste de aceite (Acceptance Test). A cada PI – Program Increment (Incremento do Programa) é necessário que as funcionalidades desenvolvidas durante o este ciclo estejam validadas antes da demonstração (System Demo).

Como o time trabalha baseado em Stories, um dos Enablers para uma User Story são a execução/criação de verificação de atributos da qualidade (funcional ou não funcional).
Pelo menos, é recomendado que se tenha o Teste de Aceitação da User Story e Testes Unitários neste processo. Veja SAFe Requirement Model.

Há uma menção referente a prática de ATDD – Acceptance Test Driven Development no papel de Product Owner (PO) no SAFe.
De forma implícita isso quer dizer que os testes, guiados pelo ATDD, devem ser desenvolvidos através de Critérios de Aceite durante a interação com o Time Ágil.

Built-in Quality é um dos quatro princípios (core values) do SAFe e possui diversos pontos de qualidade implícita e explícita.

Como traduzir o Built-in Quality em práticas?

O foco é no desenvolvimento do Product Increment (PI) [ou iterações]
• Mapear o funcionamento dos requisitos
• Mapear qualquer requisito não funcional (Enabler)
• Criar Critérios de Aceite para estender o entendimento das User Stories
• Ter exemplos dentro dos Critérios de Aceite, de acordo com a visão do Product Owner (ATDD)
• Aplicar práticas de XP como TestFirst (usando a técnica de TDD) e Acceptance Test durante o PI
• Aplicar o conceito de Continuous Integration (Integração Contínua)

Nível de Programa

Existem ações implícitas no Nível de Time que começam a emergir no time de programa, como o início de práticas para, futuramente, habilitar a cultura de DevOps.

É necessário criar um Deployment Pipeline, que entre outras coisas inclui: dados de teste, automação de teste (em todos os níveis) [1] para que este esteja presente na pipeline.
Também é necessário possuir e manter um ambiente de teste o mais próximo possível com o de produção.

Existe a figura do System Team (Time de Sistema) que é um Time Ágil focado no Programa que está focado em auxílio aos Times Ágeis no Nível de Time em construir e utilizar práticas ágeis referente a infraestrutura (Integração Contínua) bem como executar soluções end-to-end de testes de software no framework SAFe.
Este time também é responsável por criar e manter a infraestrutura, e parte desta atividade é passível a criação de testes para validar a infraestrutura. Criar plataformas e ambientes para a demonstração do produto, ambientes de teste (testes da equipe de QA com visão técnica e visão de cliente).

Dentro da solução de testes end-to-end e performance este time:

  • Cria testes automatizados baseados em cenários (Feature Acceptance Tests como um Enabler da Feature)
  • Estendem os cenários de teste para a utilização de um grande conjunto de dados
  • Organiza os casos de teste desenvolvidos pelo Time Ágil no Nível de Time em suítes ordenadas para execução
  • Executam testes manuais e testes automatizados para novas funcionalidades e Stories existentes
  • Priorizam a redução/refactoring de testes que tomam um certo tempo de execução
  • Executam testes de performance

Algumas, pequenas, métricas referente a qualidade e teste de software são coletadas e analisadas, distribuídos a Nível de Time, Programa e Portfólio:

Nível de Time – (Iteration Metrics)

  • % Cobertura de Código
  • Número de defeitos
  • Número de Casos de Teste
  • Número de Casos de Teste Automatizados
  • Total de Testes
  • % Total de Testes Automatizados
  • Número de refatorações

Nível de Programa – (Performance Metrics)

  • % Cobertura de Código
  • Defeitos
  • Total de Testes
  • % Testes Automatizados
  • Testes não funcionais

Nível de Portfólio – (Lean Portfolio Metrics)

  • Qualidade – Reduzir total de defeitos (time teste) e suportar o volume de ligações no suporte (suporte do produto) – Utilizando métricas de defeitos (dados) e volume de ligações ao suporte

Na métrica Enterprise Balanced Scorecard, no Nível de Portfólio, também há menção a Qualidade, onde uma é explícita, sendo ela os Defeitos, e as demais implícitas.

[1] “todos os níveis” refere-se a qualquer nível existente na sua arquitetura que pode, por exemplo, abordar testes unitários, de integração, de serviços, de sistema, de aceitação, de performance, etc…

Práticas adicionais de testes de software no framework SAFe

Conseguimos enxergar, com todos os valores, princípios e práticas que o SAFe apresenta, que existem papéis de testes para o time onde, na minha visão e recomendação, estes papéis sejam executados por um profissional de teste de software.

Nível de Time

  • Necessidade de ter Testadores Ágeis ajudando o time em todos os aspectos de entrega, como:
  • Trabalhar junto com o Product Owner para adicionar e refinar o DoD (Definition of Done) como critério de aceite para cada User Story.
  • Desenvolver scripts de teste através de práticas como BDD – Behavior Driven Development ou ATDD – Acceptance Test Driven Development
  • Ajudar os programadores através de pareamento a aumentar a cobertura de testes unitários
  • Quando necessário desenvolver frameworks de teste automatizados e suporte a testes manuais com a ajuda do papel de testes no Nível de Programa.
  • Entender a necessidade e aplicar a separação dos dados de teste dos scripts (data driven)
  • Saber balancear o foco de testes, sendo eles manuais e automatizados
  • Criar e executar testes não funcionais sempre que necessários alinhados com os Enablers e NFR’s

Nível de Programa

Necessidade de ter um Testador Ágil com maior conhecimento, este não sendo apenas sobre teste. Este conhecimento geralmente é associado com ações de programação, arquitetura e infraestrutura. Este desempenha algumas atividades de suporte ao time no Nível de Time e também:

  • Com a ajuda de pessoas da infraestrutura, criar e manter ambientes de teste
  • Desenvolver frameworks de teste que possam ajudar não somente um time, mas diversos times para entregar um Agile Release Train
  • Criar e executar testes automatizados (nível de time e nível de feature)
  • Planejar cada aspecto de teste na integração contínua e entrega contínua
  • Planejar, desenvolver e executar scripts de teste end-to-end, bem como testes não funcionais para suportar a entrega do Agile Release Train
  • Desenvolver e manter qualquer serviço de mock para os testadores a Nível de Time e também para o Time do Programa

Espero que você tenha gostado do artigo, caso deseje saber mais sobre testes de software no framework SAFe, acesse nossos outros artigos.

Categorias deste post

Agile, SAFe, Testes

Deixe o seu comentário: