DevOps e Teste Automatizado

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.

ʪ Material Teórico

ʪ Material Complementar

ʪ Referências

QUESTION B AN KS
1/3

ʪ Material Teórico

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.
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
 resposta.

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. 
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:

1 Con gure o teste, incluindo dados e ambiente;

2 Execute a função e meça o resultado;

3 Limpe os dados e o ambiente.

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
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

Testes não adequados para automação
automatizados

Alto Risco – Casos de Casos de teste que são recentemente

Testes Críticos para projetados e não executados manualmente
o Negócio pelo menos uma vez.

Casos de Teste que

Casos de teste para os quais os requisitos
são Executados
mudam com frequência.
Repetidamente

Caso de Testes que

são Muito Tediosos e Casos de teste executados em uma base
Difíceis de Serem ad-hoc (com interação arbitrária do
Executados testador, ou seja, um teste improvisado).
Manualmente

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;
 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.

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):

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.

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):

Ferramentas de automação selecionadas;

Projeto da estrutura e seus recursos;

Itens dentro e fora do escopo de automação;

 Preparação de bancada de teste de automação;

Cronograma e cronograma de script e execução;

Produtos de teste 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)

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:

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.

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. 
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; 
 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.

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.
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.
2/3

ʪ Material Complementar

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.
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
3/3

ʪ Referências

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.