Planejamento para Automação de Teste em Ágil

Introdução

Sabemos que a automação de teste em um contexto ágil é obrigatória, independente se esta ação será feita por uma pessoa focada (testador) ou pelos membros do time. O importante é saber como podemos planejar a automação em cada pequena fase que temos.

A seguir veremos como é a big Picture dos Níveis de Detalhe para o Planejamento e, na sequência, como podemos nos planejar para o Nível de Release.

 

Níveis de Detalhe (precisão) para o Planejamento

Há quatro níveis que podemos facilmente identificar quando focamos no planejamento da automação de teste em projetos ágeis:

  • Nível de Release: Visão do todo e planejamento em alto nível sobre automação
  • Nível de Feature: Visão de uma funcionalidade e planejamento específico
  • Nível de Story: Visão macro do que será feito frente a o planejamento
  • Nível de Tarefas: Visão micro e aplicação prática de todo o planejamento

01_niveis_detalhe

Planejamento em Nível de Release

No planejamento de um release o time já tem uma ideia da visão do produto. Como é uma visão nós podemos fazer um planejamento em alto nível. Neste momento devemos também pensar no todo, principalmente no que podemos aplicar de novas práticas, ferramentas, necessidades de ambiente e aplicação de algumas técnicas de teste.

Ao final do release é necessário ter todos estes pontos já desenvolvidos e desempenhados, logo o planejamento em termos de automação no release foca mais em aspectos que possam mudar ou impactar o planejamento como vem sendo feito.

Quando a release inclui um produto com novas tecnologias é necessário separar um tempo para experimentos, aplicações e aprender sobre possíveis problemas de design. Também é necessário levantar todos os riscos necessários

02_nivel_release

Em resumo, no Nível de Release:

  • O Time já tem uma boa visão do todo
  • É o melhor momento de pensar em:
    • Ferramentas
    • Ambiente
    • Práticas/Técnicas de Teste (Performance, Segurança, etc…)
  • Quando há novas tecnologias é necessário:
    • Fazer experimentos
    • Levantar possíveis problemas de design
    • Riscos
Nenhum comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

Complementando a visão da user story com a técnica do “Los Tres Amigos”

Introdução

Um dos grandes desafios dos métodos ágeis sempre foi o entendimento compartilhado sobre uma feature/story. Muitos times, geralmente no Backlog Grooming e no Sprint Planning, tem o entendimento destes artefatos de uma forma muitas vezes incompleta não levando em consideração a visão de todos os papéis do time gerando confusões, duplicações, complexidade e retrabalhos.

Los Tres Amigos

Também conhecido na literatura como Power Of Three ou Specification Workshop este processo onde, durante uma reunião (que tem o melhor ganho sendo no Sprint Planning), um Analista de Requisitos, um Programador e um Testador irão discutir em conjunto a feature/story e revisar este(s) artefato(s). O ideal é que este processo esteja de um a dois timeboxes na frente da iteração atual (abaixo você entenderá os motivos).

O processo é simples:

  1. O Product Owner inicia e faz a mediação da sessão apresentando a feature/story apresentando todos os subsídios necessários para o entendimento dos Tres Amigos
  2. Os Tres Amigos (Analista de Negócio, Programador e Testador) identificam suas necessidades e expõe sua visão sobre a feature/story e listam todas as dependências, necessidades, problemas e criam exemplos para deixar mais claro o entendimento
  3. Depois dos Tres Amigos terem o entendimento compartilhado é o momento de prover estimativas de desenvolvimento e testes

los-tres-amigos

Quais os benefícios deste processo?

Obviamente o entendimento compartilhado que remove uma série de problemas e apresenta muitos benefícios:

  • Detalhamento de forma colaborativa: não haverá mal-entendidos os dúvidas básicas quando o trabalho é feito pelos Los Tres Amigos
  • O que deve ser testador é criado por todos: não é só tarefa do testador dizer o que pode ser testado, o que não pode e qualquer ação referentes a testes. Todo o time cria de forma colaborativa os testes
  • Revisão em conjunto: ao aplicar o processo já estamos revisando tudo o que é necessário em conformidade com o DoR e o DoD
