O ecossistema está em constante aceleração e crescimento. Torna-se ainda mais difícil acompanhar o número de startups se movendo para aumentar a escala enquanto os unicórnios aparecem em diferentes partes do mundo. Mas conseguimos manter o ritmo a médio prazo?

O Quality Engineering é de interesse crescente para empresas que buscam entregar valor continuamente aos seus utilizadores. Eles devem equilibrar a experimentação bem-sucedida de experiências valiosas ao mesmo tempo em que garantem bases de tecnologia escalonáveis.

Esse desafio de Qualidade com Velocidade é mais fácil de dizer do que fazer. Nesta entrevista, Filipe Carvalho, Senior Engineering Manager da TalkDesk, um dos maiores unicórnios de Portugal, partilha a sua perspetiva de utilizar a Qualidade para responder a estes desafios.

Segue a QE Unit para aceder a mais conteúdos exclusivos de Quality Engineering.

Sobre Filipe Carvalho

Atualmente é Senior Engineering Manager, liderando os clusters de Developer Experience SRE e Core Platform na Talkdesk. Desde meados de 2019 atua como Líder de Engenharia de diversas equipes da área de SRE.

Anteriormente, trabalhou em várias empresas tal como Rocket Internet, Farfetch and Talkdesk como Engenheiro de Software em Teste e especialista em CI/CD, apoiando esforços de qualidade para diferentes aplicações, stacks técnicos e empresas como um todo. Também esteve envolvido em várias comunidades como o Porto Testers Meetup e eventos como o Commit Porto.

Antoine: Pode começar por apresentar-se?

Comecei como a maioria de nós como engenheiro de software. Qualidade sempre foi um tema de que gostei muito. Comecei a trabalhar na área de qualidade no final de 2014 como Engenheiro de Qualidade com foco em automação de testes e pipelines. O contexto principal foi no mobile por cerca de 3 a 4 anos. Depois, evoluí para diferentes empresas nessa área.

Depois de um tempo no domínio móvel, decidi buscar um desafio diferente trabalhando em aplicativos de back-end e front-end. Com essa experiência, senti que queria um desafio diferente. Atualmente sou Senior Engineering Manager atuando na área de Site Reliability Engineering (SRE).

Antoine: Larga experiência atuando nas áreas de front, back e operações. Se se afastar dessas experiências, quais problemas principais está tentando resolver para fornecer um software de maior valor?

Normalmente, a Qualidade não é um first-class citizen. Todas as etapas de desenvolvimento de software devem incluir a Qualidade. Começa com o código, implementação, monitoramento, etc. Há muitos domínios para abordar, não se limitando a testes. Mas o que é teste? Ele está fazendo algumas verificações? Ele está criando verificações automatizadas? Está pensando no recurso e no valor que ele traz para o cliente? O que realmente é qualidade? Esta é a primeira pergunta para depois alinhar as técnicas de teste. 

Podemos contar com verificações de teste, feitas manualmente ou automaticamente. O que acontece normalmente é que o código de testes automatizado, por si só, carece de Qualidade. Seu nível de qualidade é tão importante quanto o código que está sendo testado. Esse problema, a falta de inclusão de qualidade no design, cria todos os tipos de problemas de implementação em cascata.

Além disso, temos um problema semelhante de estratégia; mais precisamente, a falta de estratégia. Temos projetos de automação que passam a focar na “automação”. O fato é que existe um aplicativo onde os testes fazem parte do aplicativo. Este não é outro projeto ou diferente. Deve ser entendido como parte dela. Essa é a minha opinião sobre a inclusão da Qualidade.

“A qualidade é uma parte integrante do ciclo de vida de desenvolvimento de software. Deve ser implementado no nível certo em cada etapa.”

Filipe Carvalho

O que acontece com a minha experiência é que projetos de automação separados tendem a ser abandonados, morrendo ou mudando regularmente de escopo. Há uma aparente falta de estratégia e foco no que a equipe está tentando alcançar. Isso também está alinhado com a tendência de entregar código de forma consistente com o “melhor esforço”, em vez de uma preocupação real com o valor entregue, deixando de lado a qualidade.

