Ecossistema de Testes DevOps

Prévia do material em texto

<p>Conteudista: Prof.ª Dra. Marise de Barros Miranda</p><p>Revisão Textual: Prof.ª Dra. Selma Aparecida Cesarin</p><p>Objetivos da Unidade:</p><p>Conhecer o ecossistema de Testes na cultura DevOps e os tipos mais populares;</p><p>Descrever junto a implementação dos requisitos como os Testes devem ser verificados e</p><p>validados;</p><p>Validar a efetividade da automação de Testes de Software por meio de métricas.</p><p>📄 Contextualização</p><p>📄 Material Teórico</p><p>📄 Material Complementar</p><p>📄 Referências</p><p>Ciclo Criar, Medir e Aprender no Contexto de Testes</p><p>Automatizados de Software</p><p>Muitos utilitários e acessórios de computador precisam de um Pacote de Software para realizar as tarefas</p><p>solicitadas pelos usuários. Por exemplo, dispositivos IoT como relógios inteligentes que podem monitorar</p><p>nosso desempenho esportivo geralmente vêm com um APP designado, um aplicativo desenvolvido em</p><p>software.</p><p>No entanto, mesmo os APPs agrupados podem ser afetados por problemas de interoperabilidade, que</p><p>corresponde ao mau funcionamento em alguns hardwares. É por isso que existe a necessidade de testar o</p><p>software, junto com o hardware incluído.</p><p>Como existem inúmeros tipos de fabricantes de computadores, celulares, Sistemas IoT, então, a melhor</p><p>solução é testar de acordo com os recursos de produtos, e assim criar um Teste automatizado que possa</p><p>cobrir uma gama de plataformas, garantindo alta taxa de interoperabilidade.</p><p>Para validar um App, é preciso testá-lo antes. Os Testes iniciais do App são importantes se realizados juntos</p><p>a Equipe de Desenvolvimento, verificando se esses Testes alcançam o resultado desejado.</p><p>Os testes realizados em soutares, de modo geral, ajudam os desenvolvedores a melhorar o produto.</p><p>Já os testes de serviços, colocam ênfase no desempenho da experiência do usuário e na interface dele.</p><p>Os usuários esperam que seus Apps funcionem de maneira fácil e agradável. Mas, na realidade, muitos</p><p>problemas inesperados podem ocorrer, como deslocamento de imagem, carrinhos de compras com defeito,</p><p>impossibilidade de fazer login na conta... e esses problemas sem dúvida sabotarão a experiência interativa.</p><p>1 / 4</p><p>📄 Contextualização</p><p>Para construir uma experiência de usuário excepcional, é necessário começar com inspeções abrangentes</p><p>no software, das quais destacam-se: interoperabilidade, funcionalidade, confiabilidade e usabilidade, que</p><p>são os blocos de construção básicos do software.</p><p>Em primeiro lugar, as Equipes de Testes devem verificar se os requisitos principais estão bem concebidos e</p><p>funcionais. Em seguida, a experiência do usuário com o produto é testada pela interação com sua interface</p><p>de usuário.</p><p>Nesse cenário, cuidadoso e bem definido por meio de requisitos, a Automação de Testes cria possíveis</p><p>economias de tempo e aprimoramento contínuo do produto desenvolvido pela Equipe de Software.</p><p>Ecossistema de Testes Devops</p><p>DevOps é uma Metodologia popular para o Desenvolvimento de Sistemas de Software no contexto</p><p>empresarial.</p><p>Essa Metodologia Ágil enfatiza a comunicação, a colaboração e a integração entre desenvolvedores de</p><p>Software e colaboradores envolvidos em operações como Administração de TI (Figura 1).</p><p>Figura 1 – Metodologia DevOps</p><p>Fonte: Adaptada de Getty Images</p><p>2 / 4</p><p>📄 Material Teórico</p><p>No mundo da Tecnologia, Devops é a junção das palavras desenvolvimento e operações, relativas à</p><p>integração das Equipes que participam de Projetos de Software.</p><p>A fase entre Dev e Ops fazem parte de um processo e juntas formam um pipeline de DevOps. O pipeline e</p><p>suas fases são ferramentas fundamentais para trabalhar no contexto de DevOps.</p><p>Estão divididas em 8 fases básicas que se integram, interagem e se comunicam continuamente.</p><p>Planejamento (Plan)</p><p>O Estágio de Planejamento cobre tudo o que acontece antes dos desenvolvedores começarem a escrever o</p><p>Código. Aqui, o Gerente de Produto ou o Gerente de Projeto atuam.</p><p>Requisitos e feedback são coletados das partes interessadas e dos clientes. Esses requisitos são usados</p><p>para construir um roteiro do produto para orientar o desenvolvimento futuro.</p><p>O roteiro do produto pode ser registrado e rastreado usando um Sistema de Gerenciamento de Tarefas, como</p><p>Jira (Figura 2), Azure DevOps ou Trello, que fornecem uma variedade de ferramentas para rastrear o</p><p>progresso, os problemas e os marcos do projeto.</p><p>Figura 2 – Jira: Ferramenta de gerenciamento de Projetos e de Atividades de</p><p>Equipes de Desenvolvimento de Software</p><p>Fonte: Reprodução</p><p>O roadmap do produto pode ser dividido em descrições, recursos e histórias de usuários, criando um acúmulo</p><p>de tarefas que levam diretamente aos requisitos dos clientes.</p><p>As tarefas no backlog podem ser usadas para planejar sprints e alocar tarefas para a Equipe começar o</p><p>desenvolvimento.</p><p>Glossário</p><p>Backlog: é um acúmulo de logs de trabalho num determinado intervalo de tempo. Pode ser considerado</p><p>um estoque de tarefas, requisições/encomendas relativas a produtos ainda não produzidos;</p><p>Código (Code)</p><p>A Equipe deve possuir um padrão de ferramentas de desenvolvimento. Isso ajuda no Processo de</p><p>Desenvolvimento e ajuda a impor um estilo de Código consistente e evita falhas de segurança comuns e</p><p>antipadrões de Código.</p><p>Isso ajuda a ensinar aos Desenvolvedores de Boas Práticas de Codificação enquanto auxilia na</p><p>colaboração, fornecendo alguma consistência à Base de Código.</p><p>Essas ferramentas também ajudam a resolver problemas que podem falhar nos Testes posteriores do</p><p>pipeline, resultando em menos compilações com falhas, permitindo solucioná-las rapidamente.</p><p>Construir (Build)</p><p>A fase de construção é onde o DevOps realmente entra em ação. Depois que um desenvolvedor conclui uma</p><p>tarefa (task), ele confirma seu Código em um repositório de Código compartilhado, por exemplo, um Github</p><p>(Figura 3) ou Gitlab.</p><p>Há muitas maneiras de fazer isso, mas, normalmente, o desenvolvedor envia uma solicitação pull – uma</p><p>solicitação para mesclar seu novo Código com a base de Código compartilhada.</p><p>Em seguida, outro desenvolvedor analisa as alterações feitas e, quando fica satisfeito por não haver</p><p>problemas, aprova a solicitação de pull. Essa revisão manual deve ser rápida e leve, mas é eficaz na</p><p>identificação de problemas antecipadamente.</p><p>Sprint: é uma reunião de pessoas envolvidas em um Projeto para promover um desenvolvimento mais</p><p>focado nele. O termo está relacionado à Cultura Ágil de Desenvolvimento de Software.  Sua duração pode</p><p>ser diária, semanal ou quinzenal.</p><p>É uma recomendação que pequenas alterações sejam requisitadas para pull request. Assim, são mais</p><p>rápidas de serem revisadas e aprovadas.</p><p>Simultaneamente, a solicitação pull aciona um processo automatizado que cria a Base de Código e executa</p><p>uma série de Testes de Integração e Unidade Ponta a Ponta (end to end), para identificar quaisquer</p><p>regressões.</p><p>Se a compilação falhar ou qualquer um dos Testes falhar, a solicitação de Pull falhará e o desenvolvedor</p><p>será notificado para resolver o problema.</p><p>Verificando continuamente as alterações de Código em um repositório compartilhado e executando</p><p>compilações e Testes, os problemas de integração que surgem ao trabalhar em uma Base de Código</p><p>compartilhada são minimizados e os bugs surgem imediatamente no início do ciclo de vida de</p><p>desenvolvimento.</p><p>Teste</p><p>Depois de um build bem-sucedido, ele é implantado automaticamente em um ambiente de Teste para ser</p><p>testado mais profundamente. O ambiente de Teste pode ser um serviço de hospedagem existente ou pode</p><p>ser um novo ambiente provisionado como parte do Processo de Implantação.</p><p>Essa prática de provisionar automaticamente um novo ambiente no momento da implantação é conhecida</p><p>como Infrastructure-as-Code (IaC) e é uma parte essencial de muitos pipelines DevOps.</p><p>Depois que o aplicativo é implantado no ambiente de Teste, uma série de Testes Manuais e Automatizados</p><p>são executados.</p><p>O Teste Manual pode ser o Teste de Aceitação do Usuário (UAT) tradicional, em que as pessoas usam o</p><p>aplicativo como o cliente faria para destacar quaisquer problemas ou refinamentos que devem ser</p><p>resolvidos antes da implantação na produção.</p><p>Ao mesmo tempo, os Testes Automatizados podem executar varredura de segurança no aplicativo, verificar se</p><p>há mudanças na infraestrutura e conformidade com as melhores práticas de proteção, testar o desempenho</p><p>do aplicativo ou executar Testes de Carga.</p><p>O Teste que é executado durante essa fase depende da organização e do que deve ser relevante no</p><p>aplicativo, mas esse estágio pode ser considerado um test-bed que permite conectar novos Testes sem</p><p>interromper o fluxo de desenvolvedores ou impactar o ambiente de produção.</p><p>Lançamento (Release)</p><p>A fase de lançamento é um marco no pipeline de DevOps. É quando o build está pronto para a implantação</p><p>no ambiente de produção. Nesse estágio, cada alteração de Código passou por uma série de Testes</p><p>Manuais e Automatizados, e a Equipe de Operações pode ter certeza de que problemas de interrupção e</p><p>regressões são improváveis.</p><p>Dependendo da maturidade DevOps de uma Organização, eles podem optar por implantar automaticamente</p><p>qualquer build que chegue a esse estágio do pipeline.</p><p>Saiba Mais</p><p>Testbed ou test bed (Teste de mesa). É um método que conduz com rigor, transparência e</p><p>replicabilidade Testes de Software, computacionais ou de Novas Tecnologias, para dominar</p><p>ou estressar o funcionamento em condições normais ou críticas.</p><p>Os desenvolvedores podem usar sinalizadores para desativar novos recursos para que não possam ser</p><p>vistos pelos clientes até que estejam prontos para a ação.</p><p>Como alternativa, uma Organização pode querer ter controle sobre quando as compilações são liberadas</p><p>para produção. Eles podem querer ter um cronograma de lançamento regular ou lançar novos recursos</p><p>apenas quando um marco for atingido.</p><p>Pode ser acionado um processo de aprovação manual no estágio de lançamento que permite apenas que</p><p>certas pessoas dentro de uma Organização autorizem um lançamento para produção.</p><p>Implantar (Deploy)</p><p>Finalmente, nesta etapa um build de Código está pronto para ser lançado em produção. Existem várias</p><p>ferramentas e processos que podem automatizar o processo de deploy para torná-lo confiável, sem</p><p>interrupção.</p><p>A mesma infraestrutura como Código que construiu o ambiente de Teste pode ser configurada para construir o</p><p>Ambiente de Produção. Sabendo-se que o ambiente de Teste foi construído com sucesso, então, a versão</p><p>de produção ocorrerá sem problemas.</p><p>Uma implantação permite mudar a aplicação para o novo ambiente de produção sem interrupções. Em</p><p>seguida, o novo ambiente é construído e fica funcionando paralelamente ao ambiente de produção</p><p>existente.</p><p>Quando o novo ambiente está pronto, o Serviço de Hospedagem aponta todas as novas solicitações para o</p><p>novo ambiente. Se, em qualquer ponto, for encontrado um problema com a nova compilação, pode-se</p><p>simplesmente executar no serviço de hospedagem para apontar as solicitações de volta ao ambiente antigo</p><p>enquanto a Equipe Devops encontra uma correção.</p><p>Operar (Operation)</p><p>O novo lançamento está no ar e sendo usado pelos clientes. A Equipe de Operações tem de garantir que</p><p>tudo esteja funcionando perfeitamente. Com base na configuração do serviço de hospedagem, o ambiente é</p><p>dimensionado automaticamente com a carga para lidar com picos e quedas no número de usuários ativos.</p><p>A Equipe Devops também cria uma maneira de os clientes fornecerem feedback sobre o serviço, bem como</p><p>ferramentas que ajudam a coletar e fazer a triagem desse feedback para ajudar a moldar o desenvolvimento</p><p>futuro do produto.</p><p>Monitoramento (Monitor)</p><p>A fase 'final' do Ciclo Devops é monitorar o ambiente. Isso se baseia no feedback do cliente fornecido na</p><p>fase de operação, coletando dados e fornecendo análises sobre o comportamento do cliente, desempenho</p><p>e erros.</p><p>O monitoramento também deve ser feito no próprio pipeline de DevOps, monitorando possíveis gargalos no</p><p>pipeline que estão causando frustração ou impactando a produtividade das Equipes de Desenvolvimento e</p><p>Operações.</p><p>Continuous em DevOps</p><p>Todas as informações das fases do Ambiente DevOps são enviadas ao Gerente de Produto e à Equipe de</p><p>Desenvolvimento para fechar o ciclo do Processo.</p><p>O loop começa novamente, mas a realidade é que esse processo é contínuo.</p><p>Não há começo nem fim, apenas a evolução contínua de um produto ao longo de sua vida, que só termina</p><p>quando as pessoas se mudam ou não precisam mais dele (Figura 3).</p><p>Figura 3 – CI, C2D e CF no DevOps</p><p>Embora seja útil dividir o pipeline de DevOps em fases, apenas para facilitar a descrição e cada uma delas,</p><p>na prática, é um fluxo de trabalho contínuo seguido pela mesma Equipe ou combinação de Equipes,</p><p>dependendo da estrutura organizacional. Não existem barreiras rígidas entre cada uma das fases do</p><p>pipeline. Mas esse fluxo deve ser seguido considerando os pilares de 4 estruturas fundamentais existentes</p><p>no ecossistema de Devops.</p><p>Integração Contínua (Continuous Integration)</p><p>Uma das maiores dificuldades na coordenação de uma Equipe de Desenvolvimento de Software é o</p><p>gerenciamento da colaboração entre os desenvolvedores.</p><p>Um repositório de Código compartilhado pode resolver esse problema, porém, ainda pode haver problemas</p><p>ao mesclar as alterações feitas por várias pessoas no mesmo trecho de Código.</p><p>Uma mudança feita por um desenvolvedor pode impactar no que outro desenvolvedor está trabalhando e</p><p>esperar as mudanças pode gerar um desvio de tempo inadequado ao conceito ágil.</p><p>A integração contínua visa a alinhar esse processo, nas fases de Código e de construção do pipeline de</p><p>DevOps.</p><p>É a prática de mesclar regularmente o código de um desenvolvedor na base de Código centralizada e</p><p>conduzir Testes Automatizados para garantir que um requisito não especificado tenha sido introduzido.</p><p>Ao mesclar alterações menores com mais regularidade, esses problemas se tornam menores e mais fáceis</p><p>de gerenciar, melhorando a produtividade e a sanidade gerais.</p><p>Entrega Contínua (Continuous Delivery)</p><p>A entrega contínua é uma extensão da integração contínua que automatiza o processo de implantação de</p><p>um novo build na produção.</p><p>Os objetivos da Entrega Contínua são:</p><p>A entrega contínua se alinha às fases de Teste e lançamento do pipeline e permite que as Organizações</p><p>acionem manualmente o lançamento de novos builds com a regularidade que desejarem.</p><p>Realizar Testes Automatizados em cada novo modulo do sistema para verificar as construções</p><p>que estão prontas para serem lançadas em produção e falhar aquelas que não estão;</p><p>Gerenciar o provisionamento e a configuração automáticas de ambientes de implantação, bem</p><p>como o Teste desses ambientes quanto à estabilidade, desempenho e conformidade de</p><p>segurança;</p><p>Implantar uma nova versão na produção quando aprovada e acionada manualmente pela Equipe.</p><p>Implantação Contínua (Continuous Deployment)</p><p>A Implantação Contínua (Continuous Deployment) é uma versão mais aprimorada da Entrega Contínua. Os</p><p>objetivos são os mesmos, mas a etapa manual de aprovação de novos lançamentos para produção não é</p><p>considerada.</p><p>Em um modelo de implantação contínua, cada construção que passa em todas as verificações e balanços</p><p>do pipeline é implantada automaticamente na produção.</p><p>Feedback Contínuo (Continuous Feedback)</p><p>O objetivo do DevOps é lançar novos recursos e correções com maior brevidade para que a Equipe possa</p><p>obter feedback dos clientes, partes interessadas e análises para tomar melhores decisões ao projetar o</p><p>próximo conjunto de mudanças. O objetivo é atingir um forte ciclo de feedback contínuo para desenvolver</p><p>um produto melhor.</p><p>É o feedback contínuo que une as extremidades do loop, realimentando os dados e análises das fases de</p><p>operação e monitoramento de volta para a fase de planejamento para fazer tudo de novo.</p><p>Analisando as fases, o pipeline do DevOps é um ecossistema de ferramentas que auxiliam na sua</p><p>condução do Projeto (Figura 4).</p><p>Figura 4 – Ecossistema do DevOps</p><p>Fonte: Reprodução</p><p>A maioria das soluções para DevOps atuais são heterogêneas, permitindo sua adoção diante das</p><p>habilidades das Equipes,</p><p>mas mantendo o foco nos Testes do Ecossistema, as Ferramentas de Automação</p><p>de Testes colaboram com a Equipe, facilitando sua incorporação nas fases de Desenvolvimento.</p><p>A automação nas tarefas de Desenvolvimento, Teste e Implantação está no coração do DevOps.</p><p>Organizações que empregam DevOps implantam software com mais frequência do que outras empresas,</p><p>embora tenham prazos de entrega bastante reduzidos.</p><p>As Organizações que empregam DevOps fazem uso de um rico conjunto de ferramentas que automatizam</p><p>as atividades DevOps em todo o ciclo de vida dos Processos DevOps, incluindo: planejamento, codificação,</p><p>builds, testes, implantação, operações, bem como monitoramento e controle.</p><p>Essas ferramentas permitem que as organizações implementem práticas de gerenciamento enxuto e</p><p>entrega contínua em todo o ciclo de vida do DevOps.</p><p>Como resultado, é importante que os desenvolvedores DevOps entendam, aprendam e aproveitem o</p><p>ecossistema de ferramentas DevOps.</p><p>Teste em DevOps</p><p>O Teste não era parte da Metodologia DevOps. O processo inicial incluía apenas o desenvolvimento e as</p><p>operações e, nesse caso, as Equipes poderiam integrar os Testes da maneira que dominavam, manuais e ou</p><p>automatizados.</p><p>Com a introdução do conceito DevTestOps, o Teste contínuo é formalmente mesclado ao DevOps – testar</p><p>cedo, testar frequentemente, testar em qualquer lugar e testar sempre, até a conclusão da entrega do</p><p>produto final, tornou-se uma regra.</p><p>O Teste começa desde o início do desenvolvimento até a implantação, e após a entrega final.</p><p>Todos os tipos de Testes de Verificação e de Validação são realizados durante a fase de desenvolvimento</p><p>para garantir que o produto entregue funcione bem em todos os aspectos e requisitos.</p><p>DevTestOps Manifesto</p><p>Um manifesto é uma declaração pública de princípios e intenções do DevTestOps, dividido em cinco</p><p>diretrizes principais, listadas a seguir.</p><p>Manifesto 1: testes Contínuos prevalecem sobre Teste no final;</p><p>Manifesto 2: envolver todas as atividades de Teste, em vez de apenas Testes Funcionais</p><p>Automatizados;</p><p>Manifesto 3: testar o que é importante e impactante primeiro. ao invés de começar a testar tudo;</p><p>Manifesto 4: testes devem acontecer junto à Equipe de desenvolvimento e não só no</p><p>Departamento de Testes, de forma isolada;</p><p>Para dar a importância merecida a esse manifesto, o conceito de DevTestOps mescla DevOps e Testes</p><p>Contínuos, e o objetivo principal é melhorar a qualidade e a confiabilidade das compilações lançadas.</p><p>Isso foi alcançado adicionando testes em partes centrais do fluxo de trabalho (Figura 5).</p><p>Figura 5 – Testes dentro da Metodologia DevOps</p><p>Fonte: Adaptada de Getty Images</p><p>DevOps é a evolução do Modelo Agile, que emitiu ondas de choque em todos os ambientes de</p><p>Desenvolvimento e Testes, bem como alterou significativamente a frequência de lançamento de aplicativos.</p><p>DevTestOps demonstra que em cada ponto do ciclo, cada avanço para o próximo estágio, deve ser</p><p>precedido por um Teste.</p><p>Manifesto 5: testes devem priorizar a cobertura de produto sobre a cobertura de Código.</p><p>Sem os avanços recentes na automação de Testes, nenhum dos cenários de Teste contínuo poderia existir.</p><p>Benefícios dos Testes Contínuos em</p><p>DevTestOps</p><p>Esses benefícios incluem:</p><p>Esses Testes Automatizados realmente cobrem a gama dos Testes de Funcionalidade, Testes de</p><p>Desempenho, Testes de Resiliência e Testes de Segurança, dentre outros.</p><p>Debono (2017) recomenda que os Testes devem ser criados de acordo com a pirâmide de Teste, na qual os</p><p>níveis cada vez mais altos de Testes são criados sobre uma base sólida de loops de Teste já estáveis,</p><p>compostos, principalmente, de Testes Unitários na base, Testes de Serviço e Testes de IU (interface user)</p><p>na parte superior (Figura 6).</p><p>Melhor a qualidade de código;</p><p>O estado exato do Sistema em termos de bugs é conhecido após cada verificação;</p><p>Junto com o tempo de disponibilização do produto no Mercado, o feedback contínuo aumenta</p><p>a confiabilidade das compilações;</p><p>As Equipes de Desenvolvimento, Teste e Operações trabalham juntas e as lacunas de</p><p>comunicação são minimizadas;</p><p>A automação de Teste ajuda a manter a consistência na qualidade do build, build após build, e</p><p>liberação após liberação;</p><p>Reduz os riscos de negócios, pois, agora, os requisitos de negócios são automatizados e</p><p>testados de forma consistente.</p><p>Figura 6 – Pirâmide de Testes</p><p>Fonte: Adaptada de DEBONO, 2017</p><p>A pirâmide de Testes de Vocke ilustra o seguinte princípio de Teste de DevOps: a parte inferior da pirâmide</p><p>requer Testes mais rápidos e isolados e o topo representa Testes mais lentos e integrados.</p><p>Essa visão estimula a usar muitos Testes unitários de forma mais rápida, diminuindo o esforço em Testes</p><p>mais completos e complexos que testam o produto de ponta a ponta, como Testes de UI.</p><p>Para ajudar nesse percurso, o portifólio de Testes automatizados do mundo DevOps requer um conjunto de</p><p>ferramentas, homologadas, que juntas formam uma rede de segurança nos Testes, que buscam alcançar</p><p>100% de eficiência.</p><p>Os desafios dos Testes em DevOps são os seguintes:</p><p>Testes em Plataformas altamente fragmentadas, incluindo várias versões do Sistema</p><p>Operacional em uma ampla gama de dispositivos e hardware, como celulares, computadores</p><p>e Tecnologias de Internet das Coisas;</p><p>Diferença da App Store: aplicativos passam por avaliações constantes dos usuários e precisam</p><p>de correções constantes;</p><p>Tipos de Testes: Teste Unitário, Teste Contínuo, Teste Funcional e</p><p>outros Testes</p><p>Quando o tema são Testes Automatizados e utilizados em conjunto de Testes, corrigem falhas detectadas</p><p>com antecedência, ainda no ciclo de desenvolvimento.</p><p>Com isso, menos problemas chegam ao cliente, diminuindo o orçamento final na criação de novos produtos,</p><p>pois um Código construído em meio a Testes automatizados, durante o ciclo de criação, tende a ser mais</p><p>eficiente e robusto.</p><p>Como consequência, há menor gasto com manutenção (Figura 7).</p><p>Figura 7 – Detalhamento da Pirâmide de Testes</p><p>Fonte: Adaptada de DEBONO, 2017</p><p>Cada usuário pode não seguir o fluxo normal do aplicativo, pode se recusar a baixar e instalar a</p><p>atualização mais recente, e o aplicativo terá comportamento não desejado pelo usuário,</p><p>possibilitando a total inutilização da versão defasada.</p><p>A especificidade dos Testes Automatizados contempla os Testes Unitários e os Testes de Integração. O</p><p>primeiro é a base da pirâmide de Vocke e o segundo está no meio dela.</p><p>Testes Unitários</p><p>Testam a unidade que valida o comportamento de pequenos elementos em um Sistema que, em</p><p>Programação Orientada a Objetos, pode ser um Método, fortemente acoplado ao Código e sem chamadas</p><p>externas. Métodos são funções que descrevem ações.</p><p>Esses Testes consideram, também, o nível de acoplamento das dependências do Código de Programação,</p><p>como chamadas a outros métodos.</p><p>Caso os acoplamentos tenham chamadas externas, como acesso ao Banco de Dados, o Teste Unitário não</p><p>fará mais sentido, sendo necessário partir para Testes de Integração.</p><p>Veja, a seguir, um exemplo de Teste Unitário em Python para testar métodos:</p><p>Figura 8</p><p>Fonte: Reprodução</p><p>Explicando o Código do Teste Unitário em Python</p><p>O código importa o pacote unittest do Python. Um caso de Teste é criado pela subclasse unittest.TestCase. Os</p><p>três Testes Individuais são definidos como métodos cujos nomes começam com as letras test. Essa</p><p>convenção de nomenclatura informa ao Analista de Testes quais métodos representam os Testes Unitários.</p><p>O ponto crucial de cada Teste é uma chamada assertEqual() para verificar um resultado esperado:</p><p>Esses métodos são usados em vez da instrução  assert direta para que o Analista de Teste possa acumular</p><p>todos os resultados do Teste e produzir um relatório.</p><p>Os métodos setUp() e tearDown() permitem definir instruções que serão executadas antes e depois de cada</p><p>Método de Teste.</p><p>O bloco final mostra uma maneira simples de executar os Testes.</p><p>unittest.main() fornece uma interface de linha de comando para o script de Teste. Quando executado a</p><p>partir</p><p>da linha de comando, o script acima produz uma saída semelhante à apresentada a seguir:</p><p>Verifica condição verdadeira ou falsa → à assertTrue() ou assertFalse();</p><p>Verifica se uma exceção específica foi levantada → à assertRaises().</p><p>Figura 9</p><p>Fonte: Reprodução</p><p>Os três Testes foram ok e levaram apenas 0,009 segundos para serem executados:</p><p>Testes Contínuos</p><p>O Teste Contínuo é uma forma de automação alinhada ao desenvolvimento orientado pelo comportamento, o</p><p>BDD – Behavior-Driven Development.</p><p>A ideia da integração contínua é promover mudanças de Código com frequência e obter rapidamente</p><p>feedback sobre o impacto que essas mudanças têm no aplicativo ou no Sistema.</p><p>O primeiro método testa string com letra maiúscula FOO;</p><p>O segundo método testa string FOO verdadeira e foo falsa;</p><p>O terceiro método testa string separada, como hello world.</p><p>Incluir a automação de Teste no ciclo de desenvolvimento permite testar automaticamente cada mudança</p><p>incremental de Código.</p><p>Teste Funcional</p><p>O Teste Funcional é um tipo de Teste de Caixa Preta, que é realizado para confirmar que a funcionalidade de</p><p>um aplicativo ou Sistema está se comportando como esperado.</p><p>Vantagens</p><p>Saiba Mais</p><p>BDD – Behavior Driven Development – Desenvolvimento Guiado por Comportamento:</p><p>é uma técnica de desenvolvimento Ágil que encoraja a colaboração entre desenvolvedores,</p><p>setores de qualidade e pessoas não técnicas ou de negócios em um Projeto de Software.</p><p>Relaciona-se ao conceito de verificação e de validação.</p><p>O Teste do Sistema é um Teste realizado em um Sistema completo para verificar se ele funciona</p><p>como esperado, vez que todos os módulos ou componentes são integrados;</p><p>O Teste de Ponta a Ponta (End to End Test) é realizado para verificar a funcionalidade do produto.</p><p>Esse Teste é realizado somente quando os Testes de Integração do Sistema são concluídos,</p><p>incluindo tanto os requisitos funcionais quanto os não funcionais.</p><p>Desvantagens</p><p>Outros Testes</p><p>Esse Teste reproduz ou é uma réplica do Sistema real, ou seja, é uma réplica do que o produto</p><p>é no ambiente real. Os Testes são focados nas especificações de acordo com as</p><p>especificações do Sistema, isto é, especificações do Sistema, Sistema Operacional,</p><p>navegadores, etc;</p><p>Garante entregar um produto sem bugs, que tenha todas as funcionalidades funcionando de</p><p>acordo com a exigência do cliente.</p><p>Há muitas chances de realizar Testes redundantes;</p><p>Erros lógicos podem ser perdidos no produto;</p><p>Esse Teste é baseado na exigência. Caso o requisito não seja completo, seja complicado ou,</p><p>ainda, não esteja claro, torna-se difícil e pode ser demorado também.</p><p>Testes de sanidade: testes que são feitos para garantir que todas as principais e vitais</p><p>funcionalidades do aplicativo/Sistema estejam funcionando corretamente. Isso geralmente é</p><p>feito depois de um Teste de Fumaça. No âmbito de testes de softwares,   teste de fumaça é</p><p>um processo em que a construção do software é implantada em um ambiente de garantia de</p><p>qualidade e é verificada para garantir a qualidade do sistema;</p><p>Testes de aceitação: é uma fase do Processo de Testes em que um Teste de caixa-preta é</p><p>realizado em um Sistema antes de sua disponibilização. Tem por função verificar o Sistema</p><p>em relação aos seus requisitos originais, e às necessidades atuais do usuário.</p><p>Descrição de Atividades de Verificação e Validação de Testes</p><p>No mundo dos Testes, as diferenças entre Verificação e Validação podem causar confusão. Embora a distinção</p><p>possa parecer trivial, cumprem objetivos muito distintos.</p><p>Verificação</p><p>Os padrões de Engenharia de Software conhecidos como IEEE-STD-610 definem "Verificação" como: “Um</p><p>Teste de um sistema para provar que ele atende a todos os seus requisitos especificados em um</p><p>determinado estágio de seu desenvolvimento”.</p><p>Antes que a codificação comece em qualquer aplicativo, um conjunto de especificações terá sido</p><p>delineado.</p><p>A verificação do desenvolvimento refere-se à verificação do aplicativo que ainda está em desenvolvimento</p><p>para garantir que está de acordo com essas especificações.</p><p>Essas verificações podem ser algo tão simples quanto ler as especificações e compará-las à lógica do</p><p>Código para garantir que estejam alinhadas.</p><p>O processo de verificação incluirá atividades como revisões de Código, orientações, inspeções, mas</p><p>poucas, se houver, e muito mais Testes reais.</p><p>Validação</p><p>A validação, por outro lado, é bem diferente e serve a um propósito muito distinto.</p><p>A definição de validação, de acordo com IEEE-STD-610, é: uma atividade que garante que as verdadeiras</p><p>necessidades e expectativas das partes interessadas no produto final sejam atendidas.</p><p>Enquanto a verificação ocorre durante o desenvolvimento do software – o produto ainda está em</p><p>desenvolvimento, a validação é realizada após a conclusão de um determinado módulo, ou mesmo a</p><p>conclusão de toda a aplicação.</p><p>A validação se concentra em garantir que as partes interessadas obtenham o produto que desejam.</p><p>Resumo Ver x Val</p><p>A seguir, alguns exemplos para posicionar a verificação e a validação atendendo ao fluxo de</p><p>desenvolvimento (Figura 10):</p><p>Figura 10 – Diagrama Ver x Val x Testes</p><p>É necessário começar a analisar as especificações originais do Projeto e, em seguida, revisar Código,</p><p>inspecionando esse código para garantir que esteja sendo criado conforme planejado.</p><p>Quando o desenvolvimento do aplicativo for concluído, é necessário validar se o produto final está de fato</p><p>como o cliente solicitou.</p><p>Exemplos</p><p>Ver x Val:</p><p>Tabela 1</p><p>Verificação Validação</p><p>Verificar se a Equipe está</p><p>desenvolvendo o produto correto.</p><p>Validar se o produto está</p><p>funcionando conforme solicitado</p><p>pelo cliente.</p><p>Teste estático = verificação. Teste dinâmico = validação.</p><p>A verificação inclui diferentes</p><p>métodos, como inspeções, revisões</p><p>e orientações, nos Testes Unitários</p><p>e dentro dos Testes de Integração.</p><p>A validação inclui Testes como</p><p>Teste funcional, Teste de Sistema,</p><p>de Integração e Teste de Aceitação</p><p>do usuário.</p><p>É um processo de verificação dos</p><p>produtos de trabalho (não do</p><p>produto final) de um ciclo de</p><p>desenvolvimento para decidir se o</p><p>produto atende aos requisitos</p><p>especificados.</p><p>É um processo de verificação do</p><p>software durante ou no final do</p><p>ciclo de desenvolvimento para</p><p>decidir se o software segue os</p><p>requisitos de negócios</p><p>especificados.</p><p>A garantia de qualidade vem sob Teste</p><p>de Verificação.</p><p>O controle de qualidade passa por</p><p>Testes de Validação.</p><p>A execução completa do Código</p><p>não acontece no Teste de</p><p>Verificação.</p><p>No Teste de Validação, ocorre a</p><p>execução do Código.</p><p>No Teste de Verificação, podemos</p><p>encontrar os bugs no início da fase</p><p>de desenvolvimento do produto.</p><p>No Teste de Validação, podemos</p><p>encontrar esses bugs, que não são</p><p>Verificação Validação</p><p>detectados no processo de</p><p>verificação.</p><p>O Teste de Verificação é executado</p><p>pela Equipe de garantia de</p><p>qualidade para garantir que o</p><p>produto esteja sendo desenvolvido</p><p>de acordo com os requisitos dos</p><p>clientes.</p><p>O Teste de Validação é executado</p><p>pela Equipe de Teste para testar o</p><p>aplicativo.</p><p>A verificação é feita antes do Teste</p><p>de Validação.</p><p>Após o Teste de Verificação, ocorre</p><p>o Teste de Validação.</p><p>Nesse tipo de Teste, podemos</p><p>verificar se as entradas seguem as</p><p>saídas ou não.</p><p>Nesse tipo de Teste, podemos</p><p>validar se o usuário aceita ou não o</p><p>produto.</p><p>Automatização do Diagnóstico de Processos de Testes</p><p>O diagnóstico em DevOps consiste na capacidade das Equipes de monitorar e verificar constantemente</p><p>métricas e logs para medir como o desempenho influencia cada movimento feito por um usuário final. A</p><p>cobertura de Testes também deve ser medida pela Equipe de garantia de qualidade do produto.</p><p>Os dados devem ser capturados, categorizados e, em seguida, analisados com novos registros, e</p><p>oferecerão insights sobre como melhorar o desempenho e a estabilidade de um aplicativo.</p><p>Os aplicativos de monitoramento proativo também podem gerar alertas enquanto realizam análises em</p><p>tempo real dos serviços de um aplicativo, quando em produção.</p><p>A seguir, está uma lista de métricas DevOps,</p><p>que devem ser ativamente monitoradas e rastreadas 24 horas</p><p>por dia, 7 dias por semana.</p><p>Cobertura de Teste – Recomendações e Métricas</p><p>Hoje, muitos Analistas de Garantia de Qualidade discorrem sobre “cobertura de Teste”, o que dá uma boa</p><p>visão geral da qualidade do produto.</p><p>No entanto, para atingir a qualidade real, tanto a cobertura de código quanto a análise de cobertura de Teste</p><p>devem ser consideradas. Por exemplo, mesmo que alcance 100% de cobertura de Teste, ainda será</p><p>necessário ter como objetivo pelo menos 90% de cobertura de Código para garantir os melhores resultados.</p><p>Frequência de implantação;</p><p>Mudança de volume de base de dados ou contingenciamento;</p><p>Tempo de implantação;</p><p>Tempo de espera;</p><p>Ingressos de clientes;</p><p>Porcentagem de aprovação no Teste automatizado;</p><p>Taxa de escape de defeito;</p><p>Acordos de Nível de Serviço;</p><p>Implementações com falha;</p><p>Taxas de erro;</p><p>Uso, tráfego e desempenho de aplicativos.</p><p>A cobertura de Teste costuma ser confundida com a cobertura de Código.</p><p>Embora ambas as métricas sejam usadas para avaliar a qualidade do Código do aplicativo, a cobertura do</p><p>Código é um termo para descrever qual porcentagem do código do aplicativo é usada quando um usuário</p><p>interage com um aplicativo. Por outro lado, a Cobertura de Teste está testando cada requisito de negócios</p><p>pelo menos uma vez e é uma atividade da Equipe de QA.</p><p>Para obter mais cobertura de Teste em menor tempo, alguns métodos são recomendados a seguir.</p><p>Usar Ferramentas de Automação de Testes</p><p>Um dos métodos modernos de Teste de Software que qualquer Empresa ou grupo de Teste pode adotar é o</p><p>uso da Ferramenta de Automação, mas é necessário escolher e homologar para ser usada da maneira</p><p>certa.</p><p>Hoje, existem inúmeras ferramentas no Mercado para facilitar a vida dos testadores. A ferramenta certa</p><p>para a aplicação deve ser identificada.</p><p>Manter uma Lista de Verificação Adequada</p><p>Manter uma lista de verificação correta para cada comunicação no Módulo fornecido pode ajudar a alcançar</p><p>uma cobertura de Testes eficiente.</p><p>Requisitos de Priorização</p><p>Priorizar requisitos é algo necessário para atingir a cobertura máxima de Teste em menor tempo.</p><p>Classificar os requisitos fornecidos que estão com status de prioridade simples, médias e complexas, para</p><p>permitir que os testadores se concentrem em suas tarefas.</p><p>Análise de Impacto</p><p>Identificar os impactos nas construções iniciais e, consequentemente, aumentar a necessidade de</p><p>eliminação desses impactos pode ajudar a alcançar uma alta cobertura nas próximas builds.</p><p>Métricas de Cobertura de Teste</p><p>Práticas Recomendadas de Cobertura de Teste</p><p>Cobertura de código: (número de linhas de código exercidas pelos conjuntos de Teste) / (número</p><p>total de linhas de código) * 100;</p><p>Cobertura de requisitos: {[(Nº total de requisitos) - (Nº total de requisitos não atendidos)] / (Nº</p><p>total de requisitos) }* 100.</p><p>Classificar os requisitos/Módulos de Negócios de acordo com sua criticidade, frequência de</p><p>uso e fluxos de trabalho mais complexos;</p><p>Desenvolver uma matriz de rastreabilidade para os Módulos/requisitos;</p><p>Usar a cobertura de Teste como medida para "caminhos não testados" em vez de "falsa</p><p>sensação de segurança";</p><p>Desenvolver suítes automatizadas usando as estruturas integradas com utilitários de</p><p>cobertura de Código;</p><p>Medir a cobertura do Código para cada versão e planejar aprimoramentos a cada versão</p><p>subsequente;</p><p>Principais Benefícios da cobertura de Testes</p><p>Teste de Conclusão e Cobertura de Código</p><p>A cobertura do Teste não termina com os contextos anteriores. Muitos outros pontos precisam ser</p><p>considerados quando se trata de cobertura de Teste.</p><p>Nem sempre é verdade que, quando mais se testa, mais os resultados são melhores.</p><p>Quando se aumentam os Testes na verificação sem uma estratégia planejada, provavelmente isso acabará</p><p>consumindo muito tempo.</p><p>Utilizar métricas como “Densidade de defeitos”, “Distribuição de defeitos com base em</p><p>recursos” e “Eficiência de remoção de defeitos” como um guia para garantir a cobertura</p><p>aprimorada para os lançamentos subsequentes.</p><p>Ajuda, principalmente, a priorizar a tarefa de Teste;</p><p>Ajuda a atingir 100% de cobertura dos requisitos;</p><p>Útil para determinar os critérios de SAÍDA;</p><p>A análise de impactos torna-se mais fácil;</p><p>As métricas e as recomendações ajudam na preparação de relatório de fechamento de Teste</p><p>conciso e claro.</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Site</p><p>Trello</p><p>No site do Trello, você encontra informações sobre essa importante ferramenta de gestão de atividades e</p><p>sua utilização para gerenciar as tarefas de Testes, que é muito importante, principalmente, para</p><p>acompanhar e monitorar o desempenho dos Testes automatizados.</p><p>Clique no botão para conferir o conteúdo.</p><p>ACESSE</p><p>Vídeos</p><p>DevOps Saturday #01: Testes Automatizados</p><p>Vale muito à pena ouvir o pessoal. E tem a ver com o conteúdo descrito neste Material. Esta live cobre</p><p>3 / 4</p><p>📄 Material Complementar</p><p>https://trello.com/tour</p><p>termos que foram abordados, inclusive os termos que são usados na comunidade de Tecnologia. DevOps,</p><p>build, deployment, CI, CD e BDD. Descubra como esses termos foram contemplados na live.</p><p>Arcabouço de Teste Automatizado. Entenda o que Precisa Ter</p><p>O Vinícus Pessoni desvenda o “arcabouço” das ferramentas utilizadas em Testes automatizados. Alerta o</p><p>que deve ser feito antes de usar a framework, aborda também o uso do BDD e a obtenção de medidas mais</p><p>evoluídas.</p><p>DevOps Saturday #01: Testes AutomatizadosDevOps Saturday #01: Testes Automatizados</p><p>https://www.youtube.com/watch?v=qNyj_zo1FUw</p><p>Leitura</p><p>O que é CI/CD?</p><p>A RedHat é um importante fornecedor de infraestrutura para cenários DevOps. Acesse o link a seguir e</p><p>obtenha mais informações de como a Integração e a Entrega Contínua estão intimamente ligadas aos</p><p>Testes automatizados.</p><p>Clique no botão para conferir o conteúdo.</p><p>ACESSE</p><p>ARCABOUÇO de TESTE AUTOMATIZADO. Entenda o que precisa tARCABOUÇO de TESTE AUTOMATIZADO. Entenda o que precisa t……</p><p>https://www.redhat.com/pt-br/topics/devops/what-is-ci-cd</p><p>https://www.youtube.com/watch?v=P9HY_AapnyU</p><p>AURI, M; RIZZO, V. et al. Automatização de Teste de software com ferramentas de software livre. Rio de Janeiro:</p><p>Elsevier, 2018.</p><p>PALANI, N. Software Automation Testing Secrets Revealed. Part 1: Cucumber BDD, Selenium Webdriver,</p><p>Protractor, Selenium Grid, Appium, TestNG, Jenkins, UFT, RFT, Visual Studio, Excel VBA, SOAP,</p><p>Selenium IDE based Automation Testing. New Dheli: Educreation Publishing, 2018. (e-book)</p><p>PENNINGTON, J. The Eight Phases of a DevOps Pipeline. Medium, julho de 2019. Disponível em:</p><p>. Acesso em</p><p>24/04/2023.</p><p>THE DEVOPS tools lifecycle mesh for 2021. Harness, janeiro de 2021. Disponível em:</p><p>. Acesso em 24/04/2023.</p><p>DEBONO, D. The Test Pyramid: Greatest Wonder of the (Software Testing) World. Medium, fevereiro de</p><p>2022. Disponível em: . Acesso em 24/04/2023.</p><p>4 / 4</p><p>📄 Referências</p>