Quality Assurance e entrega contínua
Neste vídeo você vai conhecer como QA e entrega contínua (continuous delivery) se encaixam. Se você quiser conhecer mais de DevOps, pode começar pela formação [Primeiros passos em DevOps]( Se você estiver estudando QA, não deixe de conferir a nossa formação [Carreira QA: processos e automação de testes]( # Transcrição *Quality assurance* (em português, garantia de qualidade) ou QA e entrega contínua. Vamos ver o que esses dois têm a ver? Olá, sou o Vinicius Dias e sejam bem-vindos à Alura. Quero bater um papo bem rápido com vocês sobre como podemos aumentar a qualidade dos nossos *deploys*, digamos assim. Quero mostrar qual a relação entre QA e entrega contínua. O que esses dois têm a ver, qual a relação entre eles e como um depende do outro. Vamos entender primeiro o que é QA. Para quem me conhece, sabe que gosto de pegar uma definição formal da internet para depois esmiuçar. Quando pesquisamos "o que é *quality assurance*?" no Google, a resposta é exatamente a seguinte: ### O que é Quality Assurance? * "Garantia da qualidade é uma forma de prevenir erros ou falhas nos produtos manufaturados e evitar problemas ao entregar soluções ou serviços aos clientes." Quando trazemos isso para o mundo de software, significa que *quality assurance*, que chamaremos pela sigla QA, é uma forma de garantirmos que o código, sistema ou produto que estamos construindo está com uma qualidade aceitável. Para isso, existem diversas técnicas, processos e práticas para assegurar que a qualidade esteja satisfatória. Quando me refiro à qualidade aceitável, isso é um ponto muito importante, porque é muito difícil dizer se um código ou produto está bom, ou ruim. Por essa razão é fundamental definirmos critérios objetivos para impedir que um código vá para frente ou que um *deploy* aconteça, por exemplo. Precisamos ter o mínimo para certificar a qualidade do que está sendo feito, isso é um processo que aprendemos quando estudamos QA. O QA pode ser o papel de uma pessoa, de uma equipe inteira ou compartilhado entre diversas pessoas de uma equipe. Logo, QA não é uma caixa fechada, digamos assim. Existem vários profissionais dessa área que trabalham em setores distintos, como automação de testes, com testes manuais e os que trabalham mais do lado do negócio ou da equipe técnica. Como já mencionado, QA não é uma caixa fechada, existem várias práticas e técnicas que podemos utilizar para garantir a qualidade de um produto. ### Quality Assurance vs Quality Control *Quality assurance* é uma forma de garantirmos a qualidade **enquanto o produto está sendo desenvolvido**. Para quem já chamou alguma vez TDD de teste depois do *deploy*, sabe ao que estou me referindo quando falo que é comum criarmos um software, escrever um código ou gerar um produto e, no final do processo, enviar para alguém testar. Isso acontece bastante, inclusive, em alguns casos existe um profissional com essa função. Para que, após o desenvolvimento do produto ou serviço, esse profissional garanta que o que foi desenvolvido corresponde com a expectativa do produto. Essa técnica não se refere a QA, chamamos ***quality control***, o controle de qualidade. **Após o desenvolvimento, é garantido que o produto foi produzido corretamente**. Já o *quality assurance* faz parte do processo, enquanto é realizado o desenvolvimento, existem práticas a serem aplicadas para garantir que está sendo desenvolvido da melhor forma. Repare que QA envolve toda a parte do processo de desenvolvimento e, de fato, faz parte do processo. Não é apenas um momento pontual que adicionamos, como o teste depois do *deploy* ou quando perguntamos para a pessoa se ela já finalizou a tarefa e ela responde: "Está pronto, só falta testar". Esse "só falta testar" é o *quality control*, o *quality assurance* vai muito além disso. Essa prática de ter uma garantia de qualidade como um processo no nosso software permite diversas coisas. Tem um ponto interessante nos "Princípios por trás do manifesto ágil", o primeiro. Em que a prioridade é satisfazer o cliente e, com isso, realizar entregas o mais cedo possível através de **entregas contínuas** um software de valor. ### Principais princípios por trás do manifesto ágil * “Nossa maior prioridade é **satisfazer o cliente**, através da *entrega adiantada e contínua* de software de valor.” Essa frase nos diz que precisamos garantir que as entregas sejam contínuas, sendo o nome de um **conjunto de práticas** também. Logo, **entrega contínua** é o conceito que você possui um processo muito bem definido com QA, também bem definido, em que a entrega do software é feita de forma contínua. Por exemplo, se temos o planejamento de uma *feature* que passa pelo desenvolvimento, em que é realizado os testes necessários, gerando um *build* que passa pelo *quality control* que pode ir para outro ambiente para a verificação, e em seguida é feito o *deploy*. Isso gera uma entrega. Todo esse processo sendo feito de forma contínua e automatizada é o princípio por trás de entrega contínua. Repare que sem o *quality assurance* a entrega contínua se torna algo utópico. Poderíamos até cogitar a possibilidade de ter algo assim, mas se não existem processos para garantir a qualidade do que está sendo feito, como teríamos confiança para realizar uma entrega de software de maneira contínua, de forma, inclusive, automatizada? Logo, precisamos de QA para atingir entregas contínuas. A entrega contínua tem como núcleo a **build pipeline**. Basicamente é uma esteira de geração, podemos chamar assim. No *build pipeline* temos algumas etapas e dentro de cada uma dessas etapas existem processos de QA. 
