Concrete Logo
Hamburger button

O QA em um time ágil

  • Blog
  • 10 de Junho de 2016
Share

“Indivíduos e interações mais que processos e ferramentas” (Manifesto Ágil)

Como é possível a inserção de qualidade de software no contexto ágil, sem que o processo fique engessado? Ou melhor, como validar se é possível realizar a inserção de qualidade sem que isso vire de fato um processo?

Primeiramente, temos que responder a essa pergunta de forma categórica: qualidade de software não pode ser abordada como uma etapa do contexto ágil, mas sim como uma prática. Assim, neste post vamos tentar entender como a prática de QA (do inglês “Quality Assurance” – Garantia de Qualidade) entra no ambiente ágil por meio de alguns pontos-chave.

Quem é o QA?

Um time ágil, de acordo com a abordagem Scrum, é formado por um P.O., um Scrum  Master e o Time de Desenvolvimento. “O QA” é o integrante do time de desenvolvimento com mais habilidades para executar o desenvolvimento dos testes. Entretanto, como os times Scrum são multidisciplinares, o time todo deve se encarregar de executar as práticas de QA, e “o QA” seria um “disseminador” ou “evangelizador” da cultura de qualidade. Quando eu digo práticas me refiro à estratégia de abordagem de testes. Seja ela usando especificação por exemplo, testes manuais, testes de instrumentação, teste exploratórios, etc. Parafraseando Bambam: “É isso que a gente quer, é isso que a gente vai buscar!”

Resumindo, o ideal é que o integrante do time de desenvolvimento com mais habilidades específicas de QA seja a pessoa responsável por disseminar essas práticas com o time. Elas promovem, com o auxílio de metodologias de testes e ferramentas, o desenvolvimento de um produto que atenda às especificações. Ou seja, o desenvolvimento dos testes é feito de forma colaborativa. Sendo assim, não existe “o QA”. Uma pessoa não é a garantia de qualidade nem as práticas aplicadas ao software em desenvolvimento, mas é um conhecedor e o responsável por guiar o time nesse sentido. Assim, pense muito bem ao se dirigir a uma pessoa com essa alcunha. Existem analistas, engenheiros e uma série de nomes relacionados a QA, escolha um que lhe agrade e siga adiante. 😉

QA antes, durante e depois?

Sim! A inspiração para essa abordagem vem da indústria automobilística. Durante bastante tempo, o processo de QA (sim, processo, porque neste contexto se aplica) era executado após a fabricação do automóvel. Ou seja, a hora da execução dos testes só chegava após um longo processo de idealização e fabricação.

image00

Porém, esse era um momento bem crítico. Imagine o que você, um engenheiro automobilístico que ajudou na idealização e fabricação do carro/moto/avião/Millenium Falcon/Optimus Prime, estaria sentindo nesse momento. Medo, apreensão, taquicardia? Com certeza sim. Deve ser bem ruim um produto idealizado durante tanto tempo, construído com tanto amor e carinho, quebrar de forma inesperada e precisar ser totalmente reconstruído. É claro que essa estratégia é raramente utilizada no contexto automobilístico hoje em dia.

image03

E claro, a essa altura você deve ter feito a analogia. Esse cenário se aplica ao contexto de engenharia de software. Pense comigo: qual o principal problema dessa abordagem? O tempo. Daí você pode aplicar aquela velha máxima de “tempo é dinheiro”. Ou seja, especificar, prototipar, construir e testar novamente… Com a união desses quatro poderes temos a criação do nosso nemesis, o custo alto de retrabalho. Imagine o rosto de felicidade do cliente em saber que o software dele irá atrasar devido a uma falha de especificação que gerou um erro só visto no momento dos testes, meses depois?

2

Então vamos combinar uma coisa? Vamos jurar solenemente que testaremos os softwares que implementamos antes, durante e depoisLevando em consideração uma abordagem de testes usando Especificação por Exemplo (o Oscar Tanner fez um post excelente sobre o assunto, acesse aqui) e documentação viva (saiba mais no post da Elessandra Estevão), além de um framework ágil, mais especificamente o Scrum, é possível realizar as práticas de QA:

Antes – No início de um sprint, especificando os cenários que serão usados para validar o artefato de software que será desenvolvido. Essa especificação não é feita apenas por ele, mas de forma colaborativa. Ou seja, no momento de sua criação, para validar que de fato os testes gerem uma aceitação sobre a funcionalidade, é necessário que haja um envolvimento de todo o time. Se não for possível, que participem pelo menos um desenvolvedor, uma pessoa com conhecimento grande sobre o negócio e uma pessoa com conhecimento mais aprofundado sobre o desenvolvimento dos testes, o que pode ser comparado à técnica dos três amigos (leia mais aqui). O objetivo principal é que a criação das especificações seja feita de forma colaborativa, gerando conhecimento compartilhado sobre os requerimentos e os testes. 

Durante – É possível uma pré-implementação da automação da especificação que considere os elementos que serão utilizados para a interação no momento da execução. Também é possível uma validação prévia do que está sendo desenvolvido. Essa validação pode ser feita com a execução dos cenários que já podem ser validados, caso uma funcionalidade já possa ser testada, validação de IDs e asserções a serem feitas.

Depois – Na fase final do Sprint já é possível validar o artefato de software desenvolvido. A especificação é executada (Sim, olha que loucura! Não deixe de ver o post do Oscar) e os cenários relacionados às funcionalidades são validados.

Ou seja, caso exista algum erro pego no momento da execução da especificação automatizada, como um sprint tem tempo de iteração que varia de uma semana a um mês, dependendo do contexto do software desenvolvido, o custo de retrabalho é bastante reduzido. Lembra a analogia que eu fiz sobre o tempo e o dinheiro? Então, o tempo perdido é menor e a insatisfação do cliente também.

Desafios

Lembram o que eu falei sobre um time multidisciplinar conseguir executar as práticas de QA de forma descentralizada lá no início? Então, quando parafraseei o Bambam na sua busca pelo trapézio descendente eu quis deixar claro que essa abordagem é a ideal, porém difícil de ser implementada. Ou seja, a vida não é exatamente o Toddynho gelado que tomamos de manhã (olha aí, você deve estar desmotivado já =/). Ela é difícil, temos desafios e precisamos enfrentá-los, pois como dizia Rocky Balboa: “ninguém vai bater mais forte do que a vida. Não importa como você vai bater, mas sim o quanto aguenta apanhar e continuar lutando; e o quanto pode suportar e seguir em frente. É assim que se ganha” (Olha aí, já está motivado de novo. Vamos adiante \o/).

Para chegar a esse nível de maturidade ágil é necessário passar pela primeira abordagem, na qual existe um integrante do time responsável por executar as práticas de QA. Ou seja, em tese, as práticas de criar a especificação por exemplo estão centralizadas nele. Isso é um problema, pois o artefato de software é desenvolvido pelo time de desenvolvimento como um todo.

Como a implementação do software e a especificação compõem o desenvolvimento do artefato, o time é formado por integrantes que tenham todos os quesitos técnicos necessários para realizá-lo, ou seja, o time, unido, somando os conhecimentos de cada um de seus integrantes, deve ser capaz de transformar uma história em uma fatia de software entregável e com valor . Você pode perceber que não está escrito em lugar nenhum que o teste tem que ser escrito pelo integrante do time com skills de QA e o software tem que ser desenvolvido pelos desenvolvedores de fato. O time deve estar apto a executar todas as tarefas necessárias para o desenvolvimento do software sem que o mesmo seja, necessariamente, desenvolvido em pólos. Ou seja, os integrantes do time podem ter um perfil de habilidades em T, como mostra a figura abaixo. Podem ter mais profundidade técnica em alguma habilidade e um mínimo de conhecimento (que pode evoluir aos poucos) nas outras.

image05Alguns desenvolvedores/clientes olham os testes funcionais como algo complementar ao software a ser desenvolvido e não como parte do software, pois o que importa é o software funcionando e convertendo seu uso em dinheiro. Dessa forma, é possível que em alguns casos um software seja entregue sem que suas funcionalidades sejam totalmente validadas. O problema é: como é possível acertar o alvo (usuários), com um tiro no escuro? Pois é. 

¯\_()_/¯

Assim, o profissional focado em qualidade tem que lutar para mudar a visão sobre ele mesmo, pois em alguns casos é visto como portador de más notícias, como quando só chega com bugs…

image02… e a visão dos desenvolvedores sobre suas implementações, pois em alguns casos assumem a posição de Chuck Norris.

image04Logicamente, para mudar todos esses problemas e resistências à qualidade, é necessário que o profissional seja um evangelista das práticas de QA, difundindo a cultura e desmistificando as ferramentas utilizadas. Se todos se empenharem a implementar a qualidade de fato, teremos softwares com mais qualidade e confiabilidade nos deploys para produção.

picasion.com_95099c21430363efd018a8276be1c47e

Sintonia de um time ágil que implementa as práticas de QA de forma bem sucedida.

Concorda, discorda, tem algo a acrescentar ou ficou alguma dúvida? Deixe seu comentário abaixo. Até a próxima!

Trabalha com QA e quer fazer parte de um time ágil? Acesse aqui.