O QA além das Certificações
Todos nós sabemos que devemos procurar melhorar nossas Skills sempre. Na área de TI isso é mais forte ainda, pois a cada dia milhares de novas tecnologias, linguagens, técnicas, metodologias, processos, frameworks e tudo mais surgem, e quem não acompanha essa evolução constante infelizmente fica pra trás. Especificamente na área de Teste e Qualidade de Software, há uma grande questão que bate na porta de muita gente quando o assunto é capacitação, que é a seguinte: Somente as Certificações em Teste de Software, irão automaticamente fazer de mim um bom QA? A resposta é: Não. Não mesmo. Elas irão te dar uma excelente base teórica sobre uma ampla gama de conceitos, processos, métodos e técnicas, nas diversas vertentes (Test Analyst, Test Manager, Technical Test Analyst, e tudo mais) dentro da área, porém somente com elas não é possível se tornar um bom QA.
Tendo este questionamento em mente, aliado ao fato de que possuo várias certificações em Teste de Software e estou há alguns anos atuando na área, resolvi listar alguns pontos que, na minha opinião(Embasada em minha experiência e visão de mercado), o profissional de Teste e Qualidade de software deve trabalhar além das certificações para se tornar um bom QA. Vamos lá?
O QA saber programar não é importante. É essencial.
O mercado de teste e qualidade de software hoje em dia está cada vez mais voltado para Automação de Testes (Em todos os níveis) & TestOps (Testing + Ops). Logo, saber programar e ser mais técnico é essencial para chegar ou se manter no topo. E não digo ser técnico somente para desenvolver os scripts de automação em si, mas também para resolver problemas de desenvolvimento quando necessário, entender o código e verificar (até antes mesmo de sua execução) se ele está atendendo requisitos específicos das regras de negócio, criar testes unitários, fazer code reviews, encaixar os testes em ambientes de integração ou de entrega contínua, fazer operações diversas no banco de dados, saber analisar os logs da aplicação, e muito mais. Então, se preparar nesse ponto é algo muito importante caso você queira se tornar um profissional extremamente cobiçado e valioso para qualquer equipe em que entrar. Para a preparação em si, existem várias alternativas de cursos como os do Udemy, QANinja, Alura, Pluralsight, e repositórios no Github, como o do Thiago, Fernando Papini e Júlio de Lima. Se você realmente quiser aprender, alternativa é o que não falta.
Todo QA deve ter um profundo conhecimento do domínio que atua.
Um bom QA é aquele que conhece tão bem (ou melhor) o produto que está sendo testado e suas regras de negócio do que qualquer P.O. A obtenção de um nível alto de conhecimento de negócio, propicia ao QA a um melhor desenvolvimento de pensamento crítico/analítico/negocial e feeling sobre o produto, fazendo assim com que o mesmo possa dar sugestões de melhorias, novas funcionalidades, e aprimoramentos gerais que agreguem real valor ao produto, além de ajudá-lo a validar o software de uma forma mais eficiente (Pois ele irá descrever melhor seus testes para refletir as necessidades de negócio, e também irá saber quais testes/áreas do sistema deve priorizar e quando deve priorizá-los de acordo com os impactos decorrentes das alterações/novas funcionalidades implementadas). Conhecer a fundo o que se testa, é mais importante do que apenas checar as funcionalidades com base em scripts/checklists pré-estabelecidos.
Não gosta do Dev? Junte-se a ele.
Sabe aquele papo de que os QA’s sempre terão um relacionamento ruim/conturbado com os DEV’s? Pura besteira. Esse conceito de “briga” foi criado, acredito eu, pelo fato de nós QA’s, ao decorrer de nossas carreiras, termos a difícil tarefa de ter que informar ao desenvolvedor que os testes relacionados a funcionalidade que ele acabou de implementar falharam, fato este, que muitas vezes não é bem-vindo pelo receptor da mensagem. Ninguém gosta de errar, isso é fato. Mas será que a “raiva” do Dev não foi gerada pela forma em que o QA o abordou para reportar o bug? E no final, erro foi somente do Dev? O QA não poderia ter previsto este bug antes da funcionalidade chegar na etapa de testes? A resposta é: Sim. E não só poderia prever, como deveria. E uma boa prática neste caso, seria especificar os testes antes da funcionalidade começar a ser implementada (Usando Gherkin, por exemplo) e alinhar estes com o Dev, para que ele tivesse noção dos cenários, fluxos, exceções que o software poderia percorrer, e desta forma, realizar a implementação com o máximo de cobertura possível para os cenários definidos. Além disso, o QA poderia escrever/revisar os testes unitários em par com o Dev para verificar se a estrutura que forma a implementação realizada está realmente de acordo com as regras de negócio. A integração entre QA e DEV propicia não só o aumento da qualidade geral do produto, mas também, à formação de equipes multidisciplinares e dissipadoras de conhecimento. Que QA nunca teve aquela dúvida sobre programação/qualquer outro aspecto técnico? Pois é. Todos nós em algum momento na vida tivemos. E tenha a certeza de que se você cultivar um bom relacionamento com o Dev, ou com qualquer outro membro da equipe, ele não hesitará em lhe ajudar quando precisar.
O QA deve atuar de ponta a ponta.
Um bom QA é aquele que atua de ponta a ponta no ciclo de desenvolvimento de software. Desde a concepção/elaboração dos requisitos do software, passando pela etapa de implementação, testes, e até mesmo implantação/deploy, ele deve tomar medidas que garantam que o software será entregue com a maior qualidade possível. Com a adoção de metodologias e processos ágeis de software, a ideia da validação ocorrer somente no final do ciclo de desenvolvimento está praticamente morta. Então, para se tornar um bom QA, pense na qualidade durante todo o processo, e não somente no final dele.
Todo bom QA é um evangelizador da qualidade.
Um bom QA, é aquele que leva a cultura/mindset de qualidade de software por onde passa. Logo, o mesmo deve garantir que a responsabilidade pela qualidade do produto/serviço seja compartilhada com todos os membros do time, sem exceção. Isso fará com que todos trabalhem de forma mais integrada e consistente pelo mesmo objetivo, que é entregar o produto/serviço com o maior nível de qualidade possível para o cliente final.
Softskills? Essenciais.
Um bom QA é aquele que se relaciona bem com todos os membros da equipe. Que sabe fazer as perguntas certas. Que sabe ouvir. Que tem empatia para ver as situações em diversas perspectivas diferentes. Que sabe se comunicar de forma coerente tanto de forma verbal quanto escrita, com qualquer um. Que tem coragem de encarar novos desafios (Sendo eles técnicos ou não). Que está sempre mantendo a curiosidade no mais alto nível, pois sabe que só assim irá alcançar níveis altíssimos de conhecimento. Que está sempre buscando aprender novas tecnologias, novas metodologias, e tudo mais de novo que estiver disponível no mercado. Essas habilidades estão ligadas ao lado humano e comportamental do profissional, e são essenciais para qualquer um que queira alcançar o topo em sua área de atuação. Para desenvolvê-las, recomendo além de muita prática e aplicação, muita leitura sobre o assunto.
Se quer ir rápido, vá sozinho. Se quer ir longe, vá acompanhado.
No processo de formação do QA, é de extrema importância que ele se envolva com a comunidade, seja participando de Fóruns, grupos do Whatsapp sobre a área, eventos, workshops, meetups, ou de qualquer outra forma. Isso irá expandir as possibilidades de Networking com outros profissionais da área, e abrir novos canais para aquisição e repasse de conhecimento. Então não tenha medo de interagir e se envolver. A comunidade sempre estará de portas abertas para você.
Ler, Ler e Ler.
Basicamente, toda a nossa bagagem de conhecimento é formada pelas nossas experiências e informações que adquirimos ao longo da vida. E uma das formas mais eficientes(e rápidas) de aumentar essa bagagem, é através da leitura. A partir da execução deste excelente hábito, podemos mergulhar e ser expostos a uma imensidão inimaginável de informações que, individualmente ou juntas, irão enriquecer nosso repertório sobre diversos temas (Tecnologias, Frameworks, Linguagens de programação, Metodologias, Softskills em suas diversas formas, etc..), o que consequentemente, nos torna profissionais mais completos, criativos, e sobretudo, mais cheios de conteúdo. A importância da leitura especificamente para os QA’s foi abordada em um excelente artigo do Thiago, que vale muito a leitura, e pode ser lido aqui.
Com certeza existem mais pontos que o QA deve se atentar durante o seu desenvolvimento profissional, porém, creio que estes sejam os principais. Meu objetivo aqui foi, além de dar dicas, abrir os olhos daqueles que acham que somente uma pilha de certificações garantem que o profissional seja bom na prática, e espero que tenha atingido meu objetivo, pois o mercado não precisa de um monte de papel. Ele precisa de bons profissionais que executem o seu trabalho com o máximo de eficiência e qualidade possível.
That’s all folks.
Até a próxima!
