QA > Teste – Parte 1

Você sabia que as tarefas de uma pessoa de QA em uma equipe de desenvolvimento não são apenas os testes do sistema? Você já parou pra pensar em quais são realmente as funções e responsabilidades de um QA? QA é muito maior que testes e é sobre isso que vamos falar aqui!

Antes de começarmos a falar sobre a razão de QA ser maior que testes, precisamos entender como as coisas funcionavam lá no passado e para isso, vamos entender um pouco sobre o modelo usado que era o Waterfall. Esse modelo tinha os processos quebrados em etapas e uma etapa só se iniciava quando outra acabava. Dentro dessas etapas, existia a de testes que só acontecia antes da entrega lá no final do processo. 

Nesse modelo de desenvolvimento, existia o papel do QA = Quality Assurance que atuava nessa etapa de Testes para “garantir” que o que havia sido desenvolvido era o que havia sido realmente requisitado. Basicamente, existia uma conversa com o cliente no começo do projeto na etapa de Requisitos, onde era definido o que cliente queria e só lá na etapa de testes que era verificado se o sistema estava funcionando como havia sido solicitado. 

O problema com essa metodologia era que, com o passar do tempo do desenvolvimento, as mudanças iam ficando mais caras, até porque, uma mudança solicitada na fase de Requisitos não causaria tanto “trabalho” a ser realizada quanto uma mudança solicitada na fase de Testes, por exemplo. 

Metodologias ágeis

Foi então que surgiram os modelos ágeis. A ideia do manifesto ágil era ter ciclos curtos de iteração usando metodologias como Scrum, Kanban, etc. Mas nesses métodos de desenvolvimento não existe um papel específico do Quality Assurance como acontecia no Waterfall e por quê? Quando falamos de times ágeis, falamos de times multidisciplinares autogerenciáveis, onde todos passam a ser responsáveis pela qualidade do que está sendo feito, isso deixa de ser uma responsabilidade exclusiva do QA. Além disso, a ideia é também ter testes automatizados, independente da forma como eles são aplicados (Test after all, TDD, etc). 

Nesse modelo, o QA = Quality Assurance passa a ser o Quality Analyst, ou seja, o analista de qualidade do projeto. Essa pessoa deixa de ser quem ‘garante a qualidade’ e passa a ser o responsável por analisá-la no processo como um todo e com isso, apontar melhorias.

Para isso, o Quality Analyst precisa pensar sempre em como aumentar a qualidade do sistema e é nesse ponto em que o Modelo Queijo Suíço pode ser usado. 

Esse modelo, geralmente usado na aviação e engenharia para a análise de riscos, tem como objetivo implementar diferentes camadas de proteção para diminuir as chances de erros. Mas sabemos que elas acabam sendo imperfeitas, como o próprio queijo suíço que tem vários furos. Então a ideia é que a gente tenha uma camada de proteção e, caso alguma coisa passe por ela através de uma falha, a próxima camada possa barrar esse problema. Pode acontecer de uma falha passar por todas as camadas, mas colocando diferentes camadas ao longo do desenvolvimento, podemos evitar cada vez mais erros e consequentemente, aumentar a qualidade do sistema. Com isso, o Quality Analyst tem a função de perceber quais camadas podem ser aplicadas para proteger o sistema. 

Mas como fica o papel dessa pessoa já que não temos uma única fase de testes como vimos no modelo Waterfall? Nós falaremos mais sobre esse assunto na parte 2 desse texto, então continue acompanhando o blog para não perder!