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

12 Dicas para uma Sprint Retrospective Meeting efetiva (PARTE II)

A Sprint Retrospective é a oportunidade para todo o Scrum Team (Product Owner, ScrumMaster e Development Team) se inspecionar e criar um plano de ação para as melhorias para a próxima Sprint.

Aqui você encontra as 6 primeiras dicas para uma Sprint Retrospective eficiente.

7.      Faça a Sprint Retrospective

Não fazer a Sprint Retrospective é o mesmo que não usar Scrum

A Sprint Retrospective é o coração do Scrum, a ponto de muitos praticantes experientes dizerem que é a reunião mais importante. Jean Tabaka afirma que não fazer a Sprint Retrospective é a pior falha possível em relação a este evento.

A Sprint Retrospective é o momento em que os membros da equipe têm a oportunidade de inspecionar e adaptar o seu processo. E é nela que os membros do Scrum Team conversam sobre o que deu certo, o que poderia ter sido melhor e o que pode ser feito melhor para a próxima Sprint. O objetivo é o foco de ao menos uma melhoria no processo, ou Kaizen, e iniciar a implementação de imediato.

O processo da melhoria continua é considerado tão importante dentro do Scrum que é peça central do raciono do aumento de produtividade de um Scrum Team. Sendo considerado por Jeff Sutherland um dos principais artifícios para aumentar a produtividade do Scrum Team, ou um dos itens fundamentais para “fazer o dobro do trabalho na metade do tempo”.

srum-meeting8.      Todos têm algo importante a falar

Todos pensam, todos falam

Um ScrumMaster pode de forma inconsciente filtrar ou desconsiderar o que uma das pessoas está dizendo e isto pode destruir a Sprint Retrospective, segundo Jean Tabaka essa é uma das formas mais eficientes de destriu-la.

Existe um teste muito interessante proposto pelo Marcelo Leite para fazer uma autoavaliação da imparcialidade de um líder que deveria ser feito por todos os ScrumMasters que acreditam em sua imparcialidade.

Nele você é levado a se perguntar sobre sua relação com seu “Colega Não Favorito” e se você realmente consegue ser imparcial em sua relação a ele dentro do local de trabalho.

Caso você tenha tido um resultado próximo do meu, recomendo que você reflita o quão imparcial você é e se ao facilitar você tem momentos iguais ao do Deputado Frank Underwood, interpretado pelo Kevin Spacey, na série House of Cards.

9.      Musica dá o tom no ambiente

Música ajuda a relaxar e pode ajudar a dar o tom na sua Sprint Retrospective.

Estudos mostram que pessoas de diferentes épocas e culturas experimentam uma gama universal de reações emocionais a intervalos musicais específicos. Como se houvesse uma espécie de gramática universal tonal. Para ajudar, estudos mostram que nos esportes ouvir sua música preferida melhora o desempenho dos profissionais.

O difícil é descobrir músicas que funcionem, algumas dicas:

10.      Fluxo de facilitação na Sprint Retrospective

Utilize um fluxo para chegar em algum lugar

Não planejar a Sprint Retrospective e não seguir um fluxo podem ter consequências desastrosas em uma Sprint Retrospective. Principalmente em inicios de projeto ou quando a Meta da Sprint não foi alcançada.

Frisar a primeira diretiva do Norman Keath, uma dinâmica de warm-up, um momento especifico para falar o que foi bem, e um momento para que todos se comprometam com a melhoria podem ser a diferença entre o sucesso e o fracasso do projeto.

Existem muitos fluxos de Sprint Retrospective publicados na internet, para citar três exemplos famosos e que estão disponíveis gratuitamente:

11.      Foco nas três perguntas

Scrum não é patrocinado pela empresa que faz marcadores autoadesivos

Existe um lado lúdico e romantizado ao se utilizar flipchart e marcadores adesivos nesta reunião. Para muitos a Sprint Retrospective se resume ao ScrumMaster facilitar uma reunião mediada por uma técnica.

Primeiramente Post-it não faz parte do core do Scrum, da mesma maneira que o Planning Poker, a User Story, e o quadro de Kanban não fazem parte do framework.

O Rafael Nascimento, Agile Coach na Adaptworks, comenta que passou mais de um ano em uma multinacional facilitando diversas reuniões e nunca usou um post it.

O foco do Rafael em uma Sprint Retrospective era sempre fazer com que as seguintes três perguntas fossem respondidas:

  • O que foi bom?
  • O que melhorar?
  • Como melhorar?

srummaster12.      O ScrumMaster é uma pessoa

O ScrumMaster isento existe?

Muito se fala e lê sobre o ScrumMaster se manter isento durante esta reunião. A maior dificuldade está relacionada ao fato que em sua essência o ScrumMaster é uma pessoa.

E uma pessoa e por isso tem vieses cognitivos. Como exemplo de vieses posso citar:

