Conceção de testes: uma competência essencial de QA

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

A conceção de testes é a base negligenciada dos testes bem-sucedidos em produção. Embora as empresas se concentrem na automatização e nos processos, negligenciam esta competência crítica. Descubra por que motivo uma conceção adequada de testes melhora drasticamente os resultados dos testes em produção e como dominá-la.

Test design standard editorial post

Uma das principais ideias erradas no panorama atual dos testes é que testar em produção requer apenas três conjuntos de competências: experiência em processos, conhecimento de ferramentas de testes automatizados e capacidades de gestão de incidentes. Estas são importantes, mas há algo cuja ausência é evidente — não só nesta lista, mas também na mente dos responsáveis pela contratação — e que seria de esperar que fosse o mais fundamental:

A capacidade de conceber um teste prático para ambientes de produção.

Seria cómico se não fosse tão alarmante o facto de quase nenhuma organização dar prioridade à experiência nas principais competências de QA ao implementar estratégias de testes em produção.

Quer um teste seja executado manualmente ou através de automatização num sistema de produção ativo, é necessário primeiro saber conceber um teste que forneça informações acionáveis sem perturbar a experiência do utilizador, certo?

Seria cómico se não fosse tão alarmante o facto de quase nenhuma organização dar prioridade à experiência na conceção de testes ao implementar estratégias de testes em produção. Quer um teste seja executado manualmente num ambiente controlado ou automatizado num sistema de produção ativo, é necessário primeiro saber conceber um teste que forneça informações acionáveis sem perturbar a experiência do utilizador, certo?

Há um problema óbvio em excluir a experiência na conceção de testes da sua abordagem de testes em produção:

Não é essencial saber se a pessoa que implementa testes no seu ambiente de produção compreende o que constitui um teste relevante?

Uma vez que automatizar testes mal concebidos em produção fornece dados pouco fiáveis mais rapidamente e cria riscos desnecessários? E ser "ágil" enquanto se testa em produção de forma incompetente não me parece uma melhoria real, exceto talvez para o mestre de Scrum.

A importância e a disciplina da conceção de testes, especialmente em cenários de testes em produção, já deveriam ter sido recuperadas há muito. Considerem este o meu contributo para esse esforço.

O que é essencial para realizar testes eficazes em produção?

O primeiro passo para dominar os testes em produção consiste em estabelecer algumas distinções essenciais que, sem dúvida, já serão intuitivamente familiares à maioria dos profissionais de QA, mas que raramente são apresentadas de forma sistemática em contextos de testes em produção.

Vamos explorar estes conceitos fundamentais que transformarão a sua abordagem aos testes em produção.

Funcionalidade explícita vs. implícita em ambientes de produção

Comecemos pela distinção crítica entre funcionalidade explícita e implícita ao testar em produção.

A primeira é aquilo que a maioria de nós entende por "funcionalidade". Refere-se a funcionalidades e capacidades formalmente especificadas pelo Produto, cuja especificação formal orienta a implementação na Engenharia. Ao testar em produção, estas funções explícitas são normalmente o foco das ferramentas de monitorização e observabilidade.

Por este motivo, testar funcionalidades explícitas em produção pode parecer simples, mas mesmo no caso de funcionalidades bem definidas, não é esse o caso, como veremos mais adiante. Pelo menos, o nível de especificidade inerente à funcionalidade explícita facilita a criação de uma estrutura de testes de produção em torno dela (ou da ilusão dessa estrutura).

A funcionalidade implícita num ambiente de produção é algo completamente diferente.

Consiste em comportamentos e respostas a dados introduzidos pelo utilizador ou pelo ambiente que não foram formalmente definidos nem previstos. A incapacidade de conceber adequadamente testes para esta funcionalidade implícita em produção é, de longe, a origem da maioria dos erros críticos descobertos depois de o produto ter sido implementado (a outra é a realização inadequada de testes em ambientes periféricos de hardware/software/dispositivos).

Por outras palavras:

Testar funcionalidades implícitas em produção exige bastante engenho e imaginação. É a parte verdadeiramente criativa das estratégias de testes em produção.

Testar funcionalidades implícitas em ambientes de produção exige uma certa dose de astúcia diabólica para se tornar competente, e, infelizmente, isso não pode ser ensinado através dos processos padrão de QA.

Nenhuma quantidade de metodologia ágil ou de estruturas de testes automatizados lhe ensinará a testar eficazmente funcionalidades implícitas em produção, mas uma conceção adequada de testes pode incentivá-lo.

