Vagner da Silva Machado; Ariel da Silva Dias

DOI: 10.22167/2675-6528-202601482

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

Um aplicativo móvel legado, em operação contínua por mais de uma década, enfrentava desafios como dívida técnica, acoplamento excessivo e baixa cobertura de testes, elevando o risco de regressões. Com o objetivo de mitigar esses problemas, implementou-se e avaliou-se um processo integrado de Desenvolvimento e Garantia da Qualidade (QA) para sua evolução incremental. A metodologia adotou um estudo de caso com pesquisa-ação, desdobrado em seis fases sequenciais: estabelecimento da linha de base, desenho do processo integrado, implantação incremental inicial, ampliação da automação, avaliação comparativa e consolidação de um guia operacional. A coleta de dados combinou análise estática, cobertura de código, resultados de testes automatizados, registros de Integração Contínua (CI) e monitoramento de incidentes em produção, todos versionados por release por meio de execução de pipelines de evidências e consolidação de indicadores. Os resultados demonstraram um aumento progressivo da suíte automatizada, que atingiu 425 testes com 75,6% de cobertura, e uma melhoria nos atributos de qualidade interna, como manutenibilidade e testabilidade, proporcionando maior segurança para refatorações incrementais. Na dimensão de produção, a consolidação de incidentes e o cálculo de Tempo Médio para Reparo (MTTR) permitiram estabelecer uma base comparável e acompanhar tendências. Entretanto, a verificação de redução consistente de incidentes críticos foi limitada pela baixa cardinalidade de releases e pela janela temporal disponível. Concluiu-se que o processo implantado mostrou-se viável no contexto analisado e produziu evidências úteis para apoiar a modernização incremental de aplicativos móveis legados.

Palavras-chave: Integração contínua; Manutenibilidade; Métricas de software; Refatoração; Testabilidade.

1. Introdução

A evolução de sistemas de software, especialmente aqueles mantidos em operação por longos períodos, representa um desafio significativo no cenário da engenharia de software contemporânea. Aplicativos legados, frequentemente caracterizados por uma arquitetura envelhecida, tendem a acumular dívida técnica, manifestada por acoplamento excessivo, dependências implícitas e, crucialmente, baixa cobertura de testes automatizados (Feathers, 2013). Essa condição eleva substancialmente o risco de regressões funcionais e compromete a capacidade de evoluir o sistema com previsibilidade e segurança, impactando negativamente a agilidade e a confiabilidade das entregas. No domínio dos aplicativos móveis, esses desafios são exacerbados pela rápida evolução das plataformas, pela diversidade de dispositivos e versões de sistemas operacionais, pela dependência de recursos nativos e pela necessidade de retrocompatibilidade, impondo ciclos de publicação frequentes e complexos. Tais fatores aumentam o custo de manutenção e reduzem a testabilidade, particularmente quando a arquitetura não está adequadamente modularizada ou documentada.

A literatura especializada aponta que, diante de cenários de software legado, a modernização incremental emerge como uma estratégia mais viável do que a reescrita completa do sistema, especialmente para aplicações já consolidadas em operação e com comportamento de negócio estabelecido (Fowler, 2019). Nesse contexto, a melhoria da qualidade interna e da testabilidade são atributos cruciais para a sustentabilidade do software, conforme preconizado pela norma ISO/IEC 25010 (2011). A dívida técnica, um conceito central para compreender a degradação de sistemas, refere-se ao custo implícito de retrabalho futuro causado por escolhas técnicas subótimas ou atalhos tomados no passado (Seaman e Guo, 2011). Para mitigar essa dívida e melhorar a manutenibilidade, a refatoração, que consiste em reestruturar o código sem alterar seu comportamento externo, é uma prática fundamental (Fowler, 2019). Complementarmente, a automação de testes em diferentes camadas, seguindo a lógica da pirâmide de testes, é essencial para garantir a verificação contínua e a detecção precoce de defeitos (Ammann e Offutt, 2017). A Integração Contínua (CI), por sua vez, atua como um pilar para esse processo, proporcionando *builds* automatizados e verificações frequentes, o que reduz os riscos de integração tardia e aumenta a confiabilidade das entregas de software (Fowler, 2006; Forsgren, Humble e Kim, 2018).

No contexto específico deste estudo, um aplicativo móvel legado, em operação contínua por mais de dez anos em um ambiente institucional, enfrentava uma série de problemas que exemplificavam os desafios descritos. A análise da linha de base revelou um cenário de fragilidade estrutural e baixa governança de qualidade. O sistema não possuía testes automatizados, resultando em zero por cento de cobertura global de código. Indicadores de qualidade interna eram alarmantes: uma complexidade ciclomática máxima de 31, uma média de 2,5, a presença de 289 *code smells* e uma dívida técnica estimada em 24 horas e dez minutos de trabalho. Adicionalmente, observou-se cinco por cento de duplicação de código em uma base de 15.150 Linhas de Código (LOC). Essa condição elevava o risco de regressões e dificultava a evolução do sistema, comprometendo a capacidade da equipe de introduzir novas funcionalidades ou realizar manutenções corretivas com segurança e previsibilidade. A ausência de um processo formal de Desenvolvimento e Garantia da Qualidade (QA) e de mecanismos de rastreabilidade entre as entregas e as evidências de validação tornava a modernização uma tarefa de alto risco e custo.

Diante desse cenário, a justificativa para este trabalho reside na necessidade premente de desenvolver e avaliar uma abordagem prática e sistemática para a modernização incremental de aplicativos móveis legados, visando aprimorar sua qualidade interna e confiabilidade operacional. O objetivo principal deste estudo consistiu em implementar e avaliar, em um contexto real, por meio de um estudo de caso com pesquisa-ação, um processo integrado de Desenvolvimento e Garantia da Qualidade para a evolução incremental de um aplicativo móvel legado. Especificamente, buscou-se estabelecer uma linha de base quantitativa do sistema, implantar automação de testes em camadas, introduzir refatorações orientadas à testabilidade, integrar a *pipeline* de Integração Contínua com critérios de qualidade e consolidar um guia operacional replicável para contextos semelhantes.

2. Material e Métodos