Nenhum comentário »

Categorias deste post

Técnico, Testes

The Evolution of the Testing Pyramid

Introduction

As software testers, we’ve all heard about the Testing Pyramid. However, in my opinion (and in the opinion of others), there’s a misunderstanding in how we should apply the Testing Pyramid in our projects.

If you have never heard about the Testing Pyramid I recommend you read these posts in this sequence (believe me, doing this will help you understand this post better):

  1. Mike Cohn Testing Pyramid

  2. Test Pyramid by Martin Fowler

  3. Ice Cream Cone Anti-Patter by Alister Scott

  4. Cupcake Anti-Pattern

Let’s Think

Now, it’s time for some critical thinking.

Question: When we see a model, what is the first thing that we do?
Answer: Follow it!

Let’s be honest with ourselves: we follow the model without question (in most of the cases). But have you realizes that the Testing Pyramod is a model and a analogy?

The first post that I referred to says:

Remember that this is just a model, it is not a hard-and-fast rule that should be adhered to in every software project. (James Willet)

Many people try to use the Testing Pyramid like a hard-and-fast rule, believing that all of the tests should be pushing to the base of the pyramid because we need fewer and fewer tests in the UI. I disagree.

Testing Geometrics

After reading all these posts and concepts, do you agree with me that a strategy for testing automation is more like a Testing Geometrics than a Testing Pyramid?

Obviously, we have a lot of geometric shapes: pyramid, pentagon, rectangle, star, ellipse, and so on (try to google geometric shapes).

Now, consider the following in that mindset:

In a scenario in which you need to test a mobile app, the focus will be the user interface, correct? However, if you keep thinking that the Test Pyramid is a rule, you cannot focus (and put more tests than the other layers) in the UI layer. No, you can put however many tests you find necessary!

When we test a mobile app, at least three layers need to be tested: unit, services, and UI (this fits perfectly in the first Test Pyramid). However, if you miss a bug in the UI layer in production, what do you think is the first thing that the user will do? Obviously, it’s not reporting the bug; it’s a complete uninstallation of your app! (And the user, probably, will never return or install it again.)

So, wich geometric shape can you use to focus more on the UI layer? I say a cylinder because all of the tests in these three levels are important.

In a scenario in which you need to test microservices, the focus will be the unit tests, correct?

Again, if you keep thinking that the Testing Pyramid is a rule, you cannot focus (and cannot put more tests) in the Service layer.

If you are building a microservices, the UI layer is missing, and you will focus on the unit tests. However, the services are the heart of this. You must test them! Remember, you need to test all of the services.

So, wich geometric shape can you use to focus? I should say a star!

“But Elias, a star?” Yes!

You’ll do some unit tests, but (in my opinion) the services test will have more focus. You need to integrate each service in another test or suite in order to guarantee the sanity of this integration.

Nenhum comentário »

Categorias deste post

Técnico, Testes

3 Dicas para a Documentação de Teste em uma Equipe Ágil

  1. Minimize a sua documentação

Não crie documentos só porque é uma prática da empresa se você não sabe realmente onde ele será empregado (como será utilizado, quem irá ler o documento, etc…).

Criar documentação “só por criar” gera um custo muito alto, visto que temos sempre “pouco” tempo para uma entrega. Logo devemos criar somente entregáveis utilizáveis. Se o documento que você está criando não é utilizável interna ou externamente ele pode ser removido.

Se há documentos que você precisa criar por conta de alguma legislação, obviamente, crie! Mas não se esqueça que este deve ser estimado e priorizado (sim, ele vira uma tarefa) e precisa fazer parte da sua Definição de Pronto (DoR).

Exemplo prático referente a teste de software – Evidência de Teste

Muitas instituições financeiras necessitam documentar as evidências de teste. As evidências de teste são prints de telas, de partes estratégicas da aplicação, que são colocadas com uma descrição. É muito comum criarmos evidências de teste quando encontramos bugs para reportar a uma pessoa/equipe quando este não pode ser corrigido imediatamente, mas também é uma prática documentar os cenários de sucesso por conta de legislações vigentes em instituições financeiras (Sox)

