https://github.com/isaacalves7/qa

🧪⚗️👨🏾‍🔬 Good practices of QA/QC (Quality Assurance and Quality Control) including TDD, BDD and DDD for Continuous testing from scratch.
https://github.com/isaacalves7/qa

automated-testing automation-testing bdd cicd clean-architecture clean-code continuous-integration continuous-testing cucumber ddd extreme-programming gherkin integration-testing observability qa quality-assurance refactoring solid tdd unit-testing

Last synced: 28 days ago
JSON representation

🧪⚗️👨🏾‍🔬 Good practices of QA/QC (Quality Assurance and Quality Control) including TDD, BDD and DDD for Continuous testing from scratch.

• Host: GitHub
• URL: https://github.com/isaacalves7/qa
• Owner: IsaacAlves7
• Created: 2025-07-15T19:44:12.000Z (11 months ago)
• Default Branch: master
• Last Pushed: 2025-08-26T19:26:34.000Z (10 months ago)
• Last Synced: 2025-08-27T03:32:14.574Z (10 months ago)
• Topics: automated-testing, automation-testing, bdd, cicd, clean-architecture, clean-code, continuous-integration, continuous-testing, cucumber, ddd, extreme-programming, gherkin, integration-testing, observability, qa, quality-assurance, refactoring, solid, tdd, unit-testing
• Language: C#
• Homepage:
• Size: 12.3 MB
• Stars: 0
• Watchers: 0
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
[![License](https://img.shields.io/badge/license-Apache%20License%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)

[![Java](https://img.shields.io/badge/java-17%2B-blue)](https://www.oracle.com/java/technologies/javase/jdk17-archive-downloads.html)

[![Release](https://img.shields.io/github/release/rife2/tests-badge.svg)](https://github.com/rife2/tests-badge/releases/latest)

[![GitHub CI](https://github.com/rife2/tests-badge/actions/workflows/bld.yml/badge.svg)](https://github.com/rife2/tests-badge/actions/workflows/bld.yml)

[![Tests](https://rife2.com/tests-badge/badge/com.uwyn/tests-badge)](https://github.com/rife2/tests-badge/actions/workflows/bld.yml)

[![Tests](https://rife2.com/tests-badge/badge/com.uwyn/tests-badge)](https://github.com/rife2/tests-badge/actions/workflows/bld.yml)



> Versículo chave: "Consagre ao Senhor tudo o que você faz, e os seus planos serão bem-sucedidos." - Provérbios 16:3

# It's a repository of QA/QC from scratch 🧪

     

> 🧪 **Preparação**: Para este conteúdo, o aluno deverá dispor de um computador com acesso à internet, um web browser com suporte a HTML 5 (Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, Opera etc.), um editor de texto ou IDE (VSCode etc.).



Profissional de QA/QC com experiência multidisciplinar e visão sistêmica da qualidade de software ao longo de todo o ciclo de vida do produto, atuando de forma estratégica na prevenção de defeitos (Quality Assurance) e de forma operacional na detecção e controle da qualidade (Quality Control). Minha atuação não se limita à fase final do desenvolvimento, mas começa desde o entendimento de requisitos, regras de negócio e riscos, garantindo que a qualidade seja construída desde a concepção até a entrega e operação do software.

No contexto de Quality Assurance, trabalho com definição e evolução de processos de qualidade, estabelecendo padrões, critérios de aceitação e estratégias de teste alinhadas aos objetivos do negócio. Aplico princípios como shift-left testing, prevenção de defeitos, melhoria contínua e gestão de riscos, colaborando diretamente com times de produto, design e engenharia para garantir requisitos claros, testáveis e rastreáveis. Atuo com abordagens como TDD, BDD e ATDD, promovendo testes orientados a comportamento e valor de negócio, além de apoiar a adoção de boas práticas como pirâmide de testes, testabilidade de software e quality gates integrados ao CI/CD.

Na camada de Quality Control, executo e estruturo testes manuais e automatizados em diferentes níveis, abrangendo testes unitários, testes de integração, testes de sistema e testes de aceitação, garantindo que cada camada do sistema seja validada de forma adequada. Realizo testes funcionais, regressivos, exploratórios e de usabilidade, além de testes não funcionais como performance, carga, estresse, segurança, confiabilidade e compatibilidade. Trabalho com validação de APIs, interfaces web e aplicações distribuídas, assegurando consistência entre front-end, back-end e integrações externas.

Também atuo fortemente na automação de testes como meio de escalabilidade da qualidade, integrando suites automatizadas aos pipelines de CI/CD para garantir feedback rápido e confiável a cada commit e pull request. Utilizo estratégias de automação equilibradas, priorizando cenários críticos de negócio e evitando automação excessiva sem valor, sempre respeitando o custo-benefício e a manutenibilidade dos testes. A automação é tratada como código, seguindo princípios de Clean Code, reutilização, isolamento e clareza, garantindo que os testes evoluam junto com o sistema.

Ao longo das fases do desenvolvimento, participo ativamente de planejamento, refinamento, code reviews e retrospectivas, contribuindo para a melhoria contínua da qualidade do produto e do processo. Analiso métricas como cobertura de testes, taxa de defeitos, retrabalho, tempo de feedback e estabilidade das entregas, utilizando esses dados para orientar decisões técnicas e de produto. A qualidade deixa de ser subjetiva e passa a ser mensurável, observável e alinhada a indicadores reais de valor.

Além disso, atuo na validação da experiência do usuário e do comportamento do sistema em produção, colaborando com monitoramento, observabilidade e análise de incidentes para retroalimentar o processo de qualidade. A qualidade não termina no deploy, mas continua no acompanhamento do uso real do software, garantindo confiabilidade, segurança e evolução sustentável. Dessa forma, QA/QC se tornam pilares estratégicos para a entrega de software robusto, previsível e alinhado às expectativas técnicas e de negócio.

- https://medium.com/@n-demia/10-github-repositories-for-software-testers-121ff3b84fe1?source=email-afeafff77325-1699769789726-digest.reader--121ff3b84fe1----13-102------------------3e6a1339_641a_4699_9f6d_fd3dd3bcfe52-1

- https://youtu.be/x3cANGNPyx0

- https://substack.com/redirect/7de16a93-4fc6-4656-a50c-b1bfe73d5399?j=eyJ1IjoiMmRpcmZwIn0.DgQpD9vnxeDXnbOGqr5r4QICWGtxf2wFAnKNG8yY6Aw

Top AI Coding Tools for Developers You Can Use in 2025:

   

      

      

   

Here are our favorite dev tools:

Development Environment

A good local dev environment is a force multiplier. Powerful IDEs like VSCode, IntelliJ IDEA, Notepad++, Vim, PyCharm & Jupyter Notebook can make your life easy.

Diagramming

Showcase your ideas visually with diagramming tools like DrawIO, Excalidraw, mindmap, Mermaid, PlantUML, Microsoft Visio, and Miro

AI Tools

AI can boost your productivity. Don’t ignore tools like ChatGPT, GitHub Copilot, Tabnine, Claude, Ollama, Midjourney, and Stable Diffusion.

Hosting and Deployment

For hosting your applications, explore solutions like AWS, Cloudflare, GitHub, Fly, Heroku, and Digital Ocean.

Code Quality

Quality code is a great differentiator. Leverage tools like Jest, ESLint, Selenium, SonarQube, FindBugs, and Checkstyle to ensure top-notch quality.

Security

Don’t ignore the security aspects and use solutions like 1Password, LastPass, OWASP, Snyk, and Nmap.

Note-taking

Your notes are a reflection of your knowledge. Streamline your note-taking with Notion, Markdown, Obsidian, Roam, Logseq, and Tiddly Wiki.

Design

Elevate your visual game with design tools like Figma, Sketch, Adobe Illustrator, Canva, and Adobe Photoshop.

Over to you: Which dev tools do you use?

1. AI Code Assistants

   - GitHub Copilot: Ferramenta de completação de código e programação automática.

   - ChatGPT: Ajuda a escrever e depurar código com os modelos mais recentes.

   - Claude: Conhecimento recente e especializado de programação para gerar código preciso e atualizado.

   - Amazon CodeWhisperer: Assistente de IA no IDE

2. Curredor de IDEs

   - Alimentados por IA: IDE com IA para Windows, macOS e Linux.

   - Windsurf: IDE alimentado por IA que lida com tarefas complexas de forma independente.

   - Replit: Crie aplicativos totalmente funcionais para entrar no ar rapidamente.

3. Team Productivity

   - Cody: O assistente de código de IA corporativa para escrever, corrigir e manter código.

   - Pieces: Ferramenta de produtividade habilitada por IA para ajudar desenvolvedores a gerenciar trechos de código.

   - Visual Copilot: Converta designs Figma em código React, Vue, Svelte, Angular ou HTML.

4. Qualidade e Conclusão do Código

   - Snyk: Varredura em tempo real de vulnerabilidades de código gerado por humanos e IA.

# 👨🏾‍🔬 QA/QC - Quality Assurance and Quality Control

       



Imagine-se como um entusiasta da tecnologia, ansioso por entender como um software pode ser eficaz e confiável. Como garantir que um software atenda às expectativas dos usuários e funcione sem falhas? Esse dilema cria um conflito cognitivo que nos impulsiona a mergulhar mais fundo.

A história da **Qualidade de Software** nos mostra a evolução dos processos, desde as abordagens mais tradicionais até as metodologias ágeis modernas. Aprender sobre modelos de qualidade, como o ISO 25000, e as dimensões da qualidade, como funcionalidade e usabilidade, enriquece nossa compreensão. As peças se encaixam, transformando a questão inicial em um quebra-cabeça conceitual.

Imagine que você é um membro de uma equipe de desenvolvimento de software. Você é desafiado a aplicar os conceitos aprendidos em um cenário real. Você participa de revisões, que são análises colaborativas do código, e auditorias, que avaliam os processos utilizados. Essa simulação o coloca no ambiente profissional, onde as decisões têm impacto direto na qualidade do software.

Ao concluir as revisões e auditorias, você reflete sobre os processos e a eficácia das técnicas aplicadas. Reconhece a importância de identificar falhas cedo e como as revisões sistemáticas podem prevenir erros custosos. Você compreende que, assim como o software, o aprendizado é um processo contínuo (Continuous Learning). E à medida que você assimila esses conceitos, torna-se mais apto a contribuir para o desenvolvimento de software de alta qualidade, solidificando sua jornada na compreensão da Qualidade de Software

> [!Note]

> Esse conteúdo é geralmente abordado no final das graduações da área de TI, ou seja, é um módulo avançado e atua com boas práticas do mercado. Então eu vou supor que todos já sabem desenvolver softwares e pular toda a parte de codificação com metodologias ágeis e ciclo de vida de desenvolvimento para partir pro ponto de qualidade de software. As abordagens e princípios de qualidade de software serão os pontos chaves para o ciclo de desenvolvimento, não o que prende cada conceito, mas o essencial para que todo fluxo de desenvolvimento funcione conforme o esperado.

> [!Tip]

> Vamos recordar a importância das boas práticas de programação como um elemento essencial na busca pela qualidade de software. Revisitarmos a noção de código limpo e bem estruturado, que não só facilita a manutenção, mas também reduz erros e falhas futuras. Recordar como padrões de nomenclatura consistentes, comentários claros e modularização do código são cruciais para criar um produto de software robusto e de fácil compreensão. Isso nos lembrará que a qualidade não se limita apenas aos processos de teste, mas começa desde a concepção do código-fonte.

Primeiro, precisamos entender que a qualidade de software é uma área de grande importância no mercado de tecnologia da informação. E para garantir a qualidade de um software, é preciso conhecer seus fundamentos, entender sua história, compreender os custos envolvidos, realizar atividades de apoio, seguir padrões e avaliar seus atributos. A seguir, apresentamos alguns desses atributos:

> [!Important]

> **Definição**: Qualidade é a característica ou atributo que define algo ou alguém em termos de excelência, valor, ou nível de desempenho. Pode se referir a propriedades como durabilidade, eficiência, eficácia, ou valor percebido. “Qualidade é a medida de quanto um projeto atende aos requisitos especificados no escopo.”

Desde muito tempo, muitos engenheiros de software e empresas desenvolveram softwares de modo casual, por acreditarem que a criação de programas não podia seguir regras, normas ou padrões. Porém, o poder da comunidade eletrônica característica do século XXI, criada por redes de computadores e softwares, instituiu a era da troca de informação e conhecimentos em todo o mundo.

Sendo assim, destaca-se a área de Engenharia de Software, que auxilia o entendimento do processo de desenvolvimento de softwares. Desta forma, nos processos de qualidade de software, a gerência de risco e o teste de software são pontos fundamentais para a garantia da qualidade do produto gerado.

A proposta da disciplina é oferecer a você um guia quanto à importância de as empresas implementarem normas e modelos que permitam a garantia e a correta avaliação de qualidade de produtos e de processos de desenvolvimento de software.

O objetivo da função de qualidade e testes de software é:

- Reconhecer a necessidade de se adotar um processo de testes para garantir a qualidade do desenvolvimento de software, bem como as métricas utilizadas nos testes;

- Desenvolver um plano de qualidade de software (SQA) que esteja em conformidade com normas e padrões de qualidade, bem como usar ferramentas para garantir a qualidade no seu desenvolvimento;

- Produzir planos de mitigação de riscos e identificar qual modelo se adapta para cada tipo de software.

Antes de passarmos para os modelos de integração, discutiremos brevemente sobre os VCS, Modelos de controle de versão.

Em uma equipe de desenvolvimento, precisaremos de uma ajuda para sincronizar e manter o histórico do código, de maneira concreta utilizamos ferramentas como **Git** e SVN.

A integração contínua não possui necessidade de muitas ferramentas, em tese, mas alguns auxílios que são padrão em práticas de desenvolvimento são requiridos.

O **Git** é o mais popular em integração hoje em dia, mas não precisamos utiliza-lo, basta que tenhamos algum modelo de controle de versão de nossa escolha.

A ferramenta em si não importa, mas o que devemos inserir em nosso sistema de controle? De maneira geral, deve conter tudo aquilo que é necessário para a construção do projeto.



- código

- scripts

- migrações, schemas

- IDE Configs

- Devemos definir uma formatação de código para a equipe. Para começarmos um projeto é necessário fazer o clone - a cópia local - e o comando unificado (deve ser fácil).

- Não significa que devemos comitar o artefato de construção, ou seja, no caso de um desenvolvedor Ruby ou Gem não deveria estar dentro do repositório, o mesmo ocorre no mundo Java. Resultados da construção do software não são comitados como gem, jar, image e modules.

Sabemos o que comitar e o que não comitar, então seguiremos estudando os modelos de repositório que exitem no mercado. Então, o que deve conter no repositório?

- **Scripts de testes**, os testes são uma parte essencial da aplicação. Os testes também são códigos, e scripts relacionados a eles devem entrar no repositório;

- **Database Schema**, faz parte da aplicação e é preciso para construir e executar o projeto.

Contudo, como organizar nossos repositórios? Em uma empresa encontramos mais de um projeto por vez, e é importante que saibamos como representar estes projetos dentro do repositório.

![repository_strategy](https://github.com/user-attachments/assets/0dd4cca2-3b76-41ee-be91-06549c9b3249)

O que é mais natural é utilizar um repositório para cada projeto, de um tamanho razoável com escopo bem definido. Essa forma de organização é chamada **Multi-repo**.

No entanto, nos últimos anos, surgiu uma nova forma de organização dos nossos projetos dentro de repositórios. Empresas grandes de tecnologia como Google e Facebook não utilizam o esquema Multi-repo, porque são empresas que trabalham em inúmeros projetos de maneira concomitante. Empresas que atuam com outra dimensão de projetos utilizam o **Mono-repo**, ou seja, um único e gigantesco repositório que acumula todos os projetos.

> [!Note]

> Mono-repo e multi-repo são conceitos centrais e amplamente adotados no ecossistema de micro-frontends, justamente porque a forma como o código é organizado tem impacto direto na autonomia das equipes, no deploy independente e na escalabilidade do projeto — pilares dos micro-frontends. E microserviços também adotam amplamente os modelos de mono-repo e multi-repo, e nesse contexto a escolha é tão ou até mais estratégica do que em micro-frontends, porque afeta diretamente autonomia operacional, versionamento, esteira de deploy, governança de APIs e isolamento entre times. Em microserviços, a estrutura do repositório se torna praticamente parte do design arquitetural, e as empresas costumam escolher um modelo de acordo com o nível de independência desejado, maturidade do time e complexidade do domínio.

Quando você fala de *features* como componentes dentro de uma **plataforma componível**, você está descrevendo exatamente o movimento moderno de arquitetura modular que unifica **microserviços**, **microfrontends** e **evolução contínua de produto** (Lean Manufacturing + Agile + Spotify Squad) em um ecossistema onde cada parte é independente, substituível e expansível. E sim: nesse cenário, cada *feature* deixa de ser apenas uma “função nova” e passa a ser uma *unidade de evolução do produto*, quase como um “módulo de negócios” versionado, isolado, escalável e plugável.

A ideia é que cada *feature* não seja só um pedaço de UI ou uma rota de API, mas um **componente de domínio** inteiro: comportamento, dados, lógica, integrações e interface. Em uma plataforma componível, isso vira um bloco arquitetural — uma peça que pode ser combinada com outras, assim como peças de LEGO, para formar um produto vivo.

Quando você expande isso para o mundo real, especialmente no contexto de **microserviços** e **microfrontends**, cada feature se transforma naturalmente em um **building block** que pode ser desenvolvido, implantado, versionado e escalado de forma independente. Um módulo do domínio, como “Billing”, “Checkout”, “User Profile”, “Recommendations”, “Inventory”, por exemplo, é tratado como uma feature-mãe, que por sua vez contém subfeatures. Essa modularidade profunda é o que permite a evolução contínua do produto sem criar aquele monolito rígido que só cresce e nunca melhora.

Dentro dessa lógica, um **monorepo** fortalece a colaboração quando as equipes compartilham código, protocolos, contratos de API, padrões de UI e testes. Já o **multirepo** fortalece a autonomia quando cada feature é um “produto dono de si mesmo”: sua pipeline, seu deploy, sua versão, seu runtime, sua granularidade. Plataformas composable normalmente aceitam os dois lados: repositório único quando faz sentido compartilhar infraestrutura; múltiplos repositórios quando a autonomia acelera o produto.

E, claro, quando você conecta tudo isso — features componíveis + microserviços + microfrontends + mono/multi-repo — o produto deixa de ser um software linear e vira um ecossistema modular que evolui como um organismo vivo. Cada feature nova é uma célula que nasce no sistema, cresce, se integra, e pode ser substituída sem derrubar o corpo inteiro. Essa é a essência da evolução contínua moderna: o produto nunca está pronto, ele sempre está se transformando em algo melhor.

A desvantagem do segundo modelo é o repositório precisará ser realmente grande, e o *build* pode ser lento, talvez nem o Git seja mais a ferramenta adequada para fazer o controle de versões para esta situação. Contudo, como temos apenas um grande repositório temos uma administração relativamente mais simples, então a verificação de padrões é facilitada. As refatorações são globais, afinal estão todos dentro da mesma base.

Vamos trabalhar com o Multi-repo, afinal é o mais comum no dia a dia da maioria dos desenvolvedores.

   

      

      

   

Monorepo vs. Microrepo. Qual é o melhor? Por que diferentes empresas escolhem opções diferentes?

**Monorepo** não é novidade; Linux e Windows foram ambos criados usando Monorepo. Para melhorar a escalabilidade e a velocidade de construção, o Google desenvolveu sua cadeia interna de ferramentas dedicada para escalá-la mais rapidamente e padrões rigorosos de qualidade de codificação para mantê-la consistente.

Amazon e Netflix são grandes embaixadoras da filosofia dos Microserviços. Essa abordagem naturalmente separa o código de serviço em repositórios separados. Escala mais rápido, mas pode causar problemas de governança no futuro.

Dentro do Monorepo, cada serviço é uma pasta, e cada pasta tem uma configuração BUILD e controle de permissões OWNERS. Cada membro do serviço é responsável por sua própria pasta.

Por outro lado, no Microrepo, cada serviço é responsável por seu repositório, com a configuração de compilação e as permissões normalmente definidas para todo o repositório.

No Monorepo, as dependências são compartilhadas por todo o código de código, independentemente do seu negócio, então quando há uma atualização de versão, cada base de código atualiza sua versão.

Como o TikTok gerencia um MonoRepositor de 200K com o Sparo: 

Aviso: Os detalhes deste post foram derivados do TikTok Developer Blog. Todo o crédito pelos detalhes técnicos vai para a equipe de engenharia do TikTok. Os links para os artigos originais estão presentes na seção de referências ao final do post. Tentamos analisar os detalhes e dar nossa opinião sobre eles. Se você encontrar alguma imprecisão ou omissão, por favor, deixe um comentário e faremos o possível para corrigi-las.

O TikTok, a popular plataforma de compartilhamento de vídeos de formato curto, possui uma base de código grande e em rápido crescimento para seu front-end web. Este aplicativo de interface é construído usando TypeScript e está organizado como um monorepo – um único repositório Git contendo código para múltiplos projetos e bibliotecas.

À medida que a equipe de engenharia frontend e o conjunto de recursos do TikTok cresciam, também cresciam o tamanho e a complexidade desse mono-repo.

Com o tempo, expandiu-se para conter mais de 1.000 projetos separados e mais de 200.000 arquivos fonte. Embora a arquitetura monorepo oferecesse benefícios como código compartilhado e ferramentas, também começou a causar problemas significativos de desempenho.

Os desenvolvedores começaram a perceber lentidão nas operações comuns do Git, que são essenciais para seus fluxos de trabalho diários. Essas desacelerações foram um grande peso para a produtividade, desperdiçando tempo valioso de engenharia e prejudicando a experiência de desenvolvimento.

Os problemas vinham do tamanho enorme do código que o Git precisava processar para cada operação. Para resolver esse problema, a equipe de infraestrutura frontend do TikTok começou a explorar soluções. Eles experimentaram os recursos de desempenho embutidos do Git, como clones parciais, clones superficiais e o Git LFS, mas descobriram que eram insuficientes para a escala e taxa de crescimento do monorepo.

Por fim, a equipe desenvolveu uma ferramenta interna chamada Sparo para enfrentar os desafios de desempenho do monorepo. Eles também acabaram tornando o Sparo open-source.

Neste artigo, vamos explorar como o Sparo funciona e os benefícios que ele trouxe para a equipe de engenharia front-end do TikTok.

O problema da lentidão do git em monorepos grandes

Um monorepo, abreviação de repositório monolítico, é uma estratégia de desenvolvimento de software onde um único repositório contém múltiplos projetos, bibliotecas e serviços, frequentemente mantidos por diferentes equipes. Isso contrasta com a abordagem multi-repositório, onde cada projeto tem seu repositório separado.

O diagrama abaixo mostra a diferença entre monorepos, multirepos e bases de código monolíticos.



Os monorepos ganharam popularidade entre grandes empresas de tecnologia como Google, Facebook e Microsoft por vários motivos.

Primeiramente, os monorepos permitem melhor compartilhamento de código e reutilização entre projetos, reduzindo duplicações e promovendo a padronização.

Em segundo lugar, eles simplificam o gerenciamento de dependências, já que projetos dentro do monorepo podem facilmente se referenciar e usar uns aos outros.

Terceiro, os monorepos fornecem uma visão unificada de toda a base de código, facilitando a realização de mudanças transversais e a manutenção de uma infraestrutura consistente de construção e teste.

No entanto, à medida que os monorepos crescem em tamanho e complexidade, as operações do Git se tornam cada vez mais lentas para todos.

Foi exatamente isso que aconteceu no TikTok. Comandos como git clone para baixar uma cópia do repositório, git checkout para alternar entre branches, git status para ver as mudanças atuais e git commit para salvar novas mudanças demoraram muito mais do que antes.

Aqui estão algumas estatísticas interessantes das observações deles:

Clonar o repositório para começar a trabalhar nele pode levar mais de 40 minutos para desenvolvedores com conexões de rede mais lentas. Mesmo em conexões rápidas, um clone completo levava mais de 20 minutos.

Conhecer uma agência diferente levou mais de um minuto e meio.

Só rodar o status git para ver o estado atual da cópia funcional levou 7 segundos, interrompendo o fluxo dos desenvolvedores.

Fazer commit de alterações no código também era doloroso, com cerca de 15 segundos por commit.

Como o Sparo melhora o desempenho do MonoRepo?

No seu cerne, o Sparo aproveita dois recursos avançados do Git para acelerar drasticamente operações comuns em monorepos grandes: verificação esparsa e clone parcial.

Vamos analisar ambos em detalhes.

Checkout Esparso

O recurso de checkout esparso do Git permite especificar um subconjunto de arquivos ou diretórios para ser desligado de um repositório, em vez de buscar todo o código base. O Sparo usa isso para apenas verificar os arquivos necessários para construir uma aplicação específica – ou seja, o projeto e suas dependências.

Em um monorepo com centenas ou milhares de projetos, os arquivos necessários para qualquer projeto são um subconjunto relativamente pequeno e de crescimento lento em comparação com o repositório como um todo.

Ao usar checkout esparso para limitar a cópia funcional a apenas esse subconjunto, o Sparo reduz significativamente a quantidade de dados que precisam ser buscados e o número de arquivos que as operações Git precisam processar. Isso resulta em tempos de finalização muito mais rápidos.

Veja o diagrama abaixo que explica o conceito de checkout esparso no Git, no qual o desenvolvedor só precisa trabalhar no Desenvolvimento de Cliente Android.



Clones Parciais

Embora o checkout esparso reduza o número de arquivos na cópia funcional, um clone padrão do Git ainda recupera o conteúdo de todos os arquivos no repositório e seu histórico completo.

Para repositórios grandes, isso ainda significa uma quantidade considerável de transferência de dados e uso de disco, mesmo que grande parte não seja necessária localmente.

O recurso de clonagem parcial do Git, habilitado ao passar a opção --filter=blob:none para o clone do git, otimiza isso ao buscar o conteúdo dos arquivos sob demanda conforme necessário, e excluindo objetos que não são acessíveis por nenhuma referência. Isso reduz o tamanho do clone inicial e acelera as buscas subsequentes.

Veja o diagrama abaixo para uma representação visual do mesmo.



Diferente de um clone superficial, a história completa ainda está disponível se necessário, só que não é baixada com entusiasmo. Além disso, diferente do Git LFS, o clone parcial funciona automaticamente para todos os arquivos, sem um sistema de armazenamento separado.

Melhorias adicionais do Sparo

O Sparo adiciona algumas melhorias além de aproveitar esses dois recursos principais do Git.

Confira Perfis

O Sparo introduz o conceito de perfis de checkout, que são conjuntos pré-definidos de diretórios para serem incluídos em um checkout esparso. Perfis funcionam como um ponto de partida fácil para novos contratados ou colaboradores descobrirem qual parte do código é relevante para uma determinada equipe.

Por exemplo, uma equipe frontend pode definir um perfil que verifica seus cinco projetos mais desenvolvidos, as dependências desses projetos e alguns diretórios adicionais como docs e config.

Esses perfis são definidos em um arquivo JSON e registrados no repositório, facilitando para os desenvolvedores compartilharem perfis e configurarem rapidamente sua cópia de trabalho para corresponder ao ambiente padrão da equipe.

Veja o exemplo do arquivo de perfil:

```

{

  "selections": [

    {

      "selector": "--to",

      "argument": "project-a"

    },

    {

      "selector": "--to", 

      "argument": "project-b"

    },

    {

      "selector": "folder",

      "argument": "docs"

    }

  ]

}

```

Esse perfil ajudaria os desenvolvedores a conferir projeto-a, projeto-b e a pasta docs.

Com o perfil criado, os desenvolvedores podem usar o sparo checkout --profile para acessar o repositório de acordo com o perfil. Isso verifica apenas os projetos e pastas especificados, reduzindo significativamente os dados obtidos e o tempo levado.

Comandos Espelhados

Para tornar a adoção sem atritos, o Sparo fornece sua interface de linha de comando que visa ser uma substituição direta para a CLI padrão do Git. Em outras palavras, o Sparo é totalmente compatível com o Git, então as equipes podem adotá-lo incrementalmente enquanto ainda interoperam com o uso padrão do Git.

Ao espelhar a interface Git, o Sparo minimiza a curva de aprendizado e permite que ela seja gradualmente adotada nos fluxos de trabalho existentes. Comandos familiares como clone, checkout, status, add, commit, etc., são todos fornecidos com a mesma sintaxe que seus equivalentes no Git.

Os desenvolvedores podem usar as versões Sparo dos comandos para aproveitar o desempenho otimizado, enquanto ainda recorrem aos comandos Git regulares, se necessário, para casos avançados.

Por trás do capot, as versões Sparo desses comandos configuram automaticamente as configurações apropriadas para permitir clones parciais e checkout esparso com base no perfil ativo. Eles também permitem coletar telemetria de uso anônimo para alimentar dashboards para monitorar a adoção e o desempenho da ferramenta.

Ganhos de desempenho em Sparo

A equipe do TikTok teve melhorias dramáticas no desempenho após adotar o Sparo:

O tempo de clonagem caiu de 23 minutos para apenas 2 minutos

O tempo de finalização do check-in passou de 1,5 minuto para 30 segundos

O tempo de comando de status foi reduzido de 7 segundos para 1 segundo

O tempo de commit melhorou de 15 segundos para 11 segundos

Essas melhorias têm um enorme impacto na produtividade e experiência dos desenvolvedores. Em vez de esperar minutos para as operações do Git serem concluídas, os desenvolvedores podem iterar e comprometer mudanças rapidamente, mantendo seu fluxo e foco.

Conclusão

À medida que os monorepos crescem em tamanho e complexidade, manter um bom desempenho para operações comuns no Git torna-se cada vez mais desafiador. A equipe frontend do TikTok experimentou isso em primeira mão, já que seu monorepo TypeScript ultrapassou 1.000 projetos e 200.000 arquivos-fonte, levando a quedas significativas em comandos como clone, checkout, status e commit.

Para resolver esse problema, a equipe do TikTok desenvolveu o Sparo, uma ferramenta de código aberto que aproveita os recursos de checkout e clones parciais do Git para acelerar as operações do Git em grandes monorepos.

A trajetória da equipe de engenharia do TikTok com a Sparo destaca a importância de abordar proativamente os problemas de desempenho em bases de código em rápido crescimento.

O roadmap da Spo inclui um sistema de plugins de telemetria para monitoramento e suporte a sistemas adicionais de construção front-end. À medida que mais empresas enfrentam desafios de desempenho com monorepos gigantes, ferramentas como o Sparo podem se tornar cada vez mais importantes para manter a produtividade dos desenvolvedores.

https://substack.com/redirect/4f2fff31-8d87-484a-b108-605db7358f27?j=eyJ1IjoiMmRpcmZwIn0.DgQpD9vnxeDXnbOGqr5r4QICWGtxf2wFAnKNG8yY6Aw

https://substack.com/redirect/9e89a07f-e5db-49a4-b476-e21d2e838e4d?j=eyJ1IjoiMmRpcmZwIn0.DgQpD9vnxeDXnbOGqr5r4QICWGtxf2wFAnKNG8yY6Aw

https://substack.com/redirect/3fa0d3d9-d399-4682-84a5-7f81721564f0?j=eyJ1IjoiMmRpcmZwIn0.DgQpD9vnxeDXnbOGqr5r4QICWGtxf2wFAnKNG8yY6Aw

https://substack.com/redirect/d6624c1e-bda9-4a4e-9783-7fbf34c16c6d?j=eyJ1IjoiMmRpcmZwIn0.DgQpD9vnxeDXnbOGqr5r4QICWGtxf2wFAnKNG8yY6Aw

No **Microrepo**, as dependências são controladas dentro de cada repositório. As empresas escolhem quando atualizar suas versões com base em seus próprios cronogramas.

A Monorepo tem um padrão para check-ins. O processo de revisão de código do Google é famoso por estabelecer um padrão elevado, garantindo um padrão de qualidade coerente para o Monorepo, independentemente do negócio.

A Microrepo pode definir seu próprio padrão ou adotar um padrão compartilhado incorporando as melhores práticas. Pode escalar mais rápido para negócios, mas a qualidade do código pode ser um pouco diferente.

Engenheiros do Google construíram Bazel, e a Meta construiu Buck. Existem outras ferramentas de código aberto disponíveis, incluindo Nix, Lerna e outras.

Ao longo dos anos, o Microrepo teve mais ferramentas suportadas, incluindo Maven e Gradle para Java, NPM para NodeJS e CMake para C/C++, entre outras.

> Deixando você: Qual opção você acha melhor? Qual estratégia de repositório de código sua empresa utiliza? Quais ferramentas sua equipe usa para enviar o código para produção e garantir a qualidade do código?

Como o TikTok gerencia um monorepo frontend de 200 mil arquivos? Um MonoRepo, abreviação de repositório monolítico, é uma estratégia de desenvolvimento de software onde um único repositório contém múltiplos projetos, bibliotecas e serviços.

As partes boas de um MonoRepo são:

- Melhor compartilhamento de código

- Gerenciamento simplificado de dependências

- Uma visão unificada da base de código

No entanto, quanto maior o MonoRepo fica, mais lentas são as várias operações do Git.

O TikTok enfrentou uma mudança semelhante com seu frontend TypeScript MonoRepo com 200 mil arquivos.

Para lidar com isso, o TikTok desenvolveu uma ferramenta chamada Sparo que otimiza o desempenho das operações do Git para grandes MonoRepos frontend.

A Sparo melhorou dramaticamente o desempenho das operações do Git. Algumas estatísticas são as seguintes

- O tempo de clonagem do Git passou de 40 minutos para apenas 2 minutos.

- O check-out foi de 1,5 minutos para 30 segundos.

- O status foi de 7 segundos para 1 segundo.

- O tempo de commit do git passou de 15 segundos para 11 segundos.

A abordagem geralmente depende do tamanho da empresa. Não existe uma solução única para todos, mas tentamos oferecer uma visão geral.

![unnamed](https://github.com/user-attachments/assets/f9c70590-04a5-4f6d-96a3-eee38d23948c)

1-10 funcionários: Nos estágios iniciais de uma empresa, o foco é encontrar um ajuste produto-mercado. A ênfase está principalmente na entrega e experimentação. Utilizando ferramentas gratuitas ou de baixo custo existentes, os desenvolvedores cuidam dos testes e da implantação. Eles também prestam muita atenção ao feedback e aos relatórios dos clientes.

10-100 funcionários: Uma vez encontrado o ajuste produto-mercado, as empresas buscam escalar. Eles conseguem investir mais em qualidade para funcionalidades críticas e criar processos de evolução rápida, como implantações programadas e procedimentos de teste. As empresas também estabelecem proativamente processos de suporte ao cliente para lidar com problemas e fornecem alertas proativos.

100-1.000 funcionários: Quando a estratégia de entrada no mercado de uma empresa se mostra bem-sucedida e o produto escala e cresce rapidamente, ela começa a otimizar sua eficiência de engenharia. Mais ferramentas comerciais podem ser adquiridas, como produtos Atlassian. Um certo nível de padronização entre as ferramentas é introduzido, e a automação entra em ação.

1.000-10.000+ funcionários: Grandes empresas de tecnologia desenvolvem ferramentas experimentais e automação para garantir qualidade e coletar feedback dos clientes em larga escala. A Netflix, por exemplo, é bem conhecida por sua estratégia de "Teste em Produção", que realiza tudo por meio de experimentos.

> Deixa você: cada empresa é única. Em que estágio sua empresa está atualmente e quais ferramentas você usa?

O melhor nome de branch no Git é aquele que *comunica intenção, escopo e temporalidade*, sem ambiguidade. Como você está falando de testes (automatizados ou manuais, unitários ou de integração), o nome da branch deve deixar claro *o tipo de teste* e *o objetivo*, não apenas “teste” de forma genérica.

Na prática, a convenção mais aceita hoje segue a ideia de **prefixo semântico**, muito alinhada com Git Flow, Trunk-Based ou variações modernas.

Para **testes automatizados**, o termo mais claro e profissional é usar `test/`, porque comunica que a branch existe para validar comportamento, não para feature nem correção pontual. Exemplos bem aceitos seriam algo como `test/unit-order-service`, quando o foco é teste unitário de um contexto específico, ou `test/integration-payment-flow`, quando o objetivo é validar integração entre componentes ou serviços. Isso deixa explícito que a branch é temporária e experimental.

Se o foco for **testes manuais**, geralmente não se cria branch só para isso, porque testes manuais normalmente validam código já integrado. Mas se houver necessidade — por exemplo, para QA ou homologação isolada —, nomes como `qa/manual-tests` ou `test/manual-regression` fazem mais sentido do que algo genérico. A palavra `qa` costuma ser usada exatamente para esse contexto de validação humana.

Para **testes unitários**, o mais limpo é explicitar `unit`, porque isso evita confusão com testes mais pesados. Algo como `test/unit-auth-module` comunica imediatamente o escopo técnico e reduz ruído na revisão de PR. Já para **testes de integração**, `test/integration` ou `test/it-*` (IT = Integration Tests) é uma convenção bastante comum em times mais maduros, especialmente em ambientes com microsserviços.

Se você quiser algo ainda mais alinhado com engenharia de software e menos “acadêmico”, pode usar nomes como `validation/` ou `verification/`, mas isso só funciona bem se todo o time estiver alinhado, senão gera confusão. Em times menores ou projetos pessoais, `test/` é direto e suficiente.

> [!Note]

> Em resumo, o melhor nome não é “teste” puro. É algo que diga claramente **o que está sendo testado e como**. Algo como `test/unit`, `test/integration` ou `qa/manual` é muito mais legível, profissional e sustentável do que `branch-teste` ou variações vagas. Então, resumindo de forma direta: `test/` é o padrão mais correto, mais neutro e mais alinhado com práticas modernas de versionamento. `tests/` é aceitável, mas menos comum. `tdd/` e `bdd/` não são bons nomes de branch, porque descrevem processo mental, não objetivo técnico.

Pensando como engenheiro e não de preferência pessoal, o melhor padrão é **`test/`**, não `tests/`, e evitar `tdd/` ou `bdd/` como prefixo de branch. Isso não é porque TDD ou BDD sejam ruins, mas porque **branch nomeia intenção operacional**, não metodologia:

- [x] `test/` funciona melhor porque a branch representa uma **atividade de validação** temporária. Ela existe para testar algo, validar comportamento, rodar suites, ajustar cenários e depois morrer. `tests/` no plural costuma ser usado para **pastas no código**, não para fluxo de versionamento, e acaba misturando semânticas.

- [ ] `tdd/` e `bdd/` são ainda menos adequados como prefixo de branch porque *TDD e BDD são estratégias de desenvolvimento*, não tipos de branch. Você pode perfeitamente estar fazendo TDD dentro de uma `feature/` ou até numa `fix/`. Criar uma branch `tdd/` dá a falsa impressão de que só ali se pratica TDD, o que conceitualmente não faz sentido.

O que realmente comunica bem é combinar `test/` com o **nível do teste** e, se necessário, com o **contexto do sistema**. Algo como `test/unit-auth`, `test/integration-payment-flow` ou `test/e2e-checkout`. Isso deixa claro para qualquer pessoa do time que aquela branch não entrega funcionalidade nova, não corrige bug produtivo e não é release — ela existe para validar.







Se a distinção for entre *manual e automatizado*, o mais limpo é explicitar isso no sufixo quando realmente necessário, como `test/manual-regression` ou `test/automation-smoke`. Mas, na prática, testes manuais quase nunca justificam branch própria; eles validam código já integrado.

A realidade de times maduros em empresas grandes, especialmente aquelas que tratam engenharia de software como uma verdadeira **fábrica de software** (Lean Startup), e não apenas como entrega pontual de features. Quando a organização atinge certo nível de complexidade técnica e de negócio, o repositório deixa de ser apenas um lugar para “guardar código” e passa a ser um ativo crítico, governado por processos, padrões e decisões arquiteturais conscientes.

Em ambientes assim, seja em multirepos ou monorepos, cada repositório costuma representar um domínio, um bounded context ou ao menos uma responsabilidade bem definida dentro do ecossistema. Isso faz com que commits e PRs - pull requests não sejam avaliados apenas pelo “funciona ou não funciona”, mas pelo impacto estrutural que aquele código terá no médio e longo prazo. O code review deixa de ser cosmético e passa a ser um mecanismo de proteção do sistema contra degradação técnica, acúmulo de dívidas e introdução silenciosa de code smells que, no começo, parecem inofensivos, mas que no futuro comprometem legibilidade, manutenibilidade e estabilidade.

Por isso, a aprovação de PRs normalmente envolve múltiplos olhares: alguém atento à aderência a princípios como Clean Code e SOLID, alguém com visão mais arquitetural avaliando se aquela mudança respeita os limites do domínio e não viola decisões já consolidadas, e muitas vezes alguém com contexto histórico do sistema, capaz de identificar se aquilo está reforçando um legado problemático ou ajudando a reduzir complexidade. Em times mais avançados, esse processo não é visto como burocracia, mas como um filtro essencial para manter a saúde do software ao longo do tempo.

Quando entram conceitos como Arquitetura Limpa e DDD, o nível de exigência sobe ainda mais. Não basta escrever código “bonito”; é preciso garantir que as regras de negócio estejam isoladas, que dependências estejam apontando na direção correta e que o modelo de domínio continue expressivo e coerente com a linguagem do negócio. O PR passa a ser um espaço de discussão técnica profunda, onde se questiona se aquela abstração faz sentido, se aquele serviço realmente pertence àquele contexto ou se aquilo é apenas um atalho que vai custar caro depois.



No fim das contas, esse modelo de gestão de repositórios e revisões é justamente o que diferencia times que vivem apagando incêndio de times que conseguem evoluir sistemas grandes sem perder controle. A fábrica de software não produz apenas código que roda hoje, mas código que continua compreensível, sustentável e confiável daqui a anos, mesmo com pessoas entrando e saindo do time. É uma visão menos imediatista e muito mais estratégica da engenharia de software.

> [!Note]

> **FUNDAMENTOS DA QUALIDADE DE SOFTWARE**: Incluem a definição de requisitos, o planejamento de testes e a execução de testes de forma sistemática. Esses processos são essenciais para garantir que o software desenvolvido atenda às necessidades do usuário e atinja a qualidade esperada.

No antigo Egito, há aproximadamente 4 mil anos, para que as construções fossem feitas com **qualidade**, definiu-se o cúbito, que era a distância do cotovelo à ponta do indicador do faraó. Uma das primeiras tentativas da humanidade de _padronizar_ as medidas, gerando qualidade nas construções.

Nesta escultura, temos na base um compilado com as regras e leis a serem seguidas, impostas por Hamurabi, Rei da Babilônia, que era aplicada a cidadãos livres, comerciantes, escravos, etc. Uma das primeiras tentativas de _padronizar_ as regras de convívio da sociedade, há aproximadamente 3.800 anos atrás.

Historicamente, o conceito de qualidade está ligado à ideia de atender padrões e requisitos acordados, com base em comunicação clara e objetivos definidos, seja na qualidade do ar, qualidade da água, da qualidade de vida ou qualidade do software. Portanto, a qualidade de software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar.

A busca por qualidade não é algo novo. Desde os primórdios, o ser humano busca aprimorar suas criações e produções, seja para torná-las mais duráveis, funcionais ou esteticamente agradáveis. Com o advento da Revolução Industrial, essa busca se intensificou, principalmente no que diz respeito à produção em massa. 

Mas foi somente com a Segunda Guerra Mundial que a qualidade passou a ser vista como uma questão estratégica, com a necessidade de se produzir em larga escala produtos de alta qualidade para suprir as demandas militares. A partir daí, a qualidade começou a ser tratada como um processo e a ser estudada de forma mais sistemática. A evolução histórica da qualidade de software pode ser dividida em várias fases:

1. **PRIMEIRA FASE**: Conhecida como era dos “programadores heróis”, ocorreu na década de 1940 a 1950, quando o foco era na programação manual e não havia processos formais de garantia de qualidade.

2. **SEGUNDA FASE**: Foi a era dos “produtos de software”, que teve início nos anos 1960 e trouxe a necessidade de se preocupar com a qualidade dos softwares produzidos, mas ainda sem muita formalização.

3. **TERCEIRA FASE**: A era da “engenharia de software”, teve início nos anos 1970 e marcou o surgimento de processos formais de desenvolvimento de software e de metodologias para garantir a qualidade do produto final. Nesta fase, foi criada a ISO 9000, que estabeleceu padrões de qualidade para empresas e serviços em geral.

4. **QUALIDADE TOTAL**: Teve início na década de 1980, trouxe a ideia de que a qualidade não é responsabilidade apenas da área de desenvolvimento de software, mas sim de toda a organização. Foram estabelecidos processos de melhoria contínua e a necessidade de se envolver todos os departamentos e funcionários na busca pela qualidade.

5. **QUALIDADE DE SOFTWARE**: Teve início nos anos 1990, trouxe a necessidade de se preocupar com a qualidade do processo de desenvolvimento do software, e não apenas com o produto final. Surgiram novas metodologias e modelos de maturidade, como o Capability Matu

rity Model Integration (CMMI) e o ISO/IEC 12207, que buscam garantir a qualidade do processo de desenvolvimento.

No início da década de 1980, o governo dos Estados Unidos reconheceu a necessidade de padronizar a qualidade do software. Em 1986, foi publicado o padrão IEEE 610.12, que definiu a terminologia básica usada em engenharia de software, incluindo definições de qualidade de software. Essas definições incluem “qualidade de software” como o grau em que um sistema, componente ou processo atende aos requisitos especificados e/ou implícitos e às necessidades ou expectativas do usuário.

A partir de então, a qualidade de software se tornou um foco importante na indústria de TI e foi acompanhada pelo surgimento de várias ferramentas e técnicas de teste e garantia de qualidade de software. A demanda por softwares confiáveis e de alta qualidade é cada vez maior, uma vez que muitos negócios e serviços dependem de sistemas de software em seus processos diários.

![unnamed](https://github.com/user-attachments/assets/271ded8f-78fa-4729-81b3-25795a6c13c4)

Mudança de Paradigma: Como a Relação Desenvolvedor-Testador Mudou de 1:1 para 100:1

1:1 ratio (~1997) - Softwares costumavam ser gravados em CDs físicos e entregues aos clientes. O processo de desenvolvimento era em estilo cascata, as versões eram certificadas e as versões eram lançadas aproximadamente a cada três anos. Se você tivesse um inseto, esse inseto viveria para sempre. Só anos depois as empresas adicionaram a capacidade de software para pingar a internet em busca de atualizações e instalá-las automaticamente.

10:1 ratio (~2009) - Por volta de 2009, a velocidade de lançamento para produção aumentou significativamente. Patches podiam ser instalados em poucas semanas, e o movimento ágil, junto com o desenvolvimento orientado por iterações, mudou o processo de desenvolvimento. Por exemplo, na Amazon, os serviços web são principalmente desenvolvidos e testados pelos desenvolvedores. Eles também são responsáveis por lidar com questões de produção, e os recursos de teste estão sobrecarregados (proporção 10:1).

100:1 ratio (~2020) - Por volta de 2015, grandes empresas de tecnologia como Google e Microsoft removeram os títulos SDET ou SETI, e a Amazon desacelerou a contratação de SDETs.

Mas como isso vai funcionar para as grandes empresas de tecnologia em termos de testes?

Primeiramente, o aspecto de teste do software evoluiu para ferramentas de teste altamente escaláveis e padronizadas. Essas ferramentas foram amplamente adotadas por desenvolvedores para construir seus próprios testes automatizados.

Em segundo lugar, testar o conhecimento é disseminado por meio de educação e consultoria.

Juntos, esses fatores facilitaram uma transição suave para a proporção de testes de 100:1 que vemos hoje.



Hoje em dia, a busca pela qualidade de software continua em constante evolução, com a introdução de novas tecnologias e metodologias, como a integração contínua e o desenvolvimento ágil, e inteligência artificial que buscam garantir a qualidade do software de forma mais eficiente e rápida.

No entanto, a busca pela qualidade de software ainda é um desafio constante. Novas tecnologias e metodologias surgem a cada dia, e os desenvolvedores de software devem estar atualizados sobre as novas tendências e ferramentas disponíveis. Além disso, a complexidade dos sistemas de software modernos também torna o controle de qualidade mais difícil, exigindo uma abordagem mais estruturada e orientada a processos.

Portanto, os aspectos históricos da qualidade de software nos mostram como essa área evoluiu ao longo do tempo. Desde a década de 1970, a qualidade de software vem sendo debatida e estudada, e hoje em dia é um tema muito importante em empresas de desenvolvimento de software.

Para aprofundar seus conhecimentos sobre qualidade de software, você pode se perguntar: como garantir que um software seja de qualidade? Uma resposta é adotar processos de garantia de qualidade, que englobam atividades como revisões, testes e inspeções para identificar e corrigir defeitos. Além disso, é importante definir critérios de qualidade e medir a qualidade do software com base nesses critérios.

 

Uma ilustração que pode ajudar a entender a importância da qualidade de software é pensar em um aplicativo de banco que apresenta erros constantemente. Isso certamente afetaria a confiança do usuário no aplicativo e, consequentemente, na instituição financeira. Por isso, a qualidade do software é fundamental para garantir a satisfação e fidelização do usuário.

Um livro que eu esperava há muito tempo finalmente saiu: The Software Engineer's Guidebook, escrito por Gergely Orosz, engenheiro de software e autor do 'The Pragmatic Engineer Newsletter'.

Como o livro já saiu, entrei em contato com Gergely para saber se ele estaria disposto a compartilhar um capítulo com o público do boletim. Para minha alegria, ele gentilmente concordou. O capítulo que escolhi é 'Enviando para a Produção'. Espero que você goste.

Você pode conferir o livro aqui: O Guia do Engenheiro de Software

Como líder técnico, espera-se que você coloque o trabalho da sua equipe em produção de forma rápida e confiável. Mas como isso acontece e quais princípios você deve seguir? Isso depende de vários fatores: o ambiente, a maturidade do produto em desenvolvimento, o quão caros são as interrupções e se é mais importante mover rápido ou não ter problemas de confiabilidade.

Este capítulo aborda o envio para produção de forma confiável em diferentes ambientes. Ele destaca abordagens comuns em toda a indústria e ajuda você a aprimorar como sua equipe pensa sobre esse processo. Abordamos:

Extremos no transporte até a produção

Processos típicos de envio em diferentes tipos de empresas

Princípios e ferramentas para o envio responsável para produção

Camadas adicionais de verificação e proteções

Assumindo riscos pragmáticos para agir mais rápido

Considerações adicionais para definir um processo de implantação



Seleção de uma abordagem

1. EXTREMOS NO TRANSPORTE ATÉ A PRODUÇÃO

Vamos começar com dois "extremos" do envio para produção:

Transporte YOLO

A abordagem Você Só Vive Uma Vez (YOLO) é usada em muitos protótipos, projetos paralelos e produtos instáveis como versões alfa/beta. Também é assim que algumas mudanças urgentes entram em produção.

A ideia é simples: faça uma mudança na produção e verifique se funciona na produção. Exemplos de envio YOLO incluem:

SSH em um servidor de produção → abrir um editor (por exemplo, vim) → fazer uma alteração em um arquivo → salvar o arquivo e/ou reiniciar o servidor → ver se a mudança funciona.

Faça uma alteração em um arquivo de código-fonte → force essa mudança sem uma revisão de código → envie uma nova implantação de um serviço.

Acesse o banco de dados de produção → execute uma consulta de produção para corrigir um problema de dados (por exemplo, modificar registros com problemas) → torça para que isso resolva o problema.

O envio do YOLO é o mais rápido possível ao enviar uma mudança para produção. No entanto, ele também tem o maior risco de introduzir novos problemas na produção porque não há rede de segurança. Para produtos com poucos ou nenhum usuário de produção, o dano causado pela introdução de bugs na produção pode ser baixo, então essa abordagem é justificável.

Lançamentos YOLO são comuns para:

Projetos paralelos

Startups em estágio inicial sem clientes

Empresas de médio porte com práticas de engenharia ruins

Resolver incidentes urgentes em locais sem práticas bem definidas de manejo de incidentes

À medida que um produto de software cresce e mais clientes dependem dele, as alterações no código precisam passar por validação extra antes da produção. Vamos para o outro extremo: uma equipe obcecada em fazer tudo o que for possível para não enviar bugs para produção.

Verificação completa por várias etapas

Essa é uma abordagem usada para produtos maduros com muitos clientes valiosos, onde um único bug pode causar grandes problemas. Essa abordagem rigorosa é usada se bugs puderem resultar em clientes perdendo dinheiro ou fazê-los mudarem para a oferta de um concorrente.

Várias camadas de verificação estão em funcionamento, com o objetivo de simular o mundo real com maior precisão, tais como:

Validação local. Ferramentas para engenheiros de software detectarem problemas óbvios.

Validação de CI. Testes automatizados como testes unitários e linting em cada pull request.

Automação antes de implantar em um ambiente de teste. Testes mais caros, como testes de integração ou testes de ponta a ponta, antes da implantação para o próximo ambiente.

Ambiente de teste #1. Testes mais automatizados, como testes de fumaça. Engenheiros de garantia de qualidade podem exercitar manualmente o produto, rodando testes manuais e fazendo testes exploratórios.

Ambiente de teste #2. Um ambiente onde um subconjunto de usuários reais – como usuários internos da empresa ou beta testadores pagos – exerce o produto. O ambiente é combinado com monitoramento e a implementação é interrompida em caso de sinal de regressão.

Ambiente de pré-produção. Um ambiente no qual o conjunto final de validações é executado. Isso geralmente significa rodar outro conjunto de testes automáticos e manuais.

Implementação escalonada. Um pequeno grupo de usuários recebe as mudanças, e a equipe monitora métricas-chave para se manter saudável e verifica o feedback dos clientes. Uma estratégia de implementação em etapas depende do risco da mudança que está sendo feita.

Implementação completa. À medida que a implementação em etapas aumenta, em algum momento mudanças são empurradas para todos os clientes.

Pós-lançamento. Surgem problemas na produção, para os quais monitoramento e alertas são configurados, além de um ciclo de feedback com os clientes. Se houver um problema, ele é tratado pelo processo padrão de plantão. Discutimos esse processo mais detalhadamente na Parte 5: "Engenharia de software confiável."

Um processo de liberação de peso pesado é utilizado por:

Setores altamente regulados, como saúde, aviação ou automotiva.

Provedores de telecomunicações, onde é comum ter ~6 meses de testes rigorosos das mudanças antes que as grandes mudanças sejam enviadas aos clientes.

Bancos, onde insetos podem causar prejuízos financeiros.

Empresas tradicionais com bases de código legadas e poucos testes automatizados. Esses lugares querem manter a qualidade alta e estão felizes em retardar os lançamentos adicionando etapas de verificação.

2. PROCESSOS TÍPICOS DE ENVIO

Diferentes empresas tendem a tomar etapas distintas no envio para a produção. Abaixo está um resumo das abordagens típicas, destacando a variedade de processos:



Como as várias empresas normalmente enviam para produção? Uma tentativa, admitidamente imperfeita, de visualizar as abordagens comuns – e suas diferenças. Caixas pontilhadas significam "frequentemente, mas nem sempre."

Startups

Startups normalmente fazem menos verificações de qualidade. Essas empresas tendem a priorizar o movimento rápido e a iteração rápida, e muitas vezes fazem isso sem muita rede de segurança. Isso faz todo sentido se elas ainda não têm clientes. À medida que os clientes chegam, as equipes precisam encontrar maneiras de evitar regressões e o envio de bugs.

Startups geralmente são pequenas demais para investir em automação, então a maioria faz QA manual – incluindo os fundadores sendo os 'testadores finais', enquanto alguns lugares contratam profissionais dedicados ao QA. À medida que uma empresa encontra seu produto com o mercado, é mais comum investir em automação. E em startups de tecnologia que contratam talentos de engenharia fortes, essas equipes podem implementar testes automatizados desde o primeiro dia.

Empresas tradicionais

Esses lugares tendem a depender mais das equipes de QA. A automação às vezes está presente em empresas mais tradicionais, mas normalmente dependem de grandes equipes de QA para verificar o que é construído. Trabalhar em filiais também é comum; é raro ter desenvolvimento baseado em troncos.

O código geralmente é empurrado para produção em um cronograma semanal ou até menos frequentemente, depois que a equipe de QA verifica a funcionalidade.

Ambientes de staging e UAT (Teste de Aceitação do Usuário) são mais comuns, assim como mudanças maiores e agrupadas enviadas entre ambientes. É necessário aprovar a equipe de QA, o gerente de produto ou o gerente de projeto, para avançar o lançamento para a próxima etapa.

Grandes empresas de tecnologia

Esses locais normalmente investem fortemente em infraestrutura e automação relacionadas ao transporte marítimo com confiança. Esses investimentos frequentemente incluem testes automatizados que rodam rapidamente e entregam feedback rápido, canário, flags de funcionalidades e lançamentos em etapas.

Essas empresas buscam uma barra de alta qualidade, mas também enviar imediatamente após as verificações de qualidade serem concluídas, trabalhando no trunk. Ferramentas para lidar com conflitos de fusão se tornam importantes, já que alguns lugares podem fazer mais de 100 alterações no trunk por dia. Para detalhes sobre QA nas Big Techs, veja o artigo Como as Big Tech fazem QA.

Produto principal da Meta

O Facebook, como equipe de produto e engenharia, merece menção separada, porque essa organização tem uma abordagem sofisticada e eficaz que poucas outras empresas utilizam.

Esse produto Meta tem menos testes automatizados do que muitos imaginam, mas, por outro lado, o Facebook possui uma funcionalidade excepcional de canário automatizado, onde o código é lançado em 4 ambientes: de um ambiente de testes com automação, passando por um que todos os funcionários usam, depois por um mercado de testes em uma região geográfica menor, e finalmente para todos os usuários. Em cada etapa, o lançamento para automaticamente se as métricas estiverem erradas.

3. PRINCÍPIOS E FERRAMENTAS

Quais são princípios e abordagens que valem a pena seguir para enviar mudanças à produção de forma responsável? Considere estes:

Ambientes de desenvolvimento

Use um ambiente de desenvolvimento local ou isolado. Engenheiros devem ser capazes de fazer alterações em sua máquina local ou em um ambiente isolado e único para eles. É mais comum que desenvolvedores trabalhem em ambientes locais. No entanto, lugares como a Meta estão migrando para servidores remotos para cada engenheiro. Do artigo, Dentro da cultura de engenharia do Facebook:

"A maioria dos desenvolvedores trabalha com um servidor remoto, não localmente. A partir de 2019, todo o desenvolvimento web e backend é feito remotamente, sem código copiado localmente, e o Nuclide facilitando esse fluxo de trabalho. No fundo, o Nuclide usava máquinas virtuais (VMs) inicialmente, depois migrando para instâncias OnDemand – semelhante ao funcionamento do GitHub Codespaces hoje – anos antes do lançamento do GitHub Codespaces.

O desenvolvimento móvel ainda é feito principalmente em máquinas locais, pois fazer isso em uma configuração remota, assim como na web e backend, apresenta desafios de ferramentas."

Verifique localmente. Depois de escrever o código, faça um teste local para garantir que funciona como esperado.

Testes e verificação

Considere casos extremos e teste para eles. Quais casos obscuros sua alteração de código precisa considerar? Quais casos de uso reais você ainda não considerou?

Antes de finalizar o trabalho na mudança, compile uma lista de casos limites. Considere escrever testes automatizados para eles, se possível. Pelo menos faça testes manuais. Elaborar uma lista de casos extremos não convencionais é uma tarefa para a qual engenheiros ou testadores de QA podem ser muito úteis.

Escreva testes automatizados para validar suas alterações. Depois de verificar manualmente suas alterações, exercite-as com testes automatizados. Se seguir uma metodologia como desenvolvimento orientado a testes (TDD), você pode fazer isso ao contrário, escrevendo primeiro testes automatizados e depois verificando se sua alteração de código passa por eles.

Outro par de olhos: uma revisão de código. Com suas alterações de código concluídas, faça um pull requests e peça para alguém com contexto analisar suas alterações no código. Escreva uma descrição clara e concisa das mudanças, quais casos específicos serão testados e faça uma revisão de código.

Todos os testes automatizados são aprovados, minimizando o risco de regressões. Antes de enviar o código, execute todos os testes existentes para a base de código. Isso normalmente é feito automaticamente, via o sistema CI/CD (integração contínua/implantação contínua).

Os fundamentos de **teste de software** (Software Testing) se referem a um conjunto de práticas e técnicas utilizadas para garantir que um software seja capaz de atender aos requisitos e expectativas dos usuários, além de estar livre de erros e falhas. Para ser eficaz, o teste de software deve ser planejado, executado e gerenciado de forma adequada. Isso envolve identificar e definir os objetivos do teste, estabelecer critérios de aceitação, selecionar as técnicas e ferramentas adequadas e documentar todo o processo.

Entre os fundamentos do teste de software estão:



1. **Identificação de requisitos**: Os requisitos (requirements) são funcionalidades que o produto precisa ter para atender às expectativas e necessidades das partes interessadas. É importante que todos os requisitos do software estejam claramente definidos e documentados antes do início do teste. Essa etapa é crucial para garantir que o software atenda às expectativas dos usuários e construir MVPs (Mínimo Produto Viável). O **escopo** é o conjunto de características desejadas que descrevem o resultado final do projeto.

2. **Planejamento de teste**: o planejamento do teste deve ser feito de forma estruturada e detalhada, incluindo a definição dos objetivos, recursos, cronograma, técnicas e critérios de aceitação.

3. **Projeto de casos de teste**: os casos de teste devem ser projetados de acordo com os requisitos e objetivos do teste, de forma a garantir a cobertura de todos os aspectos do software.

4. **Execução de testes**: a execução dos testes deve ser feita de forma sistemática e controlada, registrando todas as falhas encontradas.

5. **Avaliação de resultados**: os resultados dos testes devem ser avaliados de acordo com os critérios de aceitação para determinar se o software atendeu aos requisitos.

6. **Relatórios e documentação**: todos os resultados e conclusões do teste devem ser documentados de forma clara e concisa para permitir que outras pessoas entendam e repliquem o processo.

Além desses fundamentos básicos, existem diversas técnicas e ferramentas de teste que podem ser utilizadas para tornar o processo mais eficiente e eficaz. Essas incluem testes funcionais, testes de desempenho, testes de segurança, testes de usabilidade, dentre outros. É importante que o testador esteja familiarizado com as diferentes técnicas e saiba selecionar a mais adequada para cada situação. 

Outro aspecto importante dos fundamentos de qualidade de software é a colaboração entre as equipes envolvidas no desenvolvimento. É preciso que todos os membros trabalhem em conjunto para garantir a qualidade do produto final. Isso inclui desde a comunicação eficiente entre os desenvolvedores e os testadores até a participação do usuário em testes de aceitação.



> [!Important]

> **Software Engineering: A Practitioner's Approach**: Para aprofundar seus conhecimentos sobre qualidade de software, você pode recorrer a materiais como artigos científicos, livros e cursos on-line. Uma indicação de leitura é o livro Software Engineering: A Practitioner's Approach, de Roger Pressman, que aborda temas como garantia de qualidade, medição de qualidade e processos de software. Em resumo, entender os fundamentos de qualidade de software é essencial para garantir o sucesso de projetos de desenvolvimento. Isso inclui a compreensão do conceito de qualidade, a adoção de processos de garantia de qualidade, a definição de critérios de qualidade e a colaboração entre as equipes. Aprofundar seus conhecimentos neste tema é fundamental para se destacar no mercado de trabalho e garantir a satisfação do usuário.

Portanto, o teste de software (Software testing) para os profissionais de QA’s é a forma que utilizamos para avaliar um software, com um objetivo de assegurar e garantir a qualidade do mesmo, nos pontos de vista técnico e funcional. 



O **teste de software** é a prática concreta que os profissionais de QA (no papel de testers, engenheiros de teste ou SDETs) usam para avaliar se o produto realmente cumpre o que deveria cumprir, tanto sob o ponto de vista técnico (estabilidade, performance, segurança) quanto funcional (se as regras de negócio e requisitos do usuário estão atendidos).

O desenvolvimento de software tem várias fases. Quando começamos a construir software, primeiro precisamos definir o que planejamos construir. Definimos alguns limites para o escopo do software que estamos construindo, definimos processos intermediários e marcos para colocar alguns pontos de verificação sobre se estamos indo na direção certa durante o processo de desenvolvimento e definimos critérios de sucesso para que o software saiba o que construímos é o que queríamos. 

O termo mais amplo e sofisticado "Garantia de Qualidade" lida com o estabelecimento de limites e pontos de verificação, e "Teste" é um subconjunto do processo geral de garantia de qualidade que lida com a validação de que tudo isso se juntou para culminar em um produto final que deixará as partes interessadas felizes (principalmente). Se tudo isso é muito abstrato, não tema, explicaremos com um exemplo mais concreto em breve.



Digamos que temos uma ambição simples - queremos aceitar alguma entrada do usuário e imprimi-la de volta no console. A vida não poderia ser mais simples do que isso, pode? Vamos ver como isso se traduz no processo SDLC. Duvido que uma explicação seja necessária, mas aqui está, no entanto - não é um exemplo da vida real, mas simplificado demais para ilustrar o processo de pensamento e também por que o teste de aplicativos evoluiu como uma disciplina separada do desenvolvimento. 

> "Descobrir o inesperado é mais importante do que confirmar o conhecido." - George E.P.Box

Quando falamos de testes de software usamos bastante os conceitos de dois pontos de vista: o _caminho testável_ e _caminho feliz_, mas cada um tem um propósito diferente dentro da estratégia de validação do sistema. O chamado “caminho feliz” (ou “happy path”) é aquele fluxo idealizado em que tudo acontece como esperado, sem erros, exceções ou desvios. 

É o cenário perfeito, onde o usuário ou o sistema segue exatamente o que foi planejado, com entradas válidas, comportamento conforme os requisitos e saída correta. É fundamental porque garante que a funcionalidade principal está realmente atendendo ao objetivo esperado quando usada da maneira correta, e por isso é quase sempre o primeiro caso de teste escrito, seja em testes manuais, automatizados, unitários ou de integração.

Já o “caminho testável” (alternativo ou inesperado) pode ter interpretações ligeiramente diferentes dependendo do contexto, mas normalmente é usado para se referir a qualquer rota dentro do código ou do fluxo da aplicação que pode ser exercitada por um teste. É o conjunto de caminhos possíveis que o teste consegue alcançar, incluindo o caminho feliz e também as rotas alternativas, os cenários de exceção, entradas inválidas, erros de negócio, falhas de integração, entre outros. Em outras palavras, não é só garantir que a função principal funciona, mas também que o sistema se comporta corretamente quando algo sai do esperado. É aí que entram testes negativos, de borda, de falha, de performance ou até mesmo de segurança, que exercitam a aplicação de forma mais ampla e realista.

Portanto, quando você ouve falar de “caminho feliz”, é um subconjunto do “caminho testável”. O caminho feliz prova que o básico funciona; o caminho testável inclui todas as outras possibilidades para dar robustez à aplicação. Ou seja, o usuário é inesperado, então vamos precisar "preparar" a aplicação para coisas inesperadas.

No universo do desenvolvimento de software, a qualidade é um objetivo primordial, e dois termos frequentemente se entrelaçam nesse contexto: Quality Assurance (QA) e Quality Control (QC). Embora muitas vezes usados como sinônimos, esses conceitos representam abordagens distintas, porém complementares, para garantir que o produto final atenda aos mais altos padrões de excelência.

**Quality Assurance (QA)**: Prevenindo os Erros Antes que Eles Acontecçam

Imagine um arquiteto meticuloso, que examina cada detalhe do projeto de uma casa, desde a fundação até o telhado, para garantir que a construção seja sólida, segura e atenda às necessidades dos moradores. Essa é a essência do QA, um processo proativo que se concentra em prevenir erros e defeitos durante todo o ciclo de desenvolvimento de software.

O QA atua como um guardião da qualidade, definindo e implementando processos, padrões e melhores práticas para garantir que o software seja desenvolvido da maneira correta, desde o início. Ele se concentra em:

- Definir e monitorar os processos de desenvolvimento: Implementar metodologias e práticas que garantam a qualidade em todas as etapas do desenvolvimento.

- Estabelecer padrões de qualidade: Definir critérios e métricas para avaliar a qualidade do software em diferentes aspectos, como funcionalidade, usabilidade, desempenho e segurança.

- Prevenir defeitos: Implementar medidas preventivas para evitar que erros e defeitos sejam introduzidos no software, como revisões de código, testes unitários e análise estática de código.

- Promover a cultura de qualidade: Incentivar a colaboração, a comunicação e o feedback entre os membros da equipe, criando um ambiente onde a qualidade é valorizada e priorizada.

**Quality Control (QC)**: Detectando e Corrigindo os Bugs

Agora, imagine um inspetor de qualidade que examina cada cômodo da casa já construída, verificando se tudo está de acordo com o projeto e se não há nenhum problema. Essa é a essência do QC, um processo reativo que se concentra em detectar e corrigir defeitos no software após ele ter sido desenvolvido.

O QC atua como um detetive, buscando por bugs e falhas que podem comprometer a qualidade do software. Ele se concentra em:

- Executar testes: Realizar diferentes tipos de testes, como testes funcionais, de performance, de segurança e de usabilidade, para identificar defeitos no software.

- Reportar bugs: Documentar e reportar os bugs encontrados para a equipe de desenvolvimento, fornecendo informações detalhadas para que eles possam ser corrigidos.

- Verificar as correções: Após a correção dos bugs, o QC realiza novos testes para garantir que os problemas foram resolvidos e que não foram introduzidos novos bugs.

- Monitorar a qualidade do software: Acompanhar o desempenho do software em produção, coletando dados e feedback dos usuários para identificar e corrigir problemas.

 

  

  

 

QA e QC: Um Time Imbatível. QA e QC são como duas faces da mesma moeda, trabalhando em conjunto para garantir a qualidade do software. Enquanto o QA se concentra na prevenção de defeitos, o QC se concentra na detecção e correção dos problemas. A sinergia entre esses dois processos é essencial para construir um software robusto, confiável e que atenda às expectativas dos usuários.

Compreender a diferença entre QA e QC é fundamental para construir uma estratégia de qualidade de software eficaz. Ao integrar as práticas de QA e QC em todo o ciclo de desenvolvimento, as empresas podem garantir que seus softwares sejam desenvolvidos com qualidade, eficiência e segurança, satisfazendo os usuários e impulsionando o sucesso do negócio.

E dentro da distinção clássica entre *QA (Quality Assurance)* e *QC (Quality Control)*, os **testes de software** se enquadram como atividades de QC, porque estão no nível da inspeção e verificação do produto final. 

QA olha mais para os processos, prevenindo defeitos ao longo do ciclo (definição de padrões, auditorias de qualidade, práticas de engenharia), enquanto QC foca em detectar e validar defeitos no resultado tangível — o software em execução, as integrações funcionando, os requisitos sendo cumpridos.

Portanto, sim: quando falamos em **testes manuais, automatizados, de integração, de aceitação, de regressão, de performance, etc.**, estamos atuando dentro da **camada de QC**. Eles são o mecanismo pelo qual conseguimos transformar “expectativas de qualidade” em **evidências objetivas** de que o software funciona (ou não) como esperado.



> [!Important]

> Vantagens dos testes de software: Se você quer evoluir em testes de software e entender como integrar qualidade de forma colaborativa e contínua em equipes ágeis, o livro **"Agile Testing: A Practical Guide for Testers and Agile Teams"**, escrito por Lisa Crispin e Janet Gregory, é uma leitura essencial para transformar a teoria em prática.

> 

> - Qualidade

> - Suporte ao time

> - Feedback constante

> - Produtividade

> - Documentação viva

> - Alinhamento com o negócio

> - Disseminação de conhecimento

> - Prevenção de bugs: Evitar a continuação dos bugs

> - Redução de Custos

A definição de “pronto” nada mais é do que um contrato firmado entre o time e o PO, que lista de forma clara os requisitos que determinam que uma User Story está completa.

> E a resposta é simples: normalmente, quando perguntam se uma funcionalidade ou story está pronta, respondem: “sim, mas falta testar…”.

Isso significa que ao definir o conceito de “pronto”, é importante que o QA – que faz parte do time – esteja envolvido e possa sensibilizar os membros do time e PO para que os testes façam parte deste conceito.

Dessa forma, garantimos:

- Integração entre desenvolvedores e QA;

- Maior qualidade do time;

- Que não haja desentendimentos desnecessários;

- Story testada e com aceite formal. 

As atividades de apoio da qualidade de software, como revisões, auditorias e inspeções, são essenciais para garantir que o software seja produzido de acordo com os padrões de qualidade estabelecidos. Essas atividades podem ser realizadas em diferentes momentos do ciclo de vida do software, desde a análise de requisitos até a manutenção.

As **revisões** são uma das atividades de apoio mais comuns e envolvem a análise do software por um grupo de pessoas para detectar erros e possíveis melhorias. Existem diferentes tipos de revisões, como revisões de código (Code Reviews), revisões de documentos e revisões de design. Participar de Code Reviews, garantindo a qualidade do código do time e compartilhando conhecimento ajuda a equipe a compartilhar e sustentar ideias, criar críticas construtivas, testar hipóteses e sugerir melhorias.



> [!Note]

> **Real-Time Code Reviews Powered by AI**: O Slack tornou a colaboração em tempo real fluida para as equipes. A CodeRabbit traz esse mesmo espírito para as revisões de código (Code Reviews). Ele analisa cada PR usando IA consciente do contexto que entende sua base de código, sugerindo mudanças, detectando bugs e até fazendo perguntas quando algo está errado. Perfeito para equipes rápidas que querem revisões de código de qualidade sem desacelerar. Integrado ao GitHub, GitLab, é como um engenheiro sênior revisando com você em cada commit. Gratuito para código aberto.



A **CodeRabbit** é um revisor de código com IA que ajuda você ou sua equipe a mesclar suas alterações de código mais rápido com qualidade superior. O CodeRabbit não aponta apenas problemas; Ele sugere, corrige e explica o raciocínio por trás das sugestões. Eleve a qualidade do código com análises baseadas em IA, conscientes do contexto, e correções em um clique.

O CodeRabbit oferece:

• Resumos automáticos de PR e guias de troca de arquivos.

• Roda linters populares como Biome, Ruff, PHPStan, etc.

• Destaca questões de segurança de código e configuração.

• Permite que você escreva instruções personalizadas de revisão de código e regras grep do AST.

Até o momento, o CodeRabbit já analisou mais de 5 milhões de PRs, está instalado em um milhão de repositórios, tem 15k+ interações diárias com desenvolvedores e é usado por 1000+ organizações.

As **auditorias** são semelhantes às revisões, mas geralmente são realizadas por equipes independentes de pessoas com habilidades específicas para avaliar o software em relação a padrões e regulamentações específicos. As auditorias podem ser internas ou externas e podem ser realizadas em diferentes fases do ciclo de vida do software (BRITO, 2006).

Já as **inspeções** são atividades mais formais e estruturadas, que seguem um processo específico para avaliar o software em relação a determinados padrões e especificações. As inspeções geralmente envolvem uma equipe multidisciplinar e podem ser realizadas em diferentes fases do ciclo de vida do software.

Essas atividades de apoio da qualidade de software são importantes porque ajudam a identificar problemas no software antes que ele seja lançado, reduzindo assim os custos e os riscos associados a falhas no software. Além disso, elas também podem ajudar a melhorar a eficiência e a eficácia do processo de desenvolvimento de software (SHAMA, 2016).

Para aprofundar seu conhecimento sobre atividades de apoio da qualidade de software, você pode se perguntar: 

■ Quais são as diferenças entre as atividades de revisão, auditoria e inspeção? 

■ Como as atividades de apoio podem ser integradas ao processo de desenvolvimento de software? 

■ Qual é o papel dos diferentes membros da equipe na execução dessas atividades?

Além disso, uma ilustração útil pode ser um diagrama que mostre a relação entre as atividades de apoio da qualidade de software e outras atividades do ciclo de vida do software, como desenvolvimento, teste e implantação. Isso pode ajudar a entender como as atividades de apoio se encaixam no processo geral de desenvolvimento de software e como elas podem contribuir para a melhoria da qualidade do produto final.

 

  Tipos, técnicas e níveis de testes

  Ferramentas para testes (CI/CD Pipeline)

  Ferramentas para testes (CI/CD Pipeline)

 

 

  

  

  

 





É importante destacar que a **observabilidade** (observability) não é exatamente parte do QA no sentido tradicional, mas ela se conecta de forma muito natural com a qualidade do software. QA (Quality Assurance) historicamente é voltado para prevenção de defeitos, validação e verificação de requisitos, testes funcionais, não funcionais e processos que garantem que o produto atenda ao que foi especificado. 

Observabilidade, por outro lado, nasceu com foco na operação e na confiabilidade: é a capacidade de entender o que está acontecendo em um sistema, em tempo real, a partir de sinais como logs, métricas e traces. Ela vai além de simplesmente monitorar: é sobre ser capaz de responder perguntas desconhecidas sobre o comportamento do sistema.

A relação entre as duas áreas está no fato de que quanto mais observável um sistema é, mais fácil fica detectar, diagnosticar e corrigir problemas que impactam a qualidade. QA tradicional muitas vezes termina antes da aplicação ir para produção, mas bugs e falhas ainda podem aparecer em ambientes reais. 

Com observabilidade, você complementa os testes com uma visão contínua, onde é possível acompanhar a saúde, a performance, os gargalos e até o comportamento do usuário. Para equipes modernas, especialmente em DevOps e SRE, a linha entre QA e observabilidade se mistura um pouco, pois qualidade não é mais só “testar antes de subir”, mas também garantir que o produto em execução esteja saudável, rastreável e confiável.

Portanto, observabilidade pode ser vista como complementar ao QA, não substitui testes e processos de qualidade, mas amplia a segurança e o controle. Muitas equipes de alto desempenho hoje tratam a observabilidade como parte essencial da estratégia de qualidade, especialmente quando o sistema é distribuído, usa microsserviços, filas, integrações externas ou precisa de alta disponibilidade.

No cenário acelerado de software atual, as equipes de garantia de qualidade enfrentam uma pressão intensa para entregar lançamentos de alta qualidade de forma mais rápida e econômica (impactqa.com, bugraptors.com).

Como as empresas enviam código para produção? O diagrama abaixo ilustra o fluxo de trabalho típico.

   

      APIs and Web Applications

      App Mobile

   

   

      

      

   

Passo 1: O processo começa com um product owner criando user stories baseadas em requisitos.

Passo 2: A equipe de desenvolvimento pega as histórias de usuário do backlog e as coloca em um sprint por um ciclo de desenvolvimento de duas semanas.

Passo 3: Os desenvolvedores commetem o código-fonte no repositório de código Git.

Passo 4: Uma build é acionada em Jenkins. O código-fonte deve passar por testes unitários, limiar de cobertura de código e portas no SonarQube.

Passo 5: Uma vez que a build é bem-sucedida, ela é armazenada no artefactory. Depois, a build é implantada no ambiente de desenvolvimento.

Passo 6: Pode haver várias equipes de desenvolvimento trabalhando em diferentes recursos. Os recursos precisam ser testados de forma independente, então são implantados no QA1 e QA2.

Passo 7: A equipe de QA adota os novos ambientes de QA e realiza testes de QA, testes de regressão e testes de desempenho.

Etapas 8: Uma vez que as builds de QA passam pela verificação da equipe de QA, elas são implantadas no ambiente UAT.

Passo 9: Se o teste do UAT for bem-sucedido, as versões se tornam candidatas a lançamento e serão implantadas no ambiente de produção conforme o cronograma.

Passo 10: A equipe SRE (Site Reliability Engineering) é responsável pelo monitoramento de produção.



A **hiperautomação** (Hyperautomation) surgiu como uma resposta estratégica: em vez de simplesmente executar testes roteirizados, ela une ferramentas avançadas para automatizar inteiramente fluxos de trabalho de QA de forma inteligente (dev.toimpactqa.com).

Essa abordagem utiliza IA, aprendizado de máquina (ML), workflows, automação robótica de processos (RPA) e até plataformas low-code para construir processos de teste autônomos que abrangem tudo, desde requisitos até implantação (dev.togenqe.ai).

Em outras palavras, hiperautomação em QA significa criar um ecossistema autônomo de testes onde os sistemas não apenas executam testes, mas também decidem o que testar, como se adaptar quando o código muda e quando executar testes, tudo isso com intervenção humana mínima (dev.toimpactqa.com).

A hiperautomação representa uma mudança de paradigma para o QA: de testes roteirizados executados sob comando para um ecossistema de qualidade dinâmico e autorregulado (dev.to testingxperts.com). Ao combinar IA, ML, RPA e ferramentas modernas, as equipes podem alcançar testes mais rápidos, precisos e escaláveis. Os benefícios — lançamentos mais rápidos, melhor cobertura contra defeitos e menor risco — são claros, embora realizá-los exija superar obstáculos de integração e governança. A experiência na indústria mostra que a transição é gradual: comece com pilotos e frameworks de governança, desenvolva expertise e expanda iterativamente o escopo da automação.

À medida que o desenvolvimento acelera, o QA não pode permanecer manual ou estático. Adotar a hiperautomação faz dos testes um facilitador estratégico da transformação digital. Organizações que integram com sucesso a automação inteligente ao QA entregarão software de maior qualidade em alta velocidade e navegarão com confiança pela complexidade das aplicações modernas (testingxperts.com, testingxperts.com).

**Correção Automatizada de Bugs em Escala do Facebook**: Se tem uma coisa que a maioria dos desenvolvedores realmente odeia, é depuração (debugging).

![sfd](https://github.com/user-attachments/assets/22602b9e-8794-455f-b8af-bef839f3b5cb)

Embora depurar programas pequenos não seja divertido, pode ficar extremamente irritante quando você precisa depurar milhões de linhas de código numa sexta-feira à noite para encontrar aquele bug tão difícil de encontrar.

Para piorar, bugs (de software ou não) são persistentes.

Você se livra de um e mais dois aparecem. Quando você acha que finalmente resolveu o problema e começou a testar, percebe que o patch que você acabou de fazer está causando outro travamento em outro lugar dentro dessas milhões de linhas.

Antes que perceba, você já está caminhando por mais uma caçada ao inseto.

É aí que o SapFix se projeta como uma ferramenta revolucionária no campo da correção automática de bugs.

É uma nova ferramenta híbrida de IA criada pelo Facebook com o objetivo de reduzir o tempo que os engenheiros gastam com depuração.

O SapFix facilita a depuração ao gerar automaticamente correções para problemas específicos e propor essas correções aos engenheiros para aprovação e implantação em produção.

O diagrama abaixo mostra o fluxo de trabalho do SapFix em um nível geral. Em uma seção posterior, veremos todo o processo com ainda mais detalhes.



Dizer que a SapFix mostrou potencial seria pouco. Aqui estão alguns fatos que valem a pena considerar:

O SapFix tem sido usado para sugerir correções para seis aplicativos-chave do Android na família de aplicativos do Facebook.

Os aplicativos são Facebook, Messenger, Instagram, FBLite, Workplace e Workchat.

Juntos, esses aplicativos consistem em dezenas de milhões de linhas de código e são usados diariamente por centenas de milhões de usuários ao redor do mundo.

Se você pensar bem, são 6 bases de código de vários milhões de linhas e ainda estamos nos primeiros dias de desenvolvimento do SapFix!

Neste ponto, você pode se perguntar como a SapFix consegue gerar correções para tantos aplicativos diversos com usos tão variados, que vão desde comunicação até redes sociais e construção de comunidades.

O Papel de Sapienz e Infer

O segredo do SapFix é a adoção de técnicas automatizadas de reparo de programas.

Essas técnicas são baseadas em algoritmos para identificar, analisar e corrigir bugs de software conhecidos sem intervenção humana. Uma das abordagens mais utilizadas depende de testes de software para direcionar o processo de reparo.

É aí que o Facebook utiliza seu sistema automatizado de design de casos de teste, conhecido como Sapienz.

A Sapienz utiliza Engenharia de Software baseada em Busca (SBSE) para projetar automaticamente casos de teste em nível de sistema para aplicativos móveis. Executar esses casos permite que a Sapienz encontre centenas de falhas por mês mesmo antes que possam ser descobertas pelos testadores humanos internos do Facebook.

Pense no SBSE como se tivesse um assistente super inteligente que analisa todas as linhas de código e tenta diferentes combinações para resolver um problema. É muito parecido com quando você tenta diferentes peças de um quebra-cabeça até que elas se encaixem perfeitamente.

Como estimativa, os engenheiros do Facebook conseguiram corrigir 75% das falhas relatadas pela Sapienz. Isso indica uma relação sinal-ruído muito alta para os relatórios de bugs gerados pelo Sapienz.

No entanto, para melhorar ainda mais esse número, o Facebook também usa o Infer.

Infer é uma ferramenta de código aberto que auxilia na localização e análise estática das correções propostas. Assim como o Sapienz, o Infer também é implantado diretamente no sistema interno de integração contínua do Facebook e tem acesso à maior parte da base de código do Facebook.

Sapienz e Infer colaboram entre si para fornecer informações aos desenvolvedores sobre possíveis bugs como:

Localização da provável causa raiz

O cenário de teste de falha que ajudou a identificar o bug



No entanto, Sapienz e Infer só podem fornecer informações e não economizam tempo para o desenvolvedor realmente corrigir o problema. Claro, a colaboração deles ajuda a identificar bugs e a localização deles no código, mas a maior parte do trabalho envolvido para corrigir esses bugs ainda cabe ao desenvolvedor.

É aí que o SapFix entra e combina três componentes importantes para fornecer um sistema automatizado de reparo de ponta a ponta:

Técnica baseada em mutação apoiada por padrões gerados a partir de correções humanas anteriores

O projeto automatizado de testes do Sapienz

Infraestrutura de análise estática e localização da Infer

Desde a escolha dos casos de teste que detectam o crash até a correção do problema e reteste, o SapFix cuida de todo o processo como parte do sistema contínuo de integração e implantação do Facebook.

O Fluxo de Trabalho SapFix

Como o SapFix realmente funciona?

Existem quatro tipos de correções realizadas pela SapFix:

Correção do Modelo

Correção de Mutação

Diff Revert

Revert Parcial de Diferença

Abaixo está um diagrama que mostra todo o fluxo de trabalho de como o SapFix lida com o processo de correção de um problema com base nesses tipos.