Vida de um Agile Tester – Parte I

Este é o primeiro post da série “Vida de um Agile Tester” onde serão apresentados vários aspectos da vida de um QA. Neste primeiro post vamos nos limitar a uma visão geral dos principais eventos que futuramente vamos trabalhar isoladamente, portanto muitos deles ainda estarão incompletos e sem exemplos ou referencias o suficiente. Em futuros posts vou detalhando cada um.

É importante lembrar que existem várias maneiras de trabalhar em um projeto de software, entre elas existem as “maneiras ágeis” de desenvolvimento de software. O que será apresentado durante essa série de posts, são exemplos baseados principalmente na minha experiência com projetos ágeis, portanto, não representa uma verdade absoluta ou a única “maneira ágil” de desenvolver e testar software, mas uma forma que vem dando muito certo para mim. :)

Inicialmente, vamos compreender que ágil se trata de desenvolver software de uma forma flexível o suficiente para que o produto desenvolvido possa ser adaptado as mudanças de diversas naturezas. Ágil não se declara um processo para desenvolver software, mas um conjunto de valores para desenvolver melhor o software, por isso o “processo” é muito flexível. Mais a frente vamos falar mais sobre isso, mas para esse post vamos falar sobre as práticas baseadas em valores que são comumente usadas no desenvolvimento ágil, principalmente do XP e do SCRUM.

A inception

Inception should be a few days’ work to consider if it is worth doing a few months’ work of deeper investigation during elaboration.” – Martin Fowler

Inception Story Mapping by Agile Tips

A primeira primeira e penúltima fase de um projeto ágil. A inception (não consigo encontrar uma boa tradução para isso) é relativamente parecida com a concepção para projetos waterfall/RUP Based. É um período de tempo voltado a conhecer o cliente, estudar suas necessidades, viabilidade de tecnologias/arquitetura, introduzir o pensamento ágil para o cliente e apresentar um esboço de altíssimo nível do que será o projeto para o cliente. Quando falamos, sublinhamos e colocamos em negrito o termo altíssimo nível, é porque aqui existe uma grande diferença do ágil para o waterfall. O waterfall fecha o projeto após a sua concepção (o que inclui estimativas, documentação, soluções técnicas, tipos de testes, planejamento e arquitetura), o ágil inicia o projeto (o que não inclui todas as estimativas, toda a documentação, soluções técnicas, tipos de teste,  planejamento e nem arquitetura).

Agile é a forma mais correta de criar softwares customizados, pois o cliente tem a liberdade de mudar qualquer coisa a qualquer momento. Durante todo o  desenvolvimento, o cliente terá um software funcionando para avaliar e toda a equipe trabalha dentro das expectativas do cliente. A inception deve ser o ponta pé inicial disso e por isso tem a missão de conscientizar o cliente e o time sobre esses preceitos e em troca, todos (incluindo o cliente) concordar com isso.

Ao terminar uma inception o time ágil tem um backlog do produto, que pode ser classificado como uma lista de desejos do cliente por prioridade (o que o cliente mais precisa vem primeiro) e com estimativa inicial da complexidade (medida pelo time). Essa lista de desejos será mudada pelo cliente várias vezes de agora em diante assim como a complexidade também será ajustada pelo time. Essas duas práticas ajudam a ter um produto funcionando mais rápido, assim o cliente pode mudar de ideia ou pensar em novos desejos antes que o projeto precise ser totalmente modificado para atendê-los.

Os principais papéis envolvidos nessa tarefa são o Cliente, o BA e o PM/IM/ScrumMaster, pois envolve mais explorar o negócio do que questões técnicas. Mas é muito interessante ter pelo menos um QA e um Dev Lead envolvidos na Inception, pois eles podem ajudar a encontrar User Stories técnicas, dar pitácos sobre alguns épicos ou User Stories, sugerir soluções não técnicas e até alertar sobre viabilidade técnica de algum requisito ou desejo do cliente.

Ainda durante a inception podem ser tomadas algumas decisões técnicas tais como linguagem de programação que será usada, ferramentas para integração continua, nível/ferramentas de automação de testes, ferramentas para controle de defeitos, critérios de qualidade, requisitos não funcionais (performance e segurança esperados por exemplo), DoD (definição de pronto), layout do card wall, equipe do projeto, entre outras decisões que não devem ser tomadas sem a ajuda de um QA e um Dev Lead. O importante é que as pessoas técnicas que vão tomar essas decisões não estejam fora do contexto do projeto, ou seja, não entrem somente no final da inception sem conhecer o cliente e a razão/missão do produto.

Mais sobre o assunto:

http://agiletips.blogspot.com.br/2012/02/back-to-basics-what-made-this-agile.html
http://pragprog.com/book/jtrap/the-agile-samurai

A Iteração ou Sprint

“A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an interation. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on.” – Ken Schwaber

Uma iteração (como chamada no XP) é um intervalo fixo de tempo. Normalmente as empresas usam uma ou duas semanas para determinar a duração de uma iteração, mas o XP prevê que uma iteração pode durar até três semanas. No scrum, normalmente uma iteração é chamada de Sprint. A iteração existe por vários motivos, mas acredito que os principais são para mitigar riscos e responder mais rápido as falhas e mudanças em um projeto.

Sprint by Mountain Goat

Podemos dizer que uma iteração é um pequeno projeto waterfall, onde planejamos, executamos, entregamos software funcionando e no final revemos tudo o que deu certo e errado. Para isso, existem alguns eventos ou cerimonias como o scrum chama. Vamos falar um pouco sobre esses eventos e como um QA atua neles e também sobre alguns momentos específicos ou atividades de um QA durante a iteração.

Acho interessante ressaltar que scrum é ágil, mas nem todo ágil é scrum. Vejo que as pessoas quando falam de ágil costumam associar ao scrum como se esse fosse uma solução universal, quando na verdade o scrum é apenas uma maneira de organizar o trabalho em um projeto de desenvolvimento de alguma coisa. O scrum é apenas uma forma de melhorar a comunicação e a sinergia do time e por isso ele apenas mostra os problemas. O ágil original, se é que podemos chamar assim, é muito mais baseado em soluções técnicas e foco no dia a dia do time do que em processos como o scrum.

Apesar do comentário acima, nesse primeiro post sobre o trabalho do agile tester ou QA, irei focar mais no processo do que nas soluções técnicas. Como citado anteriormente, você vai concordar com algumas coisas e discordar de outras. Se muitas coisas forem novas para você que está trabalhando em projetos tradicionais, provavelmente vai ficar assustado com algumas práticas ou vai duvidar delas, o que é muito natural. Em ambos os casos, o importante é manter a mente aberta para realidades diferentes do sua :)

Mais sobre o assunto:

http://en.wikipedia.org/wiki/Sprint_(software_development)
http://blog.brightgreenprojects.com/2010/03/10/sprint-iteration-agile-scrum/
http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X

Iteration Planning Meeting ou Sprint Planning

“The iteration planning meeting is the whopper meeting that gets the entire team on board with exactly what functionality will be worked on during the iteration.” – Cara Taber and Martin Fowler

O primeiro evento que acontece é a reunião de planejamento da iteração, ou para quem está acostumado com o scrum, o Sprint Planning.

Nessa reunião todas as histórias de usuário são revisadas, priorizadas e reestimadas. Normalmente o BA (Business Analyst) conduz a reunião do ponto de vista das histórias, o PO (Product Owner) tira as dúvidas que forem aparecendo e o PM (Product Manager/Scrum Master) ajuda a definir questões relativas a riscos, indisponibilidade e velocidade das iteração.

Os QAs e os Devs atuam bastante nessa reunião, principalmente com dúvidas e estimativas. O QA em especial deve informar a complexidade de automatizar ou não esses testes, de executar os testes de forma manual e buscar entender quais testes estão fora do escopo. A qualidade é uma preocupação de todo o time, logo todos devem tentar entender o contexto das histórias  e tentar descobrir se alguma delas pode ser melhorada, postergada ou adiada, da mesma forma que devem tentar encontrar os buracos no negócio que podem gerar novas histórias ou melhorar as existentes.

É importante também que o QA tenha claro após essa reunião quais os limites das funcionalidades que serão entregues e saiba como isso está alinhado com o PO. Não confundir bugs com features e melhorias é uma das características de um bom QA. O nosso antigo Tester julgava que qualquer comportamento externo a documentação era um bug, o que fazia com que a equipe gastasse horas em features novas ou melhorias com menor valor de negócio para o cliente sem perceber. O novo QA está tão preocupado com o over-testing quando com o under-testing e foca no valor do cliente antes de focar em um produto perfeito.

Mais sobre o assunto:

http://martinfowler.com/articles/planningXpIteration.html
http://improveit.com.br/scrum/sprint_planning_meeting
http://www.mountaingoatsoftware.com/scrum/sprint-planning-meeting
http://www.extremeprogramming.org/rules/iterationplanning.html

Stand up Meeting ou Daily Scrum

“The whole team meets every day for a quick status update. We stand up to keep the meeting short. That’s it. . . But this short definition does not really tell you the subtle details that distinguish an effective stand-up from a waste of time.” – Martin Fowler e Jason Yip

Standup Meeting by Martin Fowler

O stand up meeting, daity scrum ou reunião diária, é o momento em que o time sabe o que está acontecendo no projeto.

Cada pessoa do projeto participa, normalmente com três updates básicos:

  • O que eu fiz;
  • O que vou fazer;
  • Alguma coisa me bloqueia.

Pode parecer pouca informação, mas muitas dúvidas são solucionadas nesses pouco menos de quinze minutos. Nós QAs normalmente informamos os updates sobre os testes que estamos realizando, em quais histórias estamos trabalhando e se temos novos bugs ou impedimentos.

A stand up meeting e o card board são as mais importantes ferramentas de comunicação em um projeto de desenvolvolvimento de software, e especialmente a stand up, pode ser de grande ajuda para o QA se organizar e priorizar suas tarefas. De um dia para o outro muita coisa pode mudar. Serviços ou APIs podem ficar indisponíveis, uma story pode ser repriorizada, um commit pode ser revertido, um bug pode se tornar um change request entre vários outros acontecimentos que vão mudar seus planos para o dia ou mesmo para a iteração. Todas essas informações são parte de uma stand up meeting.

Mais sobre o assunto:

http://martinfowler.com/articles/itsNotJustStandingUp.html
http://improveit.com.br/xp/praticas/reuniao_pe
http://www.extremeprogramming.org/rules/standupmeeting.html
http://www.mountaingoatsoftware.com/scrum/daily-scrum

Métricas

“Working software is the primary measure of progress.” – agilemanifesto.org/principles.html

Burndown Chart by Kenji Hiranabe (http://drdobbs.com/)

Para quem está acostumado com projetos tradicionais como RUP e Waterfall e principalmente para quem está acostumado com projetos aderentes ao CMM/CMMi ou outro modelo de maturidade de software, quase sempre o agile parece um caos, principalmente por causa das métricas.

Métricas são sinonimo de organização e controle em várias empresas, mas até onde essas métricas são realmente necessárias? Se quer buscar essa resposta, recomendo assistir a apresentação “Agile Metrics that Matter” da Patricia Carlin sobre o assunto.

O ponto é que em agile não usamos muitas métricas obrigatórias, na verdade não existe nenhuma, mas duas métricas são necessárias para quase todos os projetos: o product burn up e o iteration burn down.

O product burn up nos mostra quantos pontos foram entregues no projeto e quantos pontos faltam de acordo com o backlog. Normalmente ele também exibe se estamos atrasados ou adiantados para as releases e para o produto final. Essa métrica também nos mostra quanto software funcional entregamos, qual a velocidade média de entrega da equipe, quanto tempo falta para terminar o projeto entre outras informações valiosas.

O iteration burn down nos da uma visão parecida com o do produto, mas apenas para a iteração atual, assim conseguimos acompanhar a entrega da iteração atual e podemos tomar decisões mais rápidas para melhorar a nossa velocidade se necessário.

Caso outra métrica seja necessária, nada impede que seja elaborada, mas é importante manter em mente que você não pode atrapalhar a produtividade da equipe, principalmente se coletar informações que não tem valor imediato para o time ou para o cliente.

No início do vídeo que eu recomendei, são exibidas duas frases e uma delas é muito interessante: “Nem tudo o que pode ser contado conta, e nem tudo o que conta pode ser contado.”, para software isso é muito verdadeiro, pois muitas empresas criam métricas de bugs por linhas de código, bugs por developer ou QAs, linhas de código por dia, casos de teste por dia, entre outras métricas que não dizem nada sobre o desempenho do profissional ou do projeto. Em contra mão, o nosso principal indicador de sucesso, software executando, é muito difícil de ser calculado com números, mas pode ser facilmente visto pelo cliente no dia a dia.

Mais sobre o assunto:

http://community.thoughtworks.com/posts/c8e710d4fe
http://www.infoq.com/news/2009/11/good-agile-metrics

http://martinfowler.com/bliki/CannotMeasureProductivity.html

Agile Card Wall

“Uma ferramenta que estabelece uma visão compartilhada da equipe, fornece um ponto central para a comunicação da equipe, destaca gargalos do processo, mostra o fluxo de trabalho, mostra a carga de trabalho do time, mostra o progresso de cada tarefa e ajuda a estabelecer um ritmo sustentável.” – Paulo Caroli

Cardwall by Fábio Pereira

O card wall é um quatro disposno no ambiente de trabalho da equipe e visível 100% do tempo. Nele são fixadas as histórias, tarefas técnicas, bugs e qualquer item que deva ser trabalhado durante a iteração. Nele também são estabelecidos os estados que uma tarefa deve passar e são vinculados os respectivos executores dessas tarefas.

Um card wall pode receber o processo que for necessário, mas devemos ficar atentos para as estravagancias. O que diferencia o agile do waterfall é exatamente o tempo de resposta, portanto, se tivermos um fluxo de trabalho com dez etapas, provavelmente vamos trabalhar como uma cascata pequena e vamos atrasar o nosso feedback.

Um fluxo de trabalho que vem funcionando para mim, envolve dois pontos para o QA. O primeiro é a análise, planejamento e automação da história e o segundo é o teste manual, normalmente exploratório e criação de novos testes automatizados.

No primeiro momento lemos a história e escrevemos os testes que executaremos. Sim, muito parecido com o modelo antigo de testar software, o que diferencia é que agora automatizamos isso no build (integração continua), e quando o desenvolvedor iniciar o desenvolvimento, ele deve satisfazer a esses testes antes de recebermos o produto para ser testado. A única diferença esta no momento em que o teste é executado e na forma como ele é executado. Nesse momento também podem ser encontrados defeitos, lacunas ou mudanças nas histórias. Esses itens são discutidos com o PO e com o BA e refatorados para que os testes reflitam a nova realidade.

O segundo momento é quando a funcionalidade está implementada e atende a todos os testes que o QA implementou no passo anterior. Nesse momento o QA pode executar testes exploratórios e reexecutar os testes automatizados de forma manual, assim como executar os testes de aceite (também automatizados) para garantir que está tudo ok. Mais a frente falaremos sobre bugs.

Mais sobre o assunto:

http://agiletips.blogspot.com/2010/06/agile-brazil-2010-notes-and-my-ppt.html

http://www.infoq.com/articles/agile-kanban-boards

 

Escrevendo testes

“The way most software is designed, developed, and launched has changed dramatically over the last decade – but what about testing? Software testing as we knew it is dead – or at least moribund – in which case we should stick a fork in it and proactively take it out of its misery for good.” – Alberto Savoia

Build Dashboard Radiator - Your Build Light ++ por Fábio Pereira

A principal atribuição de um QA não é encontrar defeitos, mas sim evitá-los. Por isso escrever testes automatizados que garantem que o produto correto será desenvolvido são parte da vida de um QA. Mas claro que encontrar defeitos depois que as histórias estão prontas também é uma atribuição do QA.

Em times ágeis não vemos valor em escrever longos planos de teste, com dezenas de casos de teste, validando cada pedacinho do produto. Isso porque raramente temos tempo para gastar com esse tipo de atividade e preferimos gastar esse tempo escrevendo cenários automatizados que guiarão os developers a construir uma história com muito menos defeitos e depois testes exploratórios cobrem cenários faltantes, como descrito anteriormente neste post.

Eu sei que todos nós QAs adoramos “quebrar coisas”, mas temos que pensar em quebrar o sistema antes dele poder ser quebrado. Muitas certificações exploram o conceito de Myers sobre o defeito ser mais caro quanto mais longe ele for descoberto, por isso temos que encontrá-lo antes que ele exista. Assim ele será mais barato e entregamos software rodando mais rápido para o cliente avaliar.

Uma frase de impacto é: “Nunca temos tempo para fazer o certo, mas sempre arrumamos tempo para refazer algo errado”. Em agile isso não deve acontecer. Temos que escrever testes antes, os developers também, os usuários devem nos responder rápido se mudarem de ideia sobre alguma coisa e devemos deixar que as máquinas executem todo o trabalho repetitivo por nós.

Mais sobre o assunto:

http://martinfowler.com/articles/continuousIntegration.html

http://www.youtube.com/watch?v=X1jWe5rOu3g

Testes exploratórios Rocks!

“Bad exploratory testers spend little time preparing and are only seeking bugs as their primary outcome. Good exploratory testers apply structure to their work and use tools to collect data so that their testing sessions are more meaningful than just bug finding exercises. Exploratory testing should be connected to the rest of the testing process and not just a late cycle bug finding activity.” – James Whittaker

Pair programming by Wikipedia

Testes exploratórios são parte da vida de um QA, independente de senioridade ou de ferramental. A quem acredite que os QAs ou Agile Testers não executam testes manuais, quando na verdade todas as histórias são testadas de forma manual em um dado momento. Em agile, assim como não existe espaço para burocracia, não existe espaço para hierarquias em um projeto. Ninguém é o arquiteto, ninguém é o tester, todos são QAs e estão habilitados para trabalhar com tudo o que o projeto precisar. Caso um dos QAs do projeto não se sinta a vontade para trabalhar com determinada tecnica, tecnologia, ferramenta ou o que quer que seja, existe sempre a opção de trabalhar em par. E o QA em par não é somente para esses momentos, mas sempre que um QA achar necessário, e ele pode parear com outro QA, com Devs, BAs ou com o PO.

Normalmente o teste exploratório vem após o desenolvimento, que vem após o entendimento e automação de cenários de teste e critérios de aceite do QA, logo o QA já possui seus principais cenários testados e usa o teste exploratório para tentar encontrar novos cenários que não havia imaginado sem um software rodando. Se um cenário desses for encontrado, o QA pode facilmente adicionar um novo cenário de teste automatizado, se for encontrado um bug adicionamos testes para cobrí-lo também, como será visto logo em seguida.

Também podem ser usadas técnicas para melhorar a produtividade como Session-Based Testing, onde são estipulados objetivos e uma timebox restrita para que esses objetivos sejam alcançados. O uso de session-based testing com elaboração dos objetivos através de mapas mentais pode ser uma ótima ideia para funcionalidades complexas, onde cada objetivo identificado no mapa mental terá a sua própria sessão. Em posts futuros vou falar sobre ambos assuntos.

Saiba mais sobre o assunto:

http://en.wikipedia.org/wiki/Exploratory_testing
http://www.amazon.com/Exploratory-Software-Testing-Tricks-Techniques/dp/0321636414
http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
http://en.wikipedia.org/wiki/Session-based_testing

Encontrei um bug!

“When a bug is found tests are created to guard against it coming back.” – extremeprogramming.org/rules/bugs.html

RSpec report by http://simplesideias.com.br/

Quando encontramos um bug, trabalhamos de forma a evitá-lo para sempre. Ao invés do tradicional formulário de cadastro de bugs usamos um teste atomatizado para descrevê-lo e rastreá-lo.

Sei que muitos leitores tradicionalistas pensariam “administrar muitos bugs com essa abordagem é impossível!”. Sim, concordo, mas as atividades colabrativas vistas anteriormente como o desenvolvimento por pares, os testes automatizados antes do desenvolvimento, testes guiados por comportamento e integração conínua criam uma redução muito grande no número de defeitos após a codificação. Nesse cenário, encontrar um defeito e corrigí-lo também se torna uma atividade muito mais rápida. Outro fator importante para reduzir o tempo de testes e aumentar o número de testes automatizados é o fato de gastarmos menos tempo com testes de regressão, uma vez que esses são realizados de forma automática a cada novo commit.

Algumas linhas do agile dizem que todo o retrabalho, o que inclui bug fix, deve ser postecipado para as proximas iterações. Particularmente eu não concordo. Acredito que dependendo do custo de corrigir e retestar isso agora, devemos fazê-lo. Para isso usamos o conceito de fix and forget it citado anteriormente, ou seja, corrija e esqueça. Ao invés de escrever o defeito em uma ferramenta de bug tracking, escreva um teste automatizado, simples, que reproduza o defeito e tenha como resultado esperado o comportamento real. O developer então corrige o problema e mesmo no futuro, se esse problema voltar a aparecer após alguma mudança dos desenvolvedores, esse problema será identificado pelo teste automatizado e não chegará ao QA.

Mais sobre o assunto:

http://www.extremeprogramming.org/rules/bugs.html

Show case ou Sprint review

“I see that there are two reasons for the sprint review.  Firstly it offers the attendees the chance to understand and see for themselves the progress that has been made on the product. (. . .) Secondly the sprint review offers the team a chance to bring closure to their work for the  duration of the sprint. (. . .)” – The Agile Leader

Agile Showcase by MSDN

Esse é um momento muito importante para toda a equipe, os resultados serão finalmente vistos por todos os interessados. O nosso objetivo é que nesse momento tenhamos um software funcional para as features que implementados na iteração, livre de bugs e pronto (ou quase pronto) para produção. Nessa reunião que deve ser curta e dispensar formalidades em excesso, o PO e o BA trabalham juntos avaliando o sistema e executando os ACs (Critérios de Aceite). Quando todos os critérios são aceitos a funcionalidade é declarada entregue.

Claro que novos defeitos podem ser encontrados, novas mudanças podem ser solicitados mesmo depois da aprovação da história e isso é esperado (mais mudanças do que defeitos). Esses itens são tratados de forma evolutiva no projeto. São priorizados do ponto de vista do PO e sua complexidade é elegida do ponto de vista do time, podendo agora ser incluída em uma nova iteração para ser implementado.

Mais sobre o assunto:

http://www.mountaingoatsoftware.com/scrum/sprint-review-meeting
http://zhangyue.info/2011/06/tips-for-showcase-in-agile/
http://www.theagileleader.com/2011/11/scrum-ceremonies-sprint-review/

Retrospective ou Sprint retrospective

“Retrospectives play a crucial role in software teams. They are the time specifically put aside to reflect on how the team is performing and what can be done to improve.” – agileretrospectivewiki.org

Agile Retrospective by Fábio Pereira

A retrospectiva é conhecida por tradicionalistas como Lições Aprendidas, mas existem algumas diferenças que tornam a restrospectiva uma das chaves do sucesso para um projeto ágil de software. Em primeiro lugar a periodicidade. Enquanto tradidional costuma fazer uma Lições Aprendidas para cada projeto ou fase do projeto (que pode durar meses), em agile é feita uma retrospectiva para cada iteração. Isso faz com que os benefícios dessa prática sejam usados durante o projeto para alinhá-lo.

Outra diferença é a forma como a reunião é desempenhada. Enquantro tradicionalistas possuem templates e documentos elaborados como atas e formulários, em times ágeis quase sempre usamos didáticas para discutir os tópicos da iteração. Por ser menos formal, e por termos um time que discute bloqueios e tarefas diariamente como visto na reunião diária mais acima, acabamos interagindo mais e sendo mais sinceros nessa reunião. É importante que todos expressamos o que achamos da iteração e os problemas dela. Essa reunião não é um lugar para falarmos que não gostamos de alguém, mas que alguma coisa pode ser melhor do que é atualmente.

Aqui também revisamos o nosso desempenho na iteração, os pontos mais positivos e mais negativos, discutimos e elaboramos um conjunto de ações para potencialisar esses pontos positivos e outros para mitigar/contornar esses pontos negatívos.

Mais sobre o assunto:

http://agileretrospectivewiki.org/
http://pragprog.com/book/dlret/agile-retrospectives
http://fabiopereira.me/blog/2008/11/23/goal-driven-retrospective/

Vivendo como um agile tester

Sempre que alguém te falar que agile é caótico, desorganizado ou sem documentação, lembre-se que tudo isso visto acima acontece em duas semanas (com exceção da inception). Ao final o cliente tem software funcionando, que é a principal métrica que podemos usar para medir o avanço de um projeto.

Aqui eu resumi muito do que é a uma iteração na vida de um agile tester, porque todos os dias as histórias podem mudar, todos os dias um novo tipo de teste pode ser requerido, todos os dias uma novidade pode aparecer. Nenhum dia é como o outro e nenhuma iteração é como a outra. Todos os dias você aprende uma coisa nova e todos os dias você se vê forçado a resolver os mais diferentes problemas.

Caso queira ouvir um pod cast sobre o assunto, recomendo o bate papo entre a Tatiane Fukuda e o Elias Nogueira no post “Podcast Episódio 2: Entrevista com Tatiane Fukuda (Yahoo!)“).

Para os futuros posts, vamos discutir cada um dos tópicos acima com mais detalhes. Enviem sugestões e dúvidas!

Para finalizar esse primeiro posto sobre o a vida de um agile testers, fica mais uma frase de reflexão:

“Desenvolvimento de software não é uma atividade altamente previsível nem repetitiva, mas sim uma atividade empírica. Agile enfatiza o controle do processo empírico.” – Paulo Caroli

Bons testes :)

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

7 thoughts on “Vida de um Agile Tester – Parte I

  1. Camilo,

    Realmente ficou bem completo!!! Está ficando bom nisso, hein!!! Parabêns!!!

    Abraços,

    Wagner Ruiz

  2. Excelente post, como tantos outros seus Camilo. Uma sugestão seria para os proximos posts do tema é se voce poderia colocar exemplos (pode ser fictcios), dos topico citados, explicando as situações e como foi feita para resolve-las. Com certeza iria enriquecer ainda mais o conteudo.
    Abraços

    Rogério

  3. Cada vez melhores os seus posts.
    As indicações de mais informações sobre os assuntos também considero muito legais!
    E a visão de agile, apesar de distante da minha realidade, é muito atrativa!!
    ;)

  4. Muito bom o texto, já tive experiências em projetos ágeis e tudo que você escreveu descreve exatamente como é o funcionamento das atividades (principalmente de testes é claro!) e qual deve ser o comportamento dos testadores/analistas.

    Sou um leitor recente do blog e já o parabenizo pelas publicações.
    Abraço!

  5. Quando falas em testes automatizados sendo desenvolvidos antes da aplicação, refere-se aos testes unitários? Se não, qual ferramentas costuma usar? Já que, normalmente, as ferramentas de automação de testes pra UI baseiam-se em record/play sendo, portanto, necessário que haja algo já implementado…

Leave a Reply