doc-de-teste-agil-blog

  1. Mantenha a documentação sempre simples

Criar gráficos, tabelas, diagramas coloridos e qualquer outro apelo visual que só servirá para “deixar o documento mais bonito” e sem informação efetiva, ou com muita informação, só faz você perder tempo. Seja simples e direto no documento. Ninguém gosta de perder tempo (horas) lendo algo que poderia ser absorvido em minutos.

Exemplo prático referente a teste de software – Plano de Teste

Antigamente (não muito tempo atrás) e até hoje muitos testadores mesmo em times ágeis continuam criando documento de Plano de Teste em um padrão/template conhecido da IEEE 829 (referente a documentação de teste). O documento é muito extenso, possui vários tópicos e não é nada direto, ou seja, uma perda de tempo precioso para o time.

Agora pense comigo: o testador (ou o papel deste) não planeja os critérios de aceite com vocês (time)? Já não está saindo o planejamento ai? Precisa de documenta para isso?

Há alguns casos, obviamente, onde iremos fazer um planejamento prévio como por exemplo a aplicação de testes de Performance, Carga e Stress. Mas no dia a dia o documento é bem pouco utilizado e, mesmo que você crie, foque em pontos chave e não o deixe extenso.

Sugiro a leitura da sessão Test Planning do Livro Agile Testing.

  1. Documente somente quando necessário

Focar na criação de diversos documentos que você necessita ao longo do tempo não é uma boa ação (big-requirement-upfront). A documentação de teste deve ser criada por demanda e, se tiver necessidade, por partes. O tamanho da documentação também importa. A documentação tem que ser objetiva, mas não pode habilitar o contexto da comunicação como em uma User Story: o documento de testes deve ser entendido por todos os membros do time e agentes externos (stakeholders) para que todos tenham um exemplo real de como a funcionalidade/requisito/regra deve funcionar.

Exemplo prático referente a teste de software – Critérios de Aceite descrito como Especificação por Exemplos

Uma documentação obrigatória para habilitar o entendimento dos requisitos, guia do desenvolvimento e validação pelo usuário final é o Critério de Aceite. Ela é criada geralmente em conjunto com o time e o cliente.

Este pode ser escrito de diversas formas. A mais recomendada para o entendimento por todo time é através da Especificação por Exemplos.

Através dela podemos, de uma só vez, informar como será o detalhe do requisito em termos de utilização mais o exemplo de dados que utilizaremos.

Uma forma comum é adotar a escrita dos Critérios de Aceite através do Ghekin (Given, When, Then). Abaixo um exemplo:

Dado que eu estou na página inicial da Adaptworks

Quando eu pesquisar pelo treinamento “Agile Testing”

Então o treinamento “Agile Testing” é apresentado

 E o treinamento “Agile Testing Automation” é apresentado

Exemplo prático referente a teste de software – Plano para Testes de Performance

O plano para a execução dos Testes de Performance é um exemplo de uma documentação de teste evolutiva ao longo do projeto. Vamos pegar o exemplo onde precisamos executar testes de performance antes da entrega da Release. A cada iteração iremos planejar quais serão os fluxos criados para o script de teste, coletar a massa de dados necessária, conversar com o pessoal de infraestrutura para ter um ambiente suportado ou mesmo o ambiente de produção, aplicação de monitores em diversas partes da arquitetura, etc…

Isso é muito difícil de fazer em apenas uma iteração, onde dividimos todas as tarefas referente a esta ação em diversas partes.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

Quem é o Agile Tester?

A definição

agile-tester-artigo1Segunda Lisa Crispin e Janet Gregory em seu livro Agile Testing: A Pratical Guide for Testers and Agile Team [1] o que define o Agile Tester é:

Definimos o Testador Ágil neste sentido: um profissional que encara as mudanças, colabora bem com pessoas técnicas e de negócio e entende o conceito de usar os testes para documentar os requisitos e guiar o desenvolvimento.

