image

Acesse bootcamps ilimitados e +650 cursos pra sempre

60
%OFF
Article image
Raissa Kuzer
Raissa Kuzer01/12/2022 00:41
Compartilhe

Motivos para desenvolvedores aprenderem sobre Quality Assurance

  • #Java
  • #TDD
  • #QA

Uma triste verdade: em empresas descuidadas é possível notar uma certa rivalidade entre profissionais de QA e de desenvolvimento, ainda que estejam no mesmo time.

Até entendo a perspectiva de algumas desenvolvedoras pois, afinal, quem é que gosta de ter que refazer o código porque uma das testers encontrou um bug que passou batido?

A verdade é que, por mais que o mercado se mova na direção de fazer com que desenvolvedoras se responsabilizem também pela testagem automatizada do que produzem, o fator humano nos testes é necessário e essencial. Não é incomum que a desenvolvedora acredite tão cegamente na qualidade do que produziu que acabe dispensando testagem. Enquanto isso, uma profissional de QA não tem seu entendimento limitado ao trecho sob sua responsabilidade e pode acabar mais familiarizada com o projeto/produto até mesmo do que as pessoas que escreveram o código.

Quer você esteja buscando formas de melhorar suas perspectivas como desenvolvedora, começando uma carreira em desenvolvimento, ou pensando em migrar de Quality Assurance para desenvolvimento, aqui estão algumas habilidades relacionadas a QA que serão muito úteis durante sua jornada:

1. Familiaridade com o Produto

Quando se está desenvolvendo um projeto pessoal no qual você é a única responsável pela aplicação, é fácil - e bem prazeroso - conhecer todos os pedacinhos e como eles se relacionam.

Essa familiaridade é praticamente impossível em aplicações maiores onde a desenvolvedora acaba trabalhando com tickets e focando apenas naquele código que está produzindo. Isso é bem saudável, diga-se de passagem, já que codebases podem ficar bem grandes e que há um time inteiro (ou times!), com membros de diferentes especializações e níveis de senioridade, responsável por fazer um produto nascer e funcionar: é coisa demais para um só cérebro!

O time de QA, por outro lado, não precisa se preocupar com detalhes nas profundezas do código, mas precisa conhecer os componentes, como eles se encaixam e, acima de tudo, como interagem. É nas interações que nascem os bugs! Profissionais de QA também precisam entender como as usuárias vão interagir com o produto (spoiler: frequentemente de maneiras não-óbvias que escapam da imaginação das desenvolvedoras) e por isso precisam compreendê-lo como um todo.

Esse nível de compreensão do produto pode ajudar a desenvolvedora a contextualizar os tickets nos quais está trabalhando, e a entender as interações entre diferentes partes do código. É relevante saber se a correção de um bug vai afetar outra parte da aplicação, e como o produto roda em um ambiente diferente do que a desenvolvedora costuma usar - em um celular, navegador ou sistema operacional antigos, por exemplo, ou mesmo em algo inusitado como um navegador rodando a partir de um Apple Watch. Sim, um Apple Watch! Já trabalhei na construção de uma aplicação web para uma empresa cuja dona queria poder ver o contador do rodapé da landing page a partir do relógio, na academia. 

De qualquer maneira, participar de alguns testes junto do time de QA pode ensinar muito sobre testar um produto - ou parte dele - de forma estruturada.

2. Empatia

QA Testers muitas vezes escrevem test cases baseadas não apenas em especificações, mas também fluxos de usuário: além de testar features isoladamente, também as testam dentro do produto como um todo da forma que seriam utilizadas.

O papel principal de uma desenvolvedora não é criar código e sim resolver problemas, certo? Sendo assim, é preciso ter em mente as usuárias para criar algo que as deixe satisfeitas, resolva seus problemas, e não crie novos. Existem empresas cujo papel é unicamente realizar pesquisas com usuárias e receber feedback, claro, e ler relatórios sobre como o produto foi utilizado é valioso… mas por que não interagir com o produto por conta própria, para ganhar conhecimento prático de como ele funciona, onde brilha e onde falha? 

Conhecer o produto um pouco mais intimamente também ajuda a descobrir pequenos detalhes que poderiam ser irrelevantes, mas que podem acabar sendo inconvenientes e irritantes para as usuárias. Como testes de QA são estruturados de maneira a considerar o produto de maneira holística, essa visão se torna valiosa quando trazida para o desenvolvimento.

3. Pensamento Crítico

Esta é uma habilidade crucial para desenvolvedoras! Observação, análise e avaliação antes de tomar decisões são essenciais quer estejamos caçando bugs, escolhendo qual tecnologia usar como ferramenta, ou mesmo implementando algo novo seguindo as especificações de um ticket.

Pensamento crítico também é um requisito para QA. Aqui brilham as especificações e a documentação (desenvolvedoras, não negligenciem documentação!) daquilo que foi implementado: tudo isso servirá de base para a tester pensar em todas as formas que algo deveria funcionar ou não funcionar, e como testar ou não testar. 

Sendo assim, o combo “observação, análise e avaliação” é primordial para criação de test cases e portanto mesmo testes manuais estão longe de serem necessariamente entediantes! 

Já citei anteriormente mas reitero: é nas interações que nascem os bugs. Sendo assim, é possível encontrar bugs dos jeitos mais inusitados e que muitas vezes nem estão no test case original! Trazendo para o lado do desenvolvimento, você como desenvolvedora tem uma visão única sobre detalhes do produto. Use-a para o bem! (de achar esses bugs elusivos para que possam ser exterminados). 

4. Pensamento “fora da caixa”

Algumas colegas estavam montando um pequeno projeto para uma hackathon e entregaram a membros da família para que testassem. Imediatamente, surgiram perguntas: “por que eu posso inserir isso duas vezes no mesmo dia?”, “quando eu criei um objeto novo, aquele que estava acima mudou de nome… é normal?”, “se eu tento apertar o botão de editar eu acabo apertando o de deletar porque estão muito pequenininhos, pode mudar isso?”. Tudo bem que uma hackathon não permite tempo suficiente para implementação dos melhores padrões de qualidade e de testes, mas os problemas enfrentados não surgiram quando as desenvolvedoras testaram a aplicação por conta própria!

Aceitemos a verdade de que usuárias vão fazer coisas inesperadas e místicas acontecerem, faz parte. Simplesmente não é possível prever todos os casos e todos os testes, mas isso não significa que não devemos tentar cobrir uma quantidade sensata deles.

Parte do trabalho de QA é pensar em ações que usuárias podem tomar e que as desenvolvedoras não tenham considerado. Como desenvolvedora, pensar em tais possibilidades antes ou durante o desenvolvimento e já partir atrás de correções e/ou testes ajuda até a impedir o nascimento de bugs - o que deixa a vida de todo mundo melhor.

Pensar fora da caixa é uma habilidade importante quando se tenta prever problemas ou mesmo a viabilidade de uma implementação. Quanto mais consciência se tem das possibilidades, mais criativas costumam ser as soluções! Esse tal de “pensamento fora da caixa” também costuma ser decisivo na hora de migrar para um cargo de liderança ou gestão, se você precisava de mais motivação para cultivá-lo.

Por fim…

Considere participar de processos de QA, mesmo que de maneira temporária, caso seja desenvolvedora. Se estiver trabalhando na área de QA, vá além de seguir o passo-a-passo delineado no test case. Use essas oportunidades para afiar seu pensamento crítico e criativo! Tente aprender mais sobre o produto, especialmente sobre as partes que costumam estar fora do seu escopo.

Esses são os motivos que me levaram a me inscrever no bootcamp GFT Quality Assurance Para Mulheres, e tenho certeza de que vão contribuir para meu sucesso como desenvolvedora! 

Compartilhe
Comentários (2)
Raissa Kuzer
Raissa Kuzer - 01/12/2022 08:43

Obrigada, Carolina! E concordo com você: QA e dev ambos são responsáveis pela construção de um produto de excelência!

Abraços 🤗

Carolina Louzada
Carolina Louzada - 01/12/2022 07:56

Parabéns pela postagem e considerações! Assino embaixo várias vezes Raissa! Vamos acabar com essa intriga de QA X dev. A responsabilidade não é de QA ou dev, mas do time, e quanto antes desenvolvimento e analistas entenderem isso, mas fluído será a integração e a correção dos problemas. Abraços!