Então, como se define uma estratégia de conceção de testes para funcionalidades implícitas no seu ambiente de produção? Felizmente, é possível fazê-lo. Mas, antes de abordarmos diretamente essa questão, vamos explorar mais algumas distinções relevantes e fundamentais para realizar testes eficazes em produção.

Testes positivos vs. negativos

Conclusão principal: Ao testar em produção, tanto os testes positivos como os negativos exigem considerações especiais que vão além das abordagens tradicionais de QA.

A maioria das pessoas que trabalham em QA compreende a diferença básica entre estes dois tipos de testes:

  • Testes positivos em produção: Validar que as funcionalidades funcionam conforme concebidas em ambientes ativos
  • Testes negativos em produção: Testar estrategicamente como o sistema responde a entradas inesperadas sem perturbar os utilizadores reais

Porque é que os testes em produção são diferentes

Embora estas distinções sejam conceptualmente claras, os testes em produção introduzem desafios únicos:

  • Riscos maiores: Os casos-limite afetam clientes reais e as operações da empresa
  • Complexidade do mundo real: Os comportamentos dos utilizadores raramente seguem padrões previsíveis
  • Continuidade do negócio: Os testes não devem perturbar as operações normais

Para além da especificação

As especificações raramente fornecem tudo o que é necessário para realizar testes eficazes em produção:

Depender demasiado da especificação — quer seja da área de Produto ou de Engenharia — limita o seu pensamento. Isto é especialmente problemático ao testar em produção, onde os padrões de utilização no mundo real se desviam frequentemente das especificações.

Este é um exemplo daquilo a que chamo "a falácia empírica": esperar que algo lhe diga explicitamente o que fazer antes de o conseguir compreender.

Uma conceção de testes bem-sucedida para ambientes de produção exige:

  1. Parametrização adequada da funcionalidade
  2. Pensamento lógico sobre aquilo que é possível
  3. Consideração das interações dos utilizadores e do ambiente

Exemplo do mundo real: comportamentos inesperados

Na era do Cretáceo do software (ou seja, nos anos 80), testei software de conversão de documentos e descobri capacidades surpreendentes:

Mostrar imagem

Exemplo clássico: No WordPerfect, era possível inserir um comando de espaçamento entre linhas a meio de um parágrafo, afetando apenas as linhas seguintes e criando parágrafos com dois valores de espaçamento diferentes.

Equivalentes modernos ao testar em produção:

  • Combinações inesperadas de permissões de utilizadores em aplicações na nuvem
  • Sequências de pedidos à API não previstas em arquiteturas de microsserviços
  • Condições de corrida em ambientes de elevada simultaneidade

Vamos agora explorar os três parâmetros fundamentais que irão aperfeiçoar a sua abordagem aos testes em produção:

1. Testes do âmbito das funcionalidades

Definição: Identificar de que formas os utilizadores podem implementar funcionalidades em contextos ou de maneiras nunca imaginados durante a conceção.

Porque é importante para os testes

Nem todas as restrições são previstas durante o desenvolvimento. Em ambientes de produção, esta falha pode ter consequências graves.

Para além da validação simples

Ao testar em produção, considere estes limites:

Lembre-se: Validar uma funcionalidade em produção não consiste apenas em confirmar que funciona conforme concebida, mas também em verificar que não pode ser utilizada de formas não previstas que possam afetar a estabilidade ou a segurança do sistema.

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

2. Testes de interrupção de fluxos de trabalho em sistemas ativos

Aviso: Esta abordagem pressupõe que já está a testar fluxos de trabalho definidos em produção. Caso contrário, trate primeiro desses fundamentos!

Para além do "caminho feliz"

Ao testar em produção, explore estas interrupções críticas dos fluxos de trabalho:

✅ Fluxos de trabalho interrompidos: O processo foi iniciado, mas nunca foi concluído
✅ Operações canceladas: O utilizador cancela explicitamente a meio do processo
✅ Processos reiniciados: O utilizador tenta realizar a mesma ação várias vezes
✅ Retrocesso: O utilizador regressa a passos anteriores com entradas diferentes

Dicas de implementação para testes em produção

Utilize técnicas como sinalizadores de funcionalidades para controlar de forma segura a exposição destes testes em ambientes de produção.

Aplicações no mundo real

Dica profissional: Estes cenários raramente são incluídos nas especificações, mas representam comportamentos reais dos utilizadores em produção.

3. Sequencialidade nos testes em produção

O desafio: Nos sistemas de produção com vários processos simultâneos, a sequência das operações pode provocar falhas inesperadas que são difíceis de reproduzir em ambientes de teste.

Dois padrões críticos de sequencialidade