A pesquisa foi caracterizada como aplicada e de natureza descritiva, empregando um estudo de caso único com elementos de pesquisa-ação. Essa abordagem metodológica foi selecionada para permitir a implantação e avaliação de um processo integrado de Desenvolvimento e Garantia da Qualidade (QA) em um ambiente real. A participação direta do pesquisador na condução da intervenção e na análise dos efeitos observados foi um aspecto central, visando compreender a dinâmica da modernização incremental de um aplicativo móvel legado. O desenho buscou aprofundar a compreensão sobre a viabilidade e os impactos de tal processo em um contexto operacional específico.

O estudo foi realizado como uma intervenção incremental em um aplicativo móvel legado, que operava continuamente há mais de dez anos em um ambiente institucional. Para preservar a confidencialidade de aspectos sensíveis, a organização, a infraestrutura e os dados do produto foram anonimizados. A unidade de análise concentrou-se na implantação e avaliação de um processo integrado de Desenvolvimento e Garantia da Qualidade (QA) nesse aplicativo. Embora o produto fosse multiplataforma, o recorte para as medições quantitativas de cobertura, testes e análise estática foi delimitado à plataforma iOS, considerando a disponibilidade da equipe e a viabilidade de instrumentação durante o período da pesquisa.

A seleção do aplicativo móvel para o estudo de caso foi intencional, guiada por critérios específicos que assegurassem a relevância e a viabilidade da intervenção. Os critérios incluíram a presença de características típicas de sistemas legados, a relevância do aplicativo para seus usuários institucionais, a necessidade contínua de evolução, a compatibilidade do escopo com o cronograma da pesquisa e a representatividade do sistema em relação a outros produtos legados da organização. A amostra para as medições quantitativas foi o recorte iOS do aplicativo, escolhido pela disponibilidade da equipe e pela facilidade de instrumentação no período do estudo, sem envolver uma população de usuários diretamente como amostra.

A intervenção foi estruturada em seis fases sequenciais, desdobradas em nove etapas operacionais, adotando uma abordagem incremental. Inicialmente, realizou-se a seleção e delimitação do caso, seguida pelo levantamento da linha de base do sistema, estabelecendo um ponto de partida quantitativo. A segunda fase concentrou-se no desenho do processo integrado de Desenvolvimento e QA, definindo papéis, critérios de qualidade e estratégias de teste. A terceira fase priorizou tecnicamente fluxos e componentes, implementando testes de caracterização e refatorações com foco na testabilidade. A quarta fase ampliou a automação, integrando-a ao fluxo de Integração Contínua (CI) e consolidando a coleta e transformação analítica das evidências. A quinta fase dedicou-se à comparação entre marcos e à interpretação dos resultados, enquanto a sexta fase consolidou os artefatos e formalizou o guia operacional.

A coleta de dados foi sistematicamente apoiada por um conjunto de ferramentas integradas, abrangendo compilação, testes, análise estática e monitoramento em produção. Para compilação e execução de testes, utilizaram-se xcodebuild, xcresulttool, xcpretty e xccov. A análise estática e a avaliação da qualidade interna foram realizadas com SonarCloud/SonarScanner e Lizard. O tamanho do código e a correlação histórica entre mudanças e *releases* foram mensurados com CLOC e Git. O monitoramento de falhas e do uso em produção empregou Firebase Crashlytics, Firebase Analytics e consultas no BigQuery. Essa instrumentação permitiu a obtenção de um panorama abrangente da evolução do sistema.

O tratamento dos dados foi realizado por meio de dois *pipelines* complementares. O primeiro *pipeline* concentrou-se na coleta e consolidação de evidências técnicas por *release*, executando compilação, testes automatizados, extração de cobertura e análise estática. Esses artefatos foram reunidos em pacotes versionados e disponibilizados como artefatos da Integração Contínua (CI). O segundo *pipeline* recebeu essas evidências e metadados de versão, realizando a transformação, padronização e consolidação dos dados. Esse processo incluiu a ingestão de telemetria *mobile*, incidentes em produção, versionamento de *releases*, qualidade estática e execuções de CI/CD, com rotinas automatizadas para extração incremental e preservação dos dados brutos para auditoria.

Sobre a base de dados tratada, aplicaram-se etapas de padronização, como *flatten* de estruturas aninhadas, normalização, deduplicação e harmonização de nomenclaturas, estruturando tabelas analíticas e visões temáticas para o cálculo reexecutável dos indicadores e comparação longitudinal. A análise combinou abordagens quantitativas e qualitativas. No plano quantitativo, métricas de qualidade interna, automação de testes e confiabilidade operacional foram comparadas entre a linha de base e os estados pós-intervenção. No plano qualitativo, foram considerados os registros de decisões de processo, ajustes iterativos e aprendizados da implantação progressiva. Indicadores inspirados no modelo DORA (Forsgren et al., 2018) e na ISO/IEC 25010 (2011) guiaram a interpretação dos resultados.

As métricas de qualidade interna incluíram cobertura de testes, quantidade de testes automatizados por tipo, complexidade ciclomática, *code smells*, dívida técnica, contagem de linhas de código, duplicação e código não referenciado. Para entrega e estabilidade, utilizaram-se Deployment Frequency (DF), Lead Time for Changes, Change Failure Rate (CFR) e estabilidade de execução no CI. No eixo de produção, analisaram-se densidade de incidentes pós-*release*, taxa de reabertura e Mean Time to Restore (MTTR). Um *Hotspot Score* sintético por arquivo foi calculado como apoio à priorização técnica de refatorações. A análise foi predominantemente descritiva, focada em tendências e comparações por *snapshot* e séries simples por *release*.

A estratégia de automação de testes seguiu a lógica da pirâmide de testes, priorizando testes de unidade, complementados por testes de integração e com uso restrito de testes de interface para fluxos essenciais. Inicialmente, foram desenvolvidos testes de caracterização para registrar o comportamento existente em pontos sensíveis do sistema legado. Posteriormente, implementaram-se testes de unidade nos componentes priorizados, testes de integração em fluxos com dependências relevantes e testes de UI em caminhos críticos para validação pré-*release*. Um subconjunto de *smoke tests* foi definido para execução rápida e recorrente na Integração Contínua (CI), atuando como *quality gate* para detecção precoce de regressões.

Tabela 1. Distribuição da suíte de testes automatizados

