Testes de produto (com Erin Hess da Crema)

Michael Luchen

Passa-se muito tempo a falar sobre a criação de produtos, mas e quanto aos testes de produto? Quais são as abordagens, posturas e disciplinas necessárias para garantir que um produto é testado exaustivamente, de modo a apoiar os utilizadores para os quais foi criado? Hoje temos connosco uma especialista em engenharia de testes, para aprofundarmos o que define este papel fundamental numa equipa de produto, como colabora com os gestores de produto e porque pode ser uma defensora essencial da empatia numa equipa de produto. Fique connosco.

Este é o podcast O Clube do CPO — as vozes da comunidade que está a escrever o manual da gestão, desenvolvimento e estratégia de produto. Somos patrocinados pela Crema, uma agência de produtos digitais que ajuda pessoas e empresas a prosperar através da criatividade, tecnologia e cultura. Saiba mais em crema.us. Continue a ouvir para obter ideias práticas e autênticas que o ajudarão a ter sucesso no mundo da gestão de produto.

Olá a todos. Estou muito entusiasmado por dar hoje as boas-vindas a Erin Hess ao programa. Tive o prazer pessoal de conhecer Erin quando ela trouxe recentemente os seus talentos para a nossa equipa na Crema, como engenheira sénior de testes. Erin tem um conjunto único de competências criativas e técnicas, adquirido ao longo de mais de 12 anos de experiência em várias funções no desenvolvimento e na engenharia de software.

Começou a sua carreira como representante de apoio ao cliente antes de se tornar uma programadora autodidata que desenvolveu gosto pelos testes de software. Defensora dos utilizadores por natureza, alguns dos principais pontos fortes de Erin incluem a empatia, a visualização e a antecipação de comportamentos e comunicações. Erin gosta de criar mapas de processos e imaginar onde poderão existir pontos problemáticos. Ao colocar-se no lugar dos outros, analisar os problemas de vários ângulos e compreender as consequências e benefícios a longo prazo das ações de hoje, Erin conseguiu fazer a diferença em todas as equipas e produtos a que se juntou.

Erin também ajuda as organizações a adotar e implementar práticas de design inclusivo, criando e divulgando informação sobre barreiras à usabilidade universal. Defende a acessibilidade e contribui continuamente com materiais de recursos para comunidades de testes online em constante crescimento.

Olá, Erin. Bem-vinda ao programa.

Erin Hess

Muito obrigada por essa excelente introdução, Michael. Estou muito contente por estar aqui.

Michael Luchen

Ótimo. Tenho de dizer que estou pessoalmente muito entusiasmado com esta conversa. Penso que uma das coisas relacionadas com a parceria entre o engenheiro de testes e o gestor de produto é que ela pode gerar alguns dos melhores resultados, mas não é muito discutida.

Está pronta para começar?

Erin Hess

Sem dúvida.

Michael Luchen

Muito bem.

Quero começar por uma perspetiva geral, talvez para alguns dos nossos ouvintes que estejam a tentar compreender esta função e não tenham um engenheiro de testes na sua equipa. Poderia começar por nos dizer quais são algumas das suas atividades preferidas enquanto engenheira de testes?

Erin Hess

Claro. Há muitas, e este é realmente um tema sobre o qual poderia falar sem parar. Há tantas atividades que podemos fazer enquanto testadores. Uma das minhas coisas preferidas, em geral, é criar relações e conhecer as equipas com que trabalho. Isso inclui o programador, o designer, os gestores de produto, outros engenheiros, o apoio ao cliente e, por vezes, até o marketing.

E, em projetos únicos, como um projeto de colaboração, conhecer também os recursos do lado do cliente. Encontrei um nicho na redação de documentação técnica. Por isso, gosto muito de ter tempo e espaço para fornecer o nível certo de detalhe e descrição, com ajudas visuais úteis.

Se puder ser criativa e acrescentar uma imagem de um gato sentado em frente a um computador, faço-o. Também gosto de aprender novas ferramentas e de trabalhar em conjunto com outros engenheiros. É algo que aguardo sempre com expectativa.

Michael Luchen

Ótimo. Como aborda a criação de relações com as suas equipas, sobretudo a partir da perspetiva de que um engenheiro de testes deve partir?

Erin Hess

Sou muito aberta e sei que todas as pessoas são um pouco diferentes. Não vou ter o mesmo tipo de conversa com o designer que teria com o programador e tenho isso em mente também relativamente ao responsável pelo produto. Por isso, sou muito aberta e tento dar à equipa o máximo de espaço e empatia possível.

Michael Luchen

Como encontra o equilíbrio entre criar esse espaço e demonstrar empatia, sobretudo quando sabe que todas as pessoas são diferentes e têm as suas próprias competências e disciplinas para trazer a uma equipa de produto?

Erin Hess:

Para mim, essa disciplina tem sido simplesmente a paciência e a prática: aprender, fazer retrospetivas comigo mesma e com a equipa sobre como correu tudo, sobre como cuidámos uns dos outros e sobre o que poderá ter sido difícil durante o ciclo. Não apenas o trabalho em si, mas também enquanto seres humanos, dando-lhes espaço para falarem comigo e terem esse tipo de conversas.

Michael Luchen

Isso é excelente. Saindo por um momento para uma perspetiva um pouco mais geral: quais são algumas das atividades típicas de um engenheiro de testes numa equipa de produto? Certamente não é apenas dizer que algo pode ser lançado — e sei que isto é uma piada.

Erin Hess

Não, de todo. Não fico simplesmente sentada com um carimbo com a palavra “aprovado” ou “reprovado”. Há muitas complexidades e muito mais criação de relações do que seria de esperar numa função técnica. Há muito trabalho e colaboração com diferentes partes da equipa, como trabalhar com o programador para melhorar a capacidade de criar e rever pedidos de integração.

Também se trabalha com um gestor de produto para obter o nível certo de detalhe nos critérios de aceitação e definir o padrão e a expectativa do que esses critérios devem conter.

Todas as histórias de utilizador e funcionalidades precisam de ser analisadas, não apenas pelos designers, programadores e restantes elementos, mas também pelas partes interessadas. Existem todas estas peças móveis diferentes. Enquanto engenheiro de testes, fazemos parte de tudo isso. Temos de acompanhar e comunicar com todas estas pessoas, porque, se não o fizermos, vamos perder alguma coisa e o risco de o produto não cumprir os requisitos aumenta.

Michael Luchen

Interessante. E isso liga-se ao que estava a dizer sobre encontrar o seu nicho na documentação técnica, porque ajuda a reunir todo esse contexto, certo?

Erin Hess

Também a uso como o meu segundo cérebro. Não espero lembrar-me de tudo, mas sei que a minha documentação é bastante boa, por isso posso consultá-la quando preciso, num projeto, ou para que outra pessoa a utilize.

Michael Luchen

Ao referir-se ao segundo cérebro, penso que algo que vi em primeira mão é que mantém toda essa documentação acessível publicamente à equipa de produto, certo?

Erin Hess

Sim.

Michael Luchen

Isso é… desculpe, continue.

Erin Hess

Ia dizer que está simplesmente disponível.

Não está escondida, fechada ou atrás de qualquer barreira de pagamento estranha. Está ali mesmo, disponível para ser consultada pela equipa. E quando crio algo, partilho-o sem dúvida.

Michael Luchen

Isso é realmente interessante. A documentação transparente é algo que penso que as equipas de produto, caso ainda não estejam a fazê-lo, deveriam esforçar-se por implementar. Não apenas na engenharia de testes, mas em todas as áreas que compõem uma equipa de produto, porque isso traz contexto — e o contexto é aquilo que torna a comunicação eficaz e ajuda a sua função a prosperar.

Para quem nos possa estar a ouvir e seja novo na função de engenharia de testes, ou que ainda não tenha tido a oportunidade de colaborar com um engenheiro de testes na sua equipa, qual é o melhor momento para este começar a colaborar com a equipa? É algum tempo depois do início do trabalho de produto? É perto do fim? É outro momento?

Erin Hess

Aprendi ao longo do tempo que, quanto mais cedo se conseguir envolver o engenheiro de testes, melhor. Algumas empresas consideram que estas pessoas estão apenas ali para preencher tarefas, escrever um teste e aprová-lo ou reprová-lo, sem grande envolvimento. Mas, quando queremos bons engenheiros de testes, pessoas que tragam mais do que apenas capacidades de teste, devemos envolvê-los antes do início oficial, durante a semana de contexto, e permitir-lhes perceber no que se estão a envolver, para que possam começar a imaginar muitas possibilidades.

Desde o início, podem até ajudar a contribuir para influenciar designs que permitam testes, influenciar o desenvolvimento e abordar os testes de acessibilidade [00:09:00], em vez de estes serem uma reflexão posterior.

Michael Luchen

Isso é excelente. Concordo totalmente. Para mim, tornou-se um risco enorme quando vejo uma equipa a iniciar o trabalho sem um engenheiro de testes desde o início, porque o contexto que se reúne a partir de todos esses ângulos é essencial para garantir que temos um produto testado com qualidade e que responde às necessidades dos utilizadores. É muito mais do que, como disse, uma espécie de carimbo que por vezes é passado de mão em mão.

Enquanto engenheira de testes, o que diria que é importante ter em mente durante um ciclo?

Erin Hess

Boa pergunta. Tenho algumas ideias. Em primeiro lugar, não sabemos aquilo que não sabemos, por isso não devemos ter receio de contactar a equipa quando temos uma dúvida ou preocupação, independentemente da gravidade que lhe atribuamos. Por vezes, uma pequena preocupação pode transformar-se numa melhoria significativa. Outra razão para falar é reduzir o risco e o custo de corrigir um problema, caso este não seja comunicado e chegue a ser lançado.

E não há “eu” no desenvolvimento de produto, tal como não há “eu” numa equipa. Não estamos a fazer isto sozinhos. Fazemos parte da equipa e não vamos ajudar ninguém se não dissermos que estamos a ter dificuldades. Uma das piores coisas que podemos fazer é esperar até ao fim de um ciclo para informar a equipa de que não conseguimos fazer algo. Por isso, devemos falar.

Michael Luchen

Sim. É fundamental, sobretudo vindo do lado da gestão de produto, porque ajuda a identificar se existem riscos importantes neste ciclo.

Sempre que começamos um ciclo como equipa de produto completa, temos uma visão limitada dos riscos que enfrentamos. Mas, como está a dizer, da perspetiva de um engenheiro de testes, pode haver algo identificado no início do ciclo que altere a trajetória desse ciclo, com boas intenções.

Erin Hess

Sim.

Michael Luchen

Entrando talvez na colaboração entre áreas, que sugestões tem para que os engenheiros de testes, designers e programadores estejam preparados para colaborar com sucesso?

Erin Hess

É certamente benéfico que designers e programadores trabalhem em conjunto com os engenheiros de testes durante o design e o desenvolvimento das histórias de utilizador, sempre que possível.

Pela minha experiência, aprendemos que existem oportunidades para trabalhar com o design e o desenvolvimento nas fases iniciais de um projeto. Isso dá-me mais informação para preparar cenários de teste, ficheiros de teste e escrever scripts de automatização. Neste momento, estou a melhorar os nossos critérios de aceitação e requisitos, incluindo Gherkin, para que, quando estivermos prontos para a automatização, a maior parte do trabalho já esteja concluída.

Michael Luchen

Interessante. Mencionou vários conceitos, como cenários de teste. O que são exatamente? É percorrer os critérios de aceitação que eu, enquanto gestor de produto, escrevo, ou é algo mais complexo?

Erin Hess

É um pouco das duas coisas. Pegamos nos critérios de aceitação que a equipa e o gestor de produto analisaram e melhoraram em conjunto. Depois, nos cenários de teste, definimos: sendo este tipo de utilizador, neste tipo de dispositivo, o que estou a fazer? Qual é o resultado esperado? Quais são os riscos? Que coisas posso querer tentar tratar de forma inadequada? Criamos diferentes fluxos completos daquilo que um utilizador poderia potencialmente fazer nesse teste.

Michael Luchen

Quando lançamos um produto, existem tantos locais e situações em que pode ser utilizado: vários navegadores, diferentes resoluções de ecrã, diferentes dispositivos e muito mais. Através desses cenários de teste, quer colocar o produto numa situação difícil.

Como determina, neste âmbito enorme de tudo aquilo que poderia testar, onde deve concentrar os esforços?

Erin Hess

Aprendi que é possível exagerar nos testes. Podemos exagerar nos testes de acessibilidade, fazendo demasiado e com demasiada frequência em páginas que não precisam necessariamente de ser testadas dessa forma.

Podemos perder completamente o controlo dos testes. Para os reduzir a uma dimensão razoável, são necessários tempo, prática e alguma reflexão prévia. É preciso pensar no tipo de projeto que temos: será uma aplicação web, uma aplicação nativa ou algo que apenas funcionará em iPhones?

Depois pensamos em todas as formas de testar e começamos a eliminar aquilo que sabemos que não será necessário testar. Construímos a nossa matriz de testes: preciso deste dispositivo com este navegador e este tipo de configuração para este tipo de utilizador.

Michael Luchen

Ao definir os seus cenários de teste e onde se deve concentrar, consulta regularmente estatísticas de utilização de navegadores e dispositivos? E como determina o que é relevante para o produto em que está a trabalhar?

Erin Hess

Existem muitos recursos que utilizo, tal como muitos engenheiros de testes, que nos informam sobre as combinações mais práticas para testar. Qual é a utilização atual de determinado navegador num dispositivo específico ou de determinada versão do navegador?

Quantas pessoas estão realmente a utilizar estas aplicações, produtos e serviços? Usamos essa informação para decidir que queremos verificar Safari e Chrome, iOS e Android. Depois podemos listar elementos de menor risco que gostaríamos de testar se tivermos tempo, como Edge ou outro navegador menos importante, mas que seria interessante saber se suporta a aplicação.

Michael Luchen

Também estou curioso: existem testes com utilizadores ou inquéritos que possam ajudar a determinar onde testar?

Erin Hess

Pessoalmente, não fiz muitos inquéritos de utilizadores, mas gosto de os preencher e de dar essa opinião. Seria algo interessante para obter feedback diretamente dos utilizadores reais. Tenho definitivamente em conta qual é a experiência média esperada para este tipo de aplicação e parto daí.

Michael Luchen

Antes de avançarmos, também tenho de perguntar sobre outra coisa que mencionou recentemente: escreve scripts de automatização. Qual é o valor da automatização num produto e porquê e quando deve ser introduzida?

Erin Hess

Esta é uma daquelas situações de “depende”. Se o projeto for de longo prazo, contínuo, tiver uma equipa sólida e não houver um fim à vista, isso pode ser adequado para a automatização. Podemos começar pelos testes manuais e classificá-los com base no risco e na funcionalidade.

Depois pensamos no tipo de estrutura de automatização que queremos utilizar ou se preferimos uma solução baseada na web e com pouco código. Existem muitas opções. A partir daí, pensamos no que faz mais sentido fazer primeiro, mesmo que seja um projeto novo a começar do zero.

Pensar na automatização desde cedo não faz mal, porque existem partes, antes do desenvolvimento e durante o design, em que podemos trabalhar com essas equipas. Por exemplo, criar etiquetas de acessibilidade nos componentes.

É algo que estamos a fazer atualmente em Gherkin, para ter algum código e alguns scripts escritos antes de existir sequer um produto. Isto pode poupar tempo e ajuda a planear melhor quando é feito em paralelo com o design, o desenvolvimento e os testes.

Acrescenta outra camada de complexidade ao trabalho do engenheiro de testes durante cada ciclo. Além dos critérios de aceitação e da redação e revisão dos casos de teste, somos quase pequenos programadores ao escrever e rever os critérios de aceitação destinados aos scripts de automatização.

Por isso, começar cedo é ótimo, mas normalmente acontece quando sentimos que existe essa necessidade: acelerar o processo geral de testes e também estabilizá-lo.

Michael Luchen

Interessante. Mudando de função na equipa, e falando de forma um pouco egoísta, como aborda a colaboração com gestores de produto?

Erin Hess

Gosto de criar relações com a equipa. Não se trata de hierarquia; quero que todas as pessoas da equipa colaborem e trabalhem umas com as outras, e gosto de ajudar esse processo. Gosto tanto de trabalhar com os gestores de produto como com os programadores e designers.

Parte disso consiste em colaborar e ajudar com os critérios de aceitação, fazer investigação ou reunir informação sobre algo que lhes interesse mais. Talvez possamos experimentar uma determinada abordagem para esse tipo de teste. Se o gestor de produto precisar de alguma coisa e eu puder ajudar, intervenho.

Michael Luchen

Como referi anteriormente, penso que a parceria entre o engenheiro de testes e o gestor de produto é uma das mais impactantes numa equipa de produto, particularmente devido ao foco nos critérios de aceitação e na forma como as coisas serão validadas antes de serem disponibilizadas aos utilizadores.

Pessoalmente, considero que existe um equilíbrio muito positivo quando os gestores de produto e os engenheiros de testes colaboram desde cedo nos critérios de aceitação. Os gestores de produto podem trazer uma perspetiva centrada nos resultados que queremos alcançar para o utilizador, enquanto o engenheiro de testes traz atenção aos detalhes e garante que todas as lacunas são cobertas num nível adequado, permitindo ainda a criatividade do resto da equipa de produto.

Dessa forma, podemos garantir que é lançado e testado um produto de qualidade que responde às necessidades dos utilizadores. Concorda com esse equilíbrio?

Erin Hess

Concordo totalmente. Já estive em situações em que o engenheiro de testes não era envolvido desde o início e agora tenho uma visão muito clara sobre isso. Valorizo verdadeiramente poder participar desde o princípio.

Michael Luchen

É muito claro quando se passa pela experiência de uma equipa de produto sem um engenheiro de testes. A diferença é enorme e torna-se evidente como as coisas podem correr mal.

Falou anteriormente sobre ser uma grande defensora da acessibilidade. Pode explicar um pouco o que isso significa?

Erin Hess

A palavra acessibilidade é utilizada muitas vezes atualmente. É um tema muito debatido. Também é conhecida como “A11Y”, porque existem 11 letras entre o A e o Y da palavra inglesa “accessibility”. Ser defensora significa ser uma voz para todos os diferentes utilizadores finais. Significa defender que as funcionalidades e o desenvolvimento de produtos e serviços sejam acessíveis a todas as pessoas. É muito sobre inclusão, diálogo e descobrir como podemos usar a nossa voz para ajudar outra pessoa.

Michael Luchen

Às vezes, as partes interessadas dizem que não têm capacidade para dar prioridade a estas questões de acessibilidade. Como responde a isso?

Erin Hess

Já o fiz de várias formas e descobri que, para algumas partes interessadas, a abordagem mais eficaz é mostrar os valores e o impacto financeiro que um sítio web não conforme pode ter na empresa. O risco de uma ação judicial é real e a situação pode tornar-se complicada.

É difícil recuperar e deixa uma impressão negativa quando as pessoas descobrem que não se teve em consideração todo um grupo de utilizadores finais. Talvez essa não tenha sido a intenção, mas é assim que provavelmente será interpretado.

Michael Luchen

Pode falar um pouco mais sobre a empatia como base dos testes?

Erin Hess

Provavelmente, a maioria das pessoas já ouviu a expressão “colocar-se no lugar de outra pessoa”, que é outra forma de falar sobre empatia. É a capacidade de compreender ou sentir aquilo que outra pessoa está a experienciar a partir da sua perspetiva. A definição de empatia pode abranger uma grande variedade de emoções.

Fiz uma apresentação especificamente sobre empatia e testes no evento TestBash da comunidade Ministry of Testing, que decorreu no início deste ano, com a minha amiga Jenny Bramble. Falámos sobre os nossos sentimentos e sobre como “A empatia é a base dos testes”, sobre o que isso significa e sobre como as nossas histórias pessoais nos colocam numa posição única para falar de empatia e das necessidades dos clientes.

Michael Luchen

Muito interessante. Em poucas palavras, o que faz da empatia a base dos testes? Quais são as práticas concretas?

Erin Hess

Em última análise, existe uma interseção entre testes e empatia. Não podemos conhecer as expectativas de alguém se não conhecermos a sua experiência.

Colocarmo-nos na experiência de outra pessoa é uma parte importante dos testes. Fazemo-lo constantemente, mesmo sem pensar nisso. Por exemplo, testar um tema de alto contraste ou um tipo de letra para pessoas com dislexia. Existe uma razão para essas funcionalidades. Em última análise, a interseção entre testes e empatia enquadra-se plenamente nos testes de acessibilidade.

Michael Luchen

É muito interessante conversar consigo e ver alguns temas a surgir, como a interseção entre ser uma defensora da acessibilidade e a forma como a empatia está presente em tudo o que faz enquanto engenheira de testes. E também a importância da colaboração para essa função, não apenas com o gestor de produto, mas com toda a equipa de produto.

Antes de terminarmos, gostaria de fazer algumas perguntas pessoais rápidas, se estiver de acordo.

Erin Hess

Força.

Michael Luchen

Qual dos seus hábitos pessoais mais contribuiu para o seu sucesso?

Erin Hess

Diria que é sem dúvida a minha capacidade de criar estrutura e organizar grandes quantidades de informação, algo que desenvolvi ao longo do tempo.

É como um dos meus superpoderes. Penso que surgiu da minha obsessão por organizar e pela organização em geral, bem como da paixão por escrever documentação boa, útil e significativa.

Michael Luchen

E qual é a sua ferramenta preferida, que utiliza regularmente?

Erin Hess

Diria que é definitivamente o Chrome DevTools, por muitos motivos. Destacaria o Modo de dispositivo, que pode ser utilizado para simular dispositivos móveis, testar a capacidade de adaptação e diferentes áreas de visualização. O painel Rede é o meu melhor amigo. Utilizo-o quando entro nas ferramentas de desenvolvimento para investigar qualquer problema que encontre. Se deteto um defeito, começo por aí. Depois, o Lighthouse e o Axe, para testes de acessibilidade.

Michael Luchen

Última pergunta: para alguém que está no início do seu percurso no mundo dos produtos, que conselho lhe daria?

Erin Hess

Diria para estar aberto a aprender tudo, independentemente de quem ensina. Se um programador, designer ou gestor de produto quiser partilhar consigo algo ou precisar do seu tempo, aceite. Use isso como uma oportunidade de aprendizagem e aproveite a experiência.

Michael Luchen

Muito bem dito. Aprendi certamente muito hoje. Muito obrigado por ter vindo ao programa, Erin.

Erin Hess

Eu é que agradeço. Obrigada pelo convite e espero poder falar ainda mais sobre testes de acessibilidade e engenharia de testes em geral.

Michael Luchen

Estou muito entusiasmado por aprofundar estes temas. Para quem nos está a ouvir e quer saber mais sobre Erin, pode conhecer melhor o trabalho dela em crema.us. Também a pode encontrar no LinkedIn. Erin está igualmente ativa no Twitter, onde pode ser encontrada através do identificador @QueenTester.

Se gostou do programa de hoje, consulte a nossa publicação relacionada, a QA Lead, onde exploramos as novidades e o melhor da automatização e dos testes. Pode visitá-la em theqalead.com.

Mais uma vez, muito obrigado, Erin, por se juntar ao programa. Este foi um episódio fantástico. Obrigado a todos por ouvirem. Não se esqueçam de deixar uma avaliação deste podcast. Gostaria muito de receber o vosso feedback e, além disso, sigam e juntem-se à nossa comunidade em theproductmanager.com. Obrigado.