QA: Quitar o Agiota? Não! Quality Assurance! Link para o cabeçalho

Conversando com uma amiga sobre carreira, eu trouxe que além de desenvolvedora, eu queria ser QA. Eis que ouço, com estranheza:
QA? Não é coisa de agiota, ilícita ou de comer não né?
Bem, além de perceber que a minha credibilidade com a minha amiga é quase zero (afinal meu único crime é amar demais), descobri também, após falar com mais gente, que não só ela, mas outras pessoas como estudantes de TI não conhecem bem o que é QA. A ideia desse post é explicar um pouco disso na tecnologia.
Existem aqui termos estranhos para algumas pessoas. Mas relax! Colocarei links explicando o que é cada um deles para melhor compreensão.

O conceito de QA Link para o cabeçalho
QA significa “Quality Assurance”, ou em tradução direta, “Garantia de Qualidade”. Então, quando alguém diz que é QA ou que atua em um time de QA, no fundo está fazendo uma referência a essa função, a função de coordenar a garantia de qualidade de um produto de software, geralmente em um time de desenvolvimento.
O que envolve qualidade? Link para o cabeçalho
Sabe quando você vai brincar em um joguinho e acontecem coisas esquitas? Ou quando o app do seu banco não colabora e fica travando? E quando até aquela figurinha que você vai mandar no grupo de Whatsapp te traz problemas?
Estes exemplos acima envolvem tretas na qualidade. E a garantia dela, por sua vez, envolve os cuidados na experiência do usuário durante o uso da aplicação, como um olhar atento nas funções de uma aplicação, evitando os famosos bugs, na velocidade (“será que a tela de login é muito devagar?”), os cuidados na compreensão com o que está sendo informado (“essa tela está muito confusa?”), no suporte caso o usuário precise tirar dúvidas (“será que estamos demorando muito para atender quem nos contata por e-mail?”), na acessibilidade (“nosso aplicativo está acessível para quem é surdo?”), e com outras tantas precauções.

E quem trabalha como QA? O que faz? Link para o cabeçalho
Essa pessoa vai não só ajudar na garantia de qualidade, evitando que existam erros comprometedores com o que será entregue, mas também auxiliar a enxergar melhorias, na entrega e nos processos do time. Por isso, quem é QA precisa estar por dentro da construção do produto, com sua atuação muitas vezes passando por:
- Documentar os requisitos daquele software e o que vai ser validado
- Validar se os processos planejados para cada área foram executados
- Testar se está tudo nos conformes (e aí entram váaaarios tipos de testes, assunto pra muitos posts aliás)
- Programar testes para serem executados automaticamente (iniciados quando alguém “der o play” nos testes ou até em stacks de CI/CD, sendo efetuados de tempos em tempos)

Para tudo isso ser feito, é preciso trocar muita, muita, muita ideia com todas as áreas envolvidas, buscando entender parte a parte deste processo.
É importante que a pessoa que é desta área tenha conhecimento dos processos e das metodologias de trabalho, e tenha um perfil analítico, flexível (afinal estamos falando da área de TI, uma área onde tudo muda rapidamente), e sempre busque a inovação e a criatividade para gerar os cenários mirabolantes de teste.
Conhecer linguagens de programação, para analisar os possíveis erros encontrados e para fazer as automações é interessante, junto com a compreensão de ferramentas para realizar os diversos tipos de testes que existem, que podem mudar de acordo com a demanda.
Então é o QA que é responsável pela qualidade? Link para o cabeçalho
Não. A qualidade é responsabilidade do time. Todos os integrantes precisam ter consciência de que cada um, em seu papel, deve ter cuidados para que o produto desta equipe seja o melhor possível para o cliente. O QA dá apenas aquela força, e vai trazer práticas, análises e insights, ajudando e coordenando/liderando esse processo.
Ele pode, em um time ágil, por exemplo:
- Amparar o PO no entendimento dos requisitos e na escrita das histórias
- Ajudar a pessoa responsável por UX na aprovação das telas e dos layouts
- Criar cenários de testes (automatizados ou manuais) para serem executados após os desenvolvedores finalizarem a codificação
- Auxiliar a pessoa responsável por DevOps a colocar dentro do processo de CI/CD alguns testes automatizados com os principais fluxos do sistema
- Executar testes manuais ao final da entrega, para tentar encontrar possíveis erros, e se colocando no lugar do usuário.
Terminando o produto, finalizou-se o trabalho do QA, certo? Link para o cabeçalho

Nope. Depois da entrega do produto, quem que vai ser o próximo a mexer nele? Isso, o usuário final - seja pessoa física ou pessoa jurídica, um hacker que quer encontrar todas as vulnerabilidades no seu sistema ou um usuário que vai digitar um monte de texto em um campo que aceita apenas números e vai ver a tela dar erro.
Nesse momento, podem existir vários feedbacks (que devem ser considerados), bugs novos (não mapeados pelo time), onde o trabalho de qualidade entra novamente, envolvendo o time todo, e o profissional de QA.

É isso meu povo! Espero ter sanado as dúvidas principais que existem quando esse termo vêm à mente.
Postagem migrada do Medium. Link para o cabeçalho
- Por Mai R. on May 14, 2021.
- Link original