O seu direito acaba onde começa o do outro.

Continuando com a série de artigos que não vemos muito por ai em blogs, comunidades de testes e derivados, venho falar um pouco sobre TDD e indo além, como nós da área de QA podemos adotar essa técnica (vou chamar assim) juntamente com nosso time de desenvolvimento e colher ótimos frutos.

TDD nada mais é que uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições…

Mas pera ai? Uma técnica de desenvolvimento … Mas sou QA.

Ta aí o X da questão, TDD em sua tradução é Desenvolvimento Orientado a Testes e se o desenvolvimento é orientado a testes, precisa-se de uma pessoa de testes, um analista de testes, um analista de qualidade, alguém que pense fora da caixa, é nessa hora que entramos, porque somos de testes. Mas antes disso precisamos tirar da nossa cabeça a teoria da conspiração: “área de QA vai acabar atuando com TDD porque o DEV vai fazer “nosso” trabalho”. Dentro do contexto ágil, todo time é responsável pela qualidade da entrega, todos estimam, todos se comprometem, todos entregam, logo, todos garantem a qualidade, conceito de time é isso ai. Lembre-se, Scrum é o momento do jogo de Rugby quando a equipe está toda unida com um único propósito em uma formação específica onde a participação de todos é essencial, a falta de comprometimento de um membro pode fazer a formação cair, então a união e o foco no objetivo (mover a bola em direção ao gol) é primordial.

Depois que zerar os pensamentos negativos, vamos a prática da técnica (veja, não sou o dono da verdade, mas é uma forma que eu acredito ser legal para se trabalhar). Vou utilizar o framework ágil Scrum para continuar o pensamento. No scrum um time é composto pelas seguintes frentes: Negocios (PO + Produtos), Desenvolvimento (DEVs e QAs). Nessa hora alguns se perguntam porque QA está no contexto do desenvolvimento. Eu vejo de forma simples, dentro de um contexto ágil não existe (ou não deveria existir) uma fase apenas para testes, tudo deveria estar dentro do desenvolvimento do produto (desenvolvimento e testes). Se olharmos o fluxo de trabalho (ciclo de vida) do scrum teremos:


**
Backlog do produto:** Lista de desejos do PO e área de Produtos.
**Backlog do sprint: **Geralemente definido em uma reunião de planejamento (planning). O objetivo principal é de entregar, na prioridade do PO o que mais tem de valor para o cliente. Algumas equipes utilizam essa cerimônia para definição de capacity, tenho algumas opiniões que não entram nesse artigo contrárias a definição de capacity. Por hora é só rs.
Dia: Reunião diária (daily)
**Sprint: **2 a 4 semanas (não é lei e não está escrito em pedra) e dentro desse período temos outras atividades: desenvolvimento + testes + aceite do PO + deploy.
Entrega: Real valor entregue.

Demais cerimônias (Grooming, Pré Planning, etc) são inseridas de acordo com o contexto de cada time, lembrando que equipes ágeis tem o poder de serem auto-gerenciáveis e com isso, inserção ou não de mais ou menos cerimônias cabe a cada time decidir.

Depois de estarmos por dentro do scrum, vamos voltar ao TDD e pra isso vou listar algumas perguntas que me faziam quando defendia a idéia:

Como QA, onde meu trabalho efetivamente começa???
Antes do Planning:

Assim como em métodos tradicionais, onde para se ter uma evolução constante do produto, o QA deve participar desde o início. No ágil, o início pode ser qualquer momento em que o QA se aproximar do PO. Ágil é aproximação do time como um todo, comunicação, feedback contínuo. Aproximar do PO é importante porque “entraremos em sua mente” para saber o que ele está pensando para ser colocado no próximo sprint e com isso já posso antever cenários de testes e escrevê-los no método BDD. A escrita em BDD é baseada na seguinte forma:

**Cenário TDD pode ser uma prática legal

Dado que fale com o PO sobre as futuras histórias
Quando entendo o contexto
Então escrevo meus testes nesse padrão

**

Durante o Planning:

Dado que os testes estejam planejados, no planning podemos apresentar aos desenvolvedores o que pensamos. É em cima dos testes que os devs irão começar o desenvolvimento daquela feature.
**
Durante o sprint: **

Auxiliar o desenvolvimento no entendimento dos testes e/ou no desenvolvimento, nesse caso, pode-se usar cucumber (mas isso é outra história), executar testes que não são possíveis na automação (notificações por email, layout, etc.)

A idéia principal na adoção da técnica é que assim antecipamos possíveis problemas. Quem nunca pegou erro no primeiro teste executado? Mas o engraçado é que nunca nos perguntamos como poderíamos ter evitado esse erro porque ainda temos a mania de nos colocar acima do bem e do mal e falar que a culpa é do dev que fez errado ou do PO que escreveu errado ou do Papa, mas pensar “puts, poderia ter avisado sobre esse efeito colateral antes” é algo meio difícil em nosso meio.

E no fim, claro, acompanhar o deploy e realizar um smoke test em produção se possível =).

Caso tenha algum dev que venha a ler, também a forma de como entrará no contexto irá mudar. Antes de mais nada, o desenvolvedor também tem que tirar a idéia de segregar pessoas (dev é dev e qa é qa), temos que pensar como time SEMPRE, acabar com a antiga picuinha e o principal, aceitar que o tester fale com ele.

Durante o Planning:

Devs em grande parte do tempo do sprint está discutindo soluções, codando e sendo o mais efetivo possível, nesse caso “antes do planning não tem muito sentido de definir um papel para ele”. Agora durante o planning, o chapéu de “apenas” desenvolvedor deverá ser retirado, porque nesse momento, dev e qa vão, além de pontuar, olhar os CTs juntos daquela feature. Como duas cabeças funcionam melhor que apenas uma, de repente há algum cenário que o dev previu que o QA não e vice versa. Pontua e vai pro abraço.

PS: Em times que a cerimônia Grooming ou Pré-Planning é realizada, essa aproximação é mais eficaz, pois é justamente nessa reunião que os principais pontos da feature são discutidos. Porém, como todo dia é auto gerenciável, nada impede de qualquer dia o dev e o qa juntos sentarem em uma sala por alguns minutos para ser apresentado o plano de testes de uma futura feature.

Durante o Sprint:

Além de desenvolver, tirar dúvidas com relação a algum teste escrito pelo QA, desenvolver os testes e no fim da feature, executar os testes ao lado do QA para ambos sentirem confiança em tudo que está sendo feito antes de ir para produção.

O papel do PO não muda muito o contexto do time na aplicação da técnica, no fim da iteração, o PO irá executar e dar o aceite na história antes de ir pra produção.

Concluindo, aplicar o TDD não quer dizer que chegaremos ao bug zero, mas dependendo da maturidade do time, reduziremos a quantidade de bugs pegos no decorrer do sprint, a aproximação e feedback rápido de fato irão funcionar e a cada iteração, o time vai ser mais produtivo e feliz.

TDD, assim como qualquer prática, não é a “bala de prata”, tudo depende do quão maduro é o time. Em contexto onde temos mais de um time de desenvolvimento, não é garantia que a prática funcione com todos eles. Importante ressaltar que o engessamento no processo ágil não é saudável e faz com que algumas técnicas falhem e isso tem se tornado comum em muitas empresas. Atuei em empresa onde haviam times atuando de forma waterfall, scrum, xp, lean, kanban e com isso defendo que antes de qualquer framework, o importante é saber ser “ágil” e para isso, não custa cada pessoa ter o manifesto ágil impresso em sua mesa =). Segue o endereço

Como eu gosto de falar,** pensar ágil é fazer ágil, é entregar ágil**. E se nada der certo da primeira vez, o esquema é dar a segunda e a terceira chance.!

@thiagompereira said:

Ta aí o X da questão, TDD em sua tradução é Desenvolvimento Orientado a Testes e se o desenvolvimento é orientado a testes, precisa-se de uma pessoa de testes…

Acredito que você se equivocou nessa sentença, assim como muitos desenvolvedores se equivocaram na época em que o TDD era novidade (aproximadamente 12 anos atrás) TDD tem muito mais haver com especificações de comportamento do que com testes e após chegar a essa conclusão Dave Astels, juntamente com Dan North, decidiram que uma mudança de terminologia era necessária e assim se deu a evolução do TDD para o BDD substituindo-se a palavra “Test” e toda sua conotação negativa por Behavior. Aqui está o post original de Dave Astels de 2005 falando sobre isso.

@thiagompereira said:

Mas antes disso precisamos tirar da nossa cabeça a teoria da conspiração: "área de QA vai acabar atuando com TDD porque o DEV vai fazer “nosso” trabalho.

Essa teoria não faz o menor sentido, porque a responsabilidade de entregar uma funcionalidade que faz o que foi especificado é o mínimo que o desenvolvedor deve fazer. Se algum Q.A. reza para que os desenvolvedores não aprendam a desenvolver utilizando TDD para entregar código de alta qualidade com medo de perderem o emprego eu rezo para que esses profissionais dinossauros sejam eliminados da área de software o quanto antes.

Outro feedback que tenho é que você misturou muitos temas em um só post, Scrum, TDD, BDD e onde fica o Q.A. no meio disso tudo. Behavior Driven Development por si só é uma metodologia ágil completa de segunda geração, Scrum é uma metodologia ágil de primeira geração, TDD é uma versão inicial do BDD que por sua vez surgiu de práticas do XP.

Concordo com o tema central acredito que o Q.A. nunca será dispensado mesmo em um time que utiliza BDD exatamente conforme descrito no livro, pelo contrário, o Q.A. nesse contexto ficará muito mais livre para explorar outros aspectos da aplicação muito além de funcionalidades básicas, ele pode explorar as questões de performance, segurança e experiência de usuário por exemplo.

@Juraci-Vieira Valeu pelo feedback =).

Talvez não tenha sido muito claro. O que eu defendo é que a utilização do TDD e indo além, evoluindo para o ATDD abre espaço para a aproximação de devs e qas.
Sobre o segundo ponto, infelizmente existem pessoas que pensam que vão perder seus empregos quando devs passam a desenvolver testes de unidade, funcionais, etc.
Tirando a utilização de muitos termos, no final o que eu quis pregar é sobre métodos ágeis independente do framework e que a figura do QA será sempre bem explorada e deverá ser mais explorada daqui pra frente.

Valeu pelo feedback.

Só me ficou uma dúvida… Escrever nesse padrão será útil ao DEV independente de qual o método de automtização que ele usa?
Na empresa que trabalho escrevo geralmente uma linha que faça ficar claro o que é desejado ser testado, para que não seja gasto muito tempo escrevendo os cenários. Valeria a pena então mudar isso?

@Nhaiara sim, a forma indepente, porque ele vai estar automatizando o cenário em si, e isso vai de acordo com que e como escrevemos, se ele utiliza outras formas de automação, ele consegue se mapear por esse cenário. Caso ele utilize cucumber + capybara/rspec/jbhave/etc será muito mais fácil de interpretar.

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.