No final, quando falamos de má ou de falta de estratégia, acabamos por falar dos atores e do seu nível de conhecimento e competências. Podemos constatar, por exemplo, no mercado português uma carência de Engenheiros da Qualidade. Não é um problema das pessoas em si; existem bons e promissores com potencial; é mais um problema de reconhecimento e necessidade dentro do ecossistema. Não há profissionais suficientes na área para levar mais empresas ao próximo nível.

Essa carência é até negativa para os perfis existentes que podem se sentir sozinhos e desmotivados em seu contexto. Eles tenderão a procurar ambientes onde possam crescer. Queremos estar com colegas com os quais possamos aprender muito, não sendo o único profissional de ponta. Com certeza, um sênior ainda pode aprender com um júnior, mas a emulação é necessária de uma perspectiva de especialização e aprendizado acelerado. 

Antoine: Se começarmos nosso SWOT sobre Qualidade, quais pontos fortes e fracos identifica?

Uma das boas práticas regulares que tenho visto é o envolvimento da equipe. Não é uma separação de interesses. Obviamente, podemos ter um engenheiro de controle de qualidade dedicado. Mas isso não significa que a definição, estruturação e implementação da qualidade serão melhores do que uma equipe composta por engenheiros, todos voltados para a qualidade (e não necessariamente os de qualidade dedicados). Uma whole-team approach to quality também pode ser muito produtiva. O contexto é tudo. Acredito que todos os engenheiros devem contribuir para a Qualidade e crescer pessoalmente, melhorando suas práticas de Qualidade.

Tenho visto revisões de código funcionando bem com foco na lógica central e nos tópicos mais profundos de implementação. Isso significa que as equipes já automatizaram as revisões triviais e menos interessantes com foco na formatação, por exemplo. Devemos questionar e melhorar como podemos ajudar a equipe a realizar uma melhor revisão de código. O envolvimento de engenheiros de qualidade na revisão de código também se mostrou útil, ainda mais, se familiarizado com a codificação.

Além disso, uma equipe pode querer testar uma característica de um colega. Deve ser tão simples quanto verificar o código e executá-lo em nossa máquina ou na nuvem. Isso significa que uma automação poderosa deve estar disponível. Às vezes, só precisamos fazer uma verificação do comportamento do negócio com iterações rápidas. A capacidade de realizar essas verificações com rapidez e facilidade é crítica para loops de feedback rápidos, executando o aplicativo local ou remotamente.

Para muitos recursos, nem sabemos se eles serão valiosos para nossos utilizadores. Precisamos entregar rápido para aprender e se adaptar mais rapidamente com base na experimentação. Em muitos casos, os recursos seriam ativados apenas em uma pequena parte do tráfego.

O que vem depois são as fraquezas.

Eu também mencionei um pouco isso, mas ainda considerar a Qualidade e os testes como algo útil é um problema real. Se um desenvolvedor iniciar um recurso percebendo que teria mais confiança com os testes de unidade e integração posteriormente, as coisas começarão a falhar. Pela minha experiência, se quisermos entregar mais rápido, sacrificamos a qualidade no curto prazo, mas enfrentamos o problema de não sermos capazes de iterar. 

Outra parte é a dificuldade do conhecimento transversal para compreender as várias implicações das diferentes práticas. Dificilmente podemos ser especialistas em várias áreas. Podemos ter mais experiência em codificação, teste, monitoramento, observabilidade, requisitos. Precisamos aprender continuamente e permanecer curiosos ao mesmo tempo em que podemos colaborar com diferentes atores. Às vezes, podemos simplesmente não ter experiência em um tópico específico; reconhecê-lo é o primeiro passo para cobrir a lacuna. 

Antoine: Nesse contexto, quais oportunidades identifica?

Eu vejo algumas oportunidades. Em primeiro lugar, existe muita motivação e interesse nesta área. Podemos julgá-lo contraditório ao que disse antes sobre os perfis experientes. O fato é que precisamos de diferentes desafios para manter nossa motivação. O interesse crescente em criar mais oportunidades para pessoas ansiosas por aprender e crescer. Todos podem aprender mais sobre as áreas, mesmo com muito conteúdo acessível gratuitamente.

Eles nem precisam de muito conteúdo técnico ou experiência. Isso é bastante específico da Qualidade; isso é bem diferente para um engenheiro de software que precisa se aprofundar em uma série de tópicos mais técnicos. Tenho visto engenheiros de qualidade muito bons que não fazem código, mas são capazes de entender, revisar, identificar o monitoramento e suas implicações operacionais. A combinação de experiência é verdadeiramente valiosa. 

Às vezes, a capacidade de codificação é altamente considerada por um engenheiro de qualidade. Mas, na realidade, é apenas uma faceta da função exigida. Pode ser bom em codificação, mas codificar a coisa errada. É por isso que a codificação não é a habilidade primordialmente exigida; pensamento crítico, qualidade e foco no negócio são competências valiosas.

Antoine: E se continuarmos com as ameaças?

Com o tempo, a rotação dos perfis qualificados pode ajudar a compartilhar as práticas, mas eles não estão mais lá para apoiá-los ou orientar a equipe. Temos muitos engenheiros recentes na área, mas eles não têm experiência. Nesse tipo de contexto, eles não podem crescer no nível esperado de exigência e habilidades. 

Outra é a tendência de hipercrescimento das empresas. Temos muitas empresas crescendo rapidamente, do início ao aumento de escala. Embora cresça rapidamente, a qualidade e os testes são coisas que começam a desmoronar primeiro. Isso tende a colocar a Qualidade completamente de lado no médio prazo. Encontramos isso na expressão querer algo “bom, de qualidade e barato”. Normalmente, a qualidade é o sacrifício. O produto pode atingir o valor mínimo esperado pelos utilizadores; no entanto, uma série de problemas internos começará a se desintegrar e impactar as operações internas. Posteriormente, problemas mais complexos de confiabilidade, escalabilidade e evolução aparecerão, impactando verdadeiramente a experiência do usuário.

Outro ponto é que as metodologias disponíveis não são suficientemente compreendidas pelos atores. Há muito conteúdo, diretrizes e práticas disponíveis, o que é ótimo. O problema é mais o entendimento e alinhamento da indústria sobre essas práticas. Normalmente, as pessoas pegam parcialmente a ideia e os jargões sem entender as verdadeiras implicações e mudanças que devem implementar. Há um ótimo conteúdo, mas filtrar e torná-lo valioso no contexto da empresa é diferente. Devemos ter cuidado com o fluxo constante de “novo” conteúdo. Uma grande parte do conteúdo é reaproveitada a partir do conteúdo existente.

Antoine: Tem práticas específicas que achou eficazes ou, ao contrário, achou ineficazes em sua experiência?

Tenho tendência a gostar de práticas sistemáticas. Algumas delas são pequenas, exigindo pequenas mudanças, mas ainda assim permanecem poderosas. Quando temos uma série de use-cases que um engenheiro de software escolhe para iniciar seu desenvolvimento, por que não incluir engenheiros de qualidade desde o início? Ele pode discutir a abordagem, fazer perguntas e também fornecer uma segunda opinião. Ele pode compartilhar os casos extremos mais prováveis ​​e discutir os cenários do usuário, melhorando a conscientização e a implementação do desenvolvedor. No final, reduziria o esforço de retrabalho e aceleraria o ciclo de desenvolvimento, possibilitando iterações mais rápidas.

Outra prática interessante é a automação de teste enquanto o recurso está sendo desenvolvido. Se o engenheiro de qualidade discutir com o desenvolvedor, ele pode emparelhar a implementação do teste com o código, permitindo interações e compartilhamentos muito mais frequentes. Quando falamos sobre revisão por pares, esta é uma prática poderosa para qualquer atividade. Nesse caso, aplicar a revisão do código e do teste foi muito poderoso, de acordo com minha experiência.

O próximo é o monitoramento. Qualquer um pode ter uma ideia sobre o que precisamos monitorar para nossos utilizadores e produtos. Podemos ter uma variedade de funções sugerindo melhorias. Podemos ter qualquer função capaz de medir, visualizar e usar dados para tomar ações corretivas. Os atores não precisam ser necessariamente perfis técnicos.

Antoine: Quais são as principais lições para melhorar o estado de qualidade?

Eu diria que cada parte do ciclo de vida do software deve incorporar Qualidade. A qualidade deve estar presente em todas as etapas do processo, não mais sendo considerada uma opção. A qualidade deve ser incorporada no início do ciclo, com toda a equipe envolvida continuamente. Por que devemos considerar qualidade ou atributos de teste separadamente? Isso não faz sentido para os recursos que pretendemos fornecer aos nossos utilizadores. Seria como seguir o objetivo errado.

O conhecimento e a importância da Qualidade devem ser realmente difundidos mais cedo. Estou até falando sobre formação inicial e universidades. Eu vejo algumas escolas adicionando mais ênfase na qualidade do código, qualidade de TI e parte de teste de seu programa. Este é um sinal positivo para o futuro, onde ainda temos um longo caminho a percorrer.

Todos os atores devem deixar claro que sua missão e trabalho não é um código, mas sim agregar valor aos nossos utilizadores. O código é uma forma de chegar a esse ponto, mas não a única. Podemos até exigir a exclusão de um recurso. Tendemos a esquecer aquela parte de cair no interesse de resolver problemas complexos. Para muitas experiências, devemos nos destacar em apenas uma coisa. 

Antoine: Tem conteúdo que recomendaria sobre essas perspectivas de qualidade ou que achou inspirador ou útil para se manter atualizado?

Mesmo que eu não esteja exclusivamente nos tópicos de qualidade, compartilharei como entro nessa área. Comecei com vários recursos diferentes. O blog de testes do Google foi uma das minhas primeiras inspirações, com artigos não muito profundos e influentes. Além disso, recomendo o Ministry of Testing. Existem muitos recursos excelentes de muitos testadores e engenheiros. Convido a participar de um evento ou da conferência Test Bash; Eu realmente recomendo.

Além disso, procure outras comunidades e pares dentro de sua área ou com interesses comuns. Geralmente pode encontrar um slack, um fórum ou um grupo Meetup nas proximidades. Se conectará com pessoas com interesses comuns, onde poderá trocar perspectivas, dificuldades e prioridades. Realmente cresce com esses compartilhamentos. Em Portugal, temos a QE Unit 😉 mas também a PTM & MoT no Porto, Quality Talks em Lisboa. A maioria desses eventos foram remotos recentemente com menos interações, mas ainda são valiosos como fontes de conhecimento. Organizo o PTM há alguns anos e mantenho contato com muitos contatos dessa época. A discussão e o compartilhamento são ótimos para o seu crescimento.

Em termos de livros, eu recomendo a qualquer um “Crucial Conversations: Tools for Talking When Stakes Are High”. Ele traz muitas maneiras valiosas e acionáveis ​​de se comunicar com mais clareza, com mais impacto e valor para todos os grupos de pessoas. A comunicação é vital para muitas posições. Para um engenheiro de qualidade ou um testador, isso é igualmente verdadeiro. As habilidades de comunicação são claramente um ponto essencial de desempenho, bem como de crescimento pessoal.

Antoine: Muito obrigado Filipe. A partir dessa perspectiva ampla de Qualidade, sua visão e contribuições são úteis para melhorar o estado de Qualidade. Desejo uma ótima jornada de Quality Engineering, prazer em tê-lo novamente em uma próxima entrevista ou mesa-redonda.

Podemos resumir a entrevista por meio do MAMOS, o framework do Quality Engineering:

• Methods
  • Metodologias sistemáticas são necessárias para incluir a Qualidade no nível certo em cada etapa do ciclo de vida do software.
  • Métodos simples implementados passo a passo podem fazer uma grande diferença na aplicação desde o início e para toda a equipa.
• Architecture
  • Nossa arquitetura e tecnologia de produto são as primeiras a sofrer quando a velocidade e o custo são favorecidos. Mas, no final, as bases frágeis resultarão em uma experiência do utilizador degradada. A qualidade deve ser defendida e incorporada por meio de argumentação sólida, exemplos e resultados.
• Management
  • O papel do líder é alinhar todos na criação de valor para os utilizadores, deixando de lado as puras questões de engenharia e tecnologia.
• Organization
  • Devemos combater os silos organizacionais aplicando a abordagem de toda a equipe à qualidade por meio de rituais sistemáticos.
• Skills
  • A escassez de profissionais qualificados reforça a necessidade de compor expertises de diversas origens, tendo como alicerce uma mente aberta, curiosa e colaborativa.

Desejo-lhe uma transformação sucedida para o Quality Engineering, a prática que restringe todas as atividades do ciclo de vida do software à entrega contínua de valor aos nossos utilizadores.

Segue a QE Unit para mais Quality Engineering.