Os testes do software estão diretamente ligados à qualidade. Contudo, não é possível utilizar uma fórmula para medir essa qualidade.
Para alguns, a qualidade pode ser determinada pela quantidade de código testada, enquanto outros afirmam que a ausência de bugs é suficiente para avaliar a qualidade do software.
Entender a importância dos testes dentro do desenvolvimento de um produto é fundamental para compreendermos o porquê certas linguagens/ferramentas/frameworks afetam a qualidade final.
A metodologia ágil também interfere na qualidade
Logo, podemos inferir que a escolha da metodologia errada de projetos pode significar o insucesso do produto.
A Metodologia Scrum, Kanban, Planning Poker, Sprint, Backlog e burndown são termos que fazem parte da rotina da grande maioria dos desenvolvedores, pelo menos na teoria.
Mas seriam esses conceitos aplicados apenas no desenvolvimento? Ou será possível aplicar o framework Scrum em testes de software?
Como QA, essas foram as principais perguntas que rondavam minha rotina nos primeiros meses aplicando a metodologia, isto é, dizer que usa scrum, que é agile, é fácil, o problema se encontra quando avaliamos o dia a dia.
>>Leitura Recomendada:
A junção do Behavior Driven Development e metodologia ágil
Teste de Software: Scrum na linha de frente
Em Scrum, quem é o responsável pelo teste de software?
Nesse sentido, o principal ponto de colisão, no meu caso, foi a desconstrução dos rótulos ‘QA’ e ‘Dev’. Comecei a trabalhar em um time Scrum e, dentro de um time scrum, todos são responsáveis por tudo, ou seja, os papéis são compartilhados.
Todos são testers e todos são desenvolvedores.
Dessa forma, a responsabilidade por garantir a qualidade é de todo o time e não apenas do QA.
Esse estranhamento ocorreu, acredito, por eu estar imerso em uma cultura completamente tradicional, onde os papéis eram bem segmentados, cada time era responsável, ou por desenvolver, ou por testar, ou qualquer outra atividade que fosse necessária para a entrega.
Logo, as responsabilidade eram dividas e aí é que os conflitos entre os times apareciam. Afinal, de quem era a culpa pelo bug que o cliente encontrou?
Portanto, quando fui informado que seria um Desenvolvedor (até então não trabalhávamos com automatização) e que a equipe não teria um responsável por testes, fiquei receoso.
Para minha surpresa a prática se mostrou muito mais eficiente que o modelo antigo, já que, não tendo um indivíduo encarregado pela qualidade, todos abraçaram a causa e se tornaram defensores de um produto coberto, o máximo possível, por testes.
>>Leitura Recomendada:
Scrum Master: quem é e o que faz?
O que vamos testar no software?
Após entendermos isso, começamos a discutir sobre o que iríamos testar.
Em oposição à metodologia tradicional, onde as especificações e requisitos dirigem os testes, no Scrum os testes são aplicados com maior ênfase nas partes que mais geram valor para o produto.
Pensando nisso, o time precisou ser muito mais crítico, visto que os testes não são desenvolvidos de maneira desordenada, mas focando no que é importante.
Desse modo, tivemos que difundir o conhecimento sobre o produto entre todos, para que o time tivesse condições de avaliar os principais pontos de impacto no software.
Portanto, ao nos comunicarmos, tornamos todas as etapas, inclusive os testes, transparentes.
No fim das contas, o ambiente que era, dependendo da situação, desconfortável devido as intrigas entre os times (Testadores vs. Desenvolvedores).
Com Scrum, tudo passou a ser colaborativo, ou seja, todos sentiam-se confortáveis para sugerir uns aos outros o que testar e de que forma testar.
>>Leitura recomendada:
Como melhorar a comunicação em times de TI?
ATENÇÃO: Não teste o produto inteiro!
“Não pense em todo o produto!” Mas o que isso quer dizer? Como isso vai me ajudar a aplicar Scrum nos testes, já que TODO o produto precisa ser testado? Vamos por partes.
Ao segmentar todo o projeto em pequenas features/tasks, a compreensão sobre a utilidade e prioridade dos itens aumenta, visto que a divisão em pequenos pedaços nos instiga a criticar sobre a contribuição deles para o todo.
Nesse sentido, o desenvolvimento e os testes, são direcionado para aquilo que realmente agrega valor.
Quando dividimos o que precisa ser testado em pequenas parcelas, conseguimos enxergar o quanto aquilo está somando ao produto.
Assim, nossa decisão sobre o que deve ser priorizado torna-se mais assertiva, já que temos a ciência de que aquilo que foi/será testado contribui para o projeto.
>>Leitura Recomendada:
Técnicas de caixa preta e branca para teste de software
O tempo é finito os testes de software, não
O fato de o Scrum ser uma contraproposta à burocracia, não significa que deixamos de ter prazos.
As entregas são acordadas entre as partes interessadas e o esforço é aplicado naquilo que traz valor ao produto.
Logo, entender que temos um período para realizar essas entregas e, que ele uma hora vai acabar, nos obriga a priorizar as atividade.
Nesse sentido, o que muda em relação ao modelo tradicional é essa consciência em aplicar nosso esforço em algo que realmente não é trivial.
Afinal, não adianta coisa alguma termos o produto mais bonito do mercado se ele não for performático ou não tiver as funcionalidades básicas de inclusão, visualização, alteração e exclusão de entidades fundamentais, se for o caso.
O scrum nos dá poder de decisão ao testar softwares
Outro ponto importante é que o time deve ser independente e autônomo, ou seja, quem toma as decisões sobre o que deve ser priorizado é o próprio time.
Isso é possível porque, diferente da abordagem tradicional, a equipe Scrum é multidisciplinar, contendo, dessa forma, todas (ou quase todas) as habilidades necessárias para realizar a entrega ao P.O. (Product Owner ou Dono do Produto).
Afinal, como aplicar scrum no projeto de testes?
Simples, entenda que não existem mais rótulos, todos são responsáveis por tudo. A comunicação entre a equipe torna-se um dos fatores mais importantes — se não o mais importante — pois gera transparência.
Faça com que todo o seu time saiba de todos objetivos para que foquem naquilo que é realmente importante.
Assim, não teste o produto inteiro, divida as atividades de testes em pequenas partes, visando o todo.
Lembre-se, o tempo é finito, os testes não, ou seja, aplique-os entendendo que há um prazo que precisa ser respeitado e precisamos entregar algo que agregue valor, sem contar que teremos outras oportunidades para cobrir aquilo que foi deixado de fora.
Por fim, o time Scrum inteiro precisa ter o poder da decisão. Todas as pessoas decidem o que pode e deve ser testado (lembra que toda a equipe deve ter basicamente as mesmas skills?).
Dessa forma, todos sabem o que vai gerar mais valor para o projeto, ou, no caso dos testes, o que pode provocar maior risco.
É isso! Espero que com essas pequenas dicas você possa aplicar o scrum no seu projeto de testes.