Uma pessoa que busque evidencias que confirmem uma hipótese inicial de problema ou solução e não permita enxergar outras possibilidades pode parecer teimosia, mas para psicólogos isso tem o nome de viés da confirmação.

Aliado ao fato do viés do observador, o ScrumMaster pode enxergar com clareza um problema que não existe e mesmo assim tentar soluciona-lo.

Um exemplo claro nisso é um observador externo ao time enxergar anarquia em um time auto organizado. Para um observador externo a anarquia é imensa, mas na realidade não existe um padrão facilmente detectável de organização. O problema fica gigantesco quando o observador tendência a propor soluções centralizadoras para uma característica do sistema auto organizado.

Estudos mostram que as escolhas das massas influenciam diretamente como uma pessoa faz escolhas mesmo que vá contra o próprio juízo da pessoa. Esse é o famoso viés da conformidade.

O extremo do viés da conformidade nos leva ao pensamento de manada, que é um fenômeno em que o desejo pela harmonia do grupo faz com que as opiniões pessoas sejam suprimidas. Pois pensamentos contrários se tornam tóxicos e fica mais difícil ainda alterar o status quo.

Um ScrumMaster não consciente desses vieses pode se deixar levar pela opinião do grupo e suprimir ideias e opiniões importantes.

Já o efeito de ancoragem é um viés cognitivo que que descreve em se “ancorar” em uma característica ou parte da informação recebida. Em outras palavras, a dificuldade de se afastar da primeira impressão.

Dessa forma um ScrumMaster que tenha a impressão que a culpa de um insucesso seja um determinado processo irá se ancorar e terá dificuldade em ver o que está realmente ocorrendo.

De forma resumida, o ScrumMaster não é uma máquina de facilitação, mas sim uma pessoa. Que deve sempre focar em processos de facilitação para se isentar o máximo possível.

Referencias

As dicas foram baseadas na minha experiência pessoal, no e-book do Better Scrum, vídeos como o da Jean Tabaka no Scrum Australia, de websites como o do Norman Kerth, e artigos como: http://www.administradores.com.br/artigos/carreira/voce-e-realmente-um-lider-imparcial-faca-o-teste-e-descubra/79793/ do Marcelo Leite, Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana (http://blog.loomio.org/2013/11/20/occupy-scrum/).

Vale ressaltar que li intensamente o Scrum Guide de 2013 para que o conteúdo ficasse aderente ao que consta no texto base do Framework Scrum.

___________________________________________________________________________________________________________________

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

Scrum, Sprint, Sprint

O que buscar em uma plataforma ALM Agile ?


Application Lifecycle Management
(ALM) é o processo de gestão de todas as fases do ciclo de desenvolvimento de software a partir de requisitos iniciais até o lançamento de uma release. Plataformas de ALM são end-to-end de soluções integradas para a gestão destes processos de uma empresa, bem como, a perspectiva técnica.
Agile é uma metodologia de desenvolvimento de software interativo que vem crescendo rapidamente entre os desenvolvedores e está moldando o mercado de ALM, com desenvolvedores corporativos cada vez mais preocupados em migrar das metodologias tradicionais de desenvolvimento de software para uma abordagem mais ágil. Ágil e ALM, dois segmentos de mercado distintos, estão agora começando a se consolidar. Como resultado, temos agora o que chamamos de plataformas ALM Agile.

 

Estamos treinados a entender plataformas ALM que dividam em grandes ciclos o desenvolvimento do software, como: planejamento, gestão, construção, teste e elaboração de relatórios.

Precisaremos adquirir conhecimento prévio sobre metodologias e frameworks ágeis, para então realizar a avaliação segura de uma ferramenta que trabalhe em harmonia com as metodologias ágeis aderentes a realidade do time e tamanho de empresa, quando pensamos em escala. Essa avaliação levará em conta alguns dos principais passos envolvidos no ciclo de desenvolvimento e entrega de software em produção:
alm

1)
Integrar valores ágeis, processos e princípios para a plataforma de ALM;
2) Gerenciar o ciclo de vida do aplicativo como um Fluxo de Valor Único;
3) Alinhar o negócio com a TI mantendo foco no “entregável”;
4) Suportar a diversidade de ambientes de desenvolvimento;
5) Ser horizontal no gerenciamento de times e flexível;
6) Proporcionar transparência e rastreabilidade;
7) Suporte End-to-End – visibilidade estratégica.
Sabemos que valorizar indivíduos e interação entre eles mais que processos e ferramentas é ser ágil, então quando avaliar uma ferramenta estiver em pauta, esta avaliação deve ser baseada em critérios claros de consolidação entre os conceitos de ALM e os conceitos ágeis. E essa ferramenta deve proporcionar imagens claras, precisas ou imediata de um estado de produto ou fluxo de valor em desenvolvimento.

___________________________________________________________________________________________________________________

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, Time de desenvolvimento