II_TSoftware

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.
˨ 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 indefinidamente. 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, afinal, 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, afinal, ao automatizar o teste
de software não estamos colocando um fim 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 é verificar 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, confiabilidade, desempenho e segurança. Como as APIs não possuem uma GUI
(interface gráfica 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 verificam 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 desafio é 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 definir 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 definindo 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, afinal, 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 significa 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. Afinal, 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 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
Configure o teste, incluindo dados e ambiente;1
Execute a função e meça o resultado;2
Limpe os dados e o ambiente.3
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
dificultar a determinação do resultado específico. 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
 
#ParaTodosVerem: Imagem de um fluxograma como de escada representada
com cinco retângulos fundo branco e contorno na cor azul. No primeiro
retângulo de cima para baixo no canto superior esquerdo a seguinte informação
“Selecionar ferramenta de teste”, deste segue uma seta que leva para o segundo
retângulo com a informação “Definir o escopo da automação”, este com uma
seta que leva para o terceiro retângulo com a informação “Planejamento,
Desenvolvimento e Design”, este possui uma seta que leva ao quarto com a
informação “Execução do Teste” com uma seta que leva ao quinto e último
retângulo com a informação “Manutenção”. Fim da Descrição”.
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;
Após selecionar a ferramenta chega a hora de definir 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):
Definido 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):
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 artificial para realizar automação em aplicativos móveis, web e desktop;
Testigma: ferramenta de automação que usa inteligência artificial 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.
Na quarta etapa, é hora de executar os scripts de automação, os quais necessitam de dados de
entrada antes de serem configurados 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 verificar 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 significa 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
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.
qualidade (QE) está envolvido muito mais cedo. O teste com deslocamento para a esquerda
permite que o QE identifique 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
 
#ParaTodosVerem: Imagem de um fluxograma como de escada representada
com cinco retângulos na cor azul.
No primeiro retângulo de cima para baixo no canto superior esquerdo a seguinte
informação “Análise e definição de requisitos”, deste segue uma seta que leva
para o segundo retângulo com a informação “Projeto de sistemas de software”,
este com uma seta que leva para o terceiro retângulo com a informação
“Implementação de teste de unidade”, este possui uma seta que leva ao quarto
com a informação “Integração e teste de sistemas” com uma seta que leva ao
quinto e último retângulo com a informação “Operação e manutenção”. Fim da
Descrição”.
O ponto principal que precisamos entender no modelo em cascata da Figura 2 é que as atividades
do projeto fluem 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 finalmente 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 final 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 insuficientes sendo alocados para o teste;
Muitos requisitos, arquitetura e defeitos de design não são descobertos e corrigidos
até que um esforço significativo tenha sido desperdiçado em sua implementação;
A depuração (incluindo a identificaçã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 ficarem 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 dificuldades de sobreviver
em um mercado com tantas concorrências. Afinal, 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 significa shift-left. Em uma abordagem linear – que você pode imaginar que vai da esquerda
para a direita – mudar algo para a esquerda significa começar a fazer isso mais cedo. Em vez de
iniciar a fase de teste no final 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 suficiente 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, codificado 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
 
#ParaTodosVerem: Imagem de fundo azul com quatro notebooks ligados á uma
nuvem ao centro. Fim da Descrição.
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íficos,
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 simplificada: as organizações de TI podem incorrer em custos
iniciais significativos 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 codificar 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. Afinal, 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 ficarem 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
suficiente 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 significa
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 final, 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 definiçã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 fim, 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 especificaçã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 definiçã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:
. Acesso em 01/10/2021.
FERREIRA, V. Apocalipse ou enganação: o que foi o Bug do Milênio? 2017. Disponível em:
. Acesso em 01/10/2021.
FOWLER, M. The Practical Test Pyramid. Disponível em:
. Acesso 01/10/2021.
MCGOVERN, G. O que é teste de automação. Disponível em:
. 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: . Acesso em:
Acesso em: 04/05/2021.
3 / 3
˨ Referências