Skip to content
screenshot of the landing page of Easy Classrooms

Motivos para aprender QA

Sim, desenvolvedores podem se beneficiar de conhecimentos de Quality Assurance

Tags that this post has been filed under. Links open in the same window.

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:

Pule para:

  1. Familiaridade com o Produto
  2. Empatia
  3. Pensamento Crítico
  4. Pensamento ‚Äúfora da caixa‚ÄĚ
  5. Por fim...

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.

Originalmente postado em: https://dio.me/articles/motivos-para-desenvolvedores-aprenderem-sobre-quality-assurance