Testadores Ágeis tendem a ter bons conhecimentos técnicos, e sabem como colaborar com outros membros do time para automatizar testes e também são experientes em executar testes exploratórios.

Eles estão dispostos a aprender o que os clientes fazem para que eles possam entender melhor os requisitos.

Eu, propositalmente, dividi em três partes para ficar mais visível tudo o que um Agile Tester é e o que ele pode fazer!

Mas a primeira resposta a pergunta “Quem é o Agile Tester?” é: qualquer pessoa do time!

Porque qualquer pessoa pode pegar uma tarefa de teste para executar. Qualquer pessoa pode pensar como um usuário no momento de um planejamento. Qualquer pessoa pode executar um teste exploratório.

Para alguém do time possuir estes skills, primeiramente, ele precisa ter o MindSet do Teste Ágil.

O MindSet do Teste Ágil

agile-tester-artigo2O time, ao invés de entregar o melhor produto, deve entregar o melhor valor de negócio para o cliente através de um produto, certo?

A grande maioria dos times focam em entregar o melhor produto, mas nem sempre o melhor produto traz o melhor resultado de negócio.

É aqui que o MindSet entra: trocar informações constantes e colaborar com o cliente* a fim de ajuda-lo a expressar de forma adequada os requisitos.

O restante dos pontos é a viabilização disso (tarefas). O MindSet é único: colaboração com o cliente para que ele mesmo entenda o que está pedindo.

Alguns itens que podem ser adicionados ao MindSet são:

  • Criatividade
  • Estar aberto a novas ideias
  • Disposição para assumir qualquer tarefa
  • Foco no cliente
  • Visão constante na Big Picture (no todo)

* a palavra “cliente” pode ser interpretada como o cliente real ou o product owner (dono do produto)

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Técnico, Testes, Time de desenvolvimento

A origem do Agile Testing

Origem

Se você já leu algo referente a Agile Testing vai lembrar logo do livro Agile Testing, que foi lançado em 2009, e associar que a origem do termo veio das duas autoras Janet Gregory e Lisa Crispin, certo? Errado!

Em 2002 Bret Pettichord já falava sobre Agile Testing [1] associando ele também com princípios de Context Driven Testing [2]. Na sequência, em 2003 Brian Marick criou o Quadrante de Teste Ágil para distinguir dentro de um processo ágil os testes baseados em negócio e em tecnologia, e os de suporte ao time dos de crítica ao produto.

A Elisabeth Hendrickson em 2008 também já falava sobre Agile Testing na sua palestra Agile Testing, Nine Principles and Six Concrete Practices for Testing on Agile Teams [3].

Lisa Crisprin, em 2002, trabalhou em um time que aplicavam as práticas de XP – Extreme Programming e já começava a criar algumas técnicas de como um testador poderia trabalhar em um time XP. Logo após o primeiro livro formal sobre o assunto foi lançado: Testing Extreme Programmimg [4]. Anos depois ela e a Janet Gregory lançaram o livro Agile Testing que é um compilado das experiências das autoras no processo de transição do Teste Tradicional para o Teste Ágil e como o testador pode ajudar a equipe.
Hoje este livro é a principal referência sobre Agile Testing.

Teste Tradicional x Agile Testing

A imagem abaixo já vai ilustrar uma similaridade e a diferença da adoção de cada abordagem:

origem-agile-testing

origem-agile-testing_2

No projeto por fases podemos ver nitidamente que há uma fase de testes, mas esta depois do desenvolvimento ter sido concluído. A ideia do tamanho das caixas nos passa uma falsa impressão que realmente teremos tempo para testar, mas o que acontece em diversos projetos (até hoje) é a fase de testes ser diminuída e termos uma nova caixa antes da Entrega: o “Teste->Bug->Correção->Reteste” que toma muito mais tempo do que qualquer planejamento inicial de testes.

No Agile os testadores trabalham em cada Interação junto ao time e testam a funcionalidade mesmo quando ela está em desenvolvimento. A funcionalidade/requisito/regra (User Story + Critérios de Aceite) só estarão realmente entregues depois de testado (que são pontos do DoD – Definition o of Done).

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento