Iniciar uma prática de Qualidade sozinho não é fácil. O verdadeiro desafio é agregar valor ao propósito e à missão da organização, alinhando as diversas partes interessadas nas prioridades certas.

Lina Kulakova é a fundadora da comunidade QualityTalks. Ela ingressou na tb.lx para assumir o desafio de impulsionar a qualidade na empresa. Nesta entrevista, compartilhamos sua perspectiva, aprendizados e convicções sobre sua experiência.

Cobrimos os seguintes temas nesta entrevista:

• Compreender o contexto, propósito e missão da empresa
• Alinhando as expectativas das partes interessadas sobre o valor a entregar
• A importância de desenvolver hábitos, autonomia e colaboração
• Como implementar loops de feedback rápidos para experimentar o valor da qualidade
• Selecione a arquitetura e tecnologia para apoiar o porquê geral
• Concentre-se na prevenção ao invés da reação, focando em causar impactos
• Use a medição ficando consciente de suas limitações

Segue à QE Unit para aceder a mais conteúdo exclusivo e regular da comunidade.

Lina Kulakova

Antoine: Pode começar por apresentar-se?

Estou na área da qualidade há vários anos. Não tenho formação em engenharia, mas me apaixonei principalmente por TI e QA. Comecei como um testador manual e depois expandi meu conhecimento rapidamente porque era movido e motivado por tudo que via diariamente. Tentei aprender diferentes técnicas rapidamente. 

Como geralmente eu era a única pessoa em Qualidade da equipe, estava lutando para obter feedback sobre meu trabalho; não havia ninguém com quem comparar. Foi assim que comecei a QualityTalks em 2017 como uma comunidade portuguesa de QA. Oferecemos agora conteúdos para um público maior em inglês. Estávamos acostumados a encontros mensais. Ele evoluiu agora com mais palestras, entrevistas e um canal no Youtube.

Paralelamente, assumi o cargo de chefe de QA em uma startup suíça. Tive que definir a estratégia do zero, construir todo o departamento de QA e, em seguida, crescer a equipe. Foi um grande desafio para mim. Eu aprendi bastante. Desde então, descobri meu nicho e outra paixão dentro do controle de qualidade: definir, pensar e alinhar a estratégia com foco no panorama geral das empresas.

Além disso, tenho trabalhado com a Portuguese Women In Tech (PWIT) como mentora, participando em iniciativas diferenciadoras. Estamos trabalhando para atrair mais mulheres no mundo da tecnologia.

Antoine: Interessante o que disse sobre ter uma perspectiva transversal e trazer valor para a empresa como um todo. 

É um exercício muito interessante. Eu tenho que me colocar de lado, pensar no quadro geral. É muito intrigante e estressante ao mesmo tempo. Acho que também é por isso que gosto tanto. No final das contas, é muito gratificante quando começa a colher os frutos.

Antoine: Sei que a sua empresa – tb.lx – tem sede em Lisboa, parte de um grupo maior do sector dos transportes. Pode nos contar um pouco mais sobre isso? O que estão tentando resolver, para quem?

Eu definitivamente gosto de tb.lx. Estamos no ponto ideal para ser uma startup dentro de um mundo corporativo. Ainda temos a liberdade de fazer escolhas tecnológicas, experimentar e aprender rapidamente em um ambiente ágil. Ao mesmo tempo, temos o apoio de um grupo muito grande, a Daimler. A nossa missão é construir soluções de transporte sustentáveis para caminhões, fusos e fretadores Mercedes-Benz..

Tb.lx está focado em uma grande missão e estou muito orgulhoso de fazer parte dela. Estamos trabalhando em um transporte sustentável para o nosso futuro, o que é crucial. Focamos nos camiões e autocarros, que são inevitáveis ​​e necessários para a entrega de alimentos e mercadorias. É incrível fazer parte de uma empresa com esse propósito.

A nossa empresa não é assim tão grande, somos cerca de 60 pessoas e continuamos a crescer. Estamos sediados em Lisboa com uma forte cultura de confiança. Trabalhamos em configurações híbridas entre trabalho presencial e remoto, com foco na diversidade. As pessoas da nossa equipa são de horizontes diversos e também estão sediadas fora de Lisboa.

Antoine: O desafio era implantar uma prática de Qualidade dentro da empresa, por quê?

A empresa contava com uma equipe de engenharia fantástica, consciente da necessidade da qualidade. Cada vez mais, vemos em diferentes empresas a necessidade de qualidade. Eu diria que a imagem mudou muito nos últimos anos. Se há alguns tempos tínhamos que convencer as pessoas de que precisamos de um departamento de qualidade, agora é mais natural para todos. É como um terreno comum que precisamos ter uma equipe de controle de qualidade.

Embora a equipe de engenharia tenha começado a fazer as coisas sem alguém oficialmente afetado como QA, eles sentiram que precisavam de alguém para canalizar seus esforços e estruturar a abordagem. A empresa e a equipe foram crescendo com uma quantidade cada vez maior de entregas. Eles pensaram que precisariam de mais estrutura e que beneficiariam de um defensor que os guiasse no processo de qualidade. Por exemplo, eles queriam construir produtos mais fiáveis. 

Antoine: O crescimento estava impulsionando a necessidade de alguém com uma perspectiva mais ampla, conectando os pontos entre as diferentes perspectivas de valor. Essa cultura de qualidade foi algo que incorporou desde o início? Como é que tudo começou? Quais foram suas prioridades durante os primeiros 90 dias?

Exatamente, eu pressionava pela qualidade para não aparecer como verificador da polícia na empresa. Não sou o porteiro, a pessoa que diz vá ou não, mas muito mais para favorecer a colaboração em equipe, dando-lhes mais responsabilidade, orientando-os quando precisam.  

Não foi fácil. Embora eles tivessem testes unitários e de integração em vigor, tínhamos que especificar um terreno comum entre nós. Tudo começou alinhando onde estamos e onde queremos estar, que tipo de testes exigimos, que nível de teste. Mesmo alinhar as convenções de nomenclatura e vocabulário não foi uma tarefa fácil. Os testes de integração têm significados diferentes para pessoas diferentes; alguns os chamariam de ponta a ponta. A primeira coisa foi realmente definir esse terreno comum entre todos nós.

“A primeira coisa foi realmente alinhar um terreno comum entre todas as partes interessadas: nossa situação atual, um vocabulário compartilhado, suas expectativas.”

Lina Kulakova

Depois disso, trabalhei para entender o que queremos oferecer e quais são as restrições. Não havia uma solução única para todos. Tínhamos que entender a perspectiva e as motivações do negócio. Tive que analisar e sentir o que precisávamos e quais seriam as principais dificuldades. Eu sabia que queríamos entregar os melhores produtos para o mundo Daimler, que tínhamos um alto grau de interação com uma variedade de partes interessadas. 

Isso foi como uma estrela guia para mim, porque eu sabia que precisávamos de algo capaz de fornecer um bom nível de comunicação entre pessoas diferentes.

Antoine: Imagino que a gestão de relacionamentos foi fundamental. Como abordou este assunto? Preferiu formatos em 1to1 ou mais colaborativos para alinhar uma definição compartilhada de qualidade e valor?

Tive que interagir com um amplo conjunto de partes interessadas, não apenas em 1to1. Acho que muitas pessoas estavam esperando que eu começasse. No momento em que comecei, todos já compartilhavam comigo para marcar reuniões comigo, para alguns em grupos. Eu me apresentei e quais eram minhas prioridades gerais.

Minhas primeiras semanas e meses foram realmente para entender o que queríamos entregar como empresa. Então, quando tive uma compreensão muito clara de nossos objetivos, propósito e valores, gradualmente conheci mais partes interessadas do mundo externo da tb.lx, ou seja, a Daimler.

Antoine: Quais eram suas prioridades de qualidade? Como os alinhou com as prioridades de negócios? Como priorizou o esforço?

Uma das principais prioridades da qualidade era alinhar as prioridades por meio da comunicação. Somos uma empresa com atores internos e externos. Tínhamos que garantir que estávamos todos na mesma página e às vezes a comunicação simplesmente não era fácil. Estamos em uma configuração remota; trabalhamos em locais diferentes e temos fusos horários diferentes. O objetivo era alinhar todos na mesma visão do que estamos entregando e do que se espera que entreguemos.

A partir daí, concentrei nossa estratégia mais nas TDD (Test Driven Development) e ATDD (Acceptance Test Driven Development) para alinhar com a equipe de desenvolvimento. Nós realmente precisávamos que seu esforço se concentrasse no que o cliente esperava de nós. Encontrei uma ferramenta que não é muito conhecida nem  amplamente adotada, o KarateDSL. É uma variação do antigo conhecido Cucumber com Gherkin. Possui uma camada a menos que o Cucumber. Portanto, é muito mais fácil implementar, codificar e escrever testes.

Pude garantir que iríamos mais rápido por causa dessa vantagem de simplicidade. Além disso, teríamos documentação viva com casos de teste claros que qualquer pessoa da equipe entenderia. Esse também foi o caso dos desenvolvedores. Mesmo que eles não estejam na prática de controle de qualidade diariamente, eles podem abrir rapidamente os testes e entender exatamente o que estamos testando.

“A qualidade é um facilitador de ciclos rápidos de feedback de comunicação entre as várias partes interessadas.”

Lina Kulakova

Esse foi o nosso ponto de partida: alinhar com os parceiros de negócios o que exatamente eles esperavam de nós e, em seguida, transformar isso em testes. A partir daí, a equipe de desenvolvimento pode trabalhar e fazer sua mágica. Eles têm a liberdade de escolher a melhor linguagem de programação, frameworks etc, desde que garantam o atendimento aos requisitos de negócio de nossos stakeholders.

Além disso, o desempenho é fundamental, pois coletamos dados massivos da frota de caminhões; investimos em testes de desempenho com Gatling. É possível vincular os cenários do KarateDSL aos testes de desempenho para manter um alinhamento. A segurança também é crítica. Para esse efeito, tentamos cobrir diferentes tipos de domínios de segurança. João Proença partilha vários temas no QA e em particular sobre sessões de risk-storming.

Como a segurança e o desempenho eram tão importantes para nós, trabalhamos para integrar os processos de invasão de risco em nossa equipe. Começamos todo o desenvolvimento com análise de risco e, em seguida, compartilhamos com as partes interessadas, como proprietários do produto, para definir os diferentes testes. Continuamos com o desenvolvimento e as partes de codificação, incluindo análise estática e de segurança em diferentes níveis. Agora estou me concentrando em maneiras sistemáticas de garantir a segurança, implementando uma estrutura de DevTestSecOps em vez de apenas uma estrutura de QA.

Antoine: De um proprietário de empresa e produto, o impacto da qualidade foi compartilhar suas expectativas e estar envolvido em sessões de avaliação de risco. Quais foram os resultados mais valiosos para eles?

O negócio vê e valoriza um alinhamento transversal do trabalho. A mudança mais significativa que notamos foi na própria equipe de engenharia. Eles não tinham uma ideia ampla do que deveriam entregar. Eles estavam focados principalmente em engenharia, tecnologia e design de soluções, em vez de negócios mais globais e perspectivas de clientes. Por exemplo, eles começaram a pensar muito mais sobre o que pode acontecer em cenários de falhas de caminhões. Isso era algo que não acontecia no passado. Eles agora têm uma estrutura muito melhor, como uma receita e um processo claros para compor, adicionar ingredientes e variações.

Estamos trabalhando para expandir nossa prática em todos os níveis e também mantê-la enquanto estamos crescendo. Uma coisa que gosto em nosso contexto é que aceitamos iterar e falhar rapidamente, se necessário. Estamos nos concentrando em realizar loops de feedback rápidos. Garantimos tempo para refletir sobre o problema e corrigi-lo adequadamente. Uma estatística diz que se testar os resultados imediatamente, um desenvolvedor levará 4 minutos para corrigir o bug. Mas se descobrir como um dia depois, já se tornará uma hora e assim por diante até semanas se for encontrado ainda mais tarde. Quanto mais tarde descobrirmos o bug, mais demorado será para todos.

Hoje, a equipe de desenvolvimento sabe exatamente os testes esperados e deve ser verde ao realizar alterações; faz parte da nossa definição de pronto. Em seguida, complementamos nossa abordagem com testes exploratórios não necessariamente sistematizados e nem a responsabilidade de desenvolvimento. O principal valor é que eles podem verificar constantemente por si próprios os resultados do teste. 

Antoine: Métricas e KPIs podem ser poderosos e perigosos em seu uso. Utilizam métricas e KPIs específicos para apoiar a iniciativa de qualidade?

Gostaríamos e estamos usando alguns. Nosso foco principal foi garantir que tivéssemos os DevTestSecOps e testes automatizados, dividindo meu tempo entre as equipes. Garantir a autonomia das equipes foi um ponto fundamental a se considerar. Seguimos, por exemplo, as compilações noturnas e os resultados dos primeiros testes realizados. Eu diria que ainda não estamos focados em métricas. 

“No final, os processos de qualidade devem se tornar naturais e fazer parte da nossa cultura.”

Lina Kulakova

Damos mais ênfase à prevenção o mais cedo possível no processo. Medimos a cobertura em diferentes camadas e diferentes níveis de teste, incluindo os de aceitação. Também tentamos garantir que os erros e bugs que encontramos sejam muito mais extensos do que os encontrados pelos nossos stakeholders.

Nosso principal objetivo é garantir uma rotina forte, padrões de qualidade e hábitos na organização. Trata-se de garantir que privilegiamos a qualidade, a partilha entre as equipas e que as equipas saibam o que se espera delas. No final das contas, o processo deve se tornar mais natural e fazer parte da nossa cultura.

Antoine: Nós regularmente vemos as perguntas sobre quem deve fazer os testes. Acho que depende do contexto. Compartilhou alguns elementos seus, os testes são implementados pelos engenheiros de software, por exemplo?

Eu concordo com que depende do contexto. Em nosso contexto, temos uma equipe de engenharia com foco nos testes de unidade e integração, e eu estou mais focado nos níveis de teste funcional. Embora eu seja apenas o único controle de qualidade por enquanto para diferentes equipes dentro da empresa, meu foco na ATDD traz o pensamento crítico para os testes. Os próprios testes em Cucumber não são muito longos para serem escritos; passamos mais tempo escrevendo os casos de teste. Eu colaboro com vários proprietários de produtos para me ajudar a pensar sobre isso.

Uma coisa incrível que alcançamos é a definição do teste que é então revisada pelo Product Owner (PO), levantando novas questões e perguntando como uma revisão por pares. Os desenvolvedores estão verificando o próprio código e temos o PO verificando os casos de uso. Os testes são abertos a toda a equipe. Essa é uma verdadeira colaboração entre nós. Eu sou o dono e todos contribuem. 

Antoine: Selecionou uma ferramenta mais utilizável e compreensível para a equipe, em vez de uma caixa de ferramentas de tecnologia perfeita. É um excelente exemplo de uma decisão de qualidade valiosa em sua jornada. Quais desafios enfrentou? Quais foram as aprendizagens nesse processo de mudança cultural?

Monte de coisas não funcionaram como o esperado por várias razões. Em primeiro lugar, diria que um dos maiores desafios é trabalhar com muitos dados. Trata-se de dados de streaming ao vivo e tecnologia de streaming ao vivo. Tive que falar com pessoas diferentes para entender como poderíamos testá-lo.

A transmissão ao vivo não é fácil. Não pode prever exatamente o que receberá. Isso complica como deve testá-lo corretamente. Uma das maiores dificuldades que tive de resolver foi que não temos um veículo real disponível para teste. Esse foi um problema para definir o conjunto de dados em que podíamos confiar. Precisávamos garantir bancadas de teste e dados de teste suficientes. Um aprendizado importante foi que não fomos capazes de testar tudo e garantir execuções rápidas e confiáveis. Tivemos que construir conjuntos de dados representando diferentes cenários. Contamos com engenheiros para obter cenários realistas e construir nossos conjuntos de dados.

O teste da arquitetura de streaming definitivamente não é fácil. Lembro que comecei a escrever alguns testes. No início, foi um desperdício porque não estava funcionando bem na maioria dos casos. Tentei aproveitar o postman, mas devido à tecnologia distribuída, isso é muito menos que uma verificação síncrona de solicitação / resposta. Após uma série de iterações rápidas, acabamos construindo a estrutura e a solução certas.

Antoine: Quais são as principais conclusões dessa experiência? Que conselho daria a alguém que começou como Head of Quality?

Em primeiro lugar, precisamos entender o que temos que entregar. Acredito que às vezes queremos nos concentrar diretamente em testes automatizados, implementar pipelines e obter muita automação para cada construção. Mas podemos esquecer rapidamente por que testamos em primeiro lugar. Isso é algo para se ter em mente em todas as fases.

Quando selecionei o ferramental, por exemplo, estava constantemente avaliando a capacidade de colaboração, sendo uma de nossas principais prioridades. Eu descartei alguns deles que não atendiam a esses requisitos, realizando experimentos rápidos. Eu estava sempre dando um passo para trás no que estava tentando alcançar. Podemos rapidamente começar a nos preocupar muito com painéis e ferramentas sofisticadas, em vez do valor que criamos.

Não é uma competição. Não se trata de ter o número máximo de testes automatizados. A automação vem, por exemplo, para remover tarefas repetitivas e enfadonhas. Não é o objetivo em si. Não temos como objetivo um determinado número de testes automatizados. Às vezes, é tão empolgante que podemos nos concentrar rapidamente na otimização da tecnologia em vez da verdadeira qualidade.

Antoine: Todos nós deveríamos colocar um post-it e um lembrete diário com “Volte no porquê”. Para encerrar com uma nota pessoal, tem conteúdo inspirador específico, como citações, livros, mesmo fora da qualidade?

Não é uma resposta fácil, não por falta de referências mas, pelo contrário, muitas coisas me inspiram.

Me sinto muito inspirado pela equipe que tenho. Não existe uma empresa, equipe ou circunstâncias perfeitas; sabemos que a grama é sempre mais verde do outro lado. É crucial trabalhar em um ambiente onde podemos confiar em seu pessoal e eles podem confiar em si. Precisa ser capaz de se comunicar com clareza, chegar lá e fazer as coisas acontecerem. Tendo o contexto certo, a equipe e um propósito impulsionador são essenciais para mim.

Existe também o mundo externo. Tenho o QualityTalks e me sinto muito inspirado tanto pelos palestrantes que recebo, quanto pelas pessoas que assistem. Eles fazem perguntas, trazem suas dúvidas e procuram orientação, ajuda ou conselho. Isso me inspira muito a continuar me esforçando e a aprender. Às vezes, aprendo mais com perguntas do que dando informações. Receber treinamento e fazer perguntas é para mim uma ótima maneira de aprender. Também tende a colocar tudo em uma perspectiva diferente. É muito legal ter essa comunidade QualityTalks.

“O propósito é essencial. Precisamos ter um impacto neste mundo. ”

Lina Kulakova

Na verdade, gosto de partilhar ideias com diversos profissionais da área como o João Proença. Também conheço um cara inspirador chamado Antoine, não sei se o conhece da QE Unit 🙂 As pessoas em TI, especialmente em Qualidade, são acessíveis. Recentemente, compartilhei, por exemplo, com Lisa Crispin, que ficou muito motivada por conversarmos juntos. 

Os livros de Lisa Crispin e Janet Grégory me inspiram muito. Angie Jones também é uma grande fonte de inspiração. Tenho tendência a procurar liderança e inspiração não técnica. Mudança de tópicos e assuntos técnicos; um dia é DevOps, Cypress e outras ferramentas. Sou muito mais movido por um propósito, alinhando o porquê e o impacto. É importante causar impacto.

Ao desenvolver um aplicativo móvel, pode ajudar alguém a acessar um serviço específico que antes não era possível. Ao trabalhar em uma plataforma de viagens, está ajudando as pessoas a realizarem seus sonhos. Tenho a enorme honra de poder transformar o futuro do transporte e isso é incrível. Procuro pessoas que me inspirem em termos de motivação, porque estamos no controle de qualidade em primeiro lugar. As pessoas que mencionei aqui são ótimas neste campo e, o mais importante, uma grande fonte de inspiração.

Antoine: O propósito nos permite continuar nosso esforço mesmo em tempos difíceis. Eu realmente acredito que compartilhamos essa importância do propósito tanto para indivíduos quanto para organizações.

Com certeza. No final do dia, temos a capacidade de fazer coisas que amamos e que são testadoras e de qualidade para nós. Também temos a oportunidade de escolher entre diferentes negócios. Quando há uma conexão verdadeira com nosso propósito, isso traz todo o potencial do que fazemos.

Isso também é crítico para a combinação trabalho-vida. Para mim, é mais um blend do que um equilíbrio porque não paro a qualidade depois das 17h ou 18h. Ainda participo de diferentes conferências, encontros ou documento-me regularmente. O propósito é essencial. Precisamos ter um impacto neste mundo.

Antoine: Obrigado Lina por compartilhar sua experiência com humildade. Aprendemos compartilhando e construindo com as comunidades; Eu realmente aprecio o que compartilhou e também agradeço tb.lx por esta abertura. Tenha uma grande jornada na construção de sua prática de controle de qualidade durante seu crescimento e tudo de melhor com QualityTalks.

Pode seguir a Lina no Linkedin, Twitter e QualityTalks.

Recursos úteis

KarateDSL https://github.com/intuit/karate 

João Proença (2020). O que é risk storming? Como começar sua carreira de qualidade? Como definir uma estratégia de controle de qualidade? Quality Talks.

Lisa Crispin, Janet Grégory (2008), Agile Testing: A Practical Guide for Testers and Agile Teams. Addison Wesley.

Lisa Crispin, Janet Grégory (2019), The Agile Testing Condensed. Addison Wesley.
ATDD et BDD quelle différence. https://latavernedutesteur.fr/2019/02/25/atdd-et-bdd-quelle-difference/ La Taverne du Testeur