Categoria	Testes	Percentual
Smoke tests	22	5,1%
Testes unitários	331	78,2%
Testes de integração	62	14,4%
Testes de UI	32	7,4%

Fonte: Dados originais da pesquisa

A criação da suíte de testes automatizados exigiu intervenções estruturais no código, realizadas de forma incremental e validadas continuamente por testes. As principais ações de refatoração incluíram a introdução de protocolos e injeção de dependências, a decomposição de métodos extensos, o isolamento de efeitos colaterais, a remoção de código obsoleto e a substituição de dependências externas por dublês de teste. Nos testes de integração e de Interface do Usuário (UI), foram adotadas práticas para reduzir a instabilidade, como sincronização explícita, uso de dados determinísticos e isolamento de dependências variáveis. O objetivo foi criar uma proteção comportamental inicial e preparar a base de código para evoluções futuras com menor risco.

Para garantir a integridade e a confidencialidade dos dados, todas as informações capazes de identificar a organização, a infraestrutura e os dados específicos do produto foram anonimizadas. Quanto aos cuidados éticos, embora não tenha havido submissão a comitê de ética formal, a pesquisa adotou medidas para mitigar riscos. Em relação à validade interna, reconheceu-se o potencial de influência do pesquisador e do contexto operacional. Essa ameaça foi mitigada pela participação de especialistas em Garantia da Qualidade (QA), revisão por pares e a aplicação de critérios objetivos de aceite para as intervenções, buscando assegurar a imparcialidade na observação e análise dos processos.

A validade externa do estudo foi limitada, uma vez que se tratou de um estudo de caso único, conduzido em um contexto organizacional específico e com foco quantitativo na plataforma iOS. Assim, os resultados não devem ser generalizados diretamente para todos os cenários de *software* legado, mas sim compreendidos em termos de generalização analítica do processo, com base na descrição detalhada do contexto. Em relação à validade de construto, algumas métricas de entrega e produção foram adaptadas ao ambiente de aplicativos móveis, considerando a defasagem entre publicação e adoção pelos usuários. Os indicadores foram operacionalizados de forma consistente com o contexto, exigindo interpretação cuidadosa.

A validade da conclusão foi afetada pela baixa cardinalidade de *releases*, pela janela temporal reduzida de observação, pela sazonalidade de uso do aplicativo e pela ocorrência de mudanças paralelas no sistema. Esses fatores limitaram a capacidade de realizar inferências robustas sobre a causalidade dos efeitos observados em produção. Consequentemente, os achados foram interpretados como evidências da viabilidade e da evolução observada no caso estudado, e não como uma demonstração conclusiva de relações de causa e efeito. A pesquisa focou em descrever a evolução e os limites da intervenção.

3. Resultados e Discussão

Os resultados obtidos neste estudo foram analisados e interpretados à luz das seis fases da intervenção, concentrando-se em três eixos analíticos principais: qualidade interna e testabilidade, capacidade de entrega com governança do fluxo, e confiabilidade em produção. Em uma perspectiva geral, os achados indicaram uma ampliação notável da automação de testes, um aumento significativo da testabilidade do sistema e uma maior estabilidade no processo de validação contínua. Contudo, é fundamental ressaltar que, embora os efeitos observáveis em produção tenham sido identificados, a curta janela temporal pós-intervenção impôs limitações à robustez das inferências causais.

A trajetória do projeto, que partiu de um cenário desprovido de testes automatizados e de rastreabilidade sistemática de evidências, culminou em um contexto com uma suíte de testes multinível, execução recorrente em Integração Contínua (CI) e um acompanhamento estruturado de indicadores de qualidade e entrega. Essa evolução alinha-se consistentemente com a literatura que preconiza a automação progressiva, a refatoração orientada à testabilidade e a integração contínua como pilares para a redução do risco de regressão e o incremento da confiança nas entregas de software (Feathers, 2004; Fowler, 2006; Humble & Farley, 2010). A adoção dessas práticas não apenas mitigou vulnerabilidades, mas também estabeleceu uma base mais sólida para a manutenção e evolução do aplicativo legado.

Apesar dos avanços na qualidade interna e na testabilidade, a observação de indicadores como o Tempo Médio para Reparo (MTTR) e a Taxa de Falha de Mudança (CFR) permaneceu limitada em termos comparativos, devido à janela observacional pós-intervenção ser relativamente curta e ao histórico inicial de incidentes ser incompleto. Este resultado, longe de contradizer a literatura, reforça o entendimento de que melhorias na qualidade interna e na testabilidade nem sempre se traduzem imediatamente em ganhos mensuráveis em produção, especialmente em sistemas legados e em contextos com baixa maturidade histórica de dados (Forsgren et al., 2018). Em ambientes complexos e com dívida técnica acumulada, a construção de uma base de medição consistente é, por si só, um resultado intermediário crucial.

Do ponto de vista da automação, o sistema passou a contar com uma suíte abrangente, composta por 425 testes, incluindo um subconjunto estratégico de 22 *smoke tests* dedicados à validação de fluxos críticos. A viabilidade operacional dessa suíte foi demonstrada pelos tempos de execução. Em ambiente local, o subconjunto de *smoke tests* apresentou um tempo médio de aproximadamente 60 segundos por execução, calculado a partir de dez execuções consecutivas sob as mesmas condições. No ambiente de CI, o tempo médio para o mesmo conjunto foi de aproximadamente 3 minutos. Esses dados são encorajadores, pois sugerem que a suíte pode ser utilizada como um mecanismo recorrente de *feedback* rápido, essencial para a detecção precoce de regressões e para a manutenção da integridade funcional no fluxo de entrega, conforme defendido pela literatura de integração contínua (Fowler, 2006; Humble & Farley, 2010). A capacidade de obter *feedback* ágil é um diferencial em sistemas legados, onde a incerteza sobre o impacto das mudanças é historicamente elevada.

A. Qualidade interna e testabilidade

O eixo de qualidade interna e testabilidade foi onde a intervenção produziu as evidências mais consistentes e transformadoras. A evolução de uma base de código sem testes para uma suíte automatizada robusta, aliada ao aumento substancial da cobertura de código e à subsequente redução de indicadores de passivos técnicos, como duplicação, dívida técnica e *code smells*, sugere que o processo implantado ampliou significativamente a capacidade de verificar mudanças com maior previsibilidade e segurança. Mais do que o mero crescimento numérico da suíte de testes, o resultado mais relevante foi a constituição de uma estrutura de validação contínua, orientada pela criticidade dos componentes e integrada de forma orgânica ao fluxo de desenvolvimento.

Linha de base (Fase 1): O Cenário Inicial do Legado

A análise da linha de base, estabelecida na Fase 1, revelou um cenário que se alinhava perfeitamente com a caracterização de sistemas legados de difícil testabilidade e com governança de qualidade incipiente. O aplicativo em estudo não possuía testes automatizados, resultando em uma cobertura de código nula. Além disso, apresentava um acúmulo significativo de *code smells*, pontos de alta complexidade ciclomática, duplicação de código e uma dívida técnica considerável.

Tabela 2. Linha de base de qualidade interna, testes e confiabilidade (estado inicial)

Indicador	Linha de base
Testes automatizados	0
Cobertura global (%)	0%
Complexidade ciclomática média (CCN)	2,5
Complexidade ciclomática máxima (CCN)	31
Code smells (quantidade)	289
Dívida técnica (horas)	24h10
Duplicação de código (%)	5%
Linhas de Código (LOC)	15.150

Fonte: Resultados originais da pesquisa

Conforme apresentado na Tabela 2, a ausência de testes automatizados (0) e a cobertura global de 0% indicavam uma vulnerabilidade extrema a regressões e uma dificuldade intrínseca para a introdução de novas funcionalidades ou refatorações. A complexidade ciclomática média de 2.5 e máxima de 31, embora a média pareça baixa, a máxima de 31 em um único componente é um sinal de alto risco, sugerindo que certas partes do código eram excessivamente ramificadas e difíceis de compreender e testar isoladamente. Esse nível de complexidade é frequentemente associado a uma maior probabilidade de defeitos e a um custo elevado de manutenção, conforme apontado por McCabe (1976), que introduziu a métrica.

A presença de 289 *code smells* e uma dívida técnica estimada em 24 horas e 10 minutos (24h10) reforçavam a fragilidade estrutural. *Code smells* são sintomas de problemas mais profundos no design do software, que podem levar a dificuldades de manutenção e evolução (Fowler et al., 1999). A dívida técnica, por sua vez, representa o custo implícito de retrabalho futuro causado pela escolha de soluções mais rápidas e de menor qualidade no presente (Cunningham, 1992; Seaman & Guo, 2011). Uma dívida técnica de 24 horas e 10 minutos, embora possa parecer modesta em um primeiro momento, em um contexto de legado, indica um passivo que, se não endereçado, tende a crescer exponencialmente, dificultando futuras intervenções.

A duplicação de código em 5% e as 15.150 Linhas de Código (LOC) completavam o panorama de um sistema que, em conjunto, confirmava a fragilidade estrutural descrita na introdução. A duplicação não apenas aumenta o volume de código a ser mantido, mas também eleva o risco de inconsistências e a dificuldade de aplicar mudanças de forma segura (Bellon et al., 2006). Esse ponto de partida é amplamente coerente com a literatura sobre software legado, que descreve bases de código mantidas por longos períodos sem uma estratégia consistente de testes e refatoração como ambientes que tendem a concentrar dependências implícitas, rigidez estrutural e um alto custo de mudança (Feathers, 2004). A intervenção, portanto, foi justificada pela necessidade de uma abordagem incremental orientada à qualidade e à redução de regressões.

Desenho do processo integrado (Fase 2): A Governança como Pré-requisito

A Fase 2, por sua natureza, não resultou em alterações quantitativas diretas nos indicadores técnicos do sistema. No entanto, ela representou um resultado metodológico de suma importância para a pesquisa. Nesta etapa, foram definidos os elementos estruturantes do processo integrado de Desenvolvimento e Garantia da Qualidade (QA), incluindo a clara delimitação de papéis e responsabilidades, o estabelecimento de critérios de qualidade objetivos, a criação de *checklists* operacionais para a passagem entre etapas, a formulação de uma estratégia de suíte de testes em camadas e a implementação de mecanismos de rastreabilidade entre requisitos, testes, evidências e *releases*.

Este tipo de formalização mínima constituiu uma condição *sine qua non* para que as etapas subsequentes de automação, refatorações e medições pudessem ser implantadas de modo comparável, consistente e sustentável. Sem essa base processual, qualquer esforço técnico estaria sujeito à inconsistência e à falta de replicabilidade. Esse achado é particularmente relevante porque aproxima o estudo de abordagens que compreendem a qualidade de software não apenas como um atributo intrínseco do código, mas também como um resultado direto da disciplina de processo, da definição explícita de critérios e da institucionalização de práticas verificáveis (Pressman & Maxim, 2020; Humble & Farley, 2010).

Diferentemente de leituras que veem a automação de testes como uma solução puramente ferramental, os resultados desta fase indicam que a formalização mínima do fluxo de trabalho foi parte constitutiva da intervenção, e não um mero elemento acessório. Em outras palavras, a pesquisa demonstrou que, em um contexto de sistema legado, a criação de uma governança processual robusta precedeu e, de fato, sustentou a melhoria técnica. A capacidade de definir um “Definition of Done” (DoD) com critérios objetivos, por exemplo, é um artefato crucial que emerge dessa fase, garantindo que cada entrega atenda a um padrão mínimo de qualidade antes de avançar no pipeline. Isso não só melhora a qualidade do produto final, mas também a previsibilidade do processo de desenvolvimento.

Pós-intervenção (Fase 3): Ganhos Iniciais e a Visibilidade dos Passivos

A primeira etapa incremental da intervenção, correspondente à Fase 3, produziu ganhos concretos e mensuráveis em termos de testabilidade. Foram introduzidos 70 testes automatizados, elevando a cobertura global de código para aproximadamente 31,7%. Paralelamente, observou-se uma redução na duplicação de código e a remoção de código obsoleto, o que é um indicativo positivo de limpeza e otimização da base. Em contrapartida, a complexidade ciclomática máxima permaneceu inalterada, e houve um aumento na quantidade de *code smells* e na dívida técnica estimada.

Tabela 3. Comparativo de métricas antes e depois da Fase 3

Indicador	Linha de Base	Pós Fase 3	Variação
Testes automatizados	0	70	+70
Cobertura global (%)	0%	31,7%	+31,7 p.p.
Complexidade ciclomática média (CCN)	2,5	2,7	+8%
Complexidade ciclomática máxima (CCN)	31	31	0%
Code smells (quantidade)	289	330	+14,2%
Dívida técnica (horas)	24h10	28h16	+17%
Duplicação de código (%)	5%	3,8%	-1,2 p.p.
Linhas de Código (LOC)	15.150	6.704	-55,8%

Fonte: Resultados originais da pesquisa

Conforme a Tabela 3, a introdução de 70 testes automatizados e o salto de 0% para 31,7% na cobertura global são avanços significativos para um sistema legado. Essa cobertura inicial, embora não seja ideal, já oferece uma camada de proteção comportamental que antes não existia. A redução da duplicação de código de 5% para 3,8% é um sinal de que o esforço de refatoração começou a surtir efeito na eliminação de redundâncias. No entanto, o aumento de *code smells* de 289 para 330 e da dívida técnica de 24h10 para 28h16 pode, à primeira vista, parecer uma piora na qualidade.

Contudo, a interpretação mais consistente para esses dados é que a Fase 3 operou, sobretudo, como uma etapa de abertura da base de código à observação e ao controle. A introdução de testes, a instrumentação mais sistemática do processo e o uso mais abrangente de ferramentas de análise estática aumentaram a visibilidade de passivos técnicos que antes estavam dispersos ou eram pouco explícitos. Esse comportamento está em linha com a literatura sobre sistemas legados, que descreve a modernização incremental como um processo em que a explicitação do comportamento existente e dos problemas estruturais frequentemente precede sua redução efetiva (Feathers, 2004; Fowler, 2018). Em muitos casos, a primeira etapa de um processo de modernização revela mais problemas do que resolve, mas essa revelação é um passo essencial para o tratamento.

Nesse sentido, os testes introduzidos na Fase 3 cumpriram um papel análogo ao dos testes de caracterização, ao criarem uma base inicial de proteção comportamental para partes críticas do sistema legado (Feathers, 2004). Diferentemente de uma estratégia de reescrita ampla, que implicaria uma interrupção significativa da operação, a intervenção adotada permitiu ampliar o controle sobre o comportamento do sistema sem ruptura funcional das entregas. Assim, o principal resultado dessa fase não foi ainda a melhoria estrutural plena e imediata, mas a criação de condições para que a base de código pudesse ser modificada com menor risco e com maior observabilidade, preparando o terreno para as fases subsequentes de refatoração e otimização.

Pós-intervenção (Fase 4): Consolidação da Testabilidade e Redução de Passivos

Na segunda etapa incremental, correspondente à Fase 4, a intervenção transcendeu a fase de preparação e instrumentação, avançando para uma consolidação mais efetiva da testabilidade e da qualidade interna. A suíte de testes foi ampliada para um total de 425 testes automatizados, resultando em uma cobertura global de 75,6%. Esse avanço foi acompanhado por uma redução significativa da complexidade ciclomática, uma queda expressiva na quantidade de *code smells*, uma diminuição da dívida técnica estimada e uma redução adicional na duplicação de código.

Tabela 4. Comparativo de métricas antes e depois da Fase 4

Indicador	Linha de Base	Pós Fase 4	Variação
Testes automatizados	0	425	+425
Cobertura global (%)	0%	75,6%	+75,6 p.p.
Complexidade ciclomática média (CCN)	2,5	2,2	-12%
Complexidade ciclomática máxima (CCN)	31	17	-45,2%
Code smells (quantidade)	289	151	-47,8%
Dívida técnica (horas)	24h10	17h47	-26,4%
Duplicação de código (%)	5%	1,9%	-3,1 p.p.
Linhas de Código (LOC)	15.150	7.603	-49,8%

Fonte: Resultados originais da pesquisa

Conforme a Tabela 4, o aumento de testes automatizados de 0 para 425 e o salto na cobertura global de 0% para 75,6% representam uma transformação substancial na capacidade de verificação do sistema. A complexidade ciclomática média reduziu de 2.5 para 2.2 (-12%), e a complexidade ciclomática máxima teve uma queda ainda mais acentuada, de 31 para 17 (-45,2%). Essa redução na complexidade é um indicador robusto de que o código se tornou mais simples, mais fácil de entender e, consequentemente, menos propenso a erros.

A quantidade de *code smells* diminuiu de 289 para 151 (-47,8%), e a dívida técnica foi reduzida de 24h10 para 17h47 (-26,4%). A duplicação de código também caiu de 5% para 1,9% (-3,1 p.p.), e as Linhas de Código (LOC) foram drasticamente reduzidas de 15.150 para 7.603 (-49,8%). Diferentemente da Fase 3, na qual predominou a exposição dos passivos existentes, a Fase 4 mostrou sinais claros de tratamento desses passivos por meio de uma combinação sinérgica de refatoração, automação em níveis superiores e critérios objetivos de validação. Esse movimento converge com a literatura que associa refatorações orientadas à testabilidade e automação progressiva à melhora gradual da modularidade, da verificabilidade e da manutenibilidade em sistemas legados (Feathers, 2004; Fowler, 2018).

Um ponto crucial para a interpretação desses resultados foi a redução significativa das Linhas de Código (LOC), decorrente principalmente da eliminação de componentes obsoletos e de reestruturações arquiteturais. Esse enxugamento do código é intrinsecamente positivo, pois reduz a superfície de falhas e o custo de manutenção. Embora essa redução de LOC possa ter influenciado parte do ganho de cobertura (código removido não compõe mais o denominador da métrica), a interpretação não deve se apoiar na cobertura isoladamente. O dado mais relevante é a convergência entre diferentes indicadores: o crescimento substancial da suíte de testes, a integração ao CI, e a redução simultânea de *code smells*, duplicação, complexidade máxima e dívida técnica. Em conjunto, esses resultados sugerem que a intervenção não apenas aumentou a quantidade de testes, mas contribuiu para tornar a base de código mais simples, mais observável e mais segura para evoluir, facilitando futuras evoluções e manutenções.

A Fase 4 também consolidou a operacionalização da suíte de testes no *pipeline* de CI, com execução automatizada. Mais do que simplesmente ampliar a automação, essa integração passou a fornecer observabilidade recorrente sobre a estabilidade e o custo operacional da suíte, especialmente em relação ao *pass rate* e ao tempo médio por categoria de teste.

Tabela 5. Desempenho operacional da suíte automatizada em ambiente de CI

Suíte	Pass rate	Tempo médio	Observações
Smoke	95%	3m26s	Utilizada como quality gate
Unidade	100%	1m	Métrica apurada via jobs do CI
Integração	100%	1m30s	Métrica apurada via jobs do CI
UI	95%	13m51s	Métrica apurada via jobs do CI

Fonte: Resultados originais da pesquisa

Os dados apresentados na Tabela 5 demonstram que os testes de unidade e de integração exibiram execução estável e tempos compatíveis com o uso recorrente no fluxo de desenvolvimento. Os *smoke tests*, empregados como *quality gate*, ofereceram um retorno rápido sobre a integridade de fluxos críticos, embora com uma margem para amadurecimento em estabilidade (95% de *pass rate*). Já os testes de Interface do Usuário (UI) concentraram um tempo de execução significativamente maior (13m51s) e uma estabilidade relativa menor (95%), um comportamento coerente com a literatura, que reconhece o maior custo e a maior suscetibilidade à variabilidade ambiental nesse nível de teste (Meszaros, 2007; Fowler, 2018). Assim, os achados desta fase reforçam não apenas a utilidade da automação em camadas, mas também a importância de distribuir o *feedback* conforme a criticidade, o custo de execução e o papel de cada nível de teste no processo de entrega. A estratégia de automação de testes, com predominância de testes de unidade e integração e uso seletivo de testes de UI e *smoke tests*, mostrou-se aderente ao racional apresentado por Ammann e Offutt (2017), segundo o qual diferentes níveis de teste cumprem papéis complementares e devem ser escolhidos conforme custo, velocidade de execução e capacidade de detecção de falhas.

B. Governança do fluxo e capacidade de entrega

Outro resultado de grande importância da intervenção foi a criação de uma camada de governança processual robusta. A definição explícita de critérios de passagem entre as etapas do desenvolvimento, a elaboração de *checklists* operacionais detalhados, a implementação de mecanismos de rastreabilidade entre evidências e *releases*, e a integração da automação ao fluxo de Integração Contínua (CI) não apenas organizaram a colaboração entre os diversos papéis envolvidos na equipe, mas também reduziram drasticamente a dependência de validações implícitas e exclusivamente manuais. Embora esse ganho possa ser menos diretamente observável em uma métrica isolada de código, ele constitui uma contribuição central do trabalho, pois transforma práticas dispersas e muitas vezes subjetivas em um processo mais explícito, auditável e replicável.

Esse achado está em perfeita consonância com a literatura de CI, que enfatiza que o benefício da automação não se limita à mera existência de testes, mas reside na sua incorporação a um fluxo recorrente, com critérios objetivos de aprovação e *feedback* rápido para a equipe de desenvolvimento (Fowler, 2006; Humble & Farley, 2010). No presente estudo, a utilização de *smoke tests* como *quality gate* e a observação contínua do *pass rate* e do tempo de execução dos testes demonstraram que a automação passou a cumprir uma função operacional crítica no processo decisório, e não apenas um papel acessório de apoio ao desenvolvimento. Isso significa que as decisões sobre a qualidade e a prontidão de uma *release* passaram a ser embasadas em dados objetivos e verificáveis, reduzindo a subjetividade e o risco.

Diferentemente de relatos de contextos mais maduros, onde a CI já é uma prática estabilizada, este trabalho evidenciou a relevância da implantação gradual desses mecanismos em um ambiente inicialmente marcado por baixa formalização e alta dívida técnica. Nesse sentido, o estudo não apenas confirma os benefícios amplamente conhecidos da integração contínua, mas acrescenta uma contribuição prática valiosa: demonstra como essa governança pode ser construída de forma incremental e eficaz em um contexto de sistema legado, com uma equipe enxuta e em operação contínua. A capacidade de adaptar e implementar princípios de CI em um ambiente desafiador é um testemunho da viabilidade do processo proposto.

C. Confiabilidade em produção

No eixo de confiabilidade em produção, a principal contribuição da intervenção foi a ampliação da capacidade de observação e comparação longitudinal dos indicadores. Os resultados, embora promissores, ainda não permitem afirmar, de forma robusta, uma redução de incidentes atribuível exclusivamente ao processo implantado. Contudo, indicam um avanço relevante na instrumentação, na rastreabilidade e na construção de uma base analítica necessária para o acompanhamento futuro da confiabilidade.

Esse resultado é coerente com a literatura que adverte que melhorias em qualidade interna e testabilidade não se convertem necessariamente, no curto prazo, em redução mensurável de falhas em produção, sobretudo quando a base histórica de mensuração é incompleta ou inconsistente (Forsgren et al., 2018). Diferentemente de estudos realizados em ambientes com maior maturidade operacional e histórico de dados robusto, este trabalho encontrou limites concretos para comparar métricas como MTTR (Mean Time to Restore) e CFR (Change Failure Rate) entre períodos de forma conclusiva.

Ainda assim, essa limitação não esvazia a relevância dos achados. Ao contrário, ela evidencia que, em contextos reais de sistemas legados, uma parte fundamental da intervenção necessária consiste justamente em construir a capacidade de medir de forma consistente e confiável. Sob essa perspectiva, a governança das evidências e a instrumentação analítica devem ser entendidas como resultados intermediários e pré-requisitos essenciais para a modernização incremental. A capacidade de coletar, processar e analisar dados de produção de forma estruturada é o primeiro passo para identificar tendências, priorizar intervenções e, eventualmente, demonstrar melhorias na confiabilidade.

Figura 1. Arquitetura dos pipelines de métricas.

Fonte: Dados originais da pesquisa

A Figura 1, que ilustra a arquitetura dos *pipelines* de métricas, é fundamental para compreender como essa capacidade de observação foi construída. O primeiro *pipeline* concentra a coleta e consolidação de evidências técnicas por *release*, executando compilação, testes automatizados, extração de cobertura e análise estática. Esses artefatos são reunidos em pacotes versionados e disponibilizados como artefatos da Integração Contínua (CI). O segundo *pipeline* recebe essas evidências e metadados de versão, realizando a transformação, padronização e consolidação dos dados. Esse processo inclui a ingestão de telemetria *mobile*, incidentes em produção, versionamento de *releases*, qualidade estática e execuções de CI/CD, com rotinas automatizadas para extração incremental e preservação dos dados brutos para auditoria. Essa infraestrutura, embora não tenha sido o foco central da avaliação, ampliou a rastreabilidade entre fontes, *snapshots* e indicadores, reforçando a capacidade de observação longitudinal do processo e apoiando a tomada de decisão gerencial.

Avaliação comparativa e limitações (Fase 5)

A comparação entre a linha de base e os estágios pós-intervenção, realizada na Fase 5, indicou uma evolução mais robusta na qualidade interna e na capacidade de verificação contínua do que nos desfechos operacionais de produção, como já mencionado. Essa distinção é crucial para uma compreensão precisa dos impactos da intervenção. Os resultados reforçam principalmente a viabilidade do processo implantado e sua contribuição fundamental para tornar a coleta de dados, o versionamento de evidências e a comparação futura de métricas mais consistentes e confiáveis.

As ameaças à validade foram tratadas de forma explícita ao longo do estudo. No que se refere à validade interna, reconheceu-se o risco de influência do pesquisador e do próprio contexto operacional da intervenção. Essa ameaça foi mitigada pela participação ativa de especialistas em Garantia da Qualidade (QA), revisão por pares e a aplicação de critérios objetivos de aceite para as intervenções, buscando assegurar a imparcialidade na observação e análise dos processos. A validade externa do estudo foi limitada, uma vez que se tratou de um estudo de caso único, conduzido em um contexto organizacional específico e com foco quantitativo na plataforma iOS. Assim, os resultados não devem ser generalizados diretamente para todos os cenários de *software* legado, mas sim compreendidos em termos de generalização analítica do processo, com base na descrição detalhada do contexto.

Em relação à validade de construto, reconheceu-se que parte das métricas de entrega e produção precisou ser adaptada ao contexto de aplicativos móveis, especialmente em razão da defasagem entre a publicação da versão e sua adoção efetiva pelos usuários. Os indicadores foram operacionalizados de modo consistente com o contexto estudado, mas seus resultados devem ser interpretados à luz dessas adaptações, exigindo uma compreensão cuidadosa das nuances do ambiente móvel. Por fim, quanto à validade da conclusão, reconheceu-se que a baixa cardinalidade de *releases*, a janela temporal reduzida de observação, a sazonalidade de uso do aplicativo e a ocorrência de mudanças paralelas no sistema limitaram a capacidade de realizar inferências robustas sobre a causalidade dos efeitos observados em produção. Consequentemente, os achados foram interpretados como evidências da viabilidade e da evolução observada no caso estudado, e não como uma demonstração conclusiva de relações de causa e efeito. A pesquisa focou em descrever a evolução e os limites da intervenção, fornecendo uma base sólida para futuras investigações e aprimoramentos.

Consolidação do processo e artefatos finais (Fase 6)

Na fase final da intervenção, a Fase 6, iniciou-se a consolidação sistemática dos artefatos produzidos ao longo do estudo, organizando-os como a base de um guia operacional replicável. Até o momento, os principais artefatos consolidados incluem: uma Definição de Pronto (Definition of Done – DoD) com critérios objetivos de qualidade, *checklists* operacionais detalhados (“Pronto para Testar” e “Pronto para Lançar”), uma estrutura multinível da suíte de testes (unitário/integração/UI) com um recorte específico de *smoke tests*, *scripts* para coleta e processamento de métricas, e diretrizes iniciais para o tratamento de testes instáveis e o isolamento de dependências.

Esses artefatos representam um valor prático significativo. O DoD, por exemplo, garante que cada etapa do desenvolvimento atenda a um padrão mínimo de qualidade antes de avançar, reduzindo a probabilidade de regressões. Os *checklists* operacionais padronizam as atividades de verificação e validação, promovendo consistência e reduzindo a dependência de conhecimento tácito. A estrutura da suíte de testes, com sua pirâmide de testes e *smoke tests*, otimiza a detecção de falhas e o *feedback* rápido. Os *scripts* de coleta de métricas automatizam o monitoramento, fornecendo dados objetivos para a tomada de decisão. As diretrizes para testes instáveis e isolamento de dependências abordam desafios comuns em sistemas legados, promovendo a estabilidade e a confiabilidade da automação.

Em complemento a esses artefatos, iniciou-se também a consolidação de uma arquitetura analítica de suporte ao *pipeline* de métricas. Essa arquitetura é voltada para a integração reexecutável de dados heterogêneos provenientes do desenvolvimento, testes, *releases* e produção. Embora essa infraestrutura não tenha constituído o foco central de avaliação do estudo, ela ampliou substancialmente a rastreabilidade entre fontes de dados, *snapshots* de métricas e indicadores consolidados, reforçando a capacidade de observação longitudinal do processo. Essa capacidade é vital para a melhoria contínua, permitindo que a equipe identifique tendências, avalie o impacto das intervenções e tome decisões baseadas em dados.

Ao término da intervenção, observou-se que a consolidação do guia operacional ainda permanecia em andamento, embora já houvesse sido estruturado um conjunto consistente de artefatos reaplicáveis. Também foi iniciado um projeto *web* para a apresentação de painéis de acompanhamento e comparativos de *snapshots* de métricas; contudo, sua implementação completa permaneceu fora do escopo deste trabalho. Ainda assim, o uso dos dados já versionados pelo *pipeline* de métricas ampliou a visibilidade gerencial sobre a evolução dos indicadores e apoiou a tomada de decisão, mesmo sem a interface *web* finalizada.

Em síntese, o estudo demonstrou a viabilidade de implantar um processo integrado, incremental e mensurável para a evolução de *software* móvel legado, com avanços mais consistentes em qualidade interna, testabilidade e governança do fluxo. A evolução incremental do legado pôde ser sustentada por uma combinação estratégica de formalização mínima do processo, automação em camadas, integração contínua e rastreabilidade de evidências.

As considerações finais reforçam que a Fase 2, com seu caráter predominantemente processual e não quantitativo, estabeleceu a base organizacional e técnica da intervenção. A definição de papéis, critérios de qualidade, *checklists* entre etapas e uma estratégia multinível para a suíte de testes mostrou-se compatível com a ISO/IEC/IEEE 29119-2:2013, que enfatiza a definição e o gerenciamento explícito dos processos de teste, e com a ISO/IEC/IEEE 12207:2017, ao tratar processos como mecanismos para definir, controlar e aprimorar o ciclo de vida de *software*. Desse modo, embora essa fase não tenha produzido variações mensuráveis nos indicadores, ela criou as condições para que as mudanças das fases subsequentes fossem executáveis, rastreáveis e comparáveis ao longo do tempo.

Ainda nessa direção, os elementos estruturados na Fase 2 puderam ser interpretados à luz de princípios associados ao CMMI (Capability Maturity Model Integration), especialmente no que se refere à explicitação de papéis, à definição de critérios de entrada e saída entre etapas, ao acompanhamento por métricas e à institucionalização de práticas de verificação, validação e melhoria contínua. Nesse sentido, a intervenção representou um avanço em direção a um processo mais definido, repetível e gerenciado, sem que isso implique afirmar formalmente um nível de maturidade nos termos do modelo.

Nos eixos de qualidade interna e testabilidade, os resultados obtidos mostraram-se coerentes com a literatura e com o modelo de qualidade da ISO/IEC 25010:2011. A redução da complexidade ciclomática, dos *code smells* e da dívida técnica estimada, associada ao aumento da cobertura e da suíte automatizada, sugere melhora de atributos relacionados à manutenibilidade, em especial analisabilidade, modificabilidade e testabilidade. Nessa perspectiva, os achados não indicaram apenas crescimento da automação, mas uma evolução estrutural em direção a uma base mais verificável e mais confiável para mudanças incrementais. Tal interpretação também converge com Feathers (2013) e Fowler (2019), ao indicar que a introdução progressiva de testes e refatorações localizadas pode ampliar a confiabilidade da evolução de sistemas legados sem exigir reescrita ampla.

Sob a perspectiva de entrega e integração contínua, os resultados também dialogaram com Forsgren, Humble e Kim (2018), na medida em que o estudo estruturou uma base de observação inspirada em métricas como *Change Failure Rate* (CFR) e *Mean Time to Restore* (MTTR). A implantação de CI com *quality gates*, execução automatizada de testes e coleta reexecutável de evidências ampliou a visibilidade sobre o fluxo de entrega e reduziu a dependência de validações exclusivamente manuais. A interpretação da dívida técnica ao longo das fases mostrou-se compatível com a leitura proposta por Seaman e Guo (2011). O aumento inicial de *code smells* e do esforço estimado de reparo na etapa de instrumentação pôde ser compreendido como efeito de maior visibilidade analítica sobre passivos já existentes, e não necessariamente como deterioração provocada pela intervenção. Com o avanço das refatorações e da instrumentação, observou-se redução posterior desses indicadores, sugerindo que a mensuração contínua favoreceu a priorização e o tratamento gradual do passivo técnico.

Como contribuição prática, o estudo oferece um conjunto de artefatos, métricas e decisões de processo reaplicável em iniciativas semelhantes de modernização de aplicativos móveis legados. Como desdobramento, recomenda-se a continuidade da observação longitudinal dos indicadores em produção e a ampliação da arquitetura analítica para fortalecer comparações históricas e apoiar novos ciclos de melhoria contínua.

4. Conclusão

Conclui-se que o objetivo foi atingido, uma vez que o estudo implementou e avaliou, em um contexto real, um processo integrado de Desenvolvimento e Garantia da Qualidade para a evolução incremental de um aplicativo móvel legado. A abordagem permitiu estabelecer uma linha de base quantitativa, implantar automação de testes em camadas, introduzir refatorações orientadas à testabilidade, integrar a *pipeline* de Integração Contínua com critérios de qualidade e consolidar um guia operacional replicável. Os resultados demonstraram avanços consistentes na qualidade interna, testabilidade e governança do fluxo de entrega, transformando um cenário de fragilidade estrutural em um ambiente mais verificável e seguro para a evolução contínua do software.

Contudo, o estudo apresentou limitações importantes. Por ser um estudo de caso único, focado na plataforma iOS, seus resultados não são diretamente generalizáveis para todos os cenários de software legado, embora o processo seja analiticamente replicável. A validade de construto foi afetada pela adaptação de métricas de entrega e produção ao contexto móvel, e a validade da conclusão foi limitada pela baixa cardinalidade de *releases* e pela curta janela temporal de observação, impedindo inferências robustas sobre a causalidade dos efeitos em produção. Para estudos futuros, recomenda-se a continuidade da observação longitudinal dos indicadores em produção e a ampliação da arquitetura analítica para fortalecer comparações históricas e apoiar novos ciclos de melhoria contínua.

Referências Bibliográficas

AMMANN, P.; OFFUTT, J. Introduction to Software Testing. 2. ed. Cambridge: Cambridge University Press, 2017.

FEATHERS, M. Trabalho eficaz com código legado. Porto Alegre: Bookman, 2013.

FORSGREN, N.; HUMBLE, J.; KIM, G. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Portland: IT Revolution, 2018.

FOWLER, M. Refatoração: aperfeiçoando o design de códigos existentes. São Paulo: Novatec, 2019.

FOWLER, Martin. Continuous integration. [S. I.], 2006. Disponível no site oficial de Martin Fowler. Acesso em: 27 mar. 2026.

Humble & Farley, 2010 [Referência completa não encontrada no documento original]

ISO/IEC 25010:2011. Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models. Geneva: International Organization for Standardization, 2011.

ISO/IEC/IEEE 12207:2017. Systems and software engineering – Software life cycle processes. Geneva: International Organization for Standardization, 2017.

ISO/IEC/IEEE 29119-2:2013. Software and systems engineering – Software testing – Part 2: Test processes. Geneva: International Organization for Standardization, 2013.

SEAMAN, C.; GUO, Y. Measuring and Monitoring Technical Debt. In: ADVANCES IN COMPUTERS, v. 82, p. 25-46, 2011.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy