Baixe o app para aproveitar ainda mais
Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original
Conteudista: Prof. Me. Ariel da Silva Dias Revisão Textual: Prof.ª M.ª Sandra Regina Fonseca Moreira Objetivos da Unidade: Compreender o conceito de teste automatizado; Reconhecer os principais frameworks de teste; Aplicar os frameworks em testes de software. QUESTION B AN KS Material Teórico Material Complementar Referências DevOps e Teste Automatizado Conceitos de Testes Automatizados Existem dois tipos de teste no mundo do software – manual e automatizado. Alguns tipos de testes manuais, como o teste de descoberta e o teste de usabilidade, são excelentes e muito difíceis de serem substituídos. Você pode fazer outros tipos de teste – como o teste de regressão e o teste funcional – manualmente, mas é uma prática bastante frustrante e cansativa para os humanos continuarem fazendo a mesma coisa inde�nidamente. São esses tipos de testes repetitivos que se prestam à automação de testes. Acrescenta-se ainda que, com a forte concorrência comercial existente nos tempos atuais, as empresas precisam lançar mais rapidamente (e com qualidade) seus softwares para atender à crescente demanda de seus serviços e produtos. Eles estão adotando práticas ágeis e DevOps, aproveitando o teste automatizado de software para obter lançamentos mais rápidos e produtos de qualidade, além de um retorno mais rápido do investimento. Teste automatizado de software é uma metodologia que ajuda a validar o funcionamento do software antes de colocá-lo em produção. Nesse processo, ferramentas de teste automatizadas são usadas pelas equipes de QA (Quality Assurance – Garantia de Qualidade) para executar os scripts de teste. A automação de teste é responsável por executar testes automaticamente, gerenciando os dados do teste e utilizando os resultados para melhorar a qualidade do software. É principalmente uma medida de garantia de qualidade, assim, suas atividades envolvem o comprometimento de toda a equipe de produção de software, de analistas de negócios a desenvolvedores e engenheiros de DevOps, a�nal, para se obter o máximo da automação de teste é necessária a inclusão de todos. 1 / 3 Material Teórico De modo geral, o plano de teste médio para um aplicativo de nível comercial possui entre 2.000 e 10.000 casos de teste. Logo, uma equipe de teste de cinco pessoas deve executar manualmente e documentar os resultados de 400 a 2.000 casos de teste. Agora, considere que a data de lançamento programada do seu produto de software está se aproximando rapidamente. O que fazer? Bem, este pode ser um bom momento para adicionar testes automatizados ao plano de teste. Com o uso de ferramentas de teste de software automatizadas, as equipes de QA podem testar rapidamente o software, preparar os relatórios de defeitos e comparar os resultados do software com os resultados esperados. Além disso, esse processo de teste automatizado oferece vários benefícios, como entrega mais rápida, facilita o tempo de teste de regressão e garante um software de qualidade, além de reduzir os esforços do teste manual. Fim do Teste Manual? O título deste subtópico é um tanto quanto sensacionalista, a�nal, ao automatizar o teste de software não estamos colocando um �m no teste manual. Em vez de substituir a intuição humana e a solução de problemas, a automação de testes consiste em automatizar os testes certos. Nem tudo o que pode ser automatizado deve ser automatizado. Como um exemplo, se você tem algo que precisa testar o mais rápido possível e é apenas um trabalho único, não há necessidade de perder tempo escrevendo um script para fazer isso por você. Automatizar os testes certos ajudará sua equipe, dando aos desenvolvedores e testadores um tempo valioso. Eles podem então se concentrar em tarefas mais importantes. Por exemplo, eles podem criar novos recursos, solucionar bugs complicados e fornecer software de alta qualidade. Tipos de Automatização Antes de mais nada, é muito importante compreender que a maioria dos testes manuais podem ser automatizados. Em outras palavras, existem diferentes tipos de testes, muitos dos quais podem ser automatizados, logo, o que um usuário realiza manualmente pode ser replicado com um script de automação. Entretanto, nem todos os testes devem ser automatizados, veremos isso mais adiante. Teste de Unidade O teste de unidade é quando você isola uma única unidade de seu aplicativo do restante do software e testa o seu comportamento. Esses testes não dependem de APIs, bancos de dados externos ou qualquer outra coisa. Se você tiver uma função na qual deseja realizar um teste de unidade e essa função usar alguma biblioteca externa, ou até mesmo outra unidade do mesmo aplicativo, esses recursos serão simulados. O principal objetivo do teste de unidade é ver como cada componente do seu aplicativo funcionará, sem ser afetado por mais nada. O teste de unidade é executado durante a fase de desenvolvimento, e é considerado o primeiro nível de teste. Teste de Integração No teste de integração, você testa como as unidades são integradas logicamente e como funcionam como um grupo. O principal objetivo do teste de integração é veri�car como os módulos se comunicam e se comportam juntos, e avaliar a conformidade de um sistema. Teste de API O teste de API envolve testar as interfaces de programação de aplicativos (APIs) – diretamente e como parte do teste de integração – para determinar se elas atendem às expectativas de funcionalidade, con�abilidade, desempenho e segurança. Como as APIs não possuem uma GUI (interface grá�ca do usuário), o teste da API é realizado na camada de mensagem. O teste de API é crítico para ser automatizado porque as APIs servem como a interface primária para a lógica do aplicativo e porque os testes de GUI são difíceis de manter com ciclos de lançamento curtos e mudanças frequentes, comumente usados com o desenvolvimento de software Agile e DevOps. Quando uma nova versão do sistema é lançada (por exemplo, alterando alguns dos componentes de negócios ou estruturas de dados internas), é necessário ter um conjunto de testes de regressão de API rápidos e fáceis de executar, que veri�cam se essas mudanças internas não quebraram as interfaces de API e, deste modo, se os aplicativos cliente que dependem das APIs continuarão a funcionar como antes. Teste de Fumaça O teste de fumaça é executado para examinar se a construção do sistema é estável ou não. Em suma, seu objetivo é examinar se as principais funcionalidades funcionam corretamente para que os testadores possam prosseguir com os testes. Teste de Desempenho Teste de carga, teste de estresse e teste de desempenho são todos nomes diferentes para um conjunto de tipos de teste automatizado em que você usa uma ferramenta de teste de carga para simular a carga de trabalho requerida por muitos usuários (chamados de usuários virtuais) em um aplicativo que está sendo testado. A principal diferença nos termos é com relação aos objetivos: Teste de carga: você coloca o número esperado de usuários em relação ao aplicativo e observa se o comportamento do aplicativo continua a ser bom ou sofre degradação; Teste de estresse: você coloca um número crescente de usuários como carga e observa onde ele falha; Teste de desempenho: você coloca um número variável de usuários para carregar, medir o desempenho e reprojetar o aplicativo para melhorar os tempos de O Que Podemos Automatizar? Os benefícios da automação são óbvios. A automação oferece a capacidade de reagir rapidamente aos requisitos de negócios em constante mudança e gerar novos testes continuamente. É razoável supor que quanto mais você automatiza, mais benefícios você colhe. Então por que não automatizar tudo? O primeiro passo para responder a esta pergunta é perceber que nenhum plano de teste pode ser executado completamente com métodos automatizados. O desa�o é determinar quais componentes do plano de teste pertencem ao intervalo de teste manual e quais componentes são mais bem atendidos no intervalo automatizado. Trata-se de de�nir expectativas realistas; a automação não pode fazer tudo. Os humanos são mais espertos do que as máquinas (pelo menos atualmente) e podemos ver padrões e detectar falhas intuitivamente de maneiras que os computadores não são capazes de fazer. Vamos começar de�nindo as expectativas em um nível razoável. Digamos que iremos automatizar 20% de todos os nossos casos de teste. Bem, existe apenas um problema, como colocado anteriormente, uma empresa possui de 2000 a 10000 casos de testes. Logo, seriam automatizados de 400 a 2000 casos de testes. Talvez esta não seja a melhor abordagem, a�nal, podemos automatizar testes que não possuem impacto na satisfação do cliente, ou então, automatizar testes que poderiam sim ser manuais (lembre-se de que automatizar não signi�ca abandonar o teste manual!). Que tal os 20% dos casos de teste usados com mais frequência, que têm o maior impacto na satisfação do cliente e que consomem cerca de 70% do tempo da equipe de teste? Os 20% dos casos de teste que reduzirão o tempo total de teste pelo maior fator, liberando a equipe para outras tarefas. resposta. Esses são os casos de teste aos quais você dedica muitas horas realizando, todos os dias, em todos os lançamentos, em todas as builds. Esses são os casos de teste com os quais você possui maior preocupação. Portanto, essas são as tarefas que compensam a existência da empresa e da equipe de teste. Esses casos de teste são tediosos, mas importantes. Exposto tudo isso, observe que um teste precisa atender a alguns critérios para ser automatizado – caso contrário, pode acabar custando mais do que economizando. A�nal, um dos principais objetivos da automação é economizar tempo, esforço e dinheiro. Deste modo, a seguir estão elencados três critérios essenciais para a automação de teste. Esses são pontos de partida, ou seja, os seus critérios ou os de sua empresa podem ser diferentes, dependendo de suas circunstâncias. Primeiro Critério: Repetível O teste deve ser repetível. Não faz sentido automatizar um teste que só pode ser executado uma vez. Um teste repetível tem três etapas: Na primeira etapa, queremos ser capazes de colocar o ambiente em um estado consistente. Se tivermos um teste para tentar adicionar um usuário existente, precisamos ter certeza de que o usuário existe antes de realizar o teste. Assim que o teste for concluído, o ambiente deve retornar ao estado original (antes do início da execução). Segundo Critério: Determinante Uma função é considerada determinante quando o resultado é o mesmo sempre que é executada com a mesma entrada. Em outras palavras, os resultados devem ser razoavelmente Con�gure o teste, incluindo dados e ambiente;1 Execute a função e meça o resultado;2 Limpe os dados e o ambiente.3 previsíveis, de modo que um script de teste seja capaz de capturar. Os testes de estresse e carga se encaixam perfeitamente nessa categoria. Por exemplo, digamos que queremos testar uma função de adição. Sabemos que 1 + 1 = 2 e que 752,78 + 247,22 = 1000,00. A adição é uma função determinante. Podemos usar qualquer valor do lado esquerdo do operador de soma, bem como outros diversos valores no operador direito do operador, e sempre teremos o resultado da adição. O software, por outro lado, pode usar um número tão alto de entradas variáveis que é difícil obter o mesmo resultado ao longo do tempo. Algumas variáveis podem até ser aleatórias, o que pode di�cultar a determinação do resultado especí�co. O projeto do software pode compensar isso, permitindo entradas de teste por meio de um. Em outro exemplo, considere a criação de um novo usuário em um sistema, o que aumentaria o número de usuários cadastrados no banco de dados. Ao menos quando adicionamos um usuário, sabemos que o número de usuários deve crescer apenas em um. No entanto, a execução de testes em paralelo pode causar resultados inesperados. Terceiro Critério: Testes de Negócios Críticos Para testes que podem causar uma interrupção no serviço e potencialmente prejudicar os negócios de alguém, a automação de teste pode ajudar a garantir que os novos recursos não quebrem os existentes. Testes de fumaça, testes de sanidade e testes de regressão são bons candidatos para automação – especialmente quando eles precisam ser testados em todas as versões e lançamentos de um aplicativo. Quarto Critério: Sem Opinião Não é possível automatizar questões de opinião. Bem, é aqui que o teste de usabilidade, o teste beta, o teste A/B, e assim por diante, realmente brilham. O feedback do usuário é importante, mas não pode ser automatizado. A Tabela 1, a seguir, apresenta uma relação de testes que são adequados para serem automatizados, e outros que não são adequados. Tabela 1 – Critérios para Automatizar os Testes de Software Testes que podem ser automatizados Testes não adequados para automação Alto Risco – Casos de Testes Críticos para o Negócio Casos de teste que são recentemente projetados e não executados manualmente pelo menos uma vez. Casos de Teste que são Executados Repetidamente Casos de teste para os quais os requisitos mudam com frequência. Caso de Testes que são Muito Tediosos e Difíceis de Serem Executados Manualmente Casos de teste executados em uma base ad-hoc (com interação arbitrária do testador, ou seja, um teste improvisado). Casos de Testes que Consomem Tempo Etapas de Automação Como em todo processo de teste, para a automação é necessário seguir algumas etapas (MCGOVERN, 2021), conforme ilustra a Figura 1. Figura 1 – Etapas para o Teste Automatizado Observe na Figura 1 que a primeira etapa é a seleção da ferramenta de teste. Existem muitas ferramentas disponíveis no mercado, cada uma com suas características e funcionalidade. Dentre elas, destacam-se (MCGOVERN, 2021): Appium: ferramenta de software livre usada para automatizar diferentes tipos de aplicativos (nativos, híbridos, web); Katalon Studio: ferramenta de automação de teste de código aberto usada para aplicativos móveis e da web; Selenium: trata-se de uma das ferramentas automatizadas mais populares, usada para realizar testes de aplicativos web em diferentes plataformas e navegadores; TestComplete: ferramenta de teste de UI (user interface) automatizada que utiliza inteligência arti�cial para realizar automação em aplicativos móveis, web e desktop; Após selecionar a ferramenta chega a hora de de�nir o escopo da automação, ou seja, a área do aplicativo que terá o teste automatizado. Para determinar o escopo, alguns pontos devem ser levados em consideração (MCGOVERN, 2021): De�nido o escopo, iremos para a terceira etapa, que é a criação da estratégia e o plano de automação. Neste plano, deve ser considerado (MCGOVERN, 2021): Testigma: ferramenta de automação que usa inteligência arti�cial para automatizar testes complexos como serviços web e API, sendo mais adequada para metodologias Ágeis e DevOps; Tosca: ferramenta de teste que é comumente utilizada para oferecer suporte a testes de ponta a ponta de aplicativos. Os recursos que são importantes para a empresa; Cenários que possuem uma grande quantidade de dados; Funcionalidades comuns entre aplicativos; Viabilidade técnica; Até que ponto os componentes de negócios são reutilizados; A complexidade dos casos de teste; Capacidade de usar os mesmos casos de teste para testes entre navegadores. Ferramentas de automação selecionadas; Projeto da estrutura e seus recursos; Itens dentro e fora do escopo de automação; Na quarta etapa, é hora de executar os scripts de automação, os quais necessitam de dados de entrada antes de serem con�gurados para serem executados. Esta execução pode ser feita em uma única máquina ou em um grupo de máquinas. Após a execução serão gerados relatórios de teste detalhados (MCGOVERN, 2021). Aqui é possível executar o script diretamente pela ferramenta de automação ou usar uma Test management, ferramenta que invocará a ferramenta de automação. A última etapa diz respeito à manutenção do teste de automação, que consiste em veri�car se as funcionalidades adicionadas ao software estão funcionando bem (MCGOVERN, 2021). Teste Shift Left Uma das tendências mais importantes e amplamente discutidas dentro da comunidade de teste de software é o teste shift left, que signi�ca simplesmente começar o teste o mais cedo possível no ciclo de vida. Enquanto o movimento ágil dividia o trabalho em pedaços menores, a fase de teste permaneceu a última. Deste modo, o teste shift left, ou teste de deslocamento para a esquerda, traz uma mentalidade diferente para o ciclo de vida de entrega de software, em que o engenheiro de qualidade (QE) está envolvido muito mais cedo. O teste com deslocamento para a esquerda permite que o QE identi�que e previna a ocorrência de defeitos, testando durante os estágios de análise e desenvolvimento. Testes Tardios (Shift-right) Preparação de bancada de teste de automação; Cronograma e cronograma de script e execução; Produtos de teste de automação. Antes de entender o que é o shift-left, é necessário voltarmos a origem e entender o modelo de desenvolvimento em cascata. Seguindo este modelo, cada atividade é alinhada em fases sucessivas. Logo, para iniciar a próxima etapa, a equipe deve concluir a anterior e trabalhar com seus resultados. A Figura 2 ilustra bem este modelo. Figura 2 – Modelo em Cascata O ponto principal que precisamos entender no modelo em cascata da Figura 2 é que as atividades do projeto �uem em uma direção, ou que se movem para baixo como uma cachoeira. Com o modelo em cascata, os projetos são bastante fáceis de gerenciar. Primeiro fazemos isso, depois isso, e �nalmente aquilo – todos sabem o que fazer em cada fase e (a princípio) os prazos são claros. Na realidade, porém, as etapas muitas vezes não são concluídas no prazo e o tempo alocado para as etapas posteriores deve ser reduzido para cumprir-se o prazo. Por décadas, sabe-se que os defeitos são mais difíceis e caros de consertar quanto mais tarde são encontrados no ciclo de vida. Esse fenômeno é um dos motivos pelos quais tratar o teste como uma fase sequencial no �nal do desenvolvimento em cascata tem sido visto, há muito tempo, como uma grande armadilha dos testes de sistema e software. Exemplos de danos causados pelo adiamento do teste incluem: Essas consequências negativas dos testes tardios aumentam os custos de desenvolvimento e manutenção, levam a prazos perdidos e atrasos no cronograma, diminuem a qualidade devido a defeitos residuais e geralmente reduzem o moral do projeto e a satisfação no trabalho. Sendo assim, empresas que se arriscam neste modelo tendem a ter di�culdades de sobreviver em um mercado com tantas concorrências. A�nal, se eles lançam uma nova versão do seu software 1 ou 2 vezes no ano, acabam por perder o interesse dos clientes. O que tornou então um modelo clássico de desenvolvimento e teste em algo depreciado? A resposta é: o modelo Agile. Os testadores podem estar menos envolvidos no planejamento inicial, muitas vezes resultando em recursos insu�cientes sendo alocados para o teste; Muitos requisitos, arquitetura e defeitos de design não são descobertos e corrigidos até que um esforço signi�cativo tenha sido desperdiçado em sua implementação; A depuração (incluindo a identi�cação, localização, correção e defeitos de teste de regressão) torna-se mais difícil à medida em que mais software é produzido e integrado; O encapsulamento torna mais difícil realizar o teste de caixa branca e atingir altos níveis de cobertura de código durante o teste; Há menos tempo para corrigir defeitos encontrados por meio de testes, aumentando assim a probabilidade de que sejam adiados para incrementos ou versões posteriores do sistema, o que cria uma "onda de proa" de dívida técnica, que pode afundar projetos se �carem muito grandes. Atualmente, encontramos várias metodologias como Scrum ou Kanban que seguem o princípio ágil. Todos eles seguem os mesmos valores fundamentais para alcançar um ciclo de vida do projeto mais adaptável. Os métodos ágeis permitem que as equipes forneçam aplicativos valiosos no início e de forma contínua. Como resultado, as empresas podem publicar novos recursos com mais frequência. Em vez de seguir uma abordagem linear e sequencial, o ágil segue uma circular e iterativa. Além disso, o teste shift-left tornou-se uma parte essencial do Agile para superar gargalos causados por testes realizados muito tarde no ciclo de desenvolvimento. Começando o Teste mais Cedo Agora que você pode compreender sobre o modelo em cascata, é menos complexo entender o que signi�ca shift-left. Em uma abordagem linear – que você pode imaginar que vai da esquerda para a direita – mudar algo para a esquerda signi�ca começar a fazer isso mais cedo. Em vez de iniciar a fase de teste no �nal do ciclo de desenvolvimento, nós o executamos em um estágio anterior e, portanto, deslocamos para a esquerda. Claro, abordagem semelhante pode ser aplicada a ambientes ágeis, mesmo quando eles não são lineares. Portanto, em vez de acumular todas as tarefas de teste para os últimos dias antes do lançamento do seu aplicativo, sua equipe começa a realizar os testes no início do ciclo de desenvolvimento. Encontrar e corrigir bugs o mais cedo possível ajuda a introduzir código de alta qualidade desde o início e economizar tempo e recursos. Além disso, o design do seu aplicativo melhora à medida em que sua equipe pode detectar e resolver possíveis problemas de desempenho e outros gargalos mais cedo. Dessa forma, você pode garantir que apenas aplicativos bem testados e altamente funcionais sejam publicados, permitindo que sua equipe tenha tempo su�ciente para respirar. Em poucas palavras, observe que o Shift Left tem o objetivo de descobrir o máximo de problemas possível, o mais cedo possível, no processo de desenvolvimento de software, para que o custo de os corrigir esteja sob controle. Testando com frequência, sua equipe e as partes interessadas podem garantir melhor visibilidade e controle sobre o estado atual do código e tomar decisões informadas durante todo o projeto. Mas, como tratamos nossos aplicativos após a implantação? Nós os deixamos fazer sua mágica e torcer pelo melhor? Não, precisamos executar testes e obter o feedback de nossos usuários após o lançamento também! Teste como Serviço (TaaS) Para organizações de TI que desenvolvem e mantêm aplicativos de software proprietários, o teste de software é um componente crucial para garantir que as versões sejam funcionais e atendam às demandas de qualidade e desempenho dos clientes. No processo tradicional de desenvolvimento de software, todos os testes ocorrem no mesmo período de tempo do projeto – depois que o produto já foi projetado, codi�cado e implementado. Para organizações que se concentram em DevOps ou metodologias de desenvolvimento Agile, o teste é uma atividade frequente, que ocorre durante todo o processo de desenvolvimento. Figura 3 – Computação em Nuvem Fonte: Freepik Além do teste de aplicativos, as organizações de TI também podem testar e auditar sua infraestrutura e ambientes em nuvem (como ilustrado na Figura 3) para avaliar o desempenho operacional e comercial, bem como a segurança. Os testes podem ser direcionados à descoberta de vulnerabilidades de segurança na rede, ou à otimização do desempenho comercial de um aplicativo ou serviço. Para organizações cuja demanda por testes ultrapassou suas capacidades, o TaaS é um modelo de terceirização no qual um provedor de serviços realiza atividades de teste em nome de funcionários de empresas de desenvolvimento de software. Em outras palavras, um provedor de serviços terceirizado é contratado para fornecer serviços de teste em conexão com as principais atividades de negócios da organização. Os provedores de serviços TaaS alavancam sua interface web existente, infraestrutura de teste existente e recursos de automação para ajudar os desenvolvedores de software a trazerem novos produtos para o mercado com mais rapidez e menos bugs. TaaS pode assumir várias formas e formatos, geralmente fornecidos por empresas especializadas em testes de software, ou empresas de desenvolvimento terceirizadas. Um ciclo de teste completo pode incluir suporte ponta a ponta e recursos tecnológicos especí�cos, usados no planejamento e realização de tipos de teste de software. Quando Contratar TaaS As organizações de TI devem considerar a contratação de um provedor TaaS: Necessidade de especialização adicional: para algumas organizações de TI ou equipes de desenvolvimento de software, pode ser que os membros da equipe não tenham as habilidades necessárias para garantia de qualidade de software e testes automatizados. Faz sentido terceirizar o processo de teste quando está claro que a experiência de provedores de serviços externos aumentará os resultados do projeto; Deve sempre haver uma preocupação quanto à privacidade, bem como realizar um contrato de sigilo, uma vez que o provedor de serviço terá acesso ao seu produto de modo exclusivo e em primeira mão. Framework de Teste (TDD, BDD, Mocha) Um framework é um conjunto de práticas recomendadas, suposições, ferramentas comuns e bibliotecas que você pode usar entre as equipes para implementar seu teste automatizado. Você simplesmente não precisa criar um exclusivo para o seu ambiente de desenvolvimento. Um framework ajudará a tornar seu código de automação de teste reutilizável, sustentável e estável, além, é claro, auxiliar sua empresa contra defeitos onerosos. A�nal, mesmo pequenos bugs podem levar a grandes problemas. Os programadores podem escrever testes de unidade e funcionais usando frameworks. Os testes de unidade testam linhas individuais de código. Os testes funcionais testam algo maior, como se uma transação ainda pode ser executada. Outros frameworks testam se o aplicativo funciona em várias versões dos sistemas operacionais de destino, diferentes orientações de tela em dispositivos móveis, diferentes navegadores e com diferentes tamanhos de tela. Turnaround curto: Para equipes de desenvolvimento que buscam uma integração contínua, ou modelo de trabalho de entrega contínua, adotando práticas Agile e DevOps, a necessidade de testes frequentes pode sobrecarregar os desenvolvedores, especialmente aqueles que agregam mais valor criando um novo código. Quando os aplicativos são muito complexos para o modelo de teste manual tradicional, um provedor de serviços TaaS pode ajudar a executar o teste automatizado com um tempo de resposta curto e liberar o tempo do desenvolvedor para continuar empurrando o novo código; Infraestrutura simpli�cada: as organizações de TI podem incorrer em custos iniciais signi�cativos ao estabelecer sua própria infraestrutura de teste. Esses custos incluem itens como teste de hardware, licenças de software e o tempo real gasto para projetar e codi�car scripts de teste. Devido às restrições de recursos, geralmente é mais barato contratar um provedor de serviços TaaS terceirizado, que já tenha a infraestrutura necessária para realizar os testes desejados. A seguir, veremos os principais frameworks que são utilizados durante o desenvolvimento automatizado de código Test Drive Development (TDD) e Behavior Drive Development (BDD). Test Drive Development (TDD) O Test Drive Development (ou Desenvolvimento Orientado a Testes) é uma metodologia para fazer os programadores se concentrarem apenas no que é importante, e não �carem presos na tarefa demorada de resolver problemas que não sejam pertinentes à tarefa principal. O TDD é uma extensão do Agile Framework, cujo objetivo é agilizar através da simplicidade, entregando pequenas tarefas discretas e rastreando-as. A ideia básica com TDD e BDD é escrever o código de teste primeiro, e depois escrever apenas o su�ciente do código do aplicativo para passar no teste. Para pessoas com pressa, como tentar cumprir o prazo de uma iteração do Agile, os programadores podem tentar enganar certos itens, como escrever chamadas de banco de dados falsas. Então, na próxima iteração do Agile, eles podem escrever o código para fazer com que funcionem de verdade. O objetivo é continuar avançando. Behavior Drive Development (BDD) Behavioral-Driven Development (BDD) possui o mesmo objetivo, mas seu foco está no aplicativo, e não no teste de parágrafos individuais de código. Portanto, é um teste funcional automatizado. Os programadores executam o teste e, quando ele falha, fazem a refatoração, o que signi�ca consertar o código. Grandes equipes usando Jenkins ou outros aplicativos para coordenar o projeto maior podem até colocar uma tela na parede para mostrar quais seções do código estão vermelhas (quebradas), ou verdes (funcionando), para permitir que todo o projeto veja rapidamente qual é o status da construção. BDD e TDD podem parecer muito semelhantes, pois ambos são estratégias de teste para um aplicativo de software. Em ambos os casos, o desenvolvedor escreve o teste antes de escrever o código para fazer o teste passar. E, em ambos os casos, os testes podem ser usados como parte de um framework de teste automatizado para evitar bugs. Por um lado, o BDD foi projetado para testar o comportamento de um aplicativo do ponto de vista do usuário �nal, por outro, o TDD se concentra em testar partes menores de funcionalidade de forma isolada. Nesta Unidade, você pôde compreender o conceito de teste automatizado e sua importância no ciclo de vida do desenvolvimento de software. Pôde conhecer a de�nição de teste manual e teste automatizado, o qual é muito utilizado principalmente quando trabalhamos com metodologias ágeis e DevOps. Conheceu também a técnica shift left, cuja proposta é iniciar os testes da esquerda para a direita, tornando o teste mais constante no desenvolvimento do software, prevendo assim comportamento inesperado desse. Por �m, pôde conhecer dois dos principais frameworks de testes: o TDD e o BDD. Indicações para saber mais sobre os assuntos abordados nesta Unidade: Livros Teste de Software No capítulo 9 do livro “Testes de Software”, o autor apresenta o conceito de automação do processo de teste, bem como ilustra com alguns exemplos. Trata-se de uma literatura recomendada para iniciantes e também para usuários intermediários. RIOS, E. Teste de Software. Rio de Janeiro: Alta books, 2013, p. 161. Introdução ao Teste de Software No capítulo 8 do livro “Introdução ao Teste de Software”, os autores apresentam uma introdução aos conceitos de testes para aplicações web, partindo do teste estrutural, bem como teste baseado em modelos de especi�cação e apresentação de ferramentas. Trata-se de uma leitura indicada para compreender, principalmente, as fases e critérios de um teste de software. 2 / 3 Material Complementar DELAMARO, M.; MALDONADO, J.; JINO, M. Introdução ao teste de software. São Paulo: Elsevier, 2007. Engenharia de Software Moderna No livro “Engenharia de software moderna”, o autor dedica o capítulo 10 para falar sobre DevOps. Ele explica todos os conceitos fundamentais e essenciais desta metodologia, bem como trata de testes automatizados em DevOps. Trata-se de uma leitura indicada para quem deseja se aprofundar nos conceitos sobre teste de software. VALENTE, M. Engenharia de software moderna. São Paulo: Editora independente, 2020. Leitura A Importância dos Testes Automatizados No artigo, o autor apresenta a de�nição dos testes de softwares automatizados, destacando pontos relevantes desta metodologia quando aplicada em um desenvolvimento ágil. Durante a leitura, o autor prende a atenção ao destacar detalhes importantes dos testes automatizados, bem como suas aplicações. Clique no botão para conferir o conteúdo. ACESSE https://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf BRAGA, P. H. C. (org.). Teste de Software. São Paulo: Pearson Education do Brasil, 2016. (e- book) DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de software. Rio de Janeiro: Elsevier, 2016. (e-book) FERRONI, M. Erro da Nasa pode ter destruído sonda. 1999. Disponível em: <https://www1.folha.uol.com.br/fsp/ciencia/fe0110199905.htm>. Acesso em 01/10/2021. FERREIRA, V. Apocalipse ou enganação: o que foi o Bug do Milênio? 2017. Disponível em: <https://www.uol.com.br/tilt/noticias/redacao/2017/08/20/apocalipse-ou-enganacao-o-que- foi-o-bug-do-milenio.htm>. Acesso em 01/10/2021. FOWLER, M. The Practical Test Pyramid. Disponível em: <https://martinfowler.com/articles/practical-test-pyramid.html>. Acesso 01/10/2021. MCGOVERN, G. O que é teste de automação. Disponível em: <https://www.guru99.com/automation-testing.html>. Acesso em: 20/10/2021. VALENTE, M. T. Engenharia de software moderna: princípios e práticas para desenvolvimento de software com produtividade. Disponível em: <https://engsoftmoderna.info/>. Acesso em: Acesso em: 04/05/2021. 3 / 3 Referências
Compartilhar