Por que a taxa de aprovação não é um fator determinante? Release Signal

O que significa "bom o suficiente para ser enviado"? na verdade significa – e quemat suas métricas atuais não são dizering tua

A taxa de aprovação não é um sinal de liberação. Aqui está o que é. 

É quinta-feira à tarde. Release Está agendado para sexta-feira de manhã. 

Você abre o painel de controle. Taxa de aprovação de 94%. Os testes reprovados são aqueles que você já viu antes – intermitentes, geralmente passando em verde em uma nova execução. Você os executa novamente. Verde. Você encerra a sessão. 

Na manhã de sábado, seu telefone vibra. 

Usuários estão relatando desconexões aleatórias de sessão. A equipe de engenharia está em alerta máximo. A causa raiz: uma condição de corrida na atualização do token de autenticação. A mesma instabilidade que um teste inconsistente vinha sinalizando por quatro sprints consecutivos – enquanto a equipe aprendia a executar o teste novamente até que tudo desse certo e, então, prosseguir. 

O sinal estava lá o tempo todo. Você é que não o estava interpretando. 

A métrica que todos acompanham. A pergunta que ela não consegue responder. 

A taxa de aprovação é a métrica mais comum em controle de qualidade para dispositivos móveis. Também é uma das menos úteis para tomar decisões de lançamento. 

Uma contagem de 847 aprovações e 23 reprovações não diz nada à liderança sobre o risco. Não revela se essas 23 reprovações afetam um fluxo de pagamento crítico ou uma página de configurações obscura. Não mostra se as reprovações estão aumentando ao longo das versões ou representam regressões isoladas.1] 

Uma taxa de aprovação de 94% não é um sinal de lançamento. É apenas uma contagem. E contagens sem contexto não respondem à pergunta que importa antes de cada lançamento: Onde se concentra o risco nesta construção? 

Uma falha no fluxo de confirmação de pagamento não representa o mesmo risco que uma falha em um caso extremo raramente utilizado. No entanto, a taxa de aprovação as trata da mesma forma.2] 

Se isso não lhe soou familiar, estas opções lhe serão úteis. 

Essa história inicial é uma versão de um padrão que se repete de diferentes formas em quase todas as equipes de desenvolvimento mobile. Os detalhes mudam. A causa raiz, não: o sinal estava lá, e ninguém tinha um sistema para interpretá-lo. 

Aqui estão mais duas situações que você provavelmente já vivenciou. 

A falha passou despercebida porque o número parecia normal. 

Sprint 6. Um único teste, que abrange a tela de confirmação de pagamento, começa a falhar. 1 falha em 847 – taxa de aprovação de 99.8%. Parece ser ruído. O produto é lançado. 

Três dias depois, os usuários relataram que não estavam recebendo os e-mails de confirmação de pedidos. Uma integração subsequente apresentou uma falha silenciosa, e o único teste que a abrangia foi justamente aquele que todos ignoraram, pois o resultado geral parecia normal. 

O problema não era a ausência de uma prova. Era que a taxa de aprovação tornava invisível uma reprovação de alto risco, transformando-a em um número tranquilizador.1] 

A deriva lenta que ninguém sinalizou 

Ao longo de quatro sprints, a taxa de aprovação varia de 97% para 96%, depois para 94% e, por fim, para 93%. Cada queda individual parece uma variação normal. Sem limite, sem linha de tendência, sem alerta – apenas um número em um relatório semanal que ninguém compara com o número do sprint anterior. 

Ao atingir 93%, surgem 11 novas falhas recorrentes distribuídas por três áreas de funcionalidades. Nenhuma delas é alarmante individualmente. Juntas, elas indicam que algo sistêmico está se deteriorando. 

A versão perigosa disso não é uma queda repentina. É uma deriva lenta que só se torna visível quando se analisa a tendência ao longo do tempo – e não como uma fotografia instantânea.4] 

O que esses cenários têm em comum? 

Nenhum deles representa uma falha nos testes. Os testes foram executados. O conjunto de testes foi concluído. Os dados estavam disponíveis. 

São todas falhas de interpretação. A equipe tinha o sinal, mas não tinha um sistema para interpretá-lo. 

O que acontece a seguir é previsível: os desenvolvedores param de ler os registros de falhas com atenção. Os líderes de controle de qualidade param de priorizar todas as versões com erro. Falhas reais são descartadas junto com as falhas instáveis. Isso não é negligência – é uma resposta racional a um sistema que produz muito ruído e pouco sinal. Quando todas as falhas parecem iguais, as equipes param de analisá-las com atenção.3] 

A pergunta certa antes de cada lançamento 

A maioria das conversas antes do lançamento gira em torno da pergunta: "Os testes foram aprovados?". A pergunta que realmente prevê o lançamento é justamente essa: safety é diferente: Onde se concentra o risco nesta construção? 

Responder a essa pergunta exige um contexto que a taxa de aprovação não fornece. 

Local da falha, não apenas a quantidade de falhas. Uma falha em uma jornada crítica do usuário é categoricamente diferente de uma falha em um caso extremo raramente utilizado. O que importa é quais falhas ocorrem, onde elas se encontram e se alguma delas está em caminhos que usuários reais irão percorrer.2] 

Tendência ao longo do tempo, não apenas um retrato momentâneo. Uma taxa de aprovação de 93% significa algo diferente se a última sprint teve 97% de aprovação do que se ela se manteve estável em 93% por seis versões. A estabilidade entre versões é um indicador muito mais confiável de prontidão para o lançamento do que qualquer execução isolada – mas apenas se alguém estiver realmente analisando a tendência, e não apenas o número.4] 

A instabilidade é um sinal de primeira classe, não um ruído a ser suprimido. Testes instáveis ​​corroem a confiança na automação. Quando as falhas parecem aleatórias, as equipes reexecutam os pipelines, ignoram os sinais e atrasam as entregas. As equipes que tratam a instabilidade como dados estruturados — classificando as falhas, analisando as tendências de instabilidade por área de teste, questionando por que um teste continua alternando — são as equipes que detectam condições de corrida antes que elas se tornem incidentes em produção. 

Esclarecimento das falhas antes do envio. Uma decisão de lançamento significativa exige saber não apenas que os testes falharam, mas também se essas falhas têm uma causa raiz clara, se são novas nesta versão ou recorrentes e se estão em um caminho que os usuários reais irão percorrer. 

Por que os dispositivos móveis dificultam isso? 

Em dispositivos móveis, o problema da relação sinal-ruído é mais grave do que na web. 

Fragmentação de dispositivos, atrasos na análise da loja de aplicativos, redes instáveis, limites de execução em segundo plano e comportamentos específicos do sistema operacional fazem com que problemas de qualidade frequentemente surjam fora do laboratório. Um teste bem-sucedido antes do envio é útil, mas não suficiente.5] 

Um conjunto de testes aprovado em seus dispositivos de laboratório praticamente não informa nada sobre a experiência de usuários com hardware, versões de sistemas operacionais e condições de rede diferentes. Sem sobrepor padrões de falha às combinações de ambiente que realmente importam, a taxa de aprovação não apenas mascara o risco, como também o representa de forma distorcida. 

O mesmo teste pode ser aprovado em um dispositivo e falhar em outro com uma versão idêntica. A variabilidade do ambiente — estado do sistema operacional, idioma, condições da rede, histórico do dispositivo — significa que o mesmo código de teste produz resultados diferentes por motivos que não têm nada a ver com o seu aplicativo. Sem visibilidade do que o ambiente estava fazendo durante a execução, um resultado "passado" não é garantia de sucesso. É um palpite que por acaso se mostrou correto.6] 

O que exigir de suas análises de teste 

O objetivo não é apenas a automação. É a entrega com alta confiabilidade – onde cada versão passa por verificações significativas, confiáveis ​​e alinhadas ao que os usuários realmente fazem em seus dispositivos.7] 

Chegar a esse ponto significa tratar os dados de teste não como um registro de aprovação/reprovação, mas como um problema analítico. Significa construir — e exigir — ferramentas que revelem a concentração de falhas, as tendências de estabilidade e os padrões de instabilidade em uma única visualização. antes Você decide quando enviar. 

A maioria das equipes está a um passo disso. Os dados existem. Os sinais estão nos registros. O que falta é uma camada de análise que transforme os resultados da execução em inteligência de lançamento. 

A próxima geração de ferramentas de análise de testes precisa ser construída em torno de uma única pergunta: não "como o conjunto de testes se comportou?", mas sim "onde devo me preocupar com esta versão?". 

At Digital.aiEsse é o problema em que estamos trabalhando. Não acreditamos que a resposta seja mais testes. Acreditamos que sejam sinais mais inteligentes – e a disciplina de fazer uma pergunta mais difícil antes de cada lançamento. 

Digital.ai Testes oferece às equipes móveis infraestrutura de execução Para executar testes em grande escala. O camada analítica O que estamos desenvolvendo agora é a transformação desses dados em confiança para a liberação da informação.