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. ![Esquema visual sequencial contendo as seguintes etapas: "Plan", "Develop", "Build", "Test", "Deploy" e "Operate"]( No momento do **planejamento**, há processos de QA para garantir que está sendo feito da forma correta, com a descrição do que precisamos da forma correta também. Na etapa de **desenvolvimento** temos as boas práticas de programação, criação de testes, entre outros processos. Na hora de fazer o ***build***, é como garantimos que estamos utilizando tudo do ambiente correto e como automatizamos essa mudança de ambientes. Realizar aquele **teste**, o *quality control*. Fazer o **deploy**, que pode ser feito de maneira contínua ou não. Talvez essa etapa seja manual por uma necessidade de negócio. Por exemplo, queremos agrupar diversas *features* que passaram por essa entrega contínua, logo a *feature* foi entregue, mas queremos agrupar para gerar uma versão, então o *deploy* vai ser manual. Contudo, se tivermos um *deploy* que é um **evento**, por exemplo, não podemos realizar às sextas-feiras ou perto de terminar o expediente, visto que precisa ter um desenvolvedor à disposição caso aconteça um erro. Isso significa que provavelmente está faltando a parte de *quality assurance*, o processo da garantia de qualidade no desenvolvimento do software. Quando temos um *build pipeline* utilizando integração contínua para chegar na entrega contínua, o que atingimos é o **feedback contínuo**. Isso até poderia virar um vídeo à parte, mas basicamente quando aplicamos essas práticas estamos garantindo que em cada etapa do processo temos um feedback, que estamos indo pelo caminho correto. Caso aconteça um erro, vamos errar pequeno e mais rápido. É justamente o princípio do manifesto ágil. Então, *quality assurance* leva à possibilidade de termos entregas contínuas. Esta está diretamente relacionada aos processos ágeis, sendo um assunto bem interessante. Inclusive, fica o convite que na plataforma da Alura existem treinamentos tanto de *quality assurance* quanto de entrega contínua, com vários elementos satélites, como integração contínua, testes e muito mais. Esses são os conceitos de *quality assurance* e entrega contínua.