Condições contribuintes antecedentes

Mostrar imagem

  • Definição: Eventos que têm de ocorrer antes de um processo falhar
  • Características: Podem apenas manifestar-se após sequências específicas que demoram dias a ocorrer naturalmente
  • Exemplo em produção: Permissões do utilizador modificadas → a cache expira → uma API específica é chamada

Condições contribuintes subsequentes

  • Definição: Falhas que só se tornam evidentes através de interações posteriores
  • Manifestação: A falha permanece mascarada até uma operação posterior
  • Exemplo em produção: Ocorre corrupção de dados silenciosamente até ser gerado um relatório

Porque é isto tão desafiante?

Definir o âmbito dos testes de sequencialidade em produção exige:

  1. Conhecimento aprofundado das interações do sistema
  2. Modelação das transições de estado para processos complexos
  3. Compreensão das combinações de estados pretendidas e não pretendidas

"Tal como aqueles valores duplos de espaçamento entre linhas num único parágrafo, estes estados inesperados podem causar o caos nos ambientes de produção."

Ferramentas essenciais para testar a sequencialidade em produção

Em suma: Os problemas de sequencialidade representam uma das fontes mais ricas de erros graves nos sistemas de produção modernos. Dê prioridade a este aspeto na sua estratégia de testes.

A conclusão

As funcionalidades condicionais transformam os testes em produção, passando de uma prática arriscada para um processo controlado e orientado por dados. Ao dissociarem a implementação do lançamento e ao disponibilizarem capacidades de reversão imediata, criam uma rede de segurança que permite às equipas validar o software em condições reais sem comprometer a experiência do utilizador ou a estabilidade do sistema.

Plataformas de gestão de funcionalidades nos testes em produção

As plataformas de gestão de funcionalidades transformaram os testes em produção, passando de uma atividade arriscada para um processo controlado e sistemático. No entanto, muitas organizações não conseguem tirar partido destas ferramentas de forma eficaz na sua estratégia de conceção de testes.

A evolução da gestão de riscos em produção

As abordagens tradicionais aos testes em produção envolviam decisões binárias — uma funcionalidade estava ativa para todos ou para ninguém. As plataformas de gestão de funcionalidades alteram fundamentalmente este paradigma:

  • Controlo granular: Testar funcionalidades com segmentos de utilizadores específicos, em vez de implementações do tipo tudo ou nada
  • Correção imediata: Desativar funcionalidades problemáticas sem implementações de código ou reversões
  • Exposição progressiva: Aumentar gradualmente a exposição dos utilizadores com base em dados de desempenho em tempo real

Para além das funcionalidades condicionais simples

Embora a utilização básica de funcionalidades condicionais exista há anos, as plataformas modernas de gestão de funcionalidades disponibilizam capacidades críticas que transformam os testes em produção:

Quando integradas corretamente na sua estratégia de conceção de testes, as plataformas de gestão de funcionalidades permitem:

  1. Contenção direcionada dos riscos - Limitar a exposição a novas funcionalidades a segmentos de utilizadores específicos
  2. Validação com utilizadores reais - Testar com utilizadores reais, em vez de dados de teste sintéticos
  3. Correção imediata - Resolver problemas sem implementações de emergência ou reversões

Integração com ferramentas de observabilidade

O verdadeiro poder das plataformas de gestão de funcionalidades manifesta-se quando estas são integradas com sistemas de observabilidade e monitorização:

Abordagem tradicional:

  • Detetar problemas após a implementação completa
  • Verificação manual dos resultados dos testes
  • Análise pós-incidente após a ocorrência de incidentes

Integração da gestão de funcionalidades:

  • Correlacionar a ativação de funcionalidades com as métricas do sistema
  • Monitorização automatizada do desempenho por sinalizador de funcionalidades
  • Informações em tempo real sobre o impacto das funcionalidades

Impacto no mundo real: transformar os testes em produção

As organizações que implementam plataformas de gestão de funcionalidades relatam benefícios significativos:

  • Redução da gravidade dos incidentes: "Podemos testar funcionalidades em produção muito antes do lançamento de uma campanha de marketing. E, se uma funcionalidade causar problemas no dia do lançamento, podemos simplesmente desligá-la com um interruptor de emergência — sem reversões." — Chris Guidry, VP de Engenharia, O'Reilly Media.
  • Ciclos de lançamento acelerados: As equipas da IBM, da TrueCar e de outras empresas líderes utilizam a gestão de funcionalidades para testar em produção, usufruindo do que descrevem como "lançamentos seguros e sem cerimónias".
  • Maior cobertura de testes: Os sinalizadores de funcionalidades expõem casos-limite impossíveis de simular em ambientes controlados.

Implementação prática na conceção de testes

Para incorporar eficazmente as plataformas de gestão de funcionalidades na sua estratégia de conceção de testes:

  1. Conceba pontos de verificação alinhados com as transições dos sinalizadores de funcionalidades
  2. Crie cenários de recurso para cada componente controlado por sinalizadores de funcionalidades
  3. Estabeleça limiares de desempenho que acionem a desativação automática de funcionalidades
  4. Defina casos de teste específicos por segmento para validar o comportamento em diferentes populações de utilizadores
  5. Documente as dependências dos sinalizadores para evitar falhas em cascata

As plataformas de gestão de funcionalidades não substituem uma conceção cuidadosa dos testes — amplificam-na. A qualidade dos seus testes em produção continua a depender fundamentalmente da qualidade da conceção dos seus testes.

Erros comuns a evitar

Mesmo com uma gestão robusta de funcionalidades, continuam a existir vários desafios:

  • Dívida de sinalizadores - Sinalizadores abandonados ou esquecidos que criam dívida técnica
  • Monitorização insuficiente - Incapacidade de correlacionar o estado dos sinalizadores com o desempenho do sistema
  • Excesso de confiança - Redução prematura dos testes de pré-produção
  • Interdependências entre sinalizadores - Criação de relações complexas e difíceis de resolver

Em suma

As plataformas de gestão de funcionalidades oferecem capacidades poderosas para testar em produção, mas devem ser cuidadosamente integradas na sua estratégia global de conceção de testes. As organizações que obtêm mais valor não se limitam a implementar estas ferramentas — repensam fundamentalmente o funcionamento da conceção de testes num ambiente com sinalizadores de funcionalidades.

Quando devidamente implementada como parte de uma abordagem abrangente à conceção de testes, a gestão de funcionalidades transforma os testes em produção de um mal necessário numa vantagem competitiva.

Ferramentas para testar em produção: desafios de implementação

Embora os sinalizadores de funcionalidades e as plataformas de gestão constituam a base dos testes em produção, o ecossistema mais amplo de ferramentas apresenta os seus próprios desafios de implementação. A seleção e configuração das ferramentas certas exige uma análise cuidadosa das capacidades da equipa, da arquitetura do sistema e das necessidades organizacionais.

Ferramentas de monitorização e observabilidade

Testar eficazmente em produção depende de uma visibilidade abrangente do comportamento do sistema:

  • Monitorização do Desempenho das Aplicações (APM)
    Benefícios: Fornece informações detalhadas sobre o desempenho em toda a pilha da aplicação.
    Desafios: Exige frequentemente uma instrumentação significativa e pode gerar dados excessivos que sobrecarregam as equipas mais pequenas.
  • Sistemas de gestão de registos
    Benefícios: Essenciais para a depuração e a análise forense durante os testes em produção.
    Desafios: Podem gerar volumes de dados excessivos sem estratégias adequadas de filtragem e indexação.
  • Rastreio distribuído
    Benefícios: Oferece visibilidade de ponta a ponta em arquiteturas de microsserviços.
    Desafios: A complexidade da implementação aumenta drasticamente em ambientes heterogéneos com várias pilhas tecnológicas.

Sistemas de Gestão de Alertas

Uma definição adequada de alertas é fundamental ao testar novas funcionalidades em produção:

  • Plataformas de Agregação de Alertas
    Vantagens: Consolidam notificações provenientes de vários sistemas de monitorização.
    Desafios: São excelentes para a gestão de incidentes, mas podem ser perturbadoras se não forem cuidadosamente configuradas para evitar a fadiga causada pelos alertas.
  • Sistemas de Resposta a Incidentes
    Vantagens: Tornam mais eficientes as comunicações durante incidentes em produção.
    Desafios: Requerem procedimentos operacionais bem definidos e pontos de integração para serem eficazes; podem criar sobrecarga em implementações simples.

More Articles

Considerações de Implementação

Ao implementar ferramentas para testes em produção, as equipas devem avaliar:

  1. Requisitos de escalabilidade - A ferramenta suportará os seus volumes de tráfego e o crescimento dos dados?
  2. Capacidades de integração - Com que facilidade se liga ao seu conjunto de ferramentas existente?
  3. Consumo de recursos - Que sobrecarga é introduzida pela própria ferramenta?
  4. Conhecimentos da equipa - Dispõe das competências necessárias para maximizar o valor da ferramenta?
  5. Relação sinal-ruído - Consegue extrair informações relevantes sem se perder num excesso de dados?

Armadilhas Comuns na Implementação

  • Proliferação de ferramentas - Acumulação de demasiadas soluções sobrepostas
  • Instrumentação incompleta - Ausência de pontos críticos de monitorização
  • Fadiga causada pelos alertas - Geração de notificações excessivas que as equipas acabam por ignorar
  • Contexto insuficiente - Incapacidade de correlacionar métricas com o impacto nos utilizadores
  • Ilhas de dados - Criação de sistemas de monitorização isolados que não partilham informações

Encontrar o Equilíbrio Adequado

As implementações de testes em produção mais bem-sucedidas alcançam um equilíbrio entre:

  • Monitorização abrangente vs. complexidade controlável
  • Informações detalhadas vs. excesso de informação
  • Respostas automatizadas vs. pontos de decisão humanos

Ao implementar ferramentas de teste em ambientes de produção, comece com objetivos específicos e de pequena dimensão e, em seguida, alargue gradualmente a cobertura à medida que a sua equipa desenvolve conhecimentos tanto sobre as ferramentas como sobre a interpretação dos dados resultantes.

Carga, Complexidade, Latência

Considere os fatores macro de carga, complexidade e latência do sistema na conceção dos seus testes. Estes podem afetar a execução ou a conclusão de um pedido, processo, ou evento. 

A relevância da carga do sistema deverá ser óbvia. A forma como os pedidos ou as transações são processados durante períodos de elevada carga de stress do sistema pode falhar (em qualquer fase do processo de transação).

Esta deve ser uma parte predefinida do planeamento dos seus testes. Como todos sabemos, a carga também pode ser gerada pelo próprio pedido — por exemplo, uma consulta de dados que desencadeia o processamento e a transmissão de grandes quantidades de dados.

Complexidade refere-se aqui principalmente à complexidade dos pedidos efetuados a um sistema. Esta complexidade pode consistir no número de condições especificadas (e nas respetivas exclusões e exceções), no número de bases de dados (virtuais ou não) envolvidas nos pedidos ou na própria topologia de processamento do sistema.

No contexto desta discussão, utilizo latência para indicar a introdução de intervalos de tempo no processo do pedido, o que não corresponde ao seu significado habitual. Refiro-me aqui à latência do utilizador, não à latência de resposta do próprio sistema. 

Por outras palavras, como se comporta a funcionalidade ou capacidade se o utilizador chegar a um passo específico do processo e ficar depois em pausa, sem fazer nada? O sistema excede o tempo limite (provavelmente deveria fazê-lo)? Deve solicitar uma ação ao utilizador? Deve permanecer nesse estado até ao fim dos tempos? 

As respostas a estas perguntas podem estar presentes na especificação, mas o produto em teste pode não comportar-se dessa forma, o que é precisamente a razão pela qual testamos.

Funções dos Utilizadores

É claro que os utilizadores finais podem interagir com sistemas de software assumindo várias funções. O mesmo utilizador pode interagir com o sistema assumindo funções diferentes, dependendo das suas ações. 

No entanto, os processos e serviços também podem ter funções diferentes e privilégios associados. Em qualquer dos casos, certifique-se de que a conceção e o planeamento dos seus testes, quer para funcionalidades quer para capacidades, considera e testa todos os estados de função possíveis.

E agora?

Procura mais dicas sobre conceção de testes? E quer desenvolver as suas competências de crescimento e liderança em SaaS?

Subscreva o nosso boletim informativo para receber as informações mais recentes de CTOs e futuros líderes tecnológicos. 

Ajudá-lo-emos a crescer de forma mais inteligente e a liderar com mais força, através de guias, recursos e estratégias dos melhores especialistas!

Niall Lynch
Niall Lynch was born in Oslo, Norway and raised in Fairbanks, Alaska, 100 miles south of the Arctic Circle. He received a BA in Religion from Reed College, and an MA in Ancient Near Eastern Literature Languages from the University of Chicago. Which of course led directly to a career in software development. Niall began working in software in 1985 in Chicago, as a QA Lead. He knew nothing about the role or the subject at the time, and no one else did either. So he is largely self-taught in the discipline. He has worked over the years in the fields of file conversion, natural language processing, statistics, cybersecurity (Symantec), fraud analysis for the mortgage industry, artificial intelligence/data science and fintech. Learning how to adapt his QA methods and philosophy to these wildly different industries and target markets has been instructive and fruitful for their development. And his. He now lives in Palm Desert, California, where he does SQA consulting and is writing a couple of novels. Send questions or jokes to NiallLynch@outlook.com

You may also like