livro unico - Qualidade E Automação De Testes

Prévia do material em texto

INTRODUÇÃO
Bem-vindo ao estudo da disciplina Qualidade e Automação de Testes. Aqui, você
estudará desde a história da testagem de softwares até as modernas ferramentas
utilizadas para a realização de testes de softwares, programas e aplicativos oriundas
das metodologias ágeis, como o TDD e o BDD, que são as siglas de Desenvolvimento
Orientado a Testes e a Comportamentos. Quando testamos um código, queremos
encontrar erros, os chamados bugs. A função de um bom teste é encontrar erros de
programação devido à linguagem ou a erros humanos de interpretação do desejo do
cliente na elaboração dos programas, pois, desta forma, evitamos que um software
seja vendido com muitos bugs. Nenhum de nós volta a usar um aplicativo sem receio
quando o utilizamos pela 1ª vez e ele não funciona da maneira que nos foi prometido.
Atualmente, as indústrias e os fabricantes de jogos e aplicativos procuram
pro�ssionais que sejam capazes de identi�car e corrigir erros de programação no
momento da realização ou antes que um produto seja vendido comercialmente. Elas
procuram por pro�ssionais que queiram trabalhar em equipe e interpretar o desejo
do cliente. Depois de concluir este curso, você será capaz de realizar a testagem,
inclusive, elaborando procedimentos e executando testes de softwares com muita
qualidade, através de um conhecimento baseado em técnicas inovadoras que te farão
um pro�ssional disputado pelo mercado de trabalho. 
HISTÓRIA DA TESTAGEM DE SOFTWARES
Muitos historiadores atribuem a origem do termo bug a Thomas Edson, o inventor da
lâmpada elétrica e do gramofone, o primeiro gravador de voz, porque um inseto –
bug, em inglês – caiu em seu gramofone, dani�cando uma de suas gravações. Outros
historiadores atribuem o termo aos engenheiros que estavam construindo o Mark I,
pois uma traça dani�cou alguns dos seus sistemas, e os engenheiros chamaram a este
erro de bug. A Figura 1 mostra a imagem do Mark I, o 1º computador digital
construído pelos engenheiros da IBM e enviado para Harvard.
Figura 1 | Mark I, o primeiro computador digital
Aula 1
A HISTÓRIA E OS FUNDAMENTOS DA TESTAGEM
EM SOFTWARES
Evolução da testagem em softwares.
47 minutos
Fonte: Flickr.
O certo é que, quando qualquer problema de programação ou de sistema aparece,
dizemos que o software “bugou”, ou seja, apresenta um erro que torna sua execução
falha. No começo do desenvolvimento de softwares e programas, os desenvolvedores
não se atentavam para a importância da testagem antes do término do processo,
tanto que alguns programas e softwares chegaram a ir para o mercado sem sequer
terem sido testados. Com isso, o número de falhas de programação aumentou
signi�cativamente a ponto de a testagem começar a ser considerada um item
essencial no desenvolvimento de softwares e programas. O primeiro livro que
abordou este tema, com um capítulo inteiro dedicado ao assunto, foi Computer
Programming Fundamentals, e o primeiro autor a escrever um livro totalmente
dedicado a este assunto foi Glenford Mayers, com seu livro A arte do teste de
software. A partir daí, os órgãos regulamentadores, como o IEEE (lemos I3E) e o IEC
(lemos I E C, cada letra separadamente), passaram a desenvolver parâmetros para a
testagem de softwares. Estes métodos e procedimentos garantiam que um software
fosse testado antes de ser lançado no mercado, diminuindo o índice de falhas em
programas de forma drástica.
No início dos anos 2000, foi publicado o livro Teste de Software, de Emerson Rios e
Trayahú Moreira, referência sobre o assunto no Brasil. A partir disso, várias empresas
lançaram produtos para ajudar os desenvolvedores e programadores a realizar a
testagem automática dos seus programas e softwares, tornando o trabalho mais
con�ável e rápido. Um dos primeiros softwares de testagem, o Selenium®, que
automatiza ferramentas web para a realização de testes, foi fabricado pela empresa
ThoughtWorks, em Chicago. Atualmente, o Brasil realiza, através da Associação Latino-
Americana de Teste de Software, um exame para emitir certi�cados para os
pro�ssionais que querem uma quali�cação extra nesta área, a qual é emitida pelo
International Software Testing Quali�cations Board (ISTQB), sendo que o 1º nível é
chamado de Certi�ed Tester.
Desta forma, os desenvolvedores de softwares, programas e aplicativos perceberam
que um programa pode ter seu valor expandido em razões estratosféricas se ele
chegar ao mercado com erros que poderiam ser percebidos e corrigidos antes do
lançamento do produto e incorporaram a testagem de softwares como uma das
etapas fundamentais no seu desenvolvimento. Outro importante ganho foi terem
feito este procedimento segundo critérios apresentados e aplicados em normas de
qualidade, o que fez com que a equipe de desenvolvimento de softwares tenha que
trabalhar junto à equipe de qualidade, permitindo um ganho na descoberta de erros e
falhas.
VIDEOAULA: HISTÓRIA DA TESTAGEM DE SOFTWARES
Neste vídeo, iremos nos aprofundar na história da testagem de softwares com a
análise de algumas estatísticas sobre a ocorrência de falhas em programas, assim
como apresentaremos alguns casos de códigos que foram lançados com inúmeras
falhas que ajudaram a contribuir para a evolução da testagem.
ETAPAS DA TESTAGEM DE SOFTWARES
Primeiramente, de�niremos o que é um teste de software para, depois, estudarmos
as etapas da testagem. Dias Neto (2016, p. 1) de�ne teste de software:
Já Polo (2020, p. 7) de�ne que “testes de softwares têm a �nalidade de assegurar que
um programa atende às necessidades dos seus usuários, como também servem para
descobrir defeitos em seu funcionamento antes de disponibilizá-lo para uso”.
Baseado nestas de�nições, temos que distinguir defeito de engano e de falha.
Delamaro, Maldonado e Jino (2016, p. 2) de�nem defeito (do inglês, fault) como “sendo
um passo, processo ou de�nição de dados incorretos”, e engano (do inglês, mistake)
como “a ação humana que produz um defeito”. Para que estes erros aconteçam, o
software não precisa estar sendo executado, por isso, estes erros são chamados de
estáticos. Quando executamos o programa, este defeito ou engano pode ocasionar
um erro (do inglês, error), “que se caracteriza por um estado inconsistente ou
inesperado. Este estado pode levar a uma falha (failure)”, que é um resultado
diferente daquele que queríamos, portanto a falha é uma saída do software que não
deveria existir. É claro que todos estes termos são usados, muitas vezes, como
sinônimos junto à palavra bug, mas devemos tentar entendê-los da forma correta.
Resumidamente, temos o Quadro 1 para �xarmos melhor estes conceitos:
Quadro 1 | Conceitos de erro, defeito e falha
Videoaula: História da testagem de softwares
Para visualizar o objeto, acesse seu material digital.
Processo de execução de um produto para determinar se ele atingiu
suas especi�cações e funcionou corretamente no ambiente para o
qual foi projeto. O seu objetivo é revelar falhas em um produto, para
que as causas dessas falhas sejam identi�cadas e possam ser
corrigidas pela equipe de desenvolvimento antes da entrega �nal.
Imprimir
Programador comete um erro –
sem querer – digitando um código
errado ou entendendo uma
informação de maneira errada.
Fonte: Pixabay.
Surge um
defeito no
software que
pode ser
executado ou
não.
Fonte: Pixabay.
Quando o defeito é
executado e o software
responde de uma maneira
incorreta, surge uma
falha.
Fonte: Pixabay.
Fonte: Lorem ipsum dolor sit amet.
Para descobrirmos todos estes problemas de programação, devemos conhecer as
etapas da realização dos testes de softwares. Estas etapas são divididas,
prioritariamente, em quatro categorias, que são:
•  Unidade.
•  Integração.
•  Sistema.
•  Manutenção.
Como o próprio nome diz, o teste de unidade é feito na menor unidade de
programação de um código, geralmente dado por uma rotina, como um if/else, um for
ou um loop. Quando estamos escrevendo um código, devemos testá-lo ao
terminarmos uma unidade,para que possamos encontrar erros nos algoritmos ou
nas estruturas de dados e até mesmo na codi�cação em si. Delamaro, Maldonado e
Jino (2016, p. 3) relatam que os testes de unidade podem ser feitos em “funções,
procedimentos, métodos ou classes com o objetivo de identi�car erros relacionados a
algoritmos, estruturas de dados incorretas ou simples erros de programação”.
Já o teste de integração testa diferentes unidades, podendo ser de�nida uma rotina
de testagem a cada incorporação de uma nova unidade ou a cada número �xo de
unidades incorporadas, dependendo do tamanho do código. Este teste garante que as
unidades funcionem de forma coordenada e em conjunto.
Até aqui, os testes de software que envolvem os testes de unidade e de integração
são, geralmente, feitos pelos próprios programadores, à medida que criam o código,
para terem certeza de que ele está sendo desenvolvido de forma correta e integrada. 
O teste de sistema, além de testar o código como um todo e sua funcionalidade,
também testa outros aspectos, como segurança, performance e robustez.
Normalmente, ele é seguido de um teste de aceitação do programa pelo cliente. 
Finalmente, quando o produto estiver em fase de produção, devem ser feitos testes
de manutenção, também chamados de testes de regressão, para se certi�car de que o
programa está funcionando corretamente, que ainda é seguro contra o ataque de
hackers e que as novas funcionalidades (atualizações) foram incorporadas de maneira
correta. 
Para que estas divisões na testagem de softwares ocorram de maneira assertiva, ou
seja, que os erros de programação ou de código sejam realmente identi�cados,
precisa-se realizar um bom planejamento, projeto, execução e análise de dados em
cada fase da testagem dos softwares. Não seria lógico que a mesma equipe que
desenvolveu o código realizasse a testagem do software, pois o objetivo de um bom
teste é encontrar erros, e não aprovar um código que acabou de ser criado. Muitas
equipes se sentem ofendidas quando apontamos erros em seus códigos, o que nunca
deve ser feito. Devemos nos lembrar que erros são da nossa natureza, e só erra quem
trabalha no melhor programa.
VIDEOAULA: ETAPAS DA TESTAGEM DE SOFTWARES 
Neste vídeo, estudaremos a diferença entre erro, defeito e falha, assim como
perceberemos que os bugs que estão presentes nos códigos são feitos por humanos.
Os programadores devem executar testes unitários e de integração. Depois, o setor
da qualidade fará o teste de sistema e o aceite do cliente.
OS REQUISITOS E AS VANTAGENS DE SE REALIZAREM TESTES EM
TI
A pior forma de realizarmos um teste de software é tentar testar o código atrás de
todos os defeitos de uma só vez. Para que a procura por defeitos seja feita de maneira
racional e viável, a testagem de softwares foi dividida em etapas. As principais etapas
da testagem de softwares são: testes de unidade, de integração, de sistema e de
manutenção.
Para que estes testes funcionem de maneira correta, precisamos que cada uma
destas etapas seja elaborada de acordo com a seguinte divisão de tarefas:
•  Planejamento.
•  Projeto.
•  Execução.
•  Análise de resultados.
Estas etapas podem ser resumidas no anagrama PDCA, ilustrado na Figura 2, que
retrata o Plan – Do – Check – Action, ou seja, planeje, aja, cheque e recomece
novamente.
Figura 2 | Ciclo PDCA
Videoaula: Etapas da testagem de softwares
Para visualizar o objeto, acesse seu material digital.
Fonte: Wikimedia Commons.
O cumprimento correto de todas estas tarefas garantirá que cada fase do teste foi
corretamente executada e que teremos um software, programa ou aplicativo
funcionando da forma correta. O planejamento é a parte do projeto que de�nirá os
recursos envolvidos na elaboração do código, o tempo que a equipe terá para realizar
esta atividade, considerando, inclusive, que, conforme um código está sendo criado,
ele deve ser testado através do teste de unidade. 
Já o projeto de�nirá como será feita cada etapa da testagem, com enfoque redobrado
nos testes de integração e de sistema, quais os dados �ctícios ou reais que serão
utilizados no teste, quanto tempo este processo demorará e quais os equipamentos e
recursos necessários que serão alocados para a execução dos testes propriamente
ditos.
A execução deve ser feita da forma mais abrangente possível, sempre pensando na
testagem do que queremos e do que não queremos. Por exemplo, imaginaremos que
estamos criando um programa de pontos para presentear nossos clientes mais �éis.
Queremos identi�car quais são estes clientes e pontuá-los, mas não queremos que os
clientes possam resgatar seus pontos duas vezes, ou que clientes com baixo número
de pontos consigam resgatar itens aos quais não poderiam ter acesso. 
Depois de executados todos os testes, inclusive a situação que o programa deve
recusar os pedidos dos usuários, devemos realizar a checagem dos resultados, com a
análise dos dados e dos problemas encontrados. Esta etapa deve ser acompanhada
pela equipe de qualidade ou pelo engenheiro de testes, porque ela deve apontar o
que deve ser alterado no código, os responsáveis por executar estas correções e,
depois, devemos realizar o teste novamente destas partes do código para que os
erros não se repitam.
Esta etapa deve ser feita com muito cuidado, porque, geralmente, não testamos o que
estava funcionando e corremos o risco de, ao corrigir os erros no código, introduzir
outros erros que nos fazem voltar à parte de erros de integração do software, ou seja,
ao mudarmos uma parte especí�ca do código, esta alteração fará com que ele não
funcione mais de forma integrada com as outras tarefas. Para isso, deve ser sempre
testada a função que foi alterada em conjunto com uma integração posterior do
código. 
Aqui, é importante conhecer dois caminhos possíveis para os testes de software:
•  Os testes caixa-preta.
•  Os testes caixa-branca.
O teste caixa-preta trata o código como algo fechado, pronto e sem que seja possível
acessá-lo e mudá-lo. Neste tipo de teste, são testadas todas as funcionalidades do
programa, o que realmente queremos que aconteça, os desejos do cliente.
Figura 3 | Teste caixa-preta
Fonte: Wikimedia Commons.
Já o teste caixa-branca trata do código, da sua estrutura e das suas con�gurações.
Durante este tipo de teste, conseguimos acessar e corrigir o código. Nas fases de teste
de integração e de unidade, o time de desenvolvimento deve realizar testes caixa-
branca, e na fase de sistema e do aceite do cliente, testes caixa-preta, ou seja, deve
ser veri�cado se o programa desenvolvido realmente entregou aquilo que o cliente
contratou.
Deste modo, podemos garantir que o cliente realmente �que satisfeito com o seu
pedido e que o programa foi desenvolvido dentro de rigorosas técnicas que garantam
não só a qualidade mas também a otimização dos recursos de processamento e de
armazenamento que serão utilizados pelo código que ajudamos a desenvolver.
VIDEOAULA: OS REQUISITOS E AS VANTAGENS DE SE
REALIZAREM TESTES EM TI
Neste bloco, ressaltaremos a importância de realização dos testes de software
atendendo aos requisitos do PDCA, ou seja, cada etapa deve ser planejada, projetada,
executada e avaliada visando à adoção da otimização do código. Conheceremos
também as técnicas caixa-preta e caixa-branca, para sabermos diferenciar estes tipos
de testes.
ESTUDO DE CASO
Imagine que você trabalha em uma empresa desenvolvedora de softwares e
aplicativos para celulares e foi promovido, graças ao seu excelente trabalho no
desenvolvimento de programas para o setor de qualidade e testagem de softwares,
que vem enfrentando muitos contratempos quanto à demora na realização dos testes
e na interpretação dos resultados. Um simples teste pode demorar mais de uma
semana para ser executado devido aos computadores serem mais antigos do que o
Videoaula: Os requisitos e as vantagens de se realizarem testes em TI
Para visualizar o objeto, acesse seu material digital.
do setor de desenvolvimentoe de não existir uma padronização no setor de testagem,
pois o programa de qualidade da empresa ainda não chegou a este setor, o que faz
com que os testes não detectem todos os bugs de programação existentes. 
O seu supervisor pediu para você elaborar um relatório apontando três causas na
demora da realização dos testes e três propostas de melhorias ao setor para que este
problema seja sanado, sendo que ele te deu carta branca para diagnosticar o que
precisa ser feito para que o setor tenha bons resultados na testagem dos produtos e
realize o trabalho em um prazo menor do que o que eles estão conseguindo entregar.
RESOLUÇÃO DO ESTUDO DE CASO
Como um pro�ssional aplicado, você organizou um roteiro de veri�cação para apontar
os possíveis problemas que estão causando atrasos na execução da testagem dos
programas, começando pela veri�cação dos equipamentos que o setor está utilizando
para a testagem dos programas desenvolvidos pela equipe de develop. Nesta etapa,
você veri�cou se os equipamentos utilizados para a testagem dos códigos são
adequados, ou seja, iguais aos utilizados pelas equipes de desenvolvimento, e
constatou que eles são obsoletos. Os equipamentos da equipe de testagem devem ter
a mesma capacidade de processamento daqueles utilizados pela equipe de
desenvolvimento, pois somente assim podemos garantir que os testes serão feitos em
um tempo razoável. Depois de concluída esta etapa, você deve veri�car se a empresa
utiliza softwares para automatizar o processo da testagem, pois, se o processo inteiro
de testagem for feito de forma manual, ele pode demorar mesmo muito tempo sem a
obtenção de resultados satisfatórios. Finalmente, você se certi�cará se a empresa
segue as normas internacionais desenvolvidas pela IEEE, para que o processo de
qualidade seja e�ciente e de alto nível. Deste modo, você poderá garantir que todos
os colaboradores que trabalhem no departamento de teste de software sigam as
mesmas rotinas de testagem, com os mesmos procedimentos, da mesma forma que
você garantirá que os resultados da testagem sejam interpretados através da mesma
métrica utilizada por todos e estabelecidas de acordo com as melhores práticas de
testagem. Caso alguma destas etapas não esteja sendo seguida, você deve elaborar
um cronograma de adequação do setor para que a etapa seja implementada e
seguida à risca, pois somente com a adoção destas três metodologias é que você
poderá garantir um setor de testagem de software com qualidade e e�ciência.
 Saiba mais
O Capítulo 1 do livro Introdução ao Teste de Software nos mostra claramente as
di�culdades na realização de testes de softwares através de um comando simples,
como elevar um número x a um expoente y que seja maior do que zero. Somente
para executar este teste, teríamos que realizar mais de 1 milhão de operações.
Felizmente, o capítulo também descreve como podemos ultrapassar este
obstáculo, testando exatamente se o programa fornecerá uma mensagem de erro
para exponentes y inferiores a 0 e para um exemplo válido qualquer. Ao término
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
da leitura, você constatará que a testagem de softwares possui inúmeros
obstáculos para ser realizada, mas que, através de técnicas padronizadas, a
superação destes problemas será feita de forma tranquila e e�ciente. Disponível
na Biblioteca Virtual da Kroton através do link:
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubc�/6
/14%5B%3Bvnd.vst.idref%3Dchapter1.xhtml%5D!/4. Acesso em: 4 set. 2021.
O artigo intitulado A Importância dos Testes Automatizados, de Bernardo e Kon,
expõe algumas das di�culdades encontradas na realização da testagem de
softwares por muitas empresas brasileiras que seguem a metodologia tradicional
da elaboração de um software e propõe algumas dicas para que este mesmo
processo possa ser feito através da automação dos testes, utilizando programas
gratuitos que realizam o trabalho de testar algumas etapas do código, como o
teste de estabilidade do sistema ao acesso de muitos usuários à plataforma, que
são impossíveis de serem testados manualmente. Disponível em:
http://ccsl.ime.usp.br/agilcoop/�les/A%20Importancia%20dos%20Testes%20Auto
matizados.pdf. Acesso em: 4 set. 2021.
No vídeo Teste de Software, podemos ter uma ideia clara do que faz um
engenheiro de testes e das etapas de testagem de programas, com a descrição
das pessoas envolvidas. Apesar de o áudio ser um pouco ruim devido às batidas
do apresentador no microfone, as explicações são claras e concisas sobre o
processo de testagem de software. Disponível em
https://www.youtube.com/watch?v=DBw_GctgPqU. Acesso em: 4 set. 2021.
No artigo Introdução a Teste de Software, Arilo Dias Neto traz uma abordagem
bem didática dos principais tipos de testes de software que temos e das
di�culdades que encontraremos para que o programa desenvolvido �que de
acordo com a vontade do cliente. Para ilustrar este desencontro, ele usa a clássica
�gura do balanço feito com um pneu e amarrado a uma árvore como sendo a
vontade do cliente e as soluções oferecidas de vários modelos de escada pela
equipe de desenvolvimento, que logicamente não funcionam nem atendem à
vontade do cliente. Disponível em:
https://edisciplinas.usp.br/plugin�le.php/3503764/mod_resource/content/3/Introd
ucao_a_Teste_de_Software.pdf. Acesso em: 6 set. 2021.
INTRODUÇÃO
Aula 2
SISTEMAS DA QUALIDADE: DEFINIÇÃO E
IMPORTÂNCIA NA TESTAGEM
Qualidade na elaboração de um procedimento de teste e requisitos aplicáveis.
50 minutos
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/14%5B%3Bvnd.vst.idref%3Dchapter1.xhtml%5D!/4
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/14%5B%3Bvnd.vst.idref%3Dchapter1.xhtml%5D!/4
http://ccsl.ime.usp.br/agilcoop/files/A%20Importancia%20dos%20Testes%20Automatizados.pdf
http://ccsl.ime.usp.br/agilcoop/files/A%20Importancia%20dos%20Testes%20Automatizados.pdf
https://www.youtube.com/watch?v=DBw_GctgPqU
https://edisciplinas.usp.br/pluginfile.php/3503764/mod_resource/content/3/Introducao_a_Teste_de_Software.pdf
https://edisciplinas.usp.br/pluginfile.php/3503764/mod_resource/content/3/Introducao_a_Teste_de_Software.pdf
Boas-vindas ao estudo da disciplina Qualidade e Automação de Testes. Nesta unidade,
vamos nos aprofundar no estudo dos sistemas da qualidade que são utilizados na
testagem de softwares, principalmente, no TMMi, de�nição de Modelo de Maturidade
de Teste. Este modelo estabelece os requisitos em que os testes devem ser
elaborados para que sejam feitos com qualidade e apresentem, além de um resultado
satisfatório, um desempenho otimizado dos sistemas e recursos utilizados para que o
software funcione de maneira adequada. Finalmente, estudaremos também alguns
softwares e aplicações para realizarmos testes de forma automatizada, recurso este
muito necessário para uma ampla testagem do programa ou software a ser
desenvolvido e muito valorizado no mercado de trabalho. Testes automatizados feitos
por plataformas, além de con�áveis, podem simular algumas situações impossíveis de
serem feitas através de um teste manual: como o acesso simultâneo de vários
usuários a um site, tentativa de invasão por hackers, criação de diferentes usuários e
per�s de acesso. Assim, você poderá programar uma outra parte do código ou até
mesmo um outro programa enquanto testa aquela parte que já foi feita. Dessa forma,
você se tornará um pro�ssional multitarefas. 
QUALIDADE NA ELABORAÇÃO DE UM PROCEDIMENTO DE TESTE
E REQUISITOS APLICÁVEIS
A qualidade do software, de acordo com Zanin et al. (2018, p. 11), pode ser de�nida “
de acordo com o quanto o software está em conformidade com o que o cliente
solicitou”. Esta de�nição vai ao encontro da regra 10 de Myers, que diz que “o custo de
se encontrar um defeito no sistema aumenta 10 vezes a cada etapa do processo em
que esse erro avançar”.
Figura 1 | Regra 10 de Myers
Fonte: Zaninet al. (2018, p. 16).
Uma de�nição de qualidade mais ampla é dada por Pressman (2021, p. 311) como
sendo uma combinação de fatores entre “produto compatível + boa qualidade +
entrega dentro do orçamento e do prazo previsto é igual à satisfação do usuário”. Um
software que tenha uma excelente qualidade com um alto custo não é melhor que um
de uma qualidade um pouco inferior, permanecendo dentro do orçamento. O grande
problema é que os testes de software são caros para serem feitos com todos os
cenários possíveis e, muitas vezes, justo um cenário não testado é o que apresentará
uma falha.
Os custos da qualidade devem ser avaliados quanto à prevenção de defeitos e à
avaliação do software. Devemos investir tempo tanto testando o código à medida que
o programamos quanto estabelecendo procedimentos para que a programação seja
feita de uma forma correta já na primeira vez. Um estudo do IEEE demonstrou que o
custo médio para corrigirmos um erro durante a etapa de elaboração do código é de,
aproximadamente, US$ 977 por erro. Agora, para se corrigir este mesmo erro durante
a fase de testes de sistema ,este custo se eleva para US$ 7.136 (CIGITAL, 2007).
Existem dois sistemas considerados como iniciadores do processo de qualidade de
software que temos hoje. O primeiro é conhecido como o triângulo de McCall. De
acordo com Pressman (2021, p. 313), podemos dividir este triângulo em três fases:
• Revisão do produto: nesta fase, são feitos os testes de software e de �exibilidade.
• Transição do produto: nesta fase, é comprovado que o software possui
interoperabilidade, reusabilidade e portabilidade.
• Operação do produto: aqui, são feitas as correções para garantir a con�abilidade e
a integridade do software, assim como é medida sua e�ciência real.
Figura 2 | Fatores de qualidade de software de McCall
Fonte: Pressman (2021, p. 313).
O segundo sistema foi adotado pela HP (Hewlett-Packard Enterprise) e é conhecido
pela sigla FURPS, do inglês Funcionality, Usability, Reability, Performance and
Supportability. O software deve funcionar para ser utilizado segundo as especi�cações
do cliente, ser reabilitado caso alguma atualização não funcione direito, ter a
performance desejada pelo cliente e a arquitetura prevista para aquela aplicação e
suportar o uso do sistema por diferentes usuários de forma simultânea.
Existem vários softwares que podem nos auxiliar no gerenciamento da qualidade. Um
deles é o SonarQube®, plataforma de código aberto, cujo download pode ser feito de
forma gratuita através do link: https://www.sonarqube.org/downloads/. Este
programa permite que o código seja inspecionado à medida que é criado, sendo que
ele consegue, através de métricas pré-estabelecidas, medir a qualidade do código a
partir de sete eixos, a saber:
• Arquitetura de Projeto.
https://www.sonarqube.org/downloads/
• Comentários.
• Padrão de Codi�cação.
• Defeitos Potenciais.
• Complexidade.
• Testes de Unidade.
• Duplicações.
Este software é um pouco complicado para ser instalado (a testagem não foi feita de
forma e�ciente, pois ele apresenta alguns erros que precisamos corrigir para que sua
instalação seja feita com sucesso). Primeiramente, devemos selecionar a opção
Community (Comunidade) no site https://www.sonarqube.org/downloads/. Essa opção
nos levará para a página https://www.sonarqube.org/success-download-community-
edition/, na qual o download começará automaticamente. O arquivo baixado será em
formato zip (compactado), chamado sonarqube-9.0.1.46107. Para que ele possa ser
instalado no nosso computador, precisaremos ter a versão 11 do Java. Este arquivo
pode ser baixado em https://www.oracle.com/java/technologies/downloads/#java11.
O nome dele é Java SE Development Kit 11.0.12 (esta escolha, caro aluno, foi feita para
o sistema operacional Windows de 64 bits; caso possua outro sistema operacional no
seu computador, você deverá ajustar o Java versão 11 para os sistemas Linux ou Mac).
O arquivo baixado será o jdk-11.0.12_windows-x64_bin. Para baixá-lo, é necessário
que você faça um cadastro na Oracle® e con�rme o e-mail enviado por este
provedor. Depois de instalar o Java na sua máquina, é necessário que você copie o
endereço deste arquivo Java. No caso da minha máquina, foi o caminho C:\Program
Files\Java\jdk-11.0.12. Feito esse procedimento, você precisa alterar o arquivo
chamado wrapper.conf pertencente ao arquivo descompactado do SonarQube. Para
isso, acesse o arquivo wrapper com o editor Bloco de Notas, coloque o símbolo #
(comentário) na linha wrapper.java.command=java e retire este símbolo da linha
acima, inserindo o caminho do Java versão 11 depois do sinal de igual. Depois disso,
ainda precisamos digitar a frase “\java” depois de bin. Feito isso, salvamos o arquivo
wrapper.
A Figura 3 ilustra como �cará o arquivo wrapper depois dessa modi�cação.
Figura 3 | Arquivo wrapper do software SonarQube modi�cado
Fonte: elaborada pela autora.
Agora, basta que executemos como administrador o item StartSonar dentro da pasta
referente ao seu sistema operacional (no meu caso, o Windows de 64 bits). A
localização deste arquivo está ilustrada na Figura 4.
Figura 4 | Arquivo StartSonar.bat
https://www.sonarqube.org/downloads/
https://www.sonarqube.org/success-download-community-edition/
https://www.sonarqube.org/success-download-community-edition/
https://www.oracle.com/java/technologies/downloads/#java11
Fonte: captura de tela.
Quando o software estiver instalado, aparecerá uma mensagem de Process[es] is up
no prompt de comando. Depois disso, no seu programa de acesso à internet (no caso,
eu utilizo o Google Chrome), basta que você digite o link https://localhosts.mobi/9000
e acesse o ícone open hppt://localhost:9000 para acessar o software, conforme ilustra
a Figura 5.
Figura 5 | Acesso à pasta da internet localhost: 9000
Fonte: https://localhosts.mobi/9000. Acesso em: 22 fev. 2022.
Os dados de login e senha para abertura do programa são: admin (na primeira vez, o
próprio site pedirá para você alterar a senha). Depois de todo este processo, o site
será aberto e possuirá a con�guração inicial retratada na Figura 6.
Figura 6 | Página inicial do software SonarQube
Fonte: https://localhosts.mobi/9000. Acesso em: 22 fev. 2022.
Agora, é só começar a usar esta ferramenta e bom trabalho!
VIDEOAULA: QUALIDADE NA ELABORAÇÃO DE UM
PROCEDIMENTO DE TESTE E REQUISITOS APLICÁVEIS
Abordaremos as principais de�nições de qualidade e o software SonarQube, utilizado
na testagem automática. É dado o passo a passo com dicas para a sua instalação bem-
sucedida, visto que este software vem com alguns bugs e necessita do Java na versão
11 instalado na máquina para funcionar corretamente.
https://localhosts.mobi/9000
OS CUSTOS DA IMPLEMENTAÇÃO DE UM PROGRAMA DE
QUALIDADE TMMI
O TMMi (Test Maturity Model Integration – Integração do Modelo de Maturidade de
Teste) possui cinco níveis de maturidade. A cada nível de maturidade que uma
organização ultrapassa, seu processo de testagem torna-se melhor e mais otimizado.
As indústrias que contratam empresas de desenvolvimento de softwares que
possuem TMMi nível 5 têm a garantia de que seu programa será desenvolvido dentro
das melhores práticas do mercado. Os cinco níveis do TMMi são:
Nível 1: este é o nível inicial de uma empresa que não adota o programa TMMi. Neste
nível, os testes de software não seguem nenhuma sequência padronizada e são feitos
de forma aleatória, caso sejam realmente feitos. A partir da decisão de se adotar o
TMMi, a empresa passa a possuir o nível 2.
Nível 2: este nível é conhecido como nível gerenciado. Nele, é fundamental que uma
empresa tenha:
• Uma política e estratégia de teste.
• Um planejamento de teste.
• Um monitoramento e controle dos testes.
• Um projeto para a execução de cada teste.
• Um ambiente de testagem especí�co.
Aqui, a empresa tomou a decisão de testar todos os códigos de uma forma
padronizada, de quanti�car os resultados e adotar procedimentos para incorporarà
correção dos erros de forma de�nida, com atribuições de tarefas fazendo com que o
pessoal de desenvolvimento e de testagem comecem a trabalhar juntos. Como os
procedimentos e padrões de testagem são iniciais neste nível, alguns erros podem
não ser detectados, como estes documentos podem sofrer revisão em busca de uma
versão que realmente funcione.
Nível 3: é chamado de de�nido e é composto por
• Uma organização do processo de testagem.
• Um programa de treinamento para os desenvolvedores e engenheiros de testes.
• Acompanhamento do ciclo de vida e integração dos softwares desenvolvidos.
• Testes não funcionais.
• Revisão por pares.
Neste nível, os testes estão integrados à cultura da empresa, e a cultura de testagem
de softwares já está consolidada na empresa como uma importante etapa no
desenvolvimento de um programa. Além do mais, a cultura de que o teste de software
é feito para encontrar defeitos, erros, e não a ausência deles, sem apontar culpados, é
prática recorrente na empresa, assim como o feedback dos erros encontrados e o
Videoaula: Qualidade na elaboração de um procedimento de teste e requisitos aplicáveis
Para visualizar o objeto, acesse seu material digital.
acompanhamento do processo de correção e retirada destes mesmos bugs. Aqui, a
documentação já pode ser usada como uma ferramenta e�caz no processo de
testagem dos softwares.
Nível 4: é chamado de Gerenciado Quantitativamente e é de�nido pela presença
de:
• Medição constante dos testes realizados.
• Avaliação da qualidade de softwares desenvolvidos.
• Revisão por pares avançada.
Nesta fase, os procedimentos já estão consolidados dentro das melhores práticas
realizadas através de métricas acompanhadas constantemente para a localização de
defeitos com porcentagens de erros mais comuns, localização destes erros, tempo
que levaram para serem solucionados e disseminação destes cases na empresa. Os
setores de vendas e de manutenção do software começam a participar de reuniões,
nas quais são explanados os cases de erros, as soluções encontradas e as normas que
foram melhoradas para que estes erros não se repitam. Os dados estatísticos já
alimentam um banco de dados considerável para que o processo seja acompanhado
de perto por todo o pessoal da empresa.
Nível 5: é chamado de otimizado e composto por:
• Prevenção de defeitos.
• Otimização do processo de teste.
• Controle de qualidade.
Aqui, a empresa já incorporou, além de todas as técnicas do TMMi, as técnicas das
Metodologias Ágeis, para minimizar o tempo de programação e testagem. A
automação de testes é parte da cultura da empresa, e rotinas padronizadas, tanto de
programação como de testagem, já estão consolidadas e são largamente utilizadas
pelo departamento de desenvolvimento de programas, que trabalha integrado ao
departamento de vendas e manutenção dos softwares. Existe um departamento de
testagem de software e controle de qualidade que trabalha em conjunto com os
demais setores da empresa. O processo de melhoria contínua e a troca de
conhecimento entre os pro�ssionais é feita de maneira automática, permitindo que o
ambiente da empresa seja leve e focado em resultados.
VIDEOAULA: OS CUSTOS DA IMPLEMENTAÇÃO DE UM
PROGRAMA DE QUALIDADE TMMI
Apresentamos os cinco níveis do TMMi e o que os diferencia e os caracteriza, com
uma explicação sobre cada etapa de cada nível. Depois, de�nimos que o teste é
realizado para se encontrar erros, e não para provar que um programa foi feito isento
deles.
Videoaula: Os custos da implementação de um programa de qualidade TMMi
Para visualizar o objeto, acesse seu material digital.
DIFERENTES FORMAS DE TESTAGEM
Pressman (2016, p. 466) de�ne teste como um “conjunto de atividades que podem ser
planejadas com antecedência e executadas sistematicamente”. Adotar uma forma de
testagem correta para cada aplicação faz com que economizemos tempo, e tempo é
dinheiro. Uma das formas de testagem mais comuns é chamada de Veri�cação e
Validação, e é conhecida pela sigla V & V. Pressman (2016, p. 467) também de�ne a
veri�cação como “um conjunto de tarefas que garantem que o software implemente
corretamente uma função especí�ca. Validação refere-se a um conjunto de tarefas
que assegurem que o software foi criado e pode ser rastreado segundo os requisitos
do cliente”.
O primeiro teste, conhecido como teste unitário, deve ser feito ao longo do
desenvolvimento do código. É claro que é inviável testarmos o código a cada linha de
programa que desenvolvemos, mas devemos fazer isso, pelo menos, a cada sequência
de comando criada e nas fronteiras destas sequências. É mais fácil e não exige tanto
recurso computacional testar um bloco de código assim que ele é feito. Por exemplo,
criamos uma sequência loop para repetir um comando três vezes, ou incrementamos
a variável x de 1 unidade, então testamos estes comandos. Podemos também testar
blocos de comando e deixá-los salvos na nossa máquina para que os utilizemos na
elaboração do código quando precisarmos destes comandos especí�cos. 
Nesta fase, é muito importante que testes com resultado de erro também sejam
avaliados. Por exemplo, se criamos um código para veri�car se um número é par e
maior que zero, temos que testar este mesmo código com números ímpares e
negativos. Somente assim teremos a certeza de que esta parte do código não
apresentará defeitos e não aceitará os números ímpares e zero como entradas
válidas. 
Depois, devemos testar um conjunto de códigos, o chamado teste de integração, para
veri�carmos que todos os atributos solicitados pelo cliente estão presentes no código,
como exemplo, podemos testar se foi feito cadastro dos usuários da forma correta,
com suas respectivas permissões de acesso e modi�cação ao código. Até esta etapa,
as boas práticas da qualidade garantem que a elaboração do software e sua testagem
sejam realizadas pela equipe responsável pelo desenvolvimento do código. Eles
devem testar, anotar e corrigir os erros de programação encontrados de maneira
e�caz e con�ável.
Quando algumas partes do código estiverem prontas, devemos realizar os testes de
integração, que devem ser feitos por equipes ou colaboradores diferentes
(geralmente, do setor da qualidade), porque não é correto que quem fez o projeto
tenha que testá-lo, já que, inconscientemente, temos a tendência de proteger nossas
criações, de não querermos ver seus defeitos. Neste momento, um setor de testagem
independente terá uma visão mais clara do código. Entretanto, este teste só
funcionará de maneira e�caz se os desenvolvedores passarem todas as informações
para o pessoal da qualidade, se houver um brie�ng e�caz do desejo e das
considerações feitas pelo cliente, porque é impossível para uma equipe aprender tudo
sobre um código em poucas semanas, face à outra equipe, que levou meses
trabalhando naquele código, conhecendo as especi�cações e os desejos do cliente. 
Podemos resumir este processo como se fosse uma espiral, partindo do menor teste
para o maior, conforme nos mostra a Figura 7.
Figura 7 | Espiral da testagem de software
Fonte: Pressman (2016 p. 375).
Na fase de validação, ou seja, na fase de testagem, se o software está de acordo com
as características do cliente, é demonstrado que o código satisfaz ao que foi solicitado
quanto à funcionalidade, ao desempenho e aos requisitos operacionais. Nesta fase,
podemos a�rmar que o teste de software foi encerrado e, agora, a função da
testagem é transferida ao usuário do programa. Isso signi�ca que aquele código será
exposto a inúmeras situações. É importante a escolha de um time de suporte ao
usuário que possa registrar estatisticamente os defeitos apresentados durante a
utilização do software ou do programa, as medidas propostas para correção para se
determinar quando é o melhor momento para lançarmos uma atualização do
programa ou um upgrade daquele código. Somente assim podemos garantir que o
programa ou o software permaneça constantemente atualizado ou apto a atenderde
forma e�caz ao cliente.
VIDEOAULA: DIFERENTES FORMAS DE TESTAGEM
Discutimos as etapas de veri�cação e validação, nas quais são feitos os testes de
unidade e de integração pela equipe de desenvolvimento do código. Abordamos a
importância de um setor de testes de softwares separado para realizar a testagem do
sistema geral e obter o aceite junto ao cliente.
ESTUDO DE CASO
Como vimos no Bloco 1 desta unidade, alguns programas são disponibilizados para o
usuário com erros, como foi o caso do SonarQube, do próprio Windows, ou de um
banco que bloqueou todas as contas dos seus clientes após uma atualização do
software. Considere que você foi recém-contratado como Gerente de Qualidade pelo
setor de qualidade da empresa fabricante do SonarQube, e sabe que a versão
Community deste software está apresentando erro de Java, deixando os usuários
bravos, fazendo com que eles reclamem no setor de atendimento ao cliente; Além
Videoaula: Diferentes formas de testagem
Para visualizar o objeto, acesse seu material digital.
disso, diversos vídeos feitos por pro�ssionais do mercado retratam o software de uma
maneira pejorativa. Quais providências você deveria adotar para que este tipo de erro
não fosse mais encontrado no software?
RESOLUÇÃO DO ESTUDO DE CASO
Como gerente da qualidade da empresa SonarQube, você deveria, primeiro,
disponibilizar uma nova versão do software com a correção do erro e informar ao
usuário que a versão em uso necessita da instalação do Java 11, inserindo
imediatamente um link para o programa instalador desta versão do Java na máquina
do usuário. Depois de feito o link, você deverá gravar um vídeo pedindo desculpas
pelo erro, realizando o procedimento de instalação, com o passo a passo em todos os
idiomas dos países que baixem este software de maneira maciça, ou seja, em inglês,
chinês e espanhol, pelo menos.
Depois disso, você teria que reunir a equipe de desenvolvimento para atualizar o
software, fazendo com que seja disponibilizada para o usuário uma nova versão do
software já com o Java 11 incorporado ao programa, ou que ele tente reconhecer a
versão do Java instalada no computador do usuário e informe, no momento da sua
instalação, que o usuário deverá baixar a versão do Java nº 11, disponibilizando um
link com o passo a passo para este download. Sua equipe deverá também veri�car a
possibilidade de refazer o software para, ao invés de baixar uma versão compacta
dele, ou seja, zipado, possa ser baixada uma versão .exe, para facilitar a instalação do
software pelo usuário leigo.
Finalmente, você deverá solicitar aos desenvolvedores que veri�quem a possibilidade
de a plataforma disponibilizar uma versão on-line do programa, já que ele utiliza uma
página da internet e um host para funcionar.
Para terminar, você deve determinar a revisão imediata do procedimento de testagem
para incluir testes com versões diferentes do software Java, para que se veri�que a
funcionalidade ou não dos programas com esta plataforma.
 Saiba mais
O livro Engenharia de Software, escrito por Pressman e Maxim, dedica o Capítulo
15, chamado de Conceitos de Qualidade, ao aprofundamento do entendimento
do aluno em relação aos principais tópicos da qualidade de software. Disponível
na Biblioteca Virtual da Kroton através do link:
https://integrada.minhabiblioteca.com.br/reader/books/9786558040118/epubc�/6
/60%5B%3Bvnd.vst.idref%3DC19.xhtml%5D!/4%5BPRESSMAN_Completo-26%5D.
Acesso em: 15 set. 2021. 
O artigo Qualidade, Qualidade de Software e Garantia de Qualidade de Software
são as mesmas coisas, escrito por Fábio Martinho Campos, traz uma análise
profunda sobre o termo “qualidade” (um conceito subjetivo, pois um produto
pode ter qualidade para uma pessoa, e para outra, não. Exemplo disso é a eterna
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
https://integrada.minhabiblioteca.com.br/reader/books/9786558040118/epubcfi/6/60%5B%3Bvnd.vst.idref%3DC19.xhtml%5D!/4%5BPRESSMAN_Completo-26%5D
https://integrada.minhabiblioteca.com.br/reader/books/9786558040118/epubcfi/6/60%5B%3Bvnd.vst.idref%3DC19.xhtml%5D!/4%5BPRESSMAN_Completo-26%5D
briga entre os fãs de celulares Apple e Samsung), com de�nições e citações de
trechos das normas ISO 9000 e do PMBOK, referências na adoção de sistemas de
qualidade e de métricas para se realizar a testagem de softwares. Disponível em:
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-
garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx. Acesso em: 14 set.
2021.
No vídeo feito pela T2Ti, chamado 03 – SonarQube – Download, Instalação e
Execução, é mostrado o passo a passo da instalação do software SonarQube,
desde como devemos fazer o download do software, do Java 11, alterarmos o item
wrapper dentro do software, executarmos o item StartSonar e acessarmos a pasta
da Internet Localhost 9000, até a colocação do login e da senha admin no software
para termos acesso à sua página inicial. Disponível em:
https://www.youtube.com/watch?v=TNEHX51L9Do. Acesso em: 14 set. 2021.
INTRODUÇÃO
Nesta unidade, daremos um maior enfoque às infraestruturas utilizadas para permitir
que o teste unitário e de automação seja efetuado mesmo com o início da
programação de um código, ou seja, com o código sem estar terminado. Isso é feito
através de ferramentas, como stubs e drivers, que auxiliam na criação de per�s
�ctícios para a testagem de comandos do código e das interfaces de integração entre
partes do software. Estudaremos também alguns softwares gratuitos que analisam o
código já em estágio mais avançado de programação através da análise dos grafos
obtidos pelo �uxograma lógico, obtendo os caminhos principais que devem ser
testados, ou seja, aquelas con�gurações que possuem mais chance de apresentar
erros.
PRINCÍPIOS DE TESTES UNITÁRIOS
Devemos considerar os testes unitários como uma ferramenta auxiliar na etapa de
programação. Cada estrutura for, if, loop, equação matemática e condição de
verdadeiro ou falso deve ser testada para veri�car se na hora da programação o
código não foi feito de maneira incorreta. O problema encontrado com esta exigência
é: como testar e elaborar o código sem que um trabalho não comprometa o outro?
Muitas vezes, não temos estrutura su�ciente para testar todas as condições, ou a
Aula 3
DIFERENTES TIPOS DE TESTES
Formular, aplicar e escolher o melhor tipo de teste aplicável a um programa entre
os diferentes tipos de testes disponíveis no mercado. De�nir o melhor protocolo
de comunicação a ser utilizado na testagem.
42 minutos
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
https://www.youtube.com/watch?v=TNEHX51L9Do
testagem de todas as condições demandaria muito tempo. Por exemplo, como
testaremos se um tipo de per�l de usuário só acessa ou modi�ca aquela parte que foi
especi�cada se não temos nenhum usuário cadastrado?
Por isso, nesta parte do código, precisamos criar alguns sca�olding (do inglês
andaime, ou “estruturas temporárias”), para podermos gerar um framework para
realizar este teste. No caso do exemplo citado, precisamos criar usuários “fake”. Neste
momento, precisaremos também criar pseudocontroladores (drivers ou stubs) para
cada parte do texto. De acordo com Pressman e Maxim (2021, p. 379), “um
pseudocontrolador usa a interface dos módulos subordinados, pode fazer uma
manipulação de dados mínima, fornece uma veri�cação de entrada e retorna o
controle para o módulo que está sendo testado”. A Figura 1 retrata a estrutura
periférica que deve ser desenvolvida junto ao código para permitir a testagem ponto a
ponto.
Figura 1 | Ambiente de teste de unidade
Fonte: Pressman e Maxim (2021, p. 379).
É claro que elaborar estas estruturas para apoiar a testagem unitária demanda
dinheiroe, muitas vezes, um tempo in�nito, que o projeto não tem. Por exemplo,
imagine que estamos criando um aplicativo que simule um jogo de xadrez. Um teste
para cada jogada possível em um jogo de xadrez poderia levar milhares de anos para
ser executado. Pensando nisso, foram criadas con�gurações básicas que devem ser
testadas no teste de unidade. A primeira con�guração é que devemos testar o �uxo
de dados por meio de um componente. Um dado deve conseguir entrar em uma
estrutura básica de código para poder ser veri�cado se aquela con�guração foi feita
corretamente. Depois, deve-se testar as fronteiras entre os códigos, ou seja, se um
comando for encerrado, o dado deve passar imediatamente para o próximo
comando. Para isso, são criados caminhos de manipulação de erros. Muitos autores
chamam esta abordagem de antidefeitos. Neste caso, são testados erros em
potencial, como:
•  Descrição confusa do erro.
•  Erro apontado não corresponde ao erro encontrado.
•  Condição de erro não permite acesso ao sistema para sua correção.
•  Procedimento exceção – condição não está gerando um teste válido.
•  Descrição de erro vaga, não permitindo sua localização no código.
Neste momento, devemos realizar o teste do caminho básico (um teste feito nos
principais códigos do software) e o teste da estrutura de controle (um teste feito
seguindo o �uxograma de programação – neste teste, veri�camos as condições falsas
também). Para isso, os desenvolvedores do código devem ter um banco de dados
criado para diferentes níveis de usuários. Se o cliente tiver este banco de dados de
outro aplicativo, ele poderá ser utilizado para tornar este teste mais próximo da
realidade. 
O teste do caminho básico deve executar, pelo menos uma vez, todas as estruturas do
código, e ele é escolhido pelo projetista para as condições verdadeiras, ou seja, o
menor caminho que permite ao usuário chegar ao �nal do programa. Ele utiliza uma
notação de grafos para informar este caminho. Cada círculo é chamado de nó, e cada
losango de ligação pode ser representado por um nó. As arestas ou ligações são os
chamados �uxos de controle e representam as opções que uma tomada de decisão
ou um atendimento a uma condição verdadeira ou falsa podem causar. Uma área de
aresta e nós é chamada de região, conforme pode ser visualizado na Figura 2.
Figura 2 | Representação de um �uxograma de um código (a) e seu respectivo grafo (b)
Fonte: Pressman e Maxim (2021, p. 384).
Alguns dos caminhos para este �uxograma são:
•  Caminho 01: 1 – 11.
•  Caminho 02: 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11.
•  Caminho 03: 1 – 2 – 3 – 6 - 8 – 9 - 10 – 1 – 11.
•  Caminho 04: 1 – 2 – 3 – 6 - 7 – 9 - 10 – 1 – 11.
Um bom exemplo de teste para este código seria testarmos os caminhos 1 e 4. 
Existem várias fórmulas de se calcular quantos caminhos críticos um código possui.
Uma delas é dada através do cálculo da complexidade ciclomática, representada
através da sigla V. Para um grafo de �uxo G, ela é calculada através da fórmula dada
por 
V (G) = E – N + 2    (Equação 1)
Onde:
E é o número de arestas do grafo de �uxo.
N é o número de nós.
Neste caso, teríamos quatro caminhos críticos para serem testados. 
V (G) = 11 arestas – 9 nós + 2 = 4.
Portanto, seriam necessários quatro casos de testes para executar um teste unitário
satisfatório para o �uxograma ilustrado na Figura 2.
VIDEOAULA: PRINCÍPIOS DE TESTES UNITÁRIOS
No Bloco 1, aprenderemos sobre como realizar a análise de um teste unitário
satisfatório para um �uxograma utilizando grafos, através do método matemático
ciclomático para calcular quantas análises deveremos executar. Estudaremos também
os stubs e drivers, ferramentas que fornecerão as condições necessárias para a
realização deste teste.
O TESTE DE AUTOMAÇÃO DOS SISTEMAS
O teste de automação é um teste caixa-preta, focado nas interfaces do sistema. De
acordo com Pressman e Maxim (2021, p. 381), o teste de automação tenta encontrar:
•  Funções incorretas ou ausentes;
•  Erros de interface;
•  Erros em estruturas de dados ou acesso a base de dados externos;
•  Erros de comportamento ou desempenho;
•  Erros de inicialização ou de término.
Para este tipo de teste, é preciso termos estruturas prontas, e não somente o código
de uma só estrutura. Ele precisa procurar erros na transição de uma estrutura para a
outra, ou de uma interface para a outra. Neste tipo de teste, é preciso que se tenha
pelo menos um per�l para cada tipo de usuário previsto, para que seja possível
conferirmos se as permissões de acesso e de modi�cação ao sistema estão corretas
por tipo de usuário. Este teste é chamado de caixa-preta, porque ele não se preocupa
com o código em si (objeto do teste unitário, por isso, chamado também de caixa
branca), e sim com as funcionalidades ou as respostas que o código deve apresentar
para diversas situações reais, por exemplo, se o código está atendendo aos requisitos
básicos solicitados pelo cliente no cadastramento de um novo usuário.
O teste de interface, por exemplo, testa se o código aceita novas informações, como
um novo usuário, e se ele armazena as informações deste novo usuário de forma
adequada. Se estivermos desenvolvendo um jogo, este tipo de teste garantirá que o
novo usuário entre em uma fase fácil, para que ele possa passar rapidamente por
Videoaula: Princípios de testes unitários
Para visualizar o objeto, acesse seu material digital.
várias fases de forma a gostar do jogo. Não teria sentido um novo usuário já ser
alocado em uma fase difícil do jogo, sem conseguir avançar, e desistir daquele
aplicativo só porque foi inserido em uma janela (ponto de início) de forma errônea.
Outro tipo de teste que pode ser aplicado nesta fase é o particionamento de
equivalência, que pode testar se todas as senhas são criadas com caracteres
numéricos, alfanuméricos ou símbolos, como @, $ de uma só vez. Durante a criação
do código, recomenda-se que este tipo de teste já seja feito e se torne um padrão de
testagem na empresa – podendo ser feito até em uma cópia do código original,
quando a parte das senhas e do cadastramento de novos usuários já tenha sido
terminada. Nesta parte, é necessário que se tenha ou se crie um banco de dados, por
exemplo, se estivermos programando um software para um banco, este programa
deve testar se cadastros de CPFs iguais utilizando nomes diferentes serão bloqueados
pelo sistema e se cadastro de nomes iguais com CPFs diferentes e dados, como
�liação, diferentes serão aceitos pelo sistema.
A Análise do Valor Limite (chamada de BVA, por causa do seu nome em inglês,
Boundary Value Analysis) é similar ao teste de equivalência, só que, desta vez, são
testados os valores limites – tanto os inferiores quanto os superiores – para um dado
código. Por exemplo, se estivermos fazendo um aplicativo de cotação de plano de
saúde por faixas etárias, os preços para faixas etárias localizados na fronteira, ou seja,
que levará um usuário a mudar de faixa, devem ser testados. Neste caso, é
recomendado que testemos as fronteiras e um valor acima e um valor abaixo, para
que o funcionamento das interfaces possa ser veri�cado de forma correta
O�cialmente, segundo Pressman e Maxim (2021, p. 389), este postulado diz que “se
uma condição de entrada especi�ca um intervalo limitado por valores a e b, deverão
ser projetados casos de teste com os valores a e b e imediatamente acima e abaixo de
a e b”. Deste modo, todas as interfaces ou valores fronteiriços devem ser testados.
Esta condição é exigida atualmente porque a chance de códigos apresentarem erros
na fronteira é maior do que no meio do intervalo. Deste modo, o teste de integração
obterá resultados satisfatórios na detecção de erros. 
VIDEOAULA: O TESTE DE AUTOMAÇÃO DOS SISTEMAS
No Bloco 2, estudaremos de forma mais detalhada o teste de integração e algumas
maneiras para criação ou incorporação de bancos de dados que serão necessários
para a realização deste tipo de teste. Aprenderemos também a diferenciar um testecaixa-branca (tipo o teste unitário) de um teste caixa-preta.
TESTE PONTO A PONTO E A IMPORTÂNCIA NA
INFRAESTRUTURA
Para conseguirmos realizar o teste ponto a ponto com precisão, temos que criar ou
escolher drivers e stubs de forma correta, pois estes dispositivos darão a
infraestrutura de apoio para que o teste possa ser feito com o objetivo de
Videoaula: O teste de automação dos sistemas
Para visualizar o objeto, acesse seu material digital.
encontrarmos bugs.
O driver possuirá a função de fornecer todos os dados necessários para que
possamos testar uma dada unidade e apresentar os dados de saída para que o
responsável por este teste possa veri�car se ele foi bem-sucedido ou não. Por
exemplo, para o cadastro de um novo usuário mediante um e-mail, este dispositivo
fornecerá um modelo de e-mail válido, para que o programa acuse a digitação correta
e envie um e-mail para o endereço fornecido e espere a con�rmação por parte do
usuário de que este e-mail é gerenciado por uma pessoa, e não um robô.
Já os stubs são ferramentas que auxiliam na simulação de comportamentos para uma
dada unidade que ainda não foi desenvolvida, mas da qual dependemos para que
esta parte do teste ponto a ponto possa ser feita de forma a encontrarmos seus
defeitos. Na Figura 3, temos a representação das de�nições de drivers e stubs.
Figura 3 | Representação de drivers e stubs
Fonte: elaborada pela autora.
A diferença entre o teste de unidade e o teste de integração dos stubs e drivers é que,
no teste de unidade, eles são usados como módulos independentes, ou seja, só
testamos um código em especí�co e, no teste de integração, eles se integram ao teste,
permitindo que conectemos as diferentes partes do código, principalmente, as
fronteiras. Essa diferença está retratada na Figura 4.
Figura 4 | Diferença entre um teste de unidade e um teste de integração
 Fonte: elaborada pela autora.
Existem algumas ferramentas on-line e softwares grátis que podem nos ajudar nestas
etapas de testagem, como as ferramentas JaBUTi (Java Bytecode Understanding and
Testing, disponível em: https://github.com/magsilva/jabuti). Para que o software
JaBUTi funcione, é necessário que, antes, instalemos o programa Graphviz (Disponível
em: https://graphviz.org/download/. Basta que o aluno escolha o programa do
sistema operacional do computador dele), deste modo, este programa consegue ler
os caminhos desenhados utilizando grafos. Este software proporciona a testagem de
códigos feitos em Java e traz várias análises estatísticas através da sua página inicial.
https://github.com/magsilva/jabuti
https://graphviz.org/download/
Outro site muito utilizado é o EclEmma (disponível em
https://marketplace.eclipse.org/content/eclemma-java-code-coverage). Este software
pode ser instalado diretamente da versão Java Eclipse, pois ele foi desenvolvido
especialmente para testar programas em Java feitos nesta plataforma. Outro site
muito utilizado é o JUnit5, programa oriundo a partir do JUnit e disponível em
https://junit.org/junit5/. Existem também comunidades que possibilitam o acesso a
sites de testagem. Uma dessas comunidades é a TestProject, que pode ser encontrada
no endereço: https://auth.testproject.io/auth/realms/TP/protocol/openid-
connect/auth?
client_id=tp.app&redirect_uri=https%3A%2F%2Fapp.testproject.io%2Fcallback.html&re
sponse_type=id_token%20token&scope=openid%20pro�le&state=6faa66bf91534d00b
0f015bfef3b623d&nonce=7d5a9978753d421fbb51b1bd846e2e10. Neste site, é
preciso somente fazer um cadastro através de uma conta Google ou Microsoft,
con�rmar o e-mail e já começar a utilizá-lo – ele permite, inclusive, que cadastremos
uma equipe.
A vantagem destes sites é que podemos nos comunicar com desenvolvedores e
testadores do mundo todo através das suas comunidades, ler artigos publicados na
plataforma e até mesmo estudar algum material especí�co através de vídeos de
aprendizagem disponibilizados pela própria desenvolvedora do software.
VIDEOAULA: TESTE PONTO A PONTO E A IMPORTÂNCIA NA
INFRAESTRUTURA
Neste bloco, serão aprofundadas algumas ferramentas que podem ser utilizadas para
o teste ponto a ponto, permitindo que seja criada uma infraestrutura automática para
auxílio do programador na realização da testagem. Essas ferramentas são gratuitas e
de fácil utilização, assim como é mostrado uma comunidade na internet dedicada a
isso.
ESTUDO DE CASO
Você foi contratado como responsável pelo setor de desenvolvimento de códigos de
uma startup brasileira que acabou de fechar uma parceria para assumir o
desenvolvimento de um novo jogo, inspirado em um jogo muito famoso que os
adolescentes adoram. Baseado nestas informações, você fez uma reunião de kick-o�
(para iniciar o projeto e explicar as exigências do cliente para os seus colaboradores).
Estas exigências são:
• Cadastro com um e-mail válido.
• Senha alfanumérica de 6 dígitos.
• Jogador que trouxer mais 3 amigos ganha 10 vidas e 50 barras de ouro.
• Jogador pode formar uma equipe com os seus 3 amigos.
Videoaula: Teste ponto a ponto e a importância na infraestrutura
Para visualizar o objeto, acesse seu material digital.
https://marketplace.eclipse.org/content/eclemma-java-code-coverage
https://junit.org/junit5/
https://auth.testproject.io/auth/realms/TP/protocol/openid-connect/auth?client_id=tp.app&redirect_uri=https%3A%2F%2Fapp.testproject.io%2Fcallback.html&response_type=id_token%20token&scope=openid%20profile&state=6faa66bf91534d00b0f015bfef3b623d&nonce=7d5a9978753d421fbb51b1bd846e2e10
https://auth.testproject.io/auth/realms/TP/protocol/openid-connect/auth?client_id=tp.app&redirect_uri=https%3A%2F%2Fapp.testproject.io%2Fcallback.html&response_type=id_token%20token&scope=openid%20profile&state=6faa66bf91534d00b0f015bfef3b623d&nonce=7d5a9978753d421fbb51b1bd846e2e10
https://auth.testproject.io/auth/realms/TP/protocol/openid-connect/auth?client_id=tp.app&redirect_uri=https%3A%2F%2Fapp.testproject.io%2Fcallback.html&response_type=id_token%20token&scope=openid%20profile&state=6faa66bf91534d00b0f015bfef3b623d&nonce=7d5a9978753d421fbb51b1bd846e2e10
https://auth.testproject.io/auth/realms/TP/protocol/openid-connect/auth?client_id=tp.app&redirect_uri=https%3A%2F%2Fapp.testproject.io%2Fcallback.html&response_type=id_token%20token&scope=openid%20profile&state=6faa66bf91534d00b0f015bfef3b623d&nonce=7d5a9978753d421fbb51b1bd846e2e10
https://auth.testproject.io/auth/realms/TP/protocol/openid-connect/auth?client_id=tp.app&redirect_uri=https%3A%2F%2Fapp.testproject.io%2Fcallback.html&response_type=id_token%20token&scope=openid%20profile&state=6faa66bf91534d00b0f015bfef3b623d&nonce=7d5a9978753d421fbb51b1bd846e2e10
Os pro�ssionais que trabalham para você relataram que, no projeto anterior que
participaram, �zeram um código muito parecido com este e, por isso, não viam a
necessidade de realizar a testagem do código. A única diferença é a senha
alfanumérica, a qual, no projeto anterior, era uma senha numérica de 4 dígitos.
Mediante a situação exposta pelos funcionários, que decisão você tomaria?
RESOLUÇÃO DO ESTUDO DE CASO
Primeiro, você deveria con�rmar esta informação e veri�car se o código entregue foi
produzido sem erros nesta parte. Uma análise do relatório de testes do projeto
anterior já resolveria esta situação. Constatada a veracidade da informação, você
deveria determinar que um programador executasse a alteração no código para a
sequência de senhas solicitadas e utilizasse o mesmo banco de dados do projeto
anterior para testar o código unitário, veri�cando um caso verdadeiro e outro falso
(como o cadastramento de uma senha numérica) para este requisito do código.
Depois disso, você deve determinar que seja realizada a testagem de automação do
código para veri�car se existe integração entre este cadastro e os itens pontuação por
indicação de amigos e se o jogador pode escolher a sua equipe. Deve ser veri�cada
também a boni�cação em barras de ouro – um teste caixa-preta com quatro usuários
resolveria esta parte da testagem.
 Saibamais
No Capítulo 4 do livro Introdução ao Teste de Software, são mostradas
informações mais detalhadas da análise de códigos através de grafos e das telas
de testagem fornecidas pelos programas de auxílio a estas formas de testes.
Neste capítulo, é analisado o software POKE-TOOL, uma ferramenta que não tem
capacidade de testar softwares comerciais, mas de muito auxílio para o estudo de
testes ponto a ponto por parte de você, caro estudante. Disponível em:
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubc�/6
/20%5B%3Bvnd.vst.idref%3Dchapter4.xhtml%5D!/4/2/2/2/2. Acesso em: 18 out.
2021.
Artigo abordando a importância do ensino da criação do código e das ferramentas
de testagem ao mesmo tempo. Os autores analisam a testagem baseada na
ferramenta JaBUTi. Disponível em:
https://pdfs.semanticscholar.org/ada8/6ab7011fb54fa3c2b2390a2cf0f9564d0fe9.p
df. Acesso em: 18 out. 2021.
Este vídeo traz uma explicação bem didática e simples do teste caixa-branca e
caixa-preta, ressaltando as principais diferenças que podemos encontrar entre
estes dois tipos de testagem. Disponível em: https://www.youtube.com/watch?
v=QyXN_zAhqJA&t=266s. Acesso em: 18 out. 2021.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/20%5B%3Bvnd.vst.idref%3Dchapter4.xhtml%5D!/4/2/2/2/2
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/20%5B%3Bvnd.vst.idref%3Dchapter4.xhtml%5D!/4/2/2/2/2
https://pdfs.semanticscholar.org/ada8/6ab7011fb54fa3c2b2390a2cf0f9564d0fe9.pdf
https://pdfs.semanticscholar.org/ada8/6ab7011fb54fa3c2b2390a2cf0f9564d0fe9.pdf
https://www.youtube.com/watch?v=QyXN_zAhqJA&t=266s
https://www.youtube.com/watch?v=QyXN_zAhqJA&t=266s
INTRODUÇÃO
Seja muito bem-vindo à nossa aula sobre qualidade no processo de integração do
software, da disciplina de Qualidade e Automação de Testes. Nesta aula, teremos a
oportunidade de melhor compreender como a qualidade está diretamente
relacionada ao desenvolvimento do software, passando pelas diversas fases que o
compõe, bem como a integração que proporciona entre todos os envolvidos do time.
É essencial também que a empresa participe de um programa ou siga métricas que
façam a veri�cação e análise daquilo que se produz, sendo essencial para manter um
padrão de qualidade, garantindo, assim, a con�ança e a credibilidade com o
consumidor daquele software, que, neste caso, é o usuário. 
E aí, gostou do que leu até agora? Então, prepare-se, pois muito mais está por vir!
Conhecimento gera conhecimento e, quanto mais sabemos, melhor nos tornamos
como pro�ssionais deste vasto universo tecnológico. 
NORMAS PARA DESENVOLVIMENTO DE SOFTWARES COM
QUALIDADE
Agora, estudaremos a respeito das normas para desenvolvimento de softwares com
qualidade. Durante esse primeiro momento, compreenderemos o que é importante
para desenvolver um sistema, seja ele web, desktop ou app com qualidade.
Utilizar-se de normas, padrões e métodos para desenvolver qualquer atividade, seja
ela qual for, acarretará um resultado positivo e satisfatório. Assim também ocorre
com a qualidade do software, que deve possuir suas diretrizes bem de�nidas para
que o produto, no início, durante e no �nal do processo, possa estar de acordo com
os anseios do cliente. Mas, antes de entrarmos no assunto propriamente dito, é
importante conceituarmos o que signi�ca qualidade. Conforme expresso pela NBR
ISSO 9000:2005, que a�rma que qualidade é o “grau no qual um conjunto de
características inerentes satisfaz aos requisitos”, tornando-a como algo subjetivo, ou
seja, não há uma padronização ou um conceito rígido, mas, sim, uma variação de
produto para produto, serviço para serviço e de cliente para cliente. Indo mais além,
Glass (1998) corrobora ao a�rmar que a relação deve ser intuitiva, apresentando a
seguinte “fórmula”: “satisfação do usuário = produto compatível + boa qualidade +
entrega dentro do orçamento e do prazo previsto”. Todos esses fatores, agregados à
Aula 4
A QUALIDADE NO PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE
compreender como a qualidade está diretamente relacionada ao
desenvolvimento do software, passando pelas diversas fases que o compõe, bem
como a integração que proporciona entre todos os envolvidos do time.
52 minutos
seriedade e à agilidade em cada etapa do processo, deverão gerar entregas
satisfatórias a todos os envolvidos, desde o time de desenvolvimento até o usuário
�nal.
Agora que você já está por dentro do assunto qualidade, podemos avançar nesse
tema e entender como funciona e quais são as normas que auxiliam durante o
processo de teste e validação do produto.
Utilizar-se de normas e padrões garante que as organizações que realizam a mesma
ação a façam de maneira similar, e que a comunicação entre elas ocorra de modo
mais facilitado, isso graças aos protocolos uni�cados, que servem como parâmetros e
embasamento de comparação e análise. Dentre as instituições detentoras das normas
mais utilizadas, temos duas, sendo:
• ISO: Organização Internacional para Padronização (International Organization for
Standardization).
• IEEE: Instituto de Engenheiros Eletricistas e Eletrônicos (Institute of Electrical and
Electronics Engineers).
Ambas se destacam no mercado mundial pelo alto grau de cobrança e de qualidade
de seus programas, possuindo selos e títulos de acordo com o nível em que a
empresa participante se encontra ou avança nas validações exigidas. Observe o
Quadro 1, que apresenta as principais normas nacionais e internacionais na área da
qualidade.
Quadro 1 | Principais normas nacionais e internacionais de qualidade de software
Normas Comentários
ISO 9126 Características da qualidade de produtos de software.
NBR
13596
Versão brasileira da ISO 9126.
ISO 14598 Guias para a avaliação de produtos de software, baseados na utilização
prática da norma ISO 9126.
ISO 12119 Características de qualidade de pacotes de software (software de
prateleira, vendido como um produto embalado).
IEEE
P1061
Standard for Software Quality Metrics Methodology. Norma que trata
das metodologias para padronização da qualidade de software,
incluindo algumas abordagens de medição.
ISO 12207 Software Life Cycle Process. Norma para a qualidade do processo de
desenvolvimento de software.
NBR ISO
9001
Sistemas de qualidade – Modelo para garantia de qualidade em
projeto, desenvolvimento, instalação e assistência técnica (processo).
NBR ISO
9000-3
Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO
9000 para o processo de desenvolvimento de software.
Normas Comentários
NBR ISO
10011
Auditoria de Sistemas de Qualidade (processo).
CMMI Capability Maturity Model Integration. Modelo da SEI (Instituto de
Engenharia de Software do Departamento de Defesa dos EUA) para
avaliação da qualidade do processo de desenvolvimento de software.
Não é uma norma ISO, mas é muito bem aceita no mercado.
SPICE ISO
15504
Projeto da ISO/IEC para avaliação do processo de desenvolvimento de
software. Ainda não é uma norma o�cial ISO, mas o processo está em
andamento.
Fonte: Morais (2010, [s. p.]).
As normas citadas no Quadro 1 agregam valor a toda empresa que fará uso dela, bem
como o fato de estar atualizado com o que há de melhor no mercado e estar à frente
de seus concorrentes.
Como destaque entre todas as normas, o padrão ISO 9126 é de grande relevância
quando o assunto é qualidade do produto de software, pois foi desenvolvido como
uma tentativa de identi�car os atributos fundamentais de qualidade para software de
computador (PRESSMAN; MAXIM, 2021). Os seis atributos fundamentais de qualidade
que o padrão estabelece podem ser encontrados no Quadro 2.
Quadro 2 | Categorias de características e subcaracterísticas de qualidade de software
CARACTERÍSTICAS SUBCARACTERÍSTICAS SIGNIFICADO
Funcionalidade
O conjunto de funções
satisfazem as necessidades
explícitas e implícitas paraa �nalidade a que se
destina o produto?
Adequação Propõe-se a fazer o que é
apropriado?
Acurácia Gera resultados corretos
ou conforme acordados?
Interoperabilidade É capaz de interagir com
os sistemas especi�cados?
Segurança de acesso Evita o acesso não
autorizado, acidental ou
deliberado a programas e
dados?
Conformidade Está de acordo com
normas e convenções
previstas em leis e
descrições similares?
CARACTERÍSTICAS SUBCARACTERÍSTICAS SIGNIFICADO
Con�abilidade
O desempenho se mantém
ao longo do tempo e em
condições estabelecidas?
Maturidade Com que frequência
apresenta falhas?
Tolerância a falhas Ocorrendo falhas, como
ele reage?
Recuperabilidade É capaz de recuperar
dados após uma falha?
Usabilidade
É fácil utilizar o software?
Inteligibilidade É fácil entender os
conceitos utilizados?
Apreensibilidade É fácil aprender a usar?
Operacionalidade É fácil de operar e
controlar a operação?
E�ciência
Os recursos e os tempos
utilizados são compatíveis
com o nível de
desempenho requerido
para o produto?
Comportamento em
relação ao tempo
Qual é o tempo de
resposta e de
processamento?
Comportamento em
relação aos recursos
Quanto recurso utiliza?
Manutenibilidade
Há facilidade para
correções, atualizações e
alterações?
Analisabilidade É fácil encontrar uma falha
quando ocorre?
Modi�cabilidade É fácil modi�car e remover
defeitos?
Estabilidade Há grandes riscos de bugs
quando se faz alterações?
Testabilidade É fácil testar quando se faz
alterações?
CARACTERÍSTICAS SUBCARACTERÍSTICAS SIGNIFICADO
Portabilidade
É possível utilizar o produto
em diversas plataformas
com pequeno esforço de
adaptação?
Adaptabilidade É fácil adaptar a outros
ambientes sem aplicar
outras ações ou meios
além dos fornecidos para
esta �nalidade no
software considerado?
Capacidade para ser
instalado
É fácil instalar em outros
ambientes?
Capacidade para
substituir
É fácil substituir por outro
software?
Conformidade Está de acordo com
padrões ou convenções de
portabilidade?
Fonte: Morais (2010, [s. p.]).
Nesse primeiro momento, identi�camos o que é necessário para que um software
possa ser construído com qualidade. Veri�camos também quais são as principais
normas que auxiliam nesse processo, garantindo os padrões exigidos pelo mercado.
Até mais!
VIDEOAULA: NORMAS PARA DESENVOLVIMENTO DE SOFTWARES
COM QUALIDADE
Neste vídeo, serão retratados os fatores fundamentais envolvidos para a construção
de softwares com qualidade, utilizando-se das principais normas nacionais e
internacionais para auxiliar nesse processo, garantindo os padrões de qualidade
exigidos pelo mercado. Assim, você obterá conhecimento e visão crítica su�cientes
para a sequência de conteúdos que serão estudados na disciplina.
O DILEMA DA QUALIDADE DE SOFTWARE
Aqui, estudaremos a respeito de como sabemos se um software possui ou não
qualidade. Você nunca se perguntou como essa classi�cação é realizada? Agora, terá a
oportunidade de melhor compreender esse processo importante no ciclo de
desenvolvimento do software. 
Primeiramente, faço uma pergunta: devemos produzir o melhor software, ou um
software bom o su�ciente? Antes de tratarmos da resposta e discutirmos um pouco
mais sobre o assunto, veja o que Bertrand Meyer mencionou durante uma entrevista,
o que conhecemos como “dilema da qualidade”:
Videoaula: Normas para desenvolvimento de softwares com qualidade
Para visualizar o objeto, acesse seu material digital.
E agora, depois da leitura dessa citação, a sua resposta continua a mesma que antes?
Certamente, tudo o que �zermos deve conter o melhor de nós, não é mesmo? Se
cortamos a grama do jardim de casa, aquele deve ser o melhor corte já realizado em
sua vida. A mesma coisa deve ocorrer durante a análise, criação e testagem de um
software, seja ele aplicativo para mobile ou um programa local (desktop) ou on-line. O
esforço concentrado para realização daquela tarefa deve ser o maior possível, haja
vista que outras pessoas serão impactadas direta ou indiretamente se tudo que você
�zer der certo ou errado. De acordo com Pressman e Maxim  (2021, p. 421), não há
nenhum problema ao produzir um software “bom o su�ciente”, pelo contrário, isso é
aceitável e tolerável, pois as empresas de software já adotam essa prática há muito
tempo, inclusive, estão fazendo isso neste momento.
Basicamente, o que acontece é que as empresas desenvolvedoras de software criam
seus produtos com erros (bugs) já conhecidos, os quais não impedem, em parte, o
usuário de trabalhar. Como a demanda costuma ser grande e a equipe de trabalho
não é su�cientemente grande o bastante para atender a essa demanda, o software
passa a ser “bom o su�ciente”, ou seja, é entregue o essencial e crucial para atender a
X função solicitada pelo usuário, devendo os aspectos secundários serem avaliados
posteriormente, em novas versões.
Portanto, o software “bom o su�ciente”, para Pressman e Maxim (2021, p. 421),
“fornece funções e características de alta qualidade que os usuários desejam, mas, ao
mesmo tempo, fornece outras funções e características mais obscuras ou
especializadas que contêm erros conhecidos”. Desta forma, a empresa espera que o
usuário foque apenas na função que foi solicitada e entregue, permanecendo os
defeitos e erros esquecidos ou com menor relevância para aquele momento.
Entretanto, utilizar-se dessa prática pode ser um tanto quanto perigoso, já que tudo
depende do tamanho e da estrutura que a empresa possui e do tipo de aplicação e
tecnologia que ela trabalha. Empresas de grande porte podem investir em marketing,
além de já estarem estruturadas no mercado, o que acaba criando uma referência
para o setor.
Outro ponto importante é determinar o custo da qualidade, o qual, para Pressman e
Maxim (2016, p. 422), pode ser dividido em custos associados à prevenção, à avaliação
e às falhas, como mostra o Quadro 3.
Quadro 3 | Tipo de custo da qualidade
Se produzimos um sistema de software de péssima qualidade,
perdemos porque ninguém vai querer comprá-lo. Se, por outro lado,
gastamos um tempo in�nito, um esforço extremamente grande e
grandes somas de dinheiro para construir um software absolutamente
perfeito, então ele levará muito tempo para ser concluído, e o custo de
produção será tão alto que iremos à falência. 
— . (VENNERS, 2003, [s. p.] apud PRESSMAN; MAXIM, 2016, p. 420)
TIPO DE
CUSTO DESCRIÇÃO
Prevenção a)  O custo de atividades de gerenciamento necessárias para
planejar e coordenar todas as atividades de controle e garantia da
qualidade.
b)  O custo de atividades técnicas adicionais para desenvolver
modelos completos de requisitos e de projeto.
c)  Os custos de planejamento de testes.
d)  O custo de todo o treinamento associado a essas atividades.
Avaliação a)  O custo da realização de revisões técnicas.
b)  O custo dos artefatos de engenharia de software.
c)  O custo da coleta de dados e avaliação de métricas.
d)  O custo dos testes e depuração.
Avaliação a)  O custo da realização de revisões técnicas.
b)  O custo dos artefatos de engenharia de software.
c)  O custo da coleta de dados e avaliação de métricas.
d)  O custo dos testes e depuração.
Falhas São divididas em duas, sendo:
1. Falhas internas:
a)  O custo necessário para realizar reformulações (reparos) para
corrigir um erro.
b)  O custo que ocorre quando reformulações geram,
inadvertidamente, efeitos colaterais que devem ser reduzidos.
c)  Os custos associados à reunião de métricas de qualidade que
permitam a uma organização avaliar os modos de falha.
2. Falhas externas:
a)  Defeitos encontrados após o produto ter sido entregue ao cliente.
Fonte: adaptado de Pressman e Maxim (2016, p. 422).
Outra informação bastante relevante, é que o custo para a correção de erros e falhas
aumenta signi�cativamente à medida que as etapas do ciclo de vida do software
avançam, sendo mais oneroso quando o software já está sendo utilizado pelo cliente.
Essa informação pode ser comprovadacom os dados coletados por Boehm e Basili
(2001 apud PRESSMAN; MAXIM, 2016), como demostrado na Figura 1.
Figura 1 | Custo relativo para correção de erros e defeitos
Fonte: Boehm e Basili (2001 apud PRESSMAN; MAXIM, 2016, p. 423).
Analisando a Figura 1, temos a dimensão que o custo médio para corrigir um defeito
durante a geração de código é de, aproximadamente, US$ 977 por erro. Para a
correção do mesmo erro, mas durante os testes do sistema, o custo passa a ser de
US$ 7.136 por erro. Essa estatística considerou uma grande aplicação com introdução
de 200 erros durante a codi�cação.
Nesse segundo momento, você compreendeu como é delicado quando precisamos
mensurar se  software possui ou não qualidade, demandando tempo e estudo em
cada caso. Outro ponto é o custo �nanceiro para que aquele erro ou falha possa ser
identi�cado e corrigido, demandando valores mais altos quando a aplicação já está no
cliente. 
VIDEOAULA: O DILEMA DA QUALIDADE DE SOFTWARE
Neste vídeo, serão retratados os pontos necessários para considerar ou não que um
software possua qualidade, sendo considerada a utilização do software “bom o
su�ciente” por empresas do setor. Outro ponto importante é quanto ao custo para
que defeitos e erros sejam corrigidos, apresentando um valor mais elevando se o
produto já estiver no cliente.
GARANTIA DA QUALIDADE DE SOFTWARE
Aqui, estudaremos sobre os aspectos para garantir a qualidade de software, sendo de
extrema importância para o seu ciclo de vida, com relação direta na manutenção e
integridade da qualidade atingida pelo produto. Durante esse bloco de estudo,
teremos a chance de melhor compreender o quanto é importante a permanência do
processo de qualidade. 
Garantir aquilo que se produz não é uma tarefa nada fácil, visto que envolve uma
série de processos e tempo para aperfeiçoamento do produto, entretanto são
essenciais para a competitividade e a permanência da empresa no mundo dos
negócios. Pressman e Maxim (2021, p. 477) relatam que: 
Videoaula: O dilema da qualidade de software
Para visualizar o objeto, acesse seu material digital.
A importância de terceiros validarem uma nova funcionalidade do software cria um
ambiente seguro e con�ável, pois novas pessoas (testes manuais), as quais não
tiveram envolvimento com o desenvolvimento, terão a chance de tomar
conhecimento sem nenhum vício, ou seja, as chances de falhas, defeitos ou erros
serem encontrados é grande, pois um olhar novo poderá se deparar com situações
até então desconhecidas.
Foi Bell Labs, em 1916, que introduziu a primeira função formal da garantia e do
controle da qualidade, espalhando-se rapidamente por todo o mundo da manufatura.
Posteriormente, já em 1940, novos conceitos formais foram criados, com foco em
medições e aprimoramento contínuo do processo (DEMING, 1986).
Quanto ao desenvolvimento de software, os padrões para a garantia da qualidade
ocorreram por iniciativa de algumas empresas terceirizadas pela indústria militar, no
ano de 1970, ganhando o mundo do software comercial rapidamente. Deste modo,
podemos entender que a garantia de qualidade de software, segundo Schulmeyer e
McManus (1998 apud PRESSMAN; MAXIM, 2016, p. 449), é um “padrão de ações
planejado e sistematizado”, necessário para garantir alta qualidade no software. Uma
das formas de veri�cação da qualidade é através do grupo de SQA (Software Quality
Assurance, ou Garantia da Qualidade de Software), que funciona como um serviço de
defesa do cliente, pois examina o software sob o ponto de vista do cliente.
A garantia de qualidade de software é um universo de possibilidades, com foco em
atividades de gestão da qualidade de software. Para Horch (2003), os elementos
podem ser sintetizados de acordo com o Quadro 4.
Quadro 4 | Elementos de garantia de qualidade de software
ELEMENTO DESCRIÇÃO
Padrões IEEE, ISO e outras organizações de padronizações produziram
uma ampla gama de padrões para engenharia de software e
documentos relacionados. Tais práticas podem ser adotadas
voluntariamente ou impostas pelo cliente ou outros envolvidos.
A SQA garante que os padrões adotados sejam seguidos, e seus
produtos estejam em conformidade com eles.
Revisões e
auditorias
Com foco em revelar erros, as atividades de controle de
qualidade são realizadas por engenheiros de software para
engenheiros de software. As auditorias realizadas pela SQA têm
o intuito de assegurar que as diretrizes de qualidade estejam
sendo seguidas no trabalho de engenharia de software.
Antes do século XX, o controle de qualidade era responsabilidade
exclusiva do artesão que construía um produto. À medida que o tempo
foi passando e técnicas de produção em massa tornaram-se comuns, o
controle de qualidade tornou-se uma atividade realizada por outras
pessoas, e não por aquelas que constroem o produto.
ELEMENTO DESCRIÇÃO
Testes É uma função de controle de qualidade, com o objetivo
principal de encontrar erros. O papel da SQA é garantir que os
testes sejam planejados apropriadamente e conduzidos
e�cientemente, de modo que se tenha a maior probabilidade
possível de alcançar seu objetivo primário.
Coleta e análise
de erros/defeitos
A SQA reúne e analisa dados de erros e defeitos para melhor
compreender como os erros são introduzidos e quais
atividades de engenharia de software são as mais adequadas
para sua eliminação.
Gerenciamento
de mudanças
A SQA garante que práticas adequadas de gerenciamento de
mudanças tenham sido instituídas.
Educação A SQA assume a liderança no processo de aperfeiçoamento do
software, sendo um proponente fundamental e patrocinador
de programas educacionais.
Gerência dos
fornecedores
O grupo de SQA deve garantir software de alta qualidade por
meio da sugestão de práticas especí�cas de garantia da
qualidade, que o fornecedor deve (sempre que possível) seguir
e incorporar exigências de qualidade como parte de qualquer
contrato com um fornecedor externo.
Administração da
segurança
Proteção por meio de �rewalls para os aplicativos móveis e
garantia de que o software não tenha sido alterado
internamente sem autorização são exemplos de administração
de segurança. A SQA garante o emprego de processos e
tecnologias apropriados para se ter a segurança de software
desejada.
Proteção A SQA pode ser responsável por avaliar o impacto de falhas de
software e por iniciar as etapas necessárias para redução de
riscos.
Gestão de riscos Apesar de a análise e a redução de riscos serem atribuições dos
engenheiros de software, a SQA garante que as atividades de
gestão de riscos sejam conduzidas apropriadamente e que
planos de contingência relacionados a riscos tenham sido
estabelecidos.
Fonte: adaptado de Horch (2003).
Como visto no Quadro 4, vários são os elementos que auxiliam no controle e na
garantia de qualidade de software, além de serem associados a dois elementos
distintos: os engenheiros de software, os quais realizam o trabalho técnico, e um
grupo de SQA, que é responsável pelo planejamento, pela supervisão, pela
manutenção de registros, pela análise e pelos relatórios referentes à garantia da
qualidade (PRESSMAN; MAXIM, 2021, p. 343).
Sendo normalmente orientado a dados, a garantia de qualidade de software moderna
apresenta um ciclo, como pode ser observado na Figura 2. Neste processo, os
envolvidos devem de�nir metas e medidas de qualidade, identi�car áreas
problemáticas, mensurar indicadores e determinar se alterações no processo são ou
não necessárias. O papel do engenheiro de software é aplicar medidas e métodos
técnicos consistentes, conduzindo as revisões técnicas e realizando testes de software
bem planejados, para garantir sua qualidade.
Figura 2 | Garantia de qualidade de software
Fonte: Pressman e Maxim (2021, p. 343).
Como atribuição, a SQA tem a tarefa de obter um produto de alta qualidade, em
parceria com a equipe de software. As atividades de SQA dizem respeito ao
planejamento, à supervisão, à manutenção de registros, à análise e aos relatóriosrelativos à garantia da qualidade. De acordo com Pressman e Maxim (2021), essas
atividades são realizadas (ou facilitadas) por um grupo de SQA independente, que
deve: preparar um plano de SQA para um projeto; participar do desenvolvimento da
descrição da gestão de qualidade do projeto; revisar as atividades de engenharia de
software para veri�car sua conformidade com a gestão de qualidade de�nida; auditar
os artefatos de software designados para veri�car sua conformidade com aqueles
de�nidos como parte da gestão de qualidade; garantir que os desvios no trabalho de
software e artefatos sejam documentados e tratados de acordo com um
procedimento documentado; registrar qualquer não conformidade e relatar à alta
direção. 
Chegamos ao �nal deste bloco. Você compreendeu melhor como ocorre a garantia da
qualidade de software, não sendo de responsabilidade apenas de alguém ou de um
grupo, mas de muitos envolvidos, garantindo a con�abilidade necessária ao usuário.
VIDEOAULA: GARANTIA DA QUALIDADE DE SOFTWARE
Neste vídeo, serão retratados os aspectos necessários para a garantia da qualidade de
software, com destaque para as práticas e os processos necessários para que o
software obtenha a qualidade desejada.
ESTUDO DE CASO
Agora chegou a hora de colocar tudo em prática! Para este estudo de caso, imagine o
seguinte cenário:
Há pouco tempo, a prefeitura de sua cidade adquiriu um app para realizar o cadastro
de solicitações para alvará de estabelecimentos comerciais e situações que se �zerem
necessárias. A plataforma permite, conforme a empresa ganhadora da licitação
prometeu, a solicitação do primeiro alvará, renovação, acompanhamento do pedido,
anexo de documentos e impressão do novo alvará. Acontece que, desde a
implantação da ferramenta, alguns problemas vêm ocorrendo, além do relato de
diversos munícipes que não conseguem a renovação do seu alvará através do
aplicativo. Os relatos são inúmeros, como perda de conexão, sistema lento, dados não
encontrados no banco de dados, entre outros.
Ciente de todos esses problemas, a prefeitura resolveu instaurar uma comissão para
averiguar o que estava, de fato, ocorrendo. Como é necessário realizar uma avaliação
técnica do aplicativo e de sua estrutura, você foi convidado a integrar o corpo técnico
do setor de tecnologia. Deste modo, você deverá investigar: 
a.  Reclamações do usuário.
b.  Existência ou não de qualidade no desenvolvimento do aplicativo.
c.  Elencar possíveis prejuízos com os problemas do aplicativo à prefeitura.
d.  Confeccionar um plano de ação, sugerindo melhorias e aperfeiçoamento no
aplicativo. 
Sua missão é de extrema importância e será impactante no dia a dia de inúmeras
pessoas. Deste modo, não deixe passar nada. Seja extremamente criterioso e aponte
tudo o que estiver fora das boas normas que o mercado pede. Então, mãos à obra!
RESOLUÇÃO DO ESTUDO DE CASO
lorePara a resolução deste estudo de caso, devemos utilizar o material dos três
blocos, sendo: a qualidade no processo de desenvolvimento de software (Bloco 1), o
impasse da qualidade do software (Bloco 2) e a qualidade de software (Bloco 3). Todo
esse material servirá de base para o relatório que deverá ser desenvolvido para o
cumprimento dessa atividade muito signi�cativa, que é a avaliação técnica do
aplicativo e de sua estrutura.
Para que a conferência possa ser executada e que nada seja esquecido, procure
considerar os seguintes aspectos:
Videoaula: Garantia da qualidade de software
Para visualizar o objeto, acesse seu material digital.
a)  Coletar o máximo de reclamações, utilizando-se de imagens para comprovar a
falha.
b)  Quais as normas de qualidade utilizadas no ciclo de vida do aplicativo pela
empresa desenvolvedora?
c)  Avaliar o aplicativo conforme os seis atributos de qualidade da norma ISO 9126.
d)  Indicar os possíveis custos para ajuste e o que isso já interferiu (desgaste) desde o
relato dos primeiros problemas.
Pronto! Agora é só realizar a veri�cação e transcrever todas as informações para um
relatório técnico e muito bem detalhado.
 Saiba mais
Caro aluno, como sugestão para aprofundar seus estudos, sugiro o livro indicado
a seguir, com o qual você obterá mais conhecimento sobre qualidade de software,
através de um material fascinaste e super atual. Vale a pena conferir!
GALLOTTI, G. M. A. Qualidade de software. São Paulo, SP: Pearson Education do
Brasil, 2016. Disponível em:
https://plataforma.bvirtual.com.br/Acervo/Publicacao/124148. Acesso em: 1º fev.
2022.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
Aula 1
BERNARDO, P. C.; KON, F. A importância dos testes automatizados: controle ágil,
rápido e con�ável de qualidade. Engenharia de Software Magazine, v. 1, n. 3, p. 54-
57, 2008. Disponível em:
http://ccsl.ime.usp.br/agilcoop/�les/A%20Importancia%20dos%20Testes%20Automati
zados.pdf.Acesso em: 4 set. 2021.
BLANCO, M. Z. Documentação de teste baseado na norma IEEE 829 – estudo de caso:
sistema de apoio a tomada de decisão. Revista Tecnologias, Infraestrutura e
Software, São Carlos, v. 1, n. 1. p. 91-97, jul. 2021. Disponível em:
http://revistatis.dc.ufscar.br/index.php/revista/article/view/18/22 . Acesso em: 5 set.
2021.
REFERÊNCIAS
15 minutos
https://plataforma.bvirtual.com.br/Acervo/Publicacao/124148
http://ccsl.ime.usp.br/agilcoop/files/A%20Importancia%20dos%20Testes%20Automatizados.pdf
http://ccsl.ime.usp.br/agilcoop/files/A%20Importancia%20dos%20Testes%20Automatizados.pdf
http://revistatis.dc.ufscar.br/index.php/revista/article/view/18/22
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de software. 2.
ed. Rio de Janeiro, RJ: Elsevier, 2016. Disponível em:
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubc�/6/2%
5B%3Bvnd.vst.idref%3Dcapa.xhtml%5D!/4/2/2/4%5B959c907a-71f3-426e-db7c-
9d57809eec41%5D%4050:79 . Acesso em: 4 set. 2021.
DIAS NETO, A. C. Introdução a testes de software. Engenharia de Software
Magazine, n. 1, p. 54-59, jun. 2016. Disponível em:
https://edisciplinas.usp.br/plugin�le.php/3503764/mod_resource/content/3/Introduca
o_a_Teste_de_Software.pdf. Acesso em: 5 set. 2021.
POLO, R. C. Validação e teste de software. Curitiba, PR: Contentus, 2020.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem
pro�ssional. Trad. João Eduardo Nóbrega Tortello. Porto Alegre, RS: AMGH, 2016.
TESTE DE SOFTWARE. [S. l.: s. n.], 2015. 1 vídeo (11min47s). Publicado pelo canal Pedro
Carvalho. Disponível em: https://www.youtube.com/watch?v=DBw_GctgPqU. Acesso
em: 4 set. 2021.
Aula 2
CAMPOS, F. M. Qualidade, Qualidade de Software e Garantia da Qualidade de
Software são as mesmas coisas? Linha de Código, [s. d.]. Disponível em:
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-
garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx. Acesso em: 14 set.
2021.
CIGITAL. Case study: Finding Defects elarlier yields enourmous savings. Cigital
Archive, 2007. Disponível em:
http://web.archive.org/web/20071003044003/http://www.cigital.com/solutions/roi-
cs2.php . Acesso em: 8 set. 2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem
pro�ssional. Porto Alegre, RS: AMGH, 2016.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem
pro�ssional. Porto Alegre, RS: AMGH, 2021.
ZANIN, A. et al. Qualidade de software. Porto Alegre, RS: SAGAH, 2018.
03 – SONARQUBE – DOWNLOAD, INSTALAÇÃO E EXECUÇÃO. [S. l.: s. n.], 2020. 1 vídeo
(11min49s). Publicado pelo canal T2Ti. Disponível em:
https://www.youtube.com/watch?v=TNEHX51L9Do. Acesso em: 14 set. 2021.
Aula 3
CORTE, C. K. D. Ensino integrado de fundamentos de programação e teste de
software. 2006. Dissertação (Mestrado em Ciências de Computação e Matemática
Computacional) – Universidade de São Paulo, São Carlos, 2006. Disponível em:
https://pdfs.semanticscholar.org/ada8/6ab7011fb54fa3c2b2390a2cf0f9564d0fe9.pdf .
Acesso em: 18 out. 2020.
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/2%5B%3Bvnd.vst.idref%3Dcapa.xhtml%5D!/4/2/2/4%5B959c907a-71f3-426e-db7c-9d57809eec41%5D%4050:79https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/2%5B%3Bvnd.vst.idref%3Dcapa.xhtml%5D!/4/2/2/4%5B959c907a-71f3-426e-db7c-9d57809eec41%5D%4050:79
https://integrada.minhabiblioteca.com.br/reader/books/9788595155732/epubcfi/6/2%5B%3Bvnd.vst.idref%3Dcapa.xhtml%5D!/4/2/2/4%5B959c907a-71f3-426e-db7c-9d57809eec41%5D%4050:79
https://edisciplinas.usp.br/pluginfile.php/3503764/mod_resource/content/3/Introducao_a_Teste_de_Software.pdf
https://edisciplinas.usp.br/pluginfile.php/3503764/mod_resource/content/3/Introducao_a_Teste_de_Software.pdf
https://www.youtube.com/watch?v=DBw_GctgPqU
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
http://web.archive.org/web/20071003044003/http://www.cigital.com/solutions/roi-cs2.php
http://web.archive.org/web/20071003044003/http://www.cigital.com/solutions/roi-cs2.php
https://www.youtube.com/watch?v=TNEHX51L9Do
https://pdfs.semanticscholar.org/ada8/6ab7011fb54fa3c2b2390a2cf0f9564d0fe9.pdf
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de software. 2.
ed. Rio de Janeiro, RJ: Elsevier, 2016.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem
pro�ssional. 9. ed. Porto Alegre, RS: AMGH, 2021.
TESTES DE SOFTWARE – TESTE CAIXA-BRANCA E CAIXA-PRETA. [S. l.: s. n.], 2017. 1 vídeo
(4min34s). Publicado pelo canal Canal TI. Disponível em:
https://www.youtube.com/watch?v=QyXN_zAhqJA&t=266s. Acesso em: 18 out. 2021.
Aula 4
ASSOCIAÇÃO BRASILERIA DE NORMAS TÉCNICAS. NBR ISO 9000. Sistema de gestão da
qualidade – Fundamentos e vocabulário. Rio de Janeiro, RJ: ABNT, 2005.
BOEHM, B. W., BASILI, V.R. Software Defect Reduction Top 10 List. IEEE Computer, v.
34, n. 1, p. 135-137, jan. 2001. Disponível em:
https://ieeexplore.ieee.org/document/962984/citations#citations. Acesso em: 14 mar.
2022.
DEMING, W. Out of the Crisis. Cambridge: MIT Press, 1986.
GLASS, R. De�ning Quality Intuitively. IEEE Software, p. 103-104, maio 1998.
HORCH, J. Practical Guide to software Quality Management. 2. ed. Londres;
Norwood: Artech House, 2003.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem
pro�ssional. 8. ed. Porto Alegre, RS: AMGH, 2016.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem
pro�ssional. 9. ed. Porto Alegre, RS: AMGH, 2021.
MORAIS, L. Qualidade de software. Revista Engenharia de Software, ed. 29, 2010.
Disponível em: https://www.devmedia.com.br/qualidade-de-software-engenharia-de-
software-29/18209. Acesso em: 14 mar. 2022.
SCHULMEYER, G.; MCMANUS, J. (eds.). Handbook of Software Quality Assurance. ed.
[S. l.]: Prentice Hall, 1998.
VENNERS, B. Design by Contract: a conversation with Bertrand Meyer. Artima
Developer, 2003. Disponível em: https://www.artima.com/articles/design-by-contract .
Acesso em: 14 mar. 2022.
https://www.youtube.com/watch?v=QyXN_zAhqJA&t=266s
https://ieeexplore.ieee.org/document/962984/citations#citations
https://www.devmedia.com.br/qualidade-de-software-engenharia-de-software-29/18209
https://www.devmedia.com.br/qualidade-de-software-engenharia-de-software-29/18209
https://www.artima.com/articles/design-by-contract
Imprimir
INTRODUÇÃO
A engenharia de software evoluiu muito nos últimos anos e trouxe consigo uma disciplina essencial ao ciclo de
desenvolvimento dos programas e à qualidade do produto de software, visto que, na atualidade, não é mais
opcional realizar testes para garantir a qualidade e a melhor experiência de uso dos produtos de softwares. 
A disciplina de testes passou a ser mandatória no processo de desenvolvimento de aplicações e soluções de
software e foi incorporada à vida dos desenvolvedores e engenheiros de software.
Nessa aula, você aprenderá sobre os conceitos e o surgimento das necessidades dos testes de aplicações de
software, os tipos de testes e como aplicá-los no processo de validação das aplicações. 
Acompanhando essa aula e assistindo aos vídeos, você terá a compreensão sobre as formas de testes em
soluções de software e como utilizá-las no seu dia a dia pro�ssional.
OS DIFERENTES NÍVEIS DA AUTOMAÇÃO DE UM PROCESSO
O desenvolvimento de uma solução de software tem como objetivo principal atender a uma necessidade ou
resolver um problema. Nesse sentido, podemos ter, por exemplo, uma aplicação de software que realiza a
automação de um processo até então realizado de forma manual, ou um aplicativo de celular que se propõe a
substituir um processo de agendamento de consultas médicas que é realizado de forma manual e através de
ligações telefônicas.
Tendo estes cenários em mente, a partir do desenvolvimento de uma aplicação de software, surgem as
necessidades de realização de testes e validações nesses sistemas de acordo com os vários níveis de
automação que os programas trazem em decorrência da substituição e da modernização de um processo
existente.
Historicamente, as indústrias iniciaram o uso da automação de processos buscando acelerar tarefas e
diminuir os prazos de entrega de seus produtos e serviços. Assim, surgiu o chamado controle de qualidade, o
qual, através de inspeções de amostras, evoluiu para o controle de inspeções automáticas. Fazendo uma
comparação com a área de tecnologia, mesmo tendo resolvido um problema quando tarefas manuais são
substituídas por instruções de códigos de programação, estes programas precisam ser testados e validados
para garantir a qualidade mínima no produto de software.
A automação de processos manuais através da criação e do desenvolvimento de sistemas de informação pode
ser aplicada como solução de automação de tarefas manuais sujeitas a erros humanos, cujo uso da tecnologia
passa a trazer o benefício de minimizar falhas e reduzir custos para as empresas.
Dentre os benefícios que a automação de processos oferece, podemos citar:
• Redução de custos: automatizar processos demanda um número menor de colaboradores para as
empresas, já que as tarefas passam a ser executadas por programas ou aplicações de software e com maior
velocidade.
• Maior produtividade: processos automatizados podem ser executados 24 horas por dia, sete dias por
semana, gerando um resultado superior em relação à produtividade de tarefas executadas de forma manual.
• Melhora na qualidade: a automação de um processo cria padrões de desenvolvimento, de testes e de
implantação de soluções, permitindo às empresas investirem na melhoria contínua dos produtos, serviços e
experiência do cliente.
Aula 1
FORMAS DE TESTE DE SOFTWARE
De�nir o nível de automação ou a característica de equipamentos para executar um programa ou
software e con�gurar um sistema de automação que obtenha bons resultados na aplicação do teste.
37 minutos
É importante destacar que a engenharia de software possui vários modelos de desenvolvimento de
aplicações, como: prescritivo, uni�cado, XP e ágil (MASCHIETTO et al., 2020), sendo que cada modelo traz
uma ou mais etapas de testes da solução de software.
Um destes modelos de desenvolvimento é conhecido como Test-Driven Development (TDD), ou modelo de
desenvolvimento orientado por testes. Neste método de desenvolvimento, os cenários de testes são escritos e
executados antes da codi�cação que o caso de teste validará, sendo dividido em três etapas: escrever o caso
de teste, criar o código que passará no teste e refatoração do código (MASCHIETTO et al., 2020).
VIDEOAULA: OS DIFERENTES NÍVEIS DA AUTOMAÇÃO DE UM PROCESSO
Neste vídeo, você conhecerá em mais detalhes o modelo de desenvolvimento Test-Driven Development (TDD),
ou modelo de desenvolvimento orientado por testes.
Você verá como esse método pode ser utilizado e compreenderá o seu funcionamento e sua simplicidade
através de um exemplo com a codi�cação do caso de teste e do programa que será validado.
AS DIFERENTES ETAPAS NA ELABORAÇÃO DE UM SOFTWARE QUE PODEM SERTESTADAS
Como vimos no bloco anterior, a engenharia de software possui vários métodos de desenvolvimento, os quais
possuem suas próprias etapas de testes. Dentre eles, falaremos de dois exemplos bastante conhecidos:
modelo V e modelo ágil.
• Modelo V: muito utilizado na década de 1980, é conhecido também como modelo em cascata (waterfall), a
partir do qual grandes empresas construíram seus principais sistemas, que continuam em funcionamento até
os dias atuais. Este modelo de desenvolvimento de software possui etapas sequenciais, como modelagem de
requisitos, arquitetura do sistema, componentização e codi�cação, sendo que para cada uma dessas etapas
existe uma etapa de testes correspondente (MASCHIETTO et al., 2020), conforme segue:
- Modelagem de requisitos > Testes de aceite do usuário.
- Arquitetura > Testes de sistema.
- Componentes > Testes de integração.
- Codi�cação > Testes unitários.
Note que cada etapa de testes depende da conclusão da fase de desenvolvimento correspondente. Por
exemplo, para realizar testes unitários, é necessário que a codi�cação dos programas tenha sido concluída.
• Modelo ágil: o método ágil trouxe uma quebra de paradigmas em relação aos modelos tradicionais
(conhecidos também como modelos em cascata, ou waterfall) de desenvolvimento de software.
Nesse modelo de desenvolvimento, os times são multidisciplinares, incluindo área de negócios, arquitetura e
engenharia numa mesma equipe, e a organização das tarefas é baseada em ciclos de entrega menores
(releases), que duram entre dois e três meses, cujo objetivo é garantir entregas menores e frequentes. Esses
ciclos são distribuídos em iterações de uma a quatro semanas, e as equipes envolvidas possuem autonomia
para executar as tarefas planejadas. A metodologia ágil prevê a realização de cerimônias, que são as reuniões
diárias rápidas, as quais devem durar, no máximo, 15 minutos, e as reuniões de início e �m das iterações
(MASCHIETTO et al., 2020).
Em relação à realização de testes, a metodologia ágil trata os vários tipos de testes de sistemas como parte do
ciclo de desenvolvimento e, apesar de não existir uma etapa especí�ca para a realização dos testes, esta
tarefa de testes e validações é mandatória para a conclusão da entrega de soluções ou funcionalidades que
demandaram a codi�cação de novos programas ou alterações em aplicações de software já existentes.
Um dos métodos ágeis mais populares e mais utilizado atualmente é o Scrum. Ele está baseado na cultura
ágil, e a organização dos times prevê a de�nição de papéis e responsabilidades bem claros (MASCHIETTO et
al., 2020), trata as iterações como sprints e recomenda sua duração entre uma a quatro semanas.
Outro ponto relevante sobre o Scrum é que ele possui três pilares: transparência, inspeção e adaptação
(MASCHIETTO et al., 2020). No pilar da inspeção, deve residir o mindset do time em realizar os testes e as
validações em códigos de programas produzidos e alterados pela própria equipe, ou seja, no Scrum, não
Videoaula: Os diferentes níveis da automação de um processo
Para visualizar o objeto, acesse seu material digital.
existe uma etapa especí�ca de testes, e sim um pilar cultural, para que o time valide e teste tudo que será
entregue.
VIDEOAULA: AS DIFERENTES ETAPAS NA ELABORAÇÃO DE UM SOFTWARE QUE PODEM SER
TESTADAS 
Neste vídeo, você conhecerá, primeiramente, o método V de desenvolvimento de software e entenderá
porque este método possui esse nome. Na segunda parte, você acompanhará uma comparação entre o
método tradicional de desenvolvimento de software conhecido como cascata e o método ágil Scrum,
amplamente utilizado no mercado da Tecnologia da Informação.
ELABORAÇÃO DE REQUISITOS MÍNIMOS PARA A EXECUÇÃO DO SOFTWARE, PÚBLICO-ALVO E
OBJETIVO
De�nir os requisitos de um sistema ou solução de software é uma das etapas mais cruciais no ciclo de
desenvolvimento dentro da engenharia de software, porque existem requisitos de negócios, funcionais, de
qualidade ou não funcionais. Desta forma, pessoas de áreas diferentes, como negócio, arquitetura e
tecnologia, precisam estar próximas para que os requisitos de�nidos sejam o mais coerentes possível com as
necessidades apresentadas pelos clientes e potenciais usuários.
O levantamento de requisitos de um software pode ser realizado através de reuniões ou entrevistas com os
usuários das áreas de negócios ou os demandantes da necessidade ou do problema que se quer resolver. É
possível também realizar o levantamento de requisitos analisando um sistema ou processo já existente em
funcionamento.
Os resultados desses levantamentos devem ser registrados em formas de casos de uso descritivos e grá�cos
para as metodologias tradicionais (cascata ou waterfall), ou os registros podem ser feitos através de histórias
de usuários, quando se estiver utilizando práticas ágeis.
• Casos de uso: os casos de uso, ou use cases, são instrumentos utilizados para documentar o levantamento
de cenários de utilização de um processo ou necessidade de uma área ou grupo de usuários. Na sua forma
grá�ca, um use case mostra as ações de usuários, suas interações com outras áreas ou sistemas, bem como o
�uxo de trabalho dos componentes e demais processos envolvidos no cenário descrito pelo caso de uso
(REINEHR, 2020).
Nos casos de uso, existem duas seções que ajudam na qualidade da entrega do produto de software para o
cliente: a seção pós-condição, que serve para descrever o estado esperado do software ao �nal da execução
do caso de uso, e a seção �uxo de exceção,  na qual devem ser mapeados todos os eventos e possibilidades
de falhas e erros na execução dos �uxos daquele caso de uso.
• Histórias de usuário: muito semelhantes aos use cases, as histórias de usuário são utilizadas em
metodologias ágeis, como o Scrum, no qual o registro dos requisitos da solução de software segue um padrão
de escrita semelhante a um pedido. É através das histórias de usuário que as tarefas da demanda serão
criadas, ou seja, codi�cação da história, testes da história, e assim com as demais tarefas necessárias para
concluir a história de usuário.
As histórias de usuários devem ter o seguinte formato:
“Como um <tipo de usuário ou cliente> eu quero/preciso <o que é necessário> para <motivo ou valor da
demanda>”
Exemplo: Como um cliente do banco ABC eu preciso receber meu cartão de crédito para realizar
compras.
Em geral, no Scrum, o Product Owner (PO) é o responsável por escrever as histórias de usuários com base nas
conversas e nos levantamentos realizados junto às áreas de clientes ou de negócios.
As histórias de usuários possuem uma seção chamada critério de aceite, em que a equipe registra o que deve
ser testado e validado quando a história for concluída.
Videoaula: As diferentes etapas na elaboração de um software que podem ser testadas
Para visualizar o objeto, acesse seu material digital.
VIDEOAULA: ELABORAÇÃO DE REQUISITOS MÍNIMOS PARA A EXECUÇÃO DO SOFTWARE,
PÚBLICO-ALVO E OBJETIVO
Neste vídeo, você verá um exemplo de um use case de um cenário de uso de serviços bancários, em que será
comentado como essa ferramenta auxilia no levantamento de requisitos de software.
Você verá também alguns exemplos de histórias de usuário com suas partes principais, mostrando a forma de
utilização dessa ferramenta para o levantamento de requisitos em projetos ágeis. 
ESTUDO DE CASO
Considere o cenário a seguir para o estudo de caso dessa aula.
Você foi contratado recentemente por uma empresa de soluções de software e está participando das
discussões sobre a modernização de um dos principais produtos da empresa. Na semana passada, durante a
reunião de checkpoint, �cou de�nido que a nova versão do software precisa seguir as práticas ágeis com o
método Scrum e que deve ser considerado que nem todos os envolvidos têm conhecimento dessa
metodologia.
No �nal da reunião, seu gestor solicitou a você um levantamento e uma avaliação sobre os seguintes pontos
críticos relacionados ao projeto de modernização:1. É necessário que você prepare um resumo com as vantagens e desvantagens sobre o uso das práticas ágeis
com Scrum nesse projeto de modernização.
2. Durante a reunião, algumas pessoas trouxeram a sugestão de criar use cases (casos de uso) para
mapeamento dos requisitos já existentes na versão atual do software. Seu gestor está preocupado e quer
saber de você se essa sugestão pode gerar algum con�ito com a adoção do ágil.
RESOLUÇÃO DO ESTUDO DE CASO
Considerando a necessidade de modernização da solução de software.
1.  É necessário que você prepare um resumo com as vantagens e desvantagens sobre o uso das práticas
ágeis nesse projeto de modernização. O desenvolvimento ágil com Scrum tem sido usado largamente na área
de tecnologia da informação, suportando todo o ciclo de desenvolvimento de software. Seguem algumas
vantagens e desvantagens:
Vantagens: 
•  O Scrum como método ágil permite realizar entregas de software menores e com maior frequência através
de iterações curtas com duração entre uma e quatro semanas.
•  Equipes multidisciplinares, incluindo negócio, arquitetura e engenharia.
•  Cerimônias diárias e no início e �m de cada sprint.
•  Histórias de usuários para registro dos requisitos da versão existente do software que será modernizado.
•  Critérios de aceitação das histórias que permitem testar e validar a história antes da entrega.
Desvantagens: 
•  Mudança cultural.
•  Novos processos e novas ferramentas.
2.  Durante a reunião, algumas pessoas trouxeram a sugestão de criar use cases (casos de uso) para
mapeamento dos requisitos já existentes na versão atual do software. Seu gestor está preocupado e quer
saber de você se essa sugestão pode gerar algum con�ito com a adoção do ágil.
Apesar de não ser muito habitual, não há qualquer impedimento em utilizar use cases para levantamento de
requisitos aliado às práticas ágeis do Scrum. Nesse caso, pode ser necessário organizar o time de uma forma
não totalmente como recomenda o ágil por conta dos papéis bem de�nidos pelo Scrum; outra opção seria
incluir no planejamento das sprints o levantamento dos requisitos utilizando use cases.
Videoaula: Elaboração de requisitos mínimos para a execução do software, público-alvo e objetivo
Para visualizar o objeto, acesse seu material digital.
 Saiba mais
A disciplina de testes de software tem evoluído muito nos últimos anos, porque é através dos testes que
se garante a qualidade da aplicação ou do sistema de software que será utilizado pelos clientes de uma
empresa. Nesse cenário, surge o analista de testes. Você sabe o que faz ou como se tornar um analista
de testes? Saiba mais, acessando: https://www.zup.com.br/blog/como-se-tornar-analista-de-testes.
Acesso em: 30 jan. 2022.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Garantir que o aplicativo de celular ou o site de vendas de produtos esteja funcionando adequadamente e
que as várias transações on-line entre pagamentos e entregas de produtos estejam sendo efetivadas com
sucesso são exemplos dos desa�os que obrigam as empresas de tecnologia a adotarem processos de
qualidade em suas soluções e aplicações de software.
Essa qualidade de software exigida e esperada pelos clientes somente pode ser garantida através da não
tolerância a falhas ou erros nos programas e aplicações construídos, sendo necessário a execução dos testes
de software.
Nessa aula, você aprenderá sobre as etapas e os tipos de testes de aplicações de software e como aplicá-los
no processo de validação das aplicações. 
Acompanhando essa aula e assistindo aos vídeos, você terá a compreensão sobre as etapas de testes de
software e como utilizá-las no seu dia a dia pro�ssional.
TESTES DE APLICATIVOS E SOFTWARES: ETAPAS DE TESTAGEM
Desenvolver soluções de software com qualidade não é mais uma opção para as empresas de tecnologia. De
fato, aplicativos de celular e sites de comércio eletrônico, por exemplo, que apresentam falhas intermitentes,
erros de acessos ou até uma experiência ruim de navegação, tendem a perder usuários e clientes por não
apresentarem um nível aceitável de qualidade e, por consequência, perda de receita.
Diante desse cenário, desenvolver e manter soluções de software se tornou um verdadeiro desa�o para as
empresas que utilizam a tecnologia para os seus negócios. Para vencer este desa�o de entregar aplicações e
soluções de software com qualidade, as áreas de tecnologia dessas empresas passaram a implementar os
testes de software.
Os testes de software têm como principal objetivo garantir que a versão do software que será liberado para
uso está em acordo com as expectativas e necessidades do cliente. Os testes possuem algumas etapas a
serem executadas, cujo objetivo é eliminar erros, falhas ou defeitos antes que a aplicação ou o sistema de
software seja lançado para uso pelos clientes ou usuários. Erro, falha e defeito, muitas vezes, são conhecidos
como bugs, e apesar de serem termos parecidos, possuem signi�cados um pouco diferentes:
• Erro: código escrito por um programador e que gerou um programa com falha.
• Falha: ocorre quando um programa com erro é executado e interfere no funcionamento esperado.
• Defeito: uma ação inesperada do sistema ou solução de software, geralmente, decorrente de uma falha.
Aula 2
TESTES DE PROGRAMAÇÃO E TESTES DE CAMPO
Analisar o nível de interação que os testes de aplicativos e softwares devem ter com os usuários para
serem validados, a duração da testagem e os objetivos a serem alcançados.
40 minutos
https://www.zup.com.br/blog/como-se-tornar-analista-de-testes
As etapas de testes estão associadas à codi�cação e ao ciclo de desenvolvimento da solução de software, ou
seja, cada etapa de testes de software garante a qualidade da parte da solução que estiver sendo testada.
As etapas de testes de software estão divididas em duas categorias: testes de veri�cação e testes de
validação, conforme descrito a seguir:
• Testes de veri�cação: são testes realizados sem a execução da aplicação ou do software. Por exemplo,
veri�cação de documentações ou desenhos da solução. Suas etapas são:
- Testes do modelo de negócios: veri�cação se o modelo de negócios está aderente às necessidades do
cliente.
- Testes dos requisitos: veri�cação da aderência dos requisitos ao modelo de negócios.
- Testes da análise e modelagem: veri�cação se a modelagem atende aos requisitos de�nidos.
- Testes da implementação: veri�cação se os processos para implementação estão aderentes às
necessidades e aos requisitos de�nidos para a solução.
• Testes de validação: são testes que garantem a qualidade do produto de software, ou seja, são validados os
códigos de programas, os serviços e as funcionalidades do sistema.
- Testes de unidade: validação isolada de um programa ou trecho de código, conhecidos também como
testes unitários.
- Testes de integração: validação das partes menores do software ou de componentes internos ou externos
de forma integrada.
- Testes de sistema: validação do sistema como um todo ou de funcionalidades.
- Testes de aceitação: validação do cliente e dos requisitos do software.
Nem todas as etapas de testes precisam ser executadas, o que signi�ca que, de acordo com a criticidade ou
complexidade da aplicação de software, pode-se executar mais ou menos etapas de testes.
VIDEOAULA: TESTES DE APLICATIVOS E SOFTWARES: ETAPAS DE TESTAGEM
Neste vídeo, você conhecerá mais detalhes sobre os testes unitários. Será mostrado como eles se relacionam
com os demais tipos de testes, quem os executa e qual o impacto destes testes na entrega da solução �nal.
Você verá também um exemplo de código de teste unitário escrito para a linguagem Java.
TÉCNICAS DE TESTES DE SOFTWARE
Testar soluções de software signi�ca validar cada funcionalidade, programa ou trecho de código com a
�nalidade de encontrar erros ou bugs e corrigi-los antes da entrega do produto de software para o cliente.
Para garantir a qualidade do software a serentregue para uso pelo cliente, as etapas de testes devem ser
executadas e, dentro delas, existem algumas técnicas que podem ser aplicadas de acordo com a necessidade
da parte da solução ou da funcionalidade do sistema que será validada.
As técnicas de testes de software mais conhecidas e mais utilizadas são:
• Caixa branca: nessa técnica, o teste é realizado pelo próprio desenvolvedor e recebe esse nome de caixa
branca por utilizar o código da aplicação que está sendo testada. Nos testes caixa branca, o desenvolvedor
utiliza diretamente o código da solução para realizar os testes e as validações. A técnica dos testes caixa
branca pode ser aplicada na execução dos testes de unidade, conhecidos também como testes unitários. Os
testes unitários podem ser escritos de forma manual ou automática, utilizando ferramentas, como JUnit,
Jasmine ou NUnit, dentre várias outras disponíveis.
• Caixa preta: conhecida também como teste funcional, por possuir em seu contexto a validação de
funcionalidades da aplicação de software. Essa técnica de testes recebe esse nome porque, na execução dos
testes, não se sabe o conteúdo dos componentes ou as funcionalidades que estão sendo testados. O objetivo
dos testes caixa preta é validar uma funcionalidade ou um componente de software sem se preocupar com o
código escrito para esta parte da solução de software que está sendo validada. A técnica dos testes de caixa
preta pode ser aplicada na execução dos testes de integração ou testes integrados e nos testes de
Videoaula: Testes de aplicativos e softwares: etapas de testagem
Para visualizar o objeto, acesse seu material digital.
performance e desempenho da solução de software. Estes últimos são conhecidos também como testes não
funcionais, já que performance e desempenho, geralmente, são requisitos não funcionais da aplicação de
software.
• Caixa cinza: essa técnica é uma combinação entre as técnicas de caixa branca e caixa preta, ou seja,
algumas partes do código são conhecidas, estão acessíveis e podem ser validadas, enquanto outras partes ou
outros componentes que fazem parte da execução do teste caixa cinza são testados como a técnica da caixa
preta. A técnica dos testes de caixa cinza pode ser aplicada em cenários de testes de integração, em que a
validação do código também é necessária. Outro cenário onde se pode utilizar a técnica de caixa cinza é nos
testes de validações de informações atualizadas em banco de dados, em que parte da validação exige a
execução de consultas ou ações na base de dados através de código.
Existem outras técnicas de testes menos populares que são mais especí�cas para os tipos de soluções de
software, como os testes de regressão, os quais permitem que, através de ferramentas de automação, seja
garantido que novas versões de um software não implantem falhas ou defeitos em componentes não
modi�cados.
Nos cenários de aplicativos de celular e de jogos, as técnicas de testes, além de seguirem o ciclo de
desenvolvimento de software, incluem ainda os usuários na realização de testes através de técnicas, como
premiação por etapas superadas, por horas de uso, recompensas e bônus.
VIDEOAULA: TÉCNICAS DE TESTES DE SOFTWARE
Neste vídeo, serão apresentadas as técnicas de testes caixa branca e caixa preta, ilustrando e exempli�cando
o uso delas no processo de validação de soluções de software e uma comparação entre as duas formas de
testes.
Será apresentada, ainda, a técnica de testes caixa cinza como uma combinação entre os testes caixa branca e
caixa preta. 
TESTES ALPHA, BETA, GAMA E DE PERFORMANCE
O produto de software, para ser liberado para o usuário �nal, precisa passar por várias etapas de testes, que
incluem os processos de veri�cação e validação da aplicação.
Para ajudar a conduzir o processo de validação, a aplicação ou solução de software é liberada em versões ou
releases-versão consolidadas de um software disponibilizadas para utilização, em que cada versão liberada
para testes tem o objetivo de garantir a melhor qualidade do produto através da correção de erros e bugs
identi�cados pelos testes realizados.
A primeira versão liberada para testes é chamada de alpha, na qual se origina o nome de testes alpha, nesse
cenário um número reduzido de usuários, normalmente desenvolvedores ou testadores executam testes de
caixa branca ou de caixa preta e registram as falhas e defeitos para que as equipes de desenvolvedores
responsáveis pela liberação da versão alpha que está em teste possam realizar as correções e ajustes
necessários.
Após a correção dos eventuais bugs da versão alpha, a equipe responsável pela aplicação está pronta para a
liberação da versão beta da aplicação para testes. Quando a versão beta é liberada, o público-alvo de
testadores passa a ser, em geral, um grupo de usuários da aplicação externos, porém em número reduzido.
Em seguida, inicia-se o ciclo de testes beta com os usuários reportando os bugs e problemas identi�cados.
Esses bugs são direcionados às equipes de desenvolvedores da aplicação, para que as correções sejam
realizadas, e uma nova versão beta será liberada com essas correções. Da mesma forma que ocorre com os
testes alpha, os testes beta são encerrados somente quando todos os bugs da versão beta estiverem
corrigidos pelos desenvolvedores e validados pelos usuários que participam dessa etapa de validação.
Existem, ainda, os chamados testes gama, que se referem a uma versão de software liberada para o usuário
�nal, geralmente de forma pouco validada, com o objetivo intencional e de forma não planejada que os
usuários encontrem erros e reportem aos desenvolvedores para serem corrigidos.
Videoaula: Técnicas de testes de software
Para visualizar o objeto, acesse seu material digital.
Para a validação do desempenho da aplicação ou solução de software, algumas técnicas de testes podem ser
aplicadas. Os testes de performance, por exemplo, podem validar a estabilidade do sistema ou solução de
software, a capacidade máxima e mínima de cargas de processamento e o desempenho e tempo de resposta,
ou se esse desempenho se mantém aceitável diante da execução de cenários de alto volume de transações e
de processamento.
É possível criar painéis para acompanhamento do desempenho e da performance das aplicações para
simpli�car o trabalho dos desenvolvedores, assim, quando uma versão do software é liberada para testes
alpha ou beta, estes painéis de monitoração auxiliarão os desenvolvedores envolvidos no processo de
desenvolvimento da solução de software a visualizar e analisar os resultados dos testes de performance,
permitindo a estes desenvolvedores atuar nos ajustes e correções dos programas que foram liberados para
testes.
VIDEOAULA: DIFERENTES FORMAS DE TESTAGEM
Neste vídeo, será apresentado o conceito de teste alpha e de teste beta e as principais aplicações do uso
desses tipos de testes nas aplicações de software.
Será mostrado e comentado o �uxo de desenvolvimento de softwares e a relação com os testes alpha e beta
até que o software seja liberado na sua versão �nal. 
ESTUDO DE CASO
Considere o cenário a seguir para o estudo de caso dessa aula.
A empresa Beleza & Beleza Cosméticos S.A. possui, atualmente, uma solução de software que permite aos
seus parceiros (revendedores) acessar o portal pela internet e registrar seus pedidos, gerenciar sua carteira de
clientes e fazer indicações de novos revendedores para conquistar bônus.
A empresa está planejando lançar um aplicativo de celular para facilitar o trabalho de seus parceiros, mas se
preocupa muito com a qualidade desse aplicativo, já que o site funciona sem grandes problemas.
A empresa de tecnologia Softwares e Testes Ltda., onde você trabalha como analista de testes, está
concluindo a proposta para fechar o negócio com a Beleza & Beleza Cosméticos S.A. para a construção e a
implantação do aplicativo.
Com seus conhecimentos sobre testes de software, você �cou responsável por preencher a parte da proposta
que trata de qualidadedo aplicativo de software.
Elabore uma proposta sobre qualidade do aplicativo, incluindo as etapas e os tipos de testes que sua empresa
adota e como estes testes podem garantir a qualidade do software que será entregue à empresa Beleza &
Beleza Cosméticos S.A.
RESOLUÇÃO DO ESTUDO DE CASO
Para garantir a qualidade do aplicativo, será necessário submetê-lo aos processos de testes de veri�cação e
de validação de software. Estes processos possuem etapas que fazem parte do ciclo de desenvolvimento de
software, o que signi�ca que os testes serão realizados durante todo o desenvolvimento da solução de
software.
No processo de veri�cação, toda a documentação produzida sobre requisitos, �uxo de dados e arquitetura
da solução é analisada com o objetivo de rati�car tudo que foi de�nido para a construção e implantação do
aplicativo de software.
No processo de validação, sendo considerado o código já concluído, podemos destacar a realização das
etapas dos testes unitários e dos testes de integração, em que cada trecho de código pode ser avaliado,
testado e corrigido, se necessário, bem como os testes de integração garantem a comunicação entre os
componentes da aplicação.
Ainda no processo de validação, podemos incluir a etapa de liberação das versões alpha e beta, sendo que,
nos testes beta, os parceiros da Beleza & Beleza Cosméticos S.A. podem ser incluídos no plano de testes
das novas versões do aplicativo, para identi�car e reportar falhas ou bugs.
Videoaula: Diferentes formas de testagem
Para visualizar o objeto, acesse seu material digital.
 Saiba mais
Garantir a qualidade dos produtos de software não é uma tarefa fácil para as empresas de tecnologia.
Prover a melhor experiência de uso para seus clientes tem sido a prioridade número 1 das empresas que
entregam serviços de tecnologia através de aplicativos e soluções de software.
Nesse sentido, a Net�ix é um exemplo de empresa que vem criando e elevando os padrões de qualidade
e de melhoria na experiência dos clientes no uso de seu produtos e serviços.
O serviço “Chaos Monkey”, criado pela Net�ix em 2010, é um bom exemplo dessa ruptura de evolução
nos modelos e padrões de qualidade.
Saiba mais, acessando:
• SEROTER, R.; SANT’ANNA, T. Chaos Monkey: mais um projeto open source da Net�ix. InfoQ, 2012.
Disponível em: https://www.infoq.com/br/news/2012/08/net�ix-chaos-monkey/. Acesso em: 5 fev. 2022.
• CHAOS MONKEY. Disponível em: https://net�ix.github.io/chaosmonkey/. Acesso em: 5 fev. 2022.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Entregar um produto de software com qualidade é a garantia de que os clientes e usuários terão uma
ferramenta con�ável e segura para atender às suas necessidades. Em busca dessa qualidade, pro�ssionais de
tecnologia da informação, como engenheiros, arquitetos, desenvolvedores e testadores, possuem um papel
fundamental nessa jornada de construir e entregar aos clientes soluções de softwares que ofereçam a melhor
experiência.
Uma forma efetiva de alcançar esse objetivo de produzir e entregar software com qualidade é através dos
métodos de testes das aplicações.
Nesta aula, você aprenderá sobre os métodos de testes de software e como a combinação desses métodos
pode elevar o nível dos resultados dos testes. Você verá também a relevância do envolvimento dos clientes e
usuários �nais nos processos de testes de software e a importância dos treinamentos sobre o uso da
aplicação e do suporte e atendimento aos usuários.
COMO OS DIFERENTES MÉTODOS DE TESTAGEM PODEM OTIMIZAR O ESPAÇO E O DESEMPENHO
DE UM PROGRAMA
Muitas são as técnicas de testes de software que podem ser aplicadas e combinadas para tornar a aplicação
uma solução de software com alto padrão de qualidade.
Algumas dessas técnicas de testagem são descritas a seguir:
Aula 3
IMPORTÂNCIA DE COMBINARMOS VÁRIOS MÉTODOS DE
TESTAGEM
Nesta aula, você aprenderá sobre os métodos de testes de software e como a combinação desses
métodos pode elevar o nível dos resultados dos testes.
35 minutos
https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey/
https://netflix.github.io/chaosmonkey/
• Test-Driven Development (TDD): essa técnica é conhecida como desenvolvimento orientado a testes.
Nela, o desenvolvedor cria primeiro o código de teste e, depois, o código da aplicação para o teste que foi
criado. Para muitos desenvolvedores, pode soar estranho ter que construir primeiro os testes e somente
depois codi�car a aplicação e os componentes, mas, apesar disso, essa técnica é muito utilizada, e sua
proposta é que o código da aplicação já esteja validado quando for construído.
• Testes de regressão: nessa técnica, os testes são realizados sempre que ocorre uma mudança em partes do
código da aplicação e as demais funcionalidades não alteradas precisam ser testadas e validadas para garantir
que as alterações de código realizadas não afetaram as partes não modi�cadas da aplicação. Apesar de
garantir a qualidade de todo o software, essa técnica torna-se muito demorada e eleva os custos de
desenvolvimento da solução de software.
• Testes smells: essa técnica se utiliza dos smells, ou cheiros (no sentido de suspeitas), de que algo não
parece bem no código dos testes unitários que foram escritos. O objetivo é evitar que se tenham casos de
testes mal de�nidos ou mal construídos que introduzam erros e falhas na aplicação de software.
• Code smells: semelhante à técnica dos testes smells, com a diferença que o smell vem do código da
aplicação. Aqui, o objetivo é que algo que pareça estranho no código da aplicação seja corrigido, removido ou,
no mínimo, veri�cado, para garantir que o código da solução de software continue sendo executado com
qualidade.
• Cobertura de testes: é uma métrica utilizada para garantir que um programa, classe ou parte de uma
aplicação possua um número ou percentual de execução de testes unitários bem-sucedidos. A fórmula básica
para esse cálculo considera o seguinte:
Percentual de cobertura = quantidade de comandos de testes / quantidade de comandos do programa.
Não existe um percentual padrão para que a cobertura de testes seja considerada aprovada. Alguns
desenvolvedores, por exemplo, consideram uma cobertura de testes válida quando o percentual está entre
90% e 100%.
• Testes mocados: essa técnica permite simular validações nos códigos de testes sem a necessidade de
adequação no código da aplicação ou nas classes de testes unitários. É muito utilizada nos cenários em que há
di�culdade de produzir o contexto real de um ambiente produtivo.
É importante considerar que as técnicas mostradas podem ser combinadas entre si de acordo com o
ambiente onde a aplicação é executada, bem como considerando-se o prazo, os custos e o nível e a qualidade
que se busca na entrega da solução de software.
VIDEOAULA: COMO OS DIFERENTES MÉTODOS DE TESTAGEM PODEM OTIMIZAR O ESPAÇO E O
DESEMPENHO DE UM PROGRAMA
Neste vídeo, você entenderá em mais detalhes o uso da técnica dos testes de regressão, qual a sua
importância para a qualidade do software e quais as implicações em utilizá-la.
Será apresentado o impacto sobre os custos e os prazos de entrega do software quando se adota a técnica
dos testes de regressão. 
A IMPLEMENTAÇÃO DO PROGRAMA E A TESTAGEM POR USUÁRIOS REAIS
O ciclo de desenvolvimento de software permite que a implementação do código de uma solução de software
seja realizada por um ou mais desenvolvedores, dependendo do porte da aplicação ou mesmo da
metodologia de desenvolvimento adotada.
As equipes de desenvolvimento, em geral, possuem autonomia para de�nir a linguagem de programação a
ser utilizada, considerando complexidade, curva de aprendizagem, maturidade da equipe e implementação
dos casos de testes. Além da linguagem de programação, a equipe, em conjunto com a engenharia e a
arquitetura de software, pode de�nir o ambiente de execução da aplicação e se, por exemplo, a aplicação será
executada em ambiente tradicional (virtualizado)ou em ambiente de nuvem, se utilizará uma solução de
contêineres ou servidores virtuais, en�m, é importante lembrar que para cada decisão na estratégia de
desenvolvimento haverá a necessidade da realização dos testes de software nos programas que serão
construídos.
Videoaula: Como os diferentes métodos de testagem podem otimizar o espaço e o desempenho de um programa
Para visualizar o objeto, acesse seu material digital.
Seguindo a necessidade dos testes de software, para cada trecho de código escrito será necessário um caso
de teste de unidade ou teste unitário para validar esse código que foi produzido.
Nesse sentido, podemos perceber a importância dos testes unitários para a aplicação como um todo. Testes
unitários são do tipo caixa branca. Os testes caixa branca recebem esse nome porque permitem a validação
do código escrito durante a execução dos testes, ou seja, validar o código é parte do processo de execução de
testes caixa branca. Nesse tipo de teste, os usuários da aplicação ou sistema não são envolvidos, visto que o
objetivo é validar as unidades de códigos construídas para a solução �nal.
Outros aspectos importantes dos testes unitários são em relação à quantidade e à automação. Normalmente,
os testes unitários são em maior número do que os demais tipos de testes, como os de integração ou
funcionais, cuja criação e execução podem utilizar ferramentas que minimizam o esforço e podem fazer a
geração desses testes unitários de forma automática.
Além dos testes de unidade, podemos destacar os testes de integração e os testes funcionais. Os testes
integrados são do tipo caixa preta, cuja validação tem foco na execução de um componente de software e de
seu comportamento sem que haja preocupação em validar o código que é executado naquele componente
que está em validação. Em geral, nos testes de integração, os usuários da aplicação ou sistema ainda não são
envolvidos, porque este tipo de teste tem um caráter mais técnico do que funcional.
Com relação aos testes funcionais, estes também são do tipo caixa preta, ou seja, não há validação de código
da aplicação, e os usuários da aplicação ou sistema são envolvidos para que as funcionalidades desenvolvidas
sejam validadas com a visão de um usuário real do sistema.
Uma outra forma de envolver usuários reais para validação de aplicações e sistemas é fazendo o lançamento
da versão beta da solução, aquela em que nem todas as funcionalidades do sistema foram testadas e
validadas, mas a equipe responsável entendeu que é o momento de envolver os usuários e clientes para a
validação daquela versão beta. Em cenários como esse, dizemos que a aplicação está em fase de testes beta.
VIDEOAULA: A IMPLEMENTAÇÃO DO PROGRAMA E A TESTAGEM POR USUÁRIOS REAIS
Neste vídeo, será ilustrado o cenário de liberação de software para utilização pelos usuários e quais as
implicações.
Será comentado sobre o envolvimento dos usuários na realização dos testes funcionais e nos testes beta. 
A IMPORTÂNCIA DO TREINAMENTO E DA EQUIPE DE SUPORTE
Uma das etapas mais aguardadas pelas equipes de desenvolvimento de software e pelos usuários e clientes é
o momento de lançamento ou liberação da solução de software. Depois de vencidas todas as etapas de
validação da solução como um todo, chega o momento de publicar a aplicação e acompanhar de forma atenta
os usuários na utilização do sistema.
E para tornar esse momento possível, as equipes envolvidas na entrega da solução de software precisam estar
preparadas para transferir, o quanto antes, o conhecimento sobre o uso do sistema para o cliente da
aplicação que está sendo entregue.
Uma forma muito e�ciente de realizar essa transferência do conhecimento sobre a aplicação é oferecendo
treinamentos aos usuários. Esses treinamentos podem ser formais, com agendas recorrentes para alcançar o
maior número possível de usuários, ou podem ser treinamentos através de vídeos curtos gravados, de cinco a
sete minutos, explicando o uso da aplicação, detalhando as principais funcionalidades e informações de dicas
de uso da aplicação de software. As documentações com passo a passo de uso de funcionalidades podem ser
uma forma alternativa de treinamento, buscando oferecer, junto às demais opções, a melhor experiência aos
clientes.
Um documento muito utilizado como apoio para os usuários é a Frequently Asked Questions (FAQ), ou
questões frequentemente perguntadas. Neste tipo de documento, são registradas as principais dúvidas e
perguntas dos usuários com suas respectivas respostas. Essa lista de perguntas e respostas �ca publicada em
alguma página de um site ou blog da aplicação, ou é disponibilizada para consulta de quem precisa de auxílio
na utilização da solução de software que está disponível para utilização.
Videoaula: A implementação do programa e a testagem por usuários reais
Para visualizar o objeto, acesse seu material digital.
São os treinamentos e a capacitação que habilitarão o colaborador da empresa a utilizar o software da melhor
forma, permitindo a essa pessoa realizar suas tarefas de forma mais rápida e com mais con�ança enquanto
utiliza o sistema.
Os treinamentos, de um modo geral, podem oferecer um canal de aproximação com o cliente, inclusive, para
receber seus feedbacks sobre a solução de software.
Parte do treinamento deve ser voltada a instruir os usuários em como obter suporte nos casos de dúvidas ou
problemas, então, além dos treinamentos, é necessário que haja uma equipe de suporte para orientar e
responder às solicitações dos usuários, disponíveis em vários canais de atendimento, como chat, e-mails ou
ferramentas de controle de chamados.
Essa equipe de suporte pode estar estruturada em dois ou três níveis de atendimento. O nível 1 responde a
dúvidas ou problemas simples, já para os problemas mais complexos, como bugs ou falhas, o nível 2 ou 3 de
atendimento estará pronto para responder às demandas e necessidades dos usuários.
Nesses atendimentos aos usuários, é fundamental que haja a preocupação nas equipes de suporte com a
experiência oferecida aos usuários, de forma que possam ser coletados os feedbacks dos usuários com
relação à experiência no atendimento recebido.
VIDEOAULA: A IMPORTÂNCIA DO TREINAMENTO E DA EQUIPE DE SUPORTE
Neste vídeo, será mostrado e comentado sobre a importância da documentação de usuário e suas formas de
utilização. 
Serão mostrados os exemplos do guia de usuário da ferramenta JUnit e da FAQ do produto S3 da AWS-
Amazon Web Services. 
ESTUDO DE CASO
Considere o cenário a seguir para o estudo de caso dessa aula.
A equipe de sustentação das aplicações que suportam o negócio da empresa onde você trabalha tem atuado
no suporte aos usuários e nas correções de bugs. 
Seu gestor reuniu a equipe de suporte da qual você faz parte e compartilhou a preocupação de que os
atendimentos e o suporte aos usuários aumentaram muito e solicitou que vocês de�nam um plano de ação
detalhado para identi�car as possíveis causas desse aumento de chamados pelos clientes e possíveis soluções
para este problema. Algumas pessoas da equipe argumentaram que é provável que a falta de documentação
ou de treinamentos pode estar causando esse aumento de acionamentos dos clientes à equipe de suporte.
Com base em seus conhecimentos sobre qualidade, testes e suporte ao usuário, elabore o plano de ação
detalhado solicitado pelo seu gestor.
RESOLUÇÃO DO ESTUDO DE CASO
Elaboração do plano de ação detalhado solicitado pelo seu gestor para identi�car as prováveis causas e
soluções possíveis para o problema de aumento de atendimentos realizados pela equipe de suporte da qual
você faz parte.
Após a análise dos atendimentos concluídos, foram identi�cadas as causas e suas soluções conforme segue:
• Causa 1: uma nova versão do software pode ter sido liberada sem passar pelos testes beta.
• Solução 1: retornar à versão anterior do software e submeter a versão atual com falhas aos testes alpha e
beta.
• Causa 2: falta de documentação de novas funcionalidadese de alterações de con�gurações da versão atual
do software.
• Solução 2: encaminhar o problema e a análise realizada para a equipe de desenvolvedores e testadores,
sugerindo a criação e a divulgação da documentação das novas funcionalidades e das con�gurações da
aplicação que foram alteradas.
Videoaula: A importância do treinamento e da equipe de suporte
Para visualizar o objeto, acesse seu material digital.
• Causa 3: instabilidade ou mudanças na infraestrutura onde a aplicação é executada.
• Solução 3: levantamento sobre as mudanças realizadas no ambiente de execução da aplicação e ajustes na
infraestrutura para estabilizar o ambiente que apresentou problemas.
 Saiba mais
Um termo utilizado por Kent Beck, em meados de 1990, e que mais tarde se popularizou através de
Martin Fowler, em seu livro Refactoring: improving the design of existing code, continua sendo utilizado
entre os desenvolvedores atualmente. Você sabe o que é code smell? Saiba mais, acessando:
https://coodesh.com/blog/dicionario/o-que-e-code-smell/. Acesso em: 9 fev. 2022.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Um produto de software, como aplicativos de celular, sites de comércio eletrônico, sistemas de serviços
bancários, entre várias outras soluções, possui um ciclo de vida de existência. Durante esse ciclo de vida, o
sistema ou a aplicação de software passa por várias etapas, como concepção, manutenção, redesenho da
solução, modernização e, por último, desligamento ou descontinuidade.
Nessa aula, você aprenderá sobre o ciclo de vida e a existência de uma solução de software, suas etapas, os
tipos de manutenção, a necessidade de atualizações e a substituição ou desativação de um sistema ou
aplicação de software.
Acompanhando essa aula e assistindo aos vídeos, você entenderá como uma solução de software é criada,
mantida, evoluída, substituída ou desligada.
CICLO DE VIDA DE UM PROGRAMA, ELABORAÇÃO, UTILIZAÇÃO, ATUALIZAÇÃO E FIM DE VIDA
No início do ciclo de vida de uma solução de software, as etapas de desenvolvimento do software são
executadas iniciando pelo levantamento dos requisitos, cujo objetivo é mapear e registrar as necessidades
dos usuários e clientes que serão implementadas no software. Os requisitos de software podem ser
registrados em ferramentas, como casos de uso (use cases), ou histórias de usuários, dependendo da
metodologia adotada para o desenvolvimento da aplicação.
Em seguida, após o levantamento dos requisitos, o desenho da solução deve ser elaborado com o apoio das
equipes de arquitetura e engenharia de sistemas. Após essa etapa, inicia-se a construção ou codi�cação da
aplicação, e todo o processo de testes e validações se iniciam junto à codi�cação do sistema. Após as
validações, incluindo a validação e aceitação do usuário, o sistema ou aplicação está pronto para ser
implantado. Nesse momento, a solução está pronta para publicação e entra na etapa de utilização do
software.
Durante a etapa de utilização do software, os usuários passam a consumir as funcionalidades e os serviços
disponíveis na aplicação. Ao utilizar o software, eles podem encontrar di�culdades, podem ocorrer falhas e
erros que devem ser reportados à equipe de suporte do sistema, a qual, por sua vez, é responsável por
Aula 4
TEMPO DE DURAÇÃO DE UM PROGRAMA E A
IMPORTÂNCIA DE SUA ATUALIZAÇÃO
Nessa aula, você aprenderá sobre o ciclo de vida e a existência de uma solução de software, suas etapas,
os tipos de manutenção, a necessidade de atualizações e a substituição ou desativação de um sistema
ou aplicação de software.
39 minutos
https://coodesh.com/blog/dicionario/o-que-e-code-smell/
solucionar os problemas identi�cados, atender às solicitações dos usuários e realizar as correções de falhas e
bugs.
Todos os problemas, falhas e bugs reportados pelos usuários do sistema depois de analisados são priorizados
e corrigidos. Esse processo gerará uma nova versão de atualização da aplicação com as correções realizadas
pela equipe de suporte. Este ciclo de análise, priorização, correção e geração de nova versão ocorre de forma
contínua, e o objetivo é manter o produto de software em funcionamento de forma que continue atendendo
às necessidades de uso dos usuários e clientes.
Um outro cenário em que as aplicações podem sofrer atualização ocorre quando surge a necessidade de
atualização tecnológica, ou seja, nos casos em que algum componente do software entra em processo de
descontinuação (deprecated).
Muitos componentes de uma solução de software podem ser descontinuados (deprecated):  linguagens de
programação utilizadas na codi�cação, versões do sistema operacional para a execução da aplicação,
dependências e bibliotecas de código consumidas pela aplicação são exemplos de componentes da solução
de software que podem, ao longo do tempo ou por questões de falhas e bugs, precisar de atualização, o que
re�ete diretamente na atualização ou na necessidade de testes e validações da sua solução de software.
Quando a solução de software deixa de atender às necessidades dos seus usuários ou quando os custos de
manutenção se tornam elevados, o software, enquanto produto, pode entrar no processo de desativação.
O processo de desativação ou desligamento de uma solução de software pode exigir das equipes envolvidas
um esforço considerável, de acordo com a complexidade do software existente. Devem ser avaliadas as
alternativas, como: substituição do software atual por outra solução mais moderna, transferência de
funcionalidades para outros sistemas ou simplesmente o desligamento da aplicação.
VIDEOAULA: CICLO DE VIDA DE UM PROGRAMA, ELABORAÇÃO, UTILIZAÇÃO, ATUALIZAÇÃO E FIM
DE VIDA
Neste vídeo, será apresentado o ciclo de vida de uma solução de software com uma ilustração mostrando as
principais etapas do desenvolvimento e da manutenção do software.
Será apresentada também a etapa de desativação ou desligamento de um software e quando ela pode
ocorrer no ciclo de vida do software. 
A IMPORTÂNCIA DA ATUALIZAÇÃO PARA CORREÇÃO DE BUGS
Quando um software está em uso, costuma-se dizer que ele está produtivo. Este termo é uma referência ao
fato de o software possuir uma versão em execução no ambiente de produção, assim, ambiente produtivo ou
de produção é onde as aplicações de software são disponibilizadas para utilização pelos usuários.
Uma aplicação produtiva, por mais que tenha passado pelas etapas de testes e validações, pode apresentar
falhas ou bugs. Estes problemas, muitas vezes reportados pelos usuários da aplicação, precisam ser
corrigidos; além disso, existem necessidades de evolução ou ajustes em funcionalidades existentes ou
adequações da aplicação a novos ambientes. Todas essas tarefas são caracterizadas como atividades de
manutenção do software, ou seja, são atividades essenciais que mantêm a estabilidade e o bom
funcionamento das aplicações.
As manutenções de software podem ser: corretivas, adaptativas e evolutivas, conforme descritas a seguir:
• Corretivas: são manutenções que incluem correções de erros ou falhas identi�cadas em funcionalidades do
sistema e incluem correção de código, documentações ou con�gurações e procedimentos recomendados aos
usuários da aplicação. Normalmente, são manutenções emergenciais que resolvem problemas mais urgentes
que podem estar causando impacto para os usuários e clientes �nais.
• Adaptativas: esse tipo de manutenção surge quando há a necessidade de atualização de algum
componente no ambiente de execução da aplicação, por exemplo, mudanças de con�gurações de servidores,
novas versões de sistemas operacionais, alterações de hardware dos servidores ou atualizações
recomendadas pelos fabricantes de software de infraestrutura de tecnologia, como telecom
(telecomunicações) ou rede.
Videoaula: Ciclo de vida de um programa, elaboração, utilização, atualização e �m de vida
Para visualizar o objeto, acesse seu material digital.
• Evolutivas: em geral, são manutenções planejadas,solicitadas pelos usuários do sistema ou por áreas
envolvidas com a solução de software. As manutenções evolutivas têm um caráter de tornar a aplicação mais
adequada ao seu uso, melhorando a experiência do usuário. Outra característica de manutenções evolutivas
são as atualizações de funcionalidades existentes, melhorando a performance ou o tempo de resposta dessas
funcionalidades.
Todos esses tipos de manutenções de software geram a necessidade de novos testes e validações, como
testes unitários, testes de integração e testes funcionais. Após essas validações, novas versões com essas
mudanças realizadas pelas manutenções serão implantadas em ambiente produtivo.
Seja qual for o tipo de atividade executada através das manutenções de software, é importante perceber que
essas manutenções são cruciais para a sobrevivência de uma solução de software, porque é através delas que
os sistemas sofrem adequações para continuar atendendo às necessidades dos usuários.
Um ponto de atenção em relação às manutenções de software é quanto ao volume dessas manutenções. Se a
quantidade de manutenções estiver tomando a maior parte da capacidade produtiva das equipes de suporte
e desenvolvimento, isso pode signi�car que a empresa está gastando muito para manter o software
funcionando, o que pode ser um indicador para avaliação de substituição, modernização ou desativação da
solução de software ou de parte dela.
VIDEOAULA: A IMPORTÂNCIA DA ATUALIZAÇÃO PARA CORREÇÃO DE BUGS
Neste vídeo, serão apresentados os tipos de manutenção e software e será comentado sobre a relevância de
cada um deles e como são utilizados.
Será mostrada, ainda, a relação das manutenções com o ciclo de vida de um software.
A RETIRADA DO PROGRAMA DE OPERAÇÃO E SUA SUBSTITUIÇÃO POR OUTRO
Depois de algum tempo em uso, uma solução de software ganha maturidade, e seu ciclo de vida contínuo
permanece em execução. O processo de manutenção de um software garante sua existência e mantém o
sistema em execução, corrigindo erros e falhas, evoluindo suas funcionalidades e adaptando a aplicação e
seus componentes às evoluções tecnológicas.
Esse ciclo de execução das manutenções de software no sistema, apesar de garantir a sobrevivência e
existência do sistema e manter suas funcionalidades, não é su�ciente para que a solução como um todo entre
num processo de descontinuação.
A obsolescência das tecnologias utilizadas pelo sistema, as funcionalidades do sistema que caem em desuso,
os custos elevados de operação e manutenção e as decisões estratégicas da empresa são exemplos dos
principais motivadores para a descontinuação de uma solução de software, conforme descritos a seguir:
• Obsolescência: as várias tecnologias que suportam uma solução de software, como linguagem de
programação, sistema operacional, bibliotecas genéricas, itens de hardware, entre outros, podem sofrer
atualizações pelos seus fabricantes, e sua solução de software deve acompanhar essa evolução e realizar as
atualizações, porém muitas versões antigas são descontinuadas e deixam de receber suporte do fornecedor
daquela tecnologia ou ferramenta que sua aplicação utiliza, obrigando a sua aplicação a ser descontinuada ou
substituída.
• Funcionalidades em desuso: muitas funcionalidades da aplicação deixam de ser utilizadas pelos usuários e
caem em desuso, justi�cando a desativação ou substituição dessas funcionalidades por outras existentes em
outros sistemas ou aplicações. Dessa forma, se muitas funcionalidades ou atividades que anteriormente eram
consideradas críticas caem em desuso, isso pode justi�car a descontinuação ou desativação desse sistema ou
solução de software.
• Custos elevados: na linha do tempo de existência de uma solução de software, as empresas responsáveis
por essas soluções acompanham a evolução dos custos de manutenção desse sistema. Assim, o cenário no
qual esses custos para manter e operar um software consome um percentual acima do planejado para
manutenções, o que pode justi�car a descontinuação ou desativação desse software.
Videoaula: A importância da atualização para correção de bugs
Para visualizar o objeto, acesse seu material digital.
• Decisões estratégicas: não é incomum que decisões estratégicas da empresa, como modernização de
plataformas, redução de custos, investimentos em outros ramos de atividade da empresa, aquisições ou
fusões, direcionem a descontinuidade ou desativação de soluções de softwares que não atenderão aos
cenários futuros da visão estratégica da empresa.
Seja qual for o motivador para a descontinuação de uma solução de software, é importante perceber que o
processo de desativação pode ser simples, como apenas desinstalar aplicativos de celular ou desligar
servidores, ou pode ser complexo e exigir o planejamento do desenvolvimento de uma nova solução ou
compra de uma solução de mercado (solução de fornecedor externo à empresa que já possui um ou mais
produtos de software equivalentes), o que pode consumir meses e até anos para a conclusão da substituição.
Esse planejamento pode precisar considerar os cenários de migração de bases de dados para a nova solução
ou arquivamento e guarda dos dados no caso de desativação. Além disso, deve-se considerar o impacto para
os usuários durante a transição entre a solução atual e a nova solução de software.
VIDEOAULA: A RETIRADA DO PROGRAMA DE OPERAÇÃO E SUA SUBSTITUIÇÃO POR OUTRO
Neste vídeo, você entenderá com mais detalhes os cenários que motivam a descontinuação ou desativação de
uma solução de software.
Será comentado quais são as implicações da descontinuidade ou do desligamento de uma aplicação e de suas
funcionalidades. 
ESTUDO DE CASO
Você é o líder técnico de uma equipe que desenvolve e realiza o suporte de uma solução de software
responsável por efetivar pagamentos. Utilizando essa solução, os clientes esperam ter sempre a melhor
experiência, podendo realizar seus pagamentos de forma segura, rápida e que não haja problemas ou falhas
durante as transações.
Nos últimos meses, o volume de transações tem aumentado muito, e você percebeu que a aplicação tem
respondido de forma satisfatória, sem grandes problemas ou impactos para os clientes.
Mesmo com esse cenário favorável, você tem sido cobrado pelos gerentes para que a solução ou parte dela
seja substituída por uma solução de mercado. Os gerentes alegam que dois concorrentes de vocês já utilizam
essa nova solução e alcançaram bons resultados.
Diante desse cenário, você, como líder técnico, se reuniu com a equipe para analisar e dar um parecer para os
gerentes sobe a adoção dessa outra solução de software.
Considerando os motivadores para a descontinuação de um software, elabore um relatório inicial com as suas
considerações e da sua equipe sobre a possibilidade de substituir a solução atual, parte dela ou evoluir e
modernizar a solução atual já mantida pela sua equipe.
RESOLUÇÃO DO ESTUDO DE CASO
Considerando os motivadores para descontinuação de um software, que são: obsolescência, custos elevados,
funcionalidades em desuso e decisões estratégicas, segue o relatório inicial:
• Obsolescência: caso algum componente da solução atual esteja obsoleto ou sem suporte de fornecedores,
é necessário avaliar a complexidade e os custos de se fazer essa atualização. Essa avaliação deve ser
considerada junto às demais avaliações para a decisão de descontinuação do software atual.
• Custos elevados: levantar os custos realizados dos últimos seis meses para avaliar frente ao orçado do
mesmo período. Esse resultado é bem relevante, pois a questão de recursos �nanceiros é sempre um
requisito com maior peso na tomada de decisões.
• Funcionalidades em desuso: a identi�cação de funcionalidades que caíram em desuso é fundamental para
medir a efetividade dos serviços mantidos pela solução atual.
• Decisões estratégicas: avaliar em conjunto com os gerentes que têm a visão do que os concorrentes já
estão utilizando ajudará a entender melhor a estratégia da empresa quanto a esse pedidode avaliação da
substituição da solução atual.
Videoaula: A retirada do programa de operação e sua substituição por outro
Para visualizar o objeto, acesse seu material digital.
Conclusão: considerando essas avaliações e os levantamentos sugeridos, será possível avaliar a viabilidade da
substituição parcial ou total da solução atual, ou mesmo se um projeto de modernização pode atender às
expectativas da visão estratégica dos gerentes e demais gestores da empresa frente à concorrência.
 Saiba mais
As práticas ágeis no desenvolvimento de software têm transformado os ambientes de trabalho e
provocado mudanças culturais nas equipes que participam dessa transformação. Saiba mais, acessando:
https://blog.geekhunter.com.br/o-que-e-desenvolvimento-agil/. Acesso em: 13 fev. 2022.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
Aula 1
EQUIPE TOTVS. Metodologia ágil: o que é e como implementar. TOTVS, 2021. Disponível em:
https://www.totvs.com/blog/negocios/metodologia-agil/ . Acesso em: 29 jan. 2022.
FERNANDES FILHO, G. E. F. Automação de Processos e de Sistemas. São Paulo, SP: Saraiva, 2014. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9788536518138/ . Acesso em: 28 jan. 2022.
GAZOLA, R. Guia completo de automação de processos em TI. ADDEE, 2020. Disponível em:
https://addee.com.br/blog/automatizacao-de-processos/ . Acesso em: 27 jan. 2022.
GUEDES, G. T. A. UML: uma abordagem prática. São Paulo, SP: Novatec, 2006.
MASCHIETTO, L. G. et al. Processos de Desenvolvimento de Software. Porto Alegre, RS: Grupo A, 2020.
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900520/ . Acesso em: 28 jan. 2022.
MASCHIETTO, L. G. et al. Desenvolvimento de Software com Metodologias Ágeis. Porto Alegre, RS: Grupo A,
2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556901824/ . Acesso em: 29 jan.
2022.
O QUE são metodologias ágeis e quais as vantagens? Robson Camargo, 2018. Disponível em:
https://robsoncamargo.com.br/blog/O-que-sao-metodologias-ageis-e-quais-as-vantagens . Acesso em: 29 jan.
2022.
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: Grupo A, 2020. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/ . Acesso em: 29 jan. 2022.
Aula 2
CAMPOS, F. M. Qualidade, Qualidade de Software e Garantia da Qualidade de Software são as mesmas coisas?
Linha de Código, [s. d.]. Disponível em: http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-
de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx. Acesso em: 14 set. 2021.
CIGITAL. Case study: Finding Defects elarlier yields enourmous savings. Cigital Archive, 2007. Disponível em:
http://web.archive.org/web/20071003044003/http://www.cigital.com/solutions/roi-cs2.php . Acesso em: 8 set.
2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. Porto Alegre, RS:
AMGH, 2016.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. Porto Alegre, RS:
AMGH, 2021.
REFERÊNCIAS
15 minutos
https://blog.geekhunter.com.br/o-que-e-desenvolvimento-agil/
https://www.totvs.com/blog/negocios/metodologia-agil/
https://integrada.minhabiblioteca.com.br/#/books/9788536518138/
https://addee.com.br/blog/automatizacao-de-processos/
https://integrada.minhabiblioteca.com.br/#/books/9786556900520/
https://integrada.minhabiblioteca.com.br/#/books/9786556901824/
https://robsoncamargo.com.br/blog/O-que-sao-metodologias-ageis-e-quais-as-vantagens
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
http://web.archive.org/web/20071003044003/http://www.cigital.com/solutions/roi-cs2.php
ZANIN, A. et al. Qualidade de software. Porto Alegre, RS: SAGAH, 2018.
03 – SONARQUBE – DOWNLOAD, INSTALAÇÃO E EXECUÇÃO. [S. l.: s. n.], 2020. 1 vídeo (11min49s). Publicado
pelo canal T2Ti. Disponível em: https://www.youtube.com/watch?v=TNEHX51L9Do. Acesso em: 14 set. 2021.
Aula 3
GONÇALVEZ, P. de F. et al. Testes de software e gerência de con�guração. Porto Alegre, RS: Grupo A, 2019.
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788595029361 . Acesso em: 8 fev. 2022.
LENZ, T. A. Conceitos básicos sobre Mockito. Contabilizei, 2019. Disponível em:
https://inside.contabilizei.com.br/conceitos-basicos-sobre-mockito-73b931ce0c2c . Acesso em: 8 fev. 2022.
SOFTWARE UNIT TEST SMELLS. Disponível em: https://testsmells.org/ . Acesso em: 8 fev. 2022.
TANOUE, B.; ORTIZ, V. Testes de Regressão Visual: Obtendo olhos à prova de erros. Ship it!, 2 abr. 2018.
Disponível em: http://shipit.resultadosdigitais.com.br/blog/testes-de-regressao-visual-obtendo-olhos-a-prova-
de-erros/. Acesso em: 11 mar. 2022.
VALENTE, M. T. Engenharia de Software Moderna. [S. l.: s. n.], 2020. Disponível em:
https://engsoftmoderna.info/cap8.html. Acesso em: 8 fev. 2022.
ZANIN, A. et al. Qualidade de software. Porto Alegre, RS: Grupo A, 2018. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595028401/ . Acesso em: 8 fev. 2022.
Aula 4
COMO desativar efetivamente um sistema. DEVMEDIA, 2013. Disponível em:
https://www.devmedia.com.br/como-desativar-efetivamente-um-sistema/29573 . Acesso em: 13 fev. 2022.
EQUIPE TOTVS. Metodologia ágil: o que é e como implementar. TOTVS, 2021. Disponível em:
https://www.totvs.com/blog/negocios/metodologia-agil/ . Acesso em: 12 fev. 2022.
MASCHIETTO, L. G. et al. Processos de Desenvolvimento de Software. Porto Alegre, RS: Grupo A, 2020.
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556900520/ . Acesso em: 12 fev. 2022.
MASCHIETTO, L. G. et al. Desenvolvimento de Software com Metodologias Ágeis. Porto Alegre, RS: Grupo A,
2021. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786556901824/ . Acesso em: 12 fev.
2022.
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: Grupo A, 2020. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/ . Acesso em: 13 fev. 2022.
https://www.youtube.com/watch?v=TNEHX51L9Do
https://integrada.minhabiblioteca.com.br/#/books/9788595029361
https://inside.contabilizei.com.br/conceitos-basicos-sobre-mockito-73b931ce0c2c
https://testsmells.org/
http://shipit.resultadosdigitais.com.br/blog/testes-de-regressao-visual-obtendo-olhos-a-prova-de-erros/
http://shipit.resultadosdigitais.com.br/blog/testes-de-regressao-visual-obtendo-olhos-a-prova-de-erros/
https://integrada.minhabiblioteca.com.br/#/books/9788595028401/
https://www.devmedia.com.br/como-desativar-efetivamente-um-sistema/29573
https://www.totvs.com/blog/negocios/metodologia-agil/
https://integrada.minhabiblioteca.com.br/#/books/9786556900520/
https://integrada.minhabiblioteca.com.br/#/books/9786556901824/
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/
Imprimir
INTRODUÇÃO
Assim como qualquer produto, um software também precisa das etapas de controle de qualidade, que
envolvem os seus testes. Os testes em softwares são importantes, pois detectam bugs antecipadamente,
evitando retrabalhos. Testar não é custoso, mas, sim, produtivo, e evita custos desnecessários.
O resultado esperado dessa aula é que você entenda a importância da aplicação de metodologias ágeis
aplicadas no desenvolvimento e nos testes de softwares. O conceito por trás dessas metodologias é conduzir
projetos que entreguem resultados esperados aos clientes, de forma rápida, como o próprio nome diz.
Pense que, ao contrário dos métodos tradicionais utilizados em projetos, em que há uma ordem pré-de�nida
de ações a serem de�nidas, com foco muito especí�co no projeto, as metodologias ágeis eliminam as
burocracias e as amarras, para entregarem resultados mais rápidos, com foco no cliente, e isso pode serum
diferencial em sua atuação pro�ssional.
INTRODUÇÃO AO CONCEITO DE METODOLOGIAS ÁGEIS
Uma das formas gerenciar testes em softwares, ou mais amplamente, gerir um projeto, é utilizar as
metodologias ágeis. De acordo com Sbrocco e Macedo (2012), a partir do início dos anos de 1980,
metodologias utilizadas em projetos começaram a incomodar as corporações, principalmente as que
trabalhavam com projetos de forma intensiva. Com essa necessidade criada, surgiram diversos novos
modelos de desenvolvimento e gestão de projetos. Segundo os autores, nesse período surgiram as
“Metodologias de Desenvolvimento Ágeis” para o projeto de diversos produtos, inclusive, de softwares.
Basicamente, as metodologias ágeis dividem o grande projeto em projetos menores, em curtos períodos, com
maiores iterações e, consequentemente, riscos e custos reduzidos, devido à possibilidade de identi�car e
corrigir problemas mais rapidamente, devido ao maior número de iterações do que uma gestão de projetos
tradicional. Mais adiante, veremos mais detalhes das metodologias ágeis e sua aplicação na Engenharia de
Software, bem como testes delas.
Um outro ponto a se destacar aqui é que, com o surgimento e a criação de diferentes métodos ágeis, em
2001, especialistas criaram o que se convencionou a chamar de “Manifesto Ágil” (SBROCCO; MACEDO, 2012). O
Quadro 1 mostra, de forma resumida, as premissas desse manifesto.
Quadro 1 | Considerações do Manifesto Ágil versus Metodologias tradicionais
Manifesto Ágil Metodologias Tradicionais
Pessoas e interação entre a equipe Foco em processos e ferramentas
Software executável   Extensa documentação, nem sempre clara
Interação e colaboração do cliente Frequentes negociações de contratos
Respostas rápidas para mudanças Planos previamente de�nidos
Fonte: adaptado de Sbrocco e Macedo (2012, p. 13).
Os resultados práticos observados em empresas – aqui, de qualquer ramo – que implementaram as
metodologias ágeis são: menores custos, melhoria da qualidade, cumprimento dos prazos de entrega e
con�abilidade. Na prática, tudo o que uma empresa quer para ser competitiva, certo?
Aula 1
METODOLOGIAS ÁGEIS E AUTOMAÇÃO DE TESTES
Analisar a aplicação da Metodologia Ágil no processo de testagem do software, baseado em dados de
usuário, valores �nanceiros e estatísticos.
35 minutos
O conceito de metodologias ágeis em softwares surgiu em meados da década de 1990, como alternativa aos
métodos tradicionais. Ao todo, são doze princípios desse manifesto, sempre citado por diversos autores
(ANDERLE, 2015; BECK et al., 2001; SBROCCO; MACEDO, 2012):
1.  A prioridade é a entrega antecipada e contínua do software ao cliente, de forma a deixá-lo satisfeito.
2.  Mudanças nos requisitos, mesmo que tardias, são bem-vindas, pois trazem vantagens competitivas para o
cliente.
3.  Entregas frequentes do software em funcionamento, em escala de semanas ou poucos meses.
4.  Os desenvolvedores devem trabalhar no projeto em conjunto com pessoas de outras áreas, como a de
negócios.
5.  O ambiente deve ser motivador a todos os envolvidos no projeto, além de trazer suporte e con�ança a eles.
6.  A comunicação deve ser e�ciente e e�caz e feita direta e pessoalmente entre os envolvidos.
7.  O progresso é medido através de softwares que funcionam.
8.  O desenvolvimento sustentável tem grande ligação com as metodologias ágeis.
9.  A agilidade do método é favorecida pela excelência técnica e pelo design.
10.  Simplicidade é essencial. Todo trabalho ou rotina não necessário deve ser descartado.
11.  As equipes auto-organizáveis geram os melhores projetos, designs e arquiteturas.
12.  A equipe busca continuamente formas de se tornar mais e�caz e coloca em prática essas formas.
VIDEOAULA: INTRODUÇÃO AO CONCEITO DE METODOLOGIAS ÁGEIS
O vídeo apresenta os conceitos básicos de metodologias ágeis, o que motivou seu surgimento, as principais
características e sua comparação com as metodologias tradicionais. O vídeo apresenta os primeiros conceitos
de aplicação das metodologias ágeis em gestão de projetos, inclusive, em projetos de controle de qualidade
de softwares.
O FUTURO DO GERENCIAMENTO DE PROJETOS EM TI E O USO DAS METODOLOGIAS ÁGEIS
(MÉTODOS SCRUM E KANBAN)
Os modelos tradicionais de desenvolvimento de software envolvem uma sequência comum, como segue:
Figura 1 | Modelo linear de engenharia de desenvolvimento de software
Fonte: Pressman (2002 apud SBROCCO; MACEDO, 2012, p. 60).
Esse modelo serve, basicamente, para projetar qualquer tipo de software, e é conhecido como o modelo
linear dentro da engenharia de software. A engenharia de sistemas entra apenas no início do processo.
Na metodologia tradicional, os testes de software sucedem a geração do código, que é a interpretação do
programa para a linguagem de máquina. Com o código gerado, o programa é testado. Percebe-se, dessa
forma, uma necessidade latente em processos de desenvolvimento e testes de softwares que sejam mais
rápidos e que gerem resultados com maior assertividade, excelência e qualidade.
Dentre as metodologias ágeis, o Scrum se destaca. Esse nome vem do método utilizado no jogo de rugby,
quando a bola sai do campo e é necessário reunir todos os jogadores, ou seja, no Scrum, atua-se em conjunto,
de forma integrada, visando a um objetivo comum.
Videoaula: Introdução ao conceito de metodologias ágeis
Para visualizar o objeto, acesse seu material digital.
A metodologia Scrum segue as doze premissas do manifesto ágil, além de possuir seis características
(SBROCCO; MACEDO, 2012, p. 161): “�exibilidade de resultados, �exibilidade de prazos, times pequenos,
revisões frequentes, colaboração e orientação a objetos”. As aplicações do Scrum atendem a muitas
demandas de agilidade de projetos, inclusive, de desenvolvimento e testes de softwares, pois sua utilização
abrange:
• Projetos complexos e com mudanças frequentes – o que costuma ser comum em encomendas de software,
em que o cliente pode solicitar mudanças no projeto ao longo do seu desenvolvimento.
• Gerenciamento de tarefas de trabalho.
• Formação de equipes autogerenciáveis.
• Implementação de processos iterativos e incrementais, em que o produto é construído em partes.
• Análise das causas de problemas para eliminar impedimentos.
• Valorização de cada indivíduo da equipe.
Com base nessas premissas, vemos que as metodologias ágeis, em todas as fases de desenvolvimento de
software, incluindo os testes, trazem um nível de informalidade que agiliza o processo e retira muitas das
burocracias existentes em processos tradicionais formais. Você observou que elas focam muito nas pessoas,
na ajuda mútua, nas prioridades e no cliente?
O Kanban é um método comumente aplicado a projetos e que pode ser utilizado dentro da engenharia de
software, junto às metodologias ágeis. Alguns autores, como Marioti (2017) e Duarte (2021), costumam
chamar o método de “ágil adaptativo”. O Kanban é um cartão (físico ou virtual) que sinaliza e controla os �uxos
de tarefas em diversas áreas, inclusive, em projetos de software.
Anderson (2003) chegou à conclusão de que o Kanban pode ser utilizado no desenvolvimento de softwares,
observando equipes dependentes de outros departamentos, o que atrasava a entrega. A necessidade de que
a equipe e a liderança se adaptassem a cada encomenda fez com que se adotasse o Kanban como método
dentro das equipes de desenvolvimento de software, para que o time evoluísse de forma incremental. Além
disso, o Kanban tem como uma das principais características ser um sistema puxado de produção, o que evita
o acúmulo, no caso de desenvolvimento de softwares, de tarefas inacabadas, reduzindo, assim, as tarefas em
andamento. Como é a equipe quem dita o ritmo de trabalho, a adoção conjunta com os sistemas ágeis
enfrenta menores resistências e potencializa a aplicação e os resultados das metodologias ágeis no
gerenciamento e desenvolvimento em Tecnologia da Informação.
VIDEOAULA: O FUTURO DO GERENCIAMENTO DE PROJETOS EM TI E O USO DAS METODOLOGIASÁGEIS (MÉTODOS SCRUM E KANBAN)
De forma geral, as metodologias ágeis apresentam grandes vantagens em relação às metodologias
tradicionais. Elas reduzem ao máximo a necessidade de documentações. O Scrum foca em reuniões rápidas
da equipe com foco no resultado de cada etapa. Quando juntamos o Kanban, temos uma potencialização das
metodologias ágeis.
O FUTURO DA TESTAGEM COM O AVANÇO DAS METODOLOGIAS ÁGEIS
As metodologias ágeis foram um grande avanço, nos anos de 1990, em relação às metodologias tradicionais
para a testagem de softwares (SOMMERVILLE, 2007), pois permitiram menor tempo de resposta e de entrega,
com softwares mais con�áveis e de melhor qualidade. 
Uma metodologia preditiva (tradicional) signi�ca que todos os pontos que podem vir a ocorrer durante o
planejamento e a execução do projeto são expostos no início do processo. Já a metodologia adaptativa, como
o próprio nome diz, permite que o projeto seja adaptado ao longo de toda a sua execução e o seu
desenvolvimento. Além disso, as metodologias ágeis respondem mais rápido às mudanças, o que é bené�co,
por exemplo, em ambientes onde as mudanças são frequentes, como a programação para a web e muitos
outros projetos na área hoje e no futuro.
Pinheiro et al. (2015) reforçam, em seu trabalho, as vantagens da execução de testes automatizados, pois
existe, entre as equipes, um esforço na tarefa de implementar scripts.
Videoaula: O futuro do gerenciamento de projetos em TI e o uso das metodologias ágeis (métodos Scrum e Kanban)
Para visualizar o objeto, acesse seu material digital.
Ele destaca:
Segundo Sommerville (2007), um dos grandes desa�os para a implementação de testes automatizados com
utilização de metodologias ágeis é a sua utilização em sistemas e empresas de grande porte. Geralmente, as
metodologias ágeis funcionam muito bem com projetos considerados de pequeno e médio porte, mas ainda
precisam avançar para projetos de grande porte, o que é uma tendência, visto a citação de Pinheiro et al.
(2015), a qual diz que as aplicações multiplataformas se tornam cada vez mais comuns, a concorrência
aumenta, exigindo softwares com maior excelência, além de necessidade de softwares mais seguros e que
possuem preocupação com a privacidade dos dados.
Com a crescente competitividade entre as empresas e as margens de lucro diminuindo cada vez mais,
exigindo escalabilidade de produção e de processos, buscam-se formas cada vez mais ágeis e e�cientes de
resolver problemas, gerir projetos e controlar a qualidade. Você já pensou sobre esse assunto? Quando
falamos em software, o processo é o mesmo. As big techs precisam cada vez mais lançar novidades no
mercado para que o público �el seja mantido. E quando se fala na área de tecnologia, inclusive de software, as
mudanças são mais rápidas do que em outros setores da economia. Isso vale não somente para as grandes
empresas de tecnologia mas também para as médias e pequenas.
VIDEOAULA: O FUTURO DA TESTAGEM COM O AVANÇO DAS METODOLOGIAS ÁGEIS
A testagem de software se torna mais importante. A automatização de testes com metodologias ágeis
funciona muito bem para pequenos e médios projetos, assim como pequenas e médias empresas. O desa�o
para o futuro é desenvolver a metodologia automatizada para que ela atenda, com qualidade, a aplicações
multiplataformas, por exemplo.
ESTUDO DE CASO
Você é um alto executivo de uma grande empresa de tecnologia, que está presente no mercado desde os
anos de 1970. O desenvolvimento de seus softwares sempre fora direcionado para grandes bancos
brasileiros, para uso exclusivamente de processos internos, não havendo, nesse caso, uma ligação direta com
o cliente �nal. Ainda hoje, a linguagem de programação usada para esse �m foi a COBOL, muito tradicional no
meio �nanceiro. Mesmo assim, a empresa possui canais digitais com seus clientes, inclusive, com aplicativos
de celular, nos quais se utiliza a linguagem Java para desenvolver suas aplicações. No entanto, todos esses
projetos sempre foram conduzidos através de metodologias tradicionais. Um dos bancos, cliente da empresa
que você trabalha, quer abrir uma plataforma mais popular, no formato de “carteira digital”, que vem se
difundindo muito no país. Essas carteiras se diferenciam dos aplicativos tradicionais por oferecerem
diferentes opções de transações, promoções e cupons, a cada semana. Em outras palavras, é uma plataforma
dinâmica. Sua tarefa é convencer, com argumentos sólidos e aprofundados, os CEOs de sua empresa de
tecnologia a mudarem o paradigma e utilizarem metodologias ágeis para o desenvolvimento, os testes e a
manutenção de seus aplicativos mobile. Utilize, para tanto, os conhecimentos aqui adquiridos, bem como a
comparação de aplicação entre as metodologias tradicionais e as metodologias ágeis. 
RESOLUÇÃO DO ESTUDO DE CASO
Com a análise dos fatores ambientais de teste e repetições de testes pode-se observar um
impacto na decisão em utilizar ou não a automatização dos testes de aceitação.
Entretanto, frente à necessidade de ter aplicações cada vez mais multiplataformas, a
segurança provida pelo teste automatizado de aceitação se mostra efetiva para a empresa
de software que propõe fornecer um produto de excelência, cumprir prazos estabelecidos
com o cliente, reduzir o esforço de teste manual, tornar o desenvolvimento do software
mais participativo entre todos os envolvidos e, consequentemente, aumentar a satisfação
com seus clientes e usuários �nais.
— (PINHEIRO et al., 2015, p. 267)
Videoaula: O futuro da testagem com o avanço das metodologias ágeis
Para visualizar o objeto, acesse seu material digital.
Para a solução do estudo de caso, comece fazendo uma tabela comparando o produto que sua empresa
produz hoje com o novo produto a ser desenvolvido. Nessa tabela, insira o tempo previsto para a realização
das etapas e o tempo previsto de reformulação e/ou ajuste de cada um dos softwares. Faça também um
resumo comparativo entre os tipos de metodologia e procure no mercado empresas semelhantes que já
utilizam metodologias ágeis para casos parecidos.
Competências, como comunicação verbal clara e simples, técnicas de negociação e uma apresentação de
slides bem conduzida, são essenciais.
 Saiba mais
Quando falamos de metodologias ágeis, não estamos nos referindo apenas a um compêndio de várias
técnicas que foram compiladas em um único método, por exemplo, Lean Manufacturing. Dentre as
metodologias ágeis, podemos citar: Feature Driven Development (FDD), Dynamic Systems Development
Methodology (DSDM), Adaptative Software Development (ASD), Crystal, Extreme Programming (XP),
SCRUM e Iconix Process.
Utilize a referência indicada a seguir e sites especializados em tecnologia na internet para pesquisar mais
sobre as semelhanças e diferenças entre essas metodologias.
SBROCCO, J. H.; MACEDO, P. C., Metodologias Ágeis: engenharia de software sob medida. São Paulo, SP:
Érica, 2012. 256p.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
As ferramentas CASE (sigla para Computer Aided Software Engineering) auxiliam no processo de criação e
testes de software ou, de forma mais ampla, são ferramentas da Engenharia de Software. Aqui, veremos quais
são essas ferramentas, como elas são utilizadas e apresentar casos de sucesso e de fracasso.
Os testes de software existentes se dividem em três tipos: Testes de Unidade Automatizada, em que o teste é
realizado no nível do código, e os problemas são identi�cados nas rotinas escritas nas linhas de programação;
Testes API (Application Programming Interface, ou Interface de Programação de Aplicativo), em que são
testadas a segurança e a funcionalidade do software; testes de GUI (Graphical User Interface), em que são
testadas as interfaces de usuário do software (ou aplicativo) (TESTES..., 2019). 
ATUALIZAÇÕES CONSTANTES DE PROGRAMAS MANTENDO OS ANTIGOS
Frequentemente, usuários se deparam com atualizações de softwares em mensagens dadas por seus
sistemasoperacionais, enquanto outros ainda utilizam planilhas eletrônicas de mais de 10 anos. O que parece
um tormento, muitas vezes, é uma tarefa necessária de ser realizada. Isso vale também para os aplicativos
mobile, softwares de usuários �nais em empresas e softwares de equipamentos de produção, por exemplo.
O motivo, em todos os casos descritos, segundo Campos (2021), é a relação custo-benefício e a necessidade
do aumento de segurança de dados. A simples atualização de segurança de um software, por si só, requer
tempo. Um administrador de tecnologia da informação em uma empresa, por exemplo, para realizar esse tipo
Aula 2
FERRAMENTAS CASE PARA AUTOMAÇÃO DE TESTES
Entender como casos de sucesso e de fracasso contribuíram para o avanço dos testes e da qualidade dos
programas ou softwares.
37 minutos
de atualização, deve se programar e mobilizar sua equipe, dependendo do software utilizado.
Já a troca de software por versões mais novas, muitas vezes, requerem a compra de novas licenças, o que,
dependendo do core business da empresa e de seu tamanho, pode ser muito custoso. Diante disso, algumas
empresas acabam por manter softwares mais antigos em utilização, porém atualizados, e reforçar a
segurança dos sistemas existentes.
Manter um software antigo, porém atualizado, em uso, também pode ser vantajoso em determinadas
situações. De acordo com Campos (2021), em automação industrial, isso pode ocorrer com frequência alta,
pois:
• O custo é elevado para a manutenção de computadores, principalmente os industriais, já que,
frequentemente, um novo software requer um hardware mais potente do que o atual.
• Hardwares novos e mais potentes possuem custos elevados.
• Além da possível necessidade de novo hardware, esse equipamento precisa ser construído com um sistema
e periféricos compatíveis com os sistemas do fabricante das máquinas, além de conexões, placas, drivers, etc.
compatíveis.
Diante do exposto, o que você faria? O mais adequado seria manter um software antigo atualizado no limite
disponibilizado pelo desenvolvedor ou substituí-lo? A resposta dependerá, principalmente, da relação custo x
benefício, tanto para pessoas como para empresas.
Por outro lado, a atualização de softwares administrativos pode ser tão custosa quanto a implementação de
um sistema totalmente novo. Valentim et al. (2014) descreve um estudo comparativo do uso de recursos,
entre a implementação e a atualização de um sistema ERP (Enterprise Resource Planning, ou Planejamento de
Recursos Empresariais, em tradução livre), em uma empresa de bebidas. Tanto a implementação de um novo
sistema como a atualização envolvem toda a companhia. Ainda segundo o autor, os sistemas ERPs são
constantemente atualizados. Os softwares podem apresentar desde mudanças na interface do usuário como
também incorporar correções ou maiores camadas de segurança das informações e outros diferenciais. No
caso apresentado, apesar de a atualização ser implementada com sucesso (ao invés de um novo sistema), o
processo envolveu todas as etapas de implementação de um novo sistema.
Como responsável por conduzir um projeto de atualização como este, você manteria o sistema antigo
atualizado? Se o uso de recursos e os custos envolvidos são os mesmos, a mudança para um novo sistema
seria mais vantajoso. Esse é um caso complexo, pois envolvem diversos softwares de um sistema ERP de uma
empresa, bem como treinamentos, backups e implementação. O mesmo não ocorreria para sistemas mais
simples, obviamente, mas teríamos em comum, nos dois casos, um software mais seguro e atual. 
VIDEOAULA: TATUALIZAÇÕES CONSTANTES DE PROGRAMAS MANTENDO OS ANTIGOS
O vídeo versa sobre as vantagens e desvantagens em utilizar um software novo ou fazer a atualização do
software. Além da apresentação de um estudo de caso real para o sistema ERP, o vídeo mostra que
especialistas indicam a atualização e, se possível, a troca, dependendo da aplicação, dentro do período de dois
a cinco anos.
CASES DE SUCESSO E CASES DE FRACASSO
Em todo projeto de produto, é esperado sempre que os resultados sejam minimamente satisfatórios e que o
produto possa ser colocado no mercado o quanto antes. Isso acontece pois estamos em um mundo onde as
mudanças ocorrem cada vez mais rápidas e a concorrência cresce rapidamente. Na área de softwares, isso
não é diferente. Inclusive, é muito mais intenso, visto que a área de desenvolvimento de softwares é uma área
extremamente tecnológica, em que o consumidor, principalmente o �nal, quer sempre novidades. Soma-se a
isso a necessidade de empresas e pessoas possuírem softwares seguros, em um mundo cada vez mais
exposto a ataques cibernéticos. Para tanto, não basta a criação do software, a veri�cação de sua capacidade
de execução. Os testes também são necessários, para evitar fracassos de adesão ao produto e de vendas.
Segundo Bernardo (2011), a área de testes de softwares é uma área em franco crescimento, e a necessidade
de testes automatizados se faz presente, devido à agilidade desse processo. Ainda segundo o autor, erros de
escrita, manutenção e testes automatizados de baixa qualidade agem de forma negativa sobre o controle de
Videoaula: Atualizações constantes de programas mantendo os antigos
Para visualizar o objeto, acesse seu material digital.
qualidade desses produtos, prejudicando, inclusive, o tempo de desenvolvimento desse software.
Glass (2006), em seu artigo, relata a crise no desenvolvimento de softwares, chegando a mencionar uma taxa
elevada de falhas, girando em torno de 70% à época. Ele relata também o caso de uma aplicação utilizada pelo
governo dos Estados Unidos, na década de 1980, para gerenciar a contabilidade. O problema residia na coleta
de dados feita pelo software em questão. O caso gerou muita discussão à época entre os técnicos da área e,
uma vez identi�cado o problema, a questão da “crise do software” �cou mais visível.
Um dos casos de falha bem conhecidos foi a apresentação do Windows 98, em abril de 1998, realizada pela
Microsoft. Durante a execução de uma das tarefas do sistema operacional, relacionada com a tecnologia plug
and play, a conhecida “tela azul” de erro apareceu para todos os que estavam assistindo ao congresso de
tecnologia COMDEX. Conforme Rebêlo (2008), a Microsoft corrigiu os problemas e acabou lançando no ano
seguinte o Windows 98SE (Segunda edição). Apesar de outros problemas que o sistema apresentou, esse
sistema operacional se tornou um dos mais utilizados no mundo. Assim como esse caso, a Microsoft teve
problemas de execução na apresentação do software Hololens 2, em 2019, e não foram explicados os motivos
das falhas.
A partir desses três exemplos, a pergunta que você deve estar fazendo é: esses softwares foram testados à
exaustão? Qual o método utilizado? Os testes foram automatizados? Esses problemas poderiam ser evitados
durante o lançamento?
Um case de sucesso de software que envolveu a utilização de testes automatizados é o caso de uma empresa
brasileira, cujo terminal de autoatendimento precisou de rápidas atualizações para receber novas
funcionalidades, o que poderia aumentar a frequência de erros, devido ao aumento dos números de
processos sendo executados. Bartie (2008) relata que a área de Tecnologia da Informação da empresa se
deparou com um gargalo em seus processos de testes e homologação de software. A proposta inicial era
colocar uma equipe em campo para testar tais softwares diretamente nas máquinas de autoatendimento, o
que seria uma maneira demorada e não produtiva de tentar resolver problemas. A empresa, então, optou por
adotar testes automatizados nos softwares dos terminais. Com a automação, foi possível executar todos os
tipos de testes e de forma contínua, o que fez diminuir o prazo de homologação do software pela metade e
aumentar o nível de cobertura desses testes para mais de 20 vezes. 
VIDEOAULA: CASES DE SUCESSO E CASES DE FRACASSO
Um sistema operacional possui uma construção muita mais complexa do que outros softwares.A questão é
dimensionar a quantidade de testes automatizados a serem realizados e analisar a necessidade de a empresa
em lançar novos produtos no mercado. Uma grande empresa possui estratégias diferentes de empresas com
terminais de autoatendimento.
FERRAMENTAS ORIENTADAS A OBJETOS, UPPER E LOWER CASE, TESTES DE SOFTWARE COM USO
DE REALIDADE VIRTUAL (RV)
Ferramentas CASE: características e categorias
Ramos (2011, p. 27) descreve a ferramenta CASE como “um conjunto de técnicas e ferramentas informatizadas
que auxiliam o engenheiro de software no desenvolvimento de aplicações”. As aplicações aqui mencionadas
são os sistemas e os softwares. As ferramentas CASE têm como objetivo melhorar a e�ciência no
desenvolvimento de softwares, para a obtenção de softwares com melhor qualidade. Ela permite, durante o
desenvolvimento de software, automatizar as atividades, como os próprios testes de execução de software e
identi�cação de problemas.
Mais especi�camente, as ferramentas CASE são muito importantes para empresas que trabalham com
engenharia de software, pois tratam de todo o ciclo de desenvolvimento, que inclui a análise do projeto, o
projeto propriamente dito, a implementação e a realização de testes (RAMOS, 2011).
Chikofsky (1993) descreve uma série de vantagens na utilização das ferramentas CASE, dentre elas:
• Padronização dos processos.
• Reutilização de ferramentas ao longo do projeto, com consequente aumento de produtividade.
Videoaula: Cases de sucesso e cases de fracasso
Para visualizar o objeto, acesse seu material digital.
• Automatização das atividades (inclusive, é a principal característica dessas ferramentas).
• Tempos de desenvolvimento otimizados.
• Integração entre as diversas etapas e equipes de desenvolvimento.
• Foco em testes e correção do software.
• Qualidade superior para o produto.
De acordo com Farias (2001), as ferramentas CASE são classi�cadas em três categorias: Lower CASE (back-
end), Upper CASE (front-end) e Integrated CASE, união das duas ferramentas anteriores. Peloso (2014) de�ne
cada uma das categorias da seguinte forma:
• As ferramentas da categoria Lower CASE trabalham em ambientes mais simples, auxiliando na criação dos
códigos dos softwares, nos seus testes, na depuração e na manutenção deles.
• As ferramentas da categoria Upper CASE trabalham em ambientes mais complexos. As tarefas de análise, de
projetos e de geração de código são mais automatizadas do que na categoria Lower
• As ferramentas da categoria Integrated CASE trabalham integradas em ambientes que relacionam entradas e
saídas. Isso permite o controle dos dados de forma consistente.
Ferramentas de testes orientadas a objetos
Conforme Martins e Tschannerl (2021), a programação orientada a objetos é muito próxima à forma de
pensamento humana, assim como os testes orientados a objetos. Apesar de mais complexos, os testes
orientados a objetos são mais e�cientes, pois aproveitam informações e rotinas de testes já realizados. A
complexidade de testes orientados a objetos se dá em função da hierarquia de classes, do aproveitamento
das rotinas já realizadas, comumente chamada de herança, e do polimor�smo.
Códigos construídos a partir de linguagens orientadas a objetos apresentam, em geral, algoritmos menos
complexos, o que facilita os procedimentos de teste. Isso ocorre porque os códigos orientados a objetos
possuem maior facilidade de interpretação. No entanto, o polimor�smo e o relacionamento de comandos
mais complexos podem di�cultar a realização de testes assim construídos.
Testes de software com uso de realidade virtual (RV)
De acordo com Souza (2017), os testes de software de realidade virtual focam, principalmente, na fase de
desenvolvimento grá�co e na interface com o usuário. Os testes para esse tipo de software utilizam estruturas
de análise de dados em árvore. Nesse tipo de estrutura, o teste começa desde o nó raiz, passando pelos nós
folhas, até o �nal do processo (cada nó representa uma parte ou um conjunto de informações, por exemplo,
cores, movimento, iluminação, entre outras variáveis, para que sejam testados. 
Processos interativos de testes também podem ser realizados, além da utilização de sistemas distribuídos,
visto a complexidade do programa. A importância desses testes para esse tipo de produto é garantir a
máxima qualidade, visto que boa parte desses sistemas já é frequentemente utilizada em aplicações médicas
(SOUZA, 2017). 
VIDEOAULA: FERRAMENTAS ORIENTADAS A OBJETOS, UPPER E LOWER CASE, TESTES DE
SOFTWARE COM USO DE REALIDADE VIRTUAL (RV)
A automatização dos testes através das ferramentas CASE, junto a metodologias ágeis, possibilita testar
exaustivamente um software. Uma forma de teste recente é realizada com softwares de realidade virtual. Eles
são utilizados em simulações simples, como jogos, ou complexas, como simuladores na Medicina. Os testes
são imprescindíveis no último caso.
ESTUDO DE CASO
Você é um dos engenheiros de software de uma indústria que produz softwares de realidade virtual para
Medicina e para testes em automóveis. A princípio, a construção de um software para esses �ns é semelhante
à construção de softwares para �ns menos complexos ou que não envolvem segurança e vidas humanas.
Você, junto à sua equipe, precisa desenvolver e testar, antes de enviar para o cliente que encomendou um
Videoaula: Ferramentas orientadas a objetos, Upper e Lower CASE, testes de software com uso de realidade virtual (RV)
Para visualizar o objeto, acesse seu material digital.
software para que médicos possam realizar cirurgias trabalhando com realidade virtual. Elabore um �uxo de
ações e detalhe cada uma delas para a construção desse software. Você considera a necessidade de ter uma
equipe multidisciplinar para trabalhar junto à sua equipe? Será necessário que o cliente participe da
construção desse software? Explique de forma detalhada essas duas questões. 
RESOLUÇÃO DO ESTUDO DE CASO
Para a resolução do Estudo de Caso, o aluno deve, inicialmente, re�etir sobre o grau de exigência de testes
que devem ser realizados nesse software. Será necessário a utilização de ferramentas automatizadas e
alguma metodologia ágil para o teste desse software? Além disso, na construção do �uxograma detalhado, o
aluno deve inserir todas as fases de levantamento de dados e as necessidades junto ao cliente, os nós onde
ocorrem os testes e onde o cliente entra em cena para o desenvolvimento deles, porque o cliente, além de
uma equipe multidisciplinar, deve participar da construção e dos testes desse produto.
 Saiba mais
Os testes de software começaram a ganhar força com a popularização do computador pessoal, na
década de 1980, e se intensi�cou quando as grandes empresas de tecnologia começaram a ter maior
visibilidade, antes voltada para empresas tradicionais, de alimentos ou de automóveis. Hoje, os maiores
faturamentos estão nessas empresas, também conhecidas como big techs, a maioria localizada no
Estado norte-americano da Califórnia, no Vale do Silício. A necessidade de entregar softwares cada vez
mais rápidos, e�cientes e com interfaces grá�cas atraentes aumentou muito, devido à concorrência,
principalmente, de sistemas operacionais para aplicações mobile (smartphones) e softwares de uso
pessoal, como os editores de texto, apresentações e planilhas. Como sugestão, procure na internet,
através de buscadores, sobre a evolução dos softwares, o intervalo de lançamento e de atualizações,
bem como o faturamento anual das maiores empresas de tecnologia, comparadas às empresas de
outros ramos. O que podemos concluir com isso? O futuro será determinado por essas grandes
empresas, e seus softwares serão poderosos? As atualizações e os lançamentos passarão a ser mais
frequentes, exigindo cada vez mais testagens rápidas?
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Quando estudamos a qualidade e automação de testes, alguns conceitos importantes devem ser abordados,
comoa escolha da melhor linguagem de programação para o projeto, que é composto de apenas um ou um
conjunto de softwares. Entender o escopo dos projetos de programas, para compreender como funciona a
engenharia de software, desde a escolha do método de desenvolvimento (se tradicional ou ágil), mas sem
deixar de destacar que os softwares devem ser testados e que a forma mais atual e e�ciente de testes de
software é o automatizado.
É importante entender também como funciona a implantação do projeto de software em diversos tipos de
empresa. Você pode se deparar, em sua carreira, desenvolvendo softwares customizados para os mais
diferentes tipos e tamanhos de empresas. Veja só que interessante: o desenvolvimento e teste de software
Aula 3
PRINCIPAIS ETAPAS DE ELABORAÇÃO DE UM PROGRAMA
OU SOFTWARE
Entender o escopo dos projetos de programas, para compreender como funciona a engenharia de
software.
35 minutos
não é um trabalho individual ou de uma equipe isolada, mas, sim, de uma equipe multidisciplinar. Vamos
entender isso tudo? 
ESCOLHA DAS DIFERENTES LINGUAGENS DE PROGRAMAÇÃO E EXPLICAÇÃO POR LINHA DE
CÓDIGO
De acordo com Sommerville (2008), quando se estuda ou se trabalha com engenharia de software, mais
especi�camente o projeto e a testagem dele, é difícil de�nir uma linguagem de programação especí�ca.
Existem diversas linguagens de programação com diferentes abordagens para o desenvolvimento de um
software. Nessas situações, o que prevalece é o que o autor chama de “Engenharia de Con�ança”, cujo
signi�cado é a utilização de boas práticas de programação aceitas mundialmente. Em outras palavras, a
escolha da linguagem de programação deve ser adequada ao propósito esperado para o software solicitado.
Conforme Schach (2008), é na fase de implementação, quando o projeto do software é convertido em código,
que se deve utilizar de práticas consagradas (e adequadas) de codi�cação. Nesse momento, é escolhida
também a linguagem de programação, seguindo determinadas regras, dentre as quais:
•  Utilizar a linguagem de programação escolhida pelo cliente. No caso de o cliente não especi�car a
linguagem, a equipe deve escolher a linguagem a que está acostumada e que esteja adequada aos propósitos,
como já mencionado.
•  A escolha do nome das variáveis deve estar condizente com a sua função dentro do programa. Isso facilita e
agiliza a programação, os testes e as possíveis manutenções que o software poderá passar com o tempo de
uso e possíveis atualizações.
•  A documentação referente ao código deve ser detalhada e clara, incluindo as últimas modi�cações
ocorridas, a identi�cação das pessoas da equipe que trabalharão no projeto e a descrição da função do
software e de suas partes. Boa parte da documentação deve explicar as linhas de código, caso o projeto
permita ou seja uma documentação exclusiva da empresa desenvolvedora.
Para a escolha da linguagem de programação, Zapalowski (2011) cita três métricas, que são:
•  Quantidade de linhas do código.
•  Tempo de execução do algoritmo.
•  E�ciência do software nas diversas linguagens.
Para essa comparação, o autor utilizou como exemplo as linguagens C, C++, PHP, Java, Ruby e Python. A partir
de seus testes, observou-se que as linguagens C e C++ eram mais e�cientes para a execução, e as demais,
apesar de menos e�cientes sob o ponto de vista de compilação, possuíam desenvolvimento menos complexo.
A partir de um exemplo como esse, �ca complicado escolher a linguagem, não é mesmo? De fato, o
desenvolvedor deve escolher a linguagem solicitada pelo cliente, ou a que ele possui maior “�uência”.
As linhas do código são pontos importantes na análise e na documentação do software. Segundo Seabra,
Drummond e Gomes (2018), o código produzido no projeto do software pode ser analisado sob o ponto de
vista de sua complexidade e de sua e�ciência. No processo de compilação de um programa, temos duas
etapas: análise e síntese. Na etapa de análise, é veri�cado se o programa está coerente com a linguagem
utilizada, para que, na etapa de síntese, na qual são gerados e otimizados os códigos do programa, este seja
analisado quanto à e�ciência e à presença de erros (GESSER, 2003). 
VIDEOAULA: ESCOLHA DAS DIFERENTES LINGUAGENS DE PROGRAMAÇÃO E EXPLICAÇÃO POR
LINHA DE CÓDIGO
A escolha de uma linguagem de programação especí�ca de um projeto pode estar ligada a uma especi�cação
do cliente. Caso essa especi�cação não exista, a melhor linguagem a ser escolhida é aquela que atende aos
propósitos do projeto e ao que a equipe esteja mais familiarizada.
A IMPORTÂNCIA DA DEFINIÇÃO DE ESCOPO DE DESENVOLVIMENTO DE UM PROGRAMA
Videoaula: Escolha das diferentes linguagens de programação e explicação por linha de código
Para visualizar o objeto, acesse seu material digital.
Para muitas pessoas, a de�nição de software é simplesmente um programa de computador. No entanto,
dentro da Engenharia de Software, o desenvolvimento envolve não somente escrever linhas de programação
em uma determinada linguagem, mas também produzir toda a documentação relativa ao programa, bem
como o manual de con�gurações necessárias para que o programa funcione corretamente. Em outras
palavras, um desenvolvedor pode escrever um programa para uma determinada função, sem um projeto
especí�co, ou existir o projeto solicitado por um cliente, que requer um escopo de desenvolvimento, além de
toda a documentação necessária.
Segundo Debastiani (2016), na década de 1980, quando as aplicações eram mais modestas sob o ponto de
vista de suas funcionalidades, os sistemas não eram integrados, a forma de processamento não era
distribuída, e o projeto era essencialmente baseado nas entradas e saídas que o cliente solicitava. As equipes
de projeto de softwares ou sistemas não enxergavam a grande necessidade de planejamento e do
desenvolvimento de escopos do projeto. Hoje, com o aumento visível das demandas e da complexidade de
um programa, bem como a concorrência, temos uma nova dinâmica para as equipes de desenvolvimento:
maior integração e de�nição dos escopos.
Ainda de acordo com Debastiani (2016), o aumento de demandas de qualidade, complexidade dos sistemas,
agilidade e tempo obrigou as companhias a trabalhar com padrões especí�cos de funcionamento. A
padronização das atividades do projeto deve focar em etapas, como formulação de funcionalidades do
software, de�nição e tratamento de base de dados e testes de funcionamento.
Sbrocco e Macedo (2012, p. 41) traz a seguinte de�nição para escopo em projetos de software:
Ainda segundo os autores, o escopo leva à produção de uma lista de requisitos que englobam as
necessidades dos clientes. Esses requisitos, por sua vez, trazem os atributos relacionados às funcionalidades.
Dentre os requisitos, destacam-se:
• Prioridade: ordena as funcionalidades de acordo com sua relevância para o projeto. Ela é dividida em
prioridade crítica, cuja funcionalidade deve ser inserida na próxima atualização ou versão do software;
prioridade importante, cuja funcionalidade possui grau de importância, mas pode ter sua implementação
adiada no caso de problemas técnicos; prioridade útil, cuja não implementação em uma próxima versão pode
ser adiada e não trará prejuízos ao funcionamento do software.
• Complexidade: pode ser dividida em baixa, média e alta, e está relacionada com a di�culdade de
implementação de uma ou mais funcionalidades solicitadas pelo cliente. É uma medida, segundo os autores,
dos recursos gastos para desenvolver as funcionalidades que estão no escopo do projeto.
• Risco: é um requisito que auxilia na de�nição das prioridades dentro do escopo. A partir da análise de riscos,
são identi�cadas as funcionalidades críticas e que precisam de mais atenção. Geralmente, as funcionalidades
mais críticas são colocadas primeiro dentro do cronograma do projeto.
• Esforço-tempo: requisito de fundamental importância para a de�nição do orçamento do software. É medido
a partir do número de integrantes do projeto versus tempo, porisso, é chamado esforço-tempo. As variáveis
que devem ser analisadas são: o tamanho do projeto, o tempo total para execução do projeto, o número de
pessoas no projeto e as ferramentas utilizadas.
Quando se utilizam as metodologias tradicionais, é mais difícil prever as métricas de cada um dos requisitos
citados logo no início do processo. Já na utilização de metodologias ágeis, o escopo do projeto pode sofrer
alterações ou, em outras palavras, as alterações são esperadas e fazem parte da rotina de condução do
projeto e do desenvolvimento do software.
O escopo de um projeto de desenvolvimento de software possui várias de�nições. Sob o
ponto de vista da análise de requisitos, podemos dizer que ele representa uma lista de
funcionalidades que devem estar presentes no sistema de software. Quando dividimos o
desenvolvimento do software em várias fases, e as fases em iterações, podemos
denominar o escopo de desenvolvimento das iterações como uma baseline ou linha de
base dos requisitos.
VIDEOAULA: A IMPORTÂNCIA DA DEFINIÇÃO DE ESCOPO DE DESENVOLVIMENTO DE UM
PROGRAMA
A produção de um escopo de projeto auxilia no planejamento das atividades que serão realizadas durante a
sua execução. A partir do escopo, é possível de�nir o orçamento do software, as etapas prioritárias e até o
tamanho da equipe envolvida.
CASOS DE SUCESSO DE PROJETOS DE IMPLANTAÇÃO DE SISTEMAS
Existem diversos casos e estudos de caso de sucesso na implantação de sistemas automatizados em
diferentes áreas. Aqui, serão apresentados três deles, vindo de estudos de pesquisadores de diferentes partes
do mundo, em diferentes situações e tamanhos de empresas. No caso, os nomes das empresas não serão
citados por questões de sigilo.
Um dos casos é de uma empresa de transportes aéreos chineses (LIU et al., 2014). Trata-se de um caso de
implantação de um projeto de sistema automatizado de testes dos softwares de segurança da empresa, mais
especi�camente testes de con�abilidade desses sistemas. No caso, a ferramenta utilizada se chama SRTAT –
software reliability test & assessment tool-suite, ou ferramentas de teste e avaliação de con�abilidade de
software, em tradução livre. Os estudos mostraram que a implementação dessa ferramenta permitiu tarefas
antes consideradas impossíveis de serem realizadas em tempo hábil, como veri�car a con�abilidade de todos
os sistemas manualmente, o que era possível através da automatização de testes.
Outro caso de projeto de implantação de sistemas especí�cos para melhorar processos é o de uma empresa
de contabilidade (KURNIAWAN et al., 2017). Foi implementado o que eles chamaram de “Sistema de
Informação Contábil”, que permitiu coletar, analisar e conciliar dados para gerar informações que trouxeram
impactos econômicos mensuráveis, além de benefícios intangíveis para a empresa. O caso foi estudado
diretamente em uma empresa da Indonésia, através de levantamento de dados do software implementado
em execução. Além dos benefícios já mencionados, o software permitiu sanar de�ciências percebidas em
outros momentos.
E os casos de implantação de softwares ou sistemas considerados prontos, “de prateleira”? Muitas empresas,
principalmente as de pequeno porte, acabam implementando softwares não encomendados para
informatizar suas atividades. A princípio, pode trazer certa insegurança, mas, nesses casos, é necessário
realizar testes de implementação e veri�car as suas saídas. Dois pesquisadores do Babson College, em Babson
Park, Massachusetts, analisaram os resultados, de curto e longo prazos, do projeto de implantação de um
sistema de prateleira em uma empresa, através de testes em campo (CALE; ERIKSEN, 1994). O sistema
recebeu ajustes iniciais que foram propostos tanto pela alta administração como pelos usuários �nais, além
da equipe de Tecnologia da Informação. As conclusões a curto prazo são que o sistema teve sucesso na
implementação, determinado, principalmente, por três fatores: o custo-benefício relativo do sistema para o
usuário �nal, a compatibilidade do sistema com as normas de trabalho e os processos da empresa e a
facilidade de uso do sistema, por sua baixa complexidade. No longo prazo, veri�caram que não ocorreram
problemas, e eles atribuem isso aos ajustes iniciais, ao entendimento das necessidades dos usuários �nais (e
se o sistema é adaptável à equipe) e à adaptação de seu uso e manutenção pela equipe de suporte de
Tecnologia da Informação, que deve possuir as competências necessárias e ser capaz de manter o sistema em
pleno funcionamento. Segundo os pesquisadores, eles consideram que os resultados se assemelham ao
sucesso de implementação de sistemas customizados.
Com isso, vemos que tanto sistemas customizados como sistemas prontos podem ser implementados em
empresas, obviamente, analisando sua aplicação, o porte da empresa, quem utilizará e a equipe de suporte.  
VIDEOAULA: CASOS DE SUCESSO DE PROJETOS DE IMPLANTAÇÃO DE SISTEMAS
O sucesso da implementação de projeto de sistemas dependerá sempre de uma análise prévia dos requisitos,
além de um planejamento feito através de um escopo, junto à equipe que utilizará o sistema ou software,
tanto para empresas de pequeno, médio ou grande porte das mais diversas áreas.
Videoaula: A importância da de�nição de escopo de desenvolvimento de um programa
Para visualizar o objeto, acesse seu material digital.
Videoaula: Casos de sucesso de projetos de implantação de sistemas
Para visualizar o objeto, acesse seu material digital.
ESTUDO DE CASO
Você é o gerente de Tecnologia da Informação de uma média empresa do ramo de laticínios. Com o
crescimento da empresa, da carteira de clientes e da necessidade de uma logística mais otimizada, o CEO da
empresa solicitou a você a análise e implantação de um sistema semelhante a um ERP para controlar todas
essas áreas. No mercado, existem sistemas prontos adaptáveis (“de prateleira”) e empresas que podem
desenvolver um sistema customizado. Você deve decidir, baseado nas etapas de implementação do projeto,
qual sistema será implantado. No caso da escolha do sistema pronto, que etapas de implantação e quais
cargos serão envolvidos? Haverá muitas adaptações a serem feitas? Sua equipe (de TI) será treinada? No caso
da escolha do sistema customizado, quais parâmetros devem ser colocados? Há uma linguagem especí�ca
que a equipe de TI de sua empresa pre�ra trabalhar? O que você solicitará na documentação do código desse
sistema? 
RESOLUÇÃO DO ESTUDO DE CASO
A solução para esse caso dependerá de alguns fatores, como: quem utilizará o sistema (customizado ou não)
tem familiaridade com informática? Se não possui, a equipe de TI, junto aos gestores, deverão treiná-los. Qual
o orçamento disponível para a compra do sistema? Ele permite a compra de um sistema customizado ou de
prateleira? O sistema de prateleira é mais simples de ser implementado e pode trazer os mesmos resultados
de um customizado? Qual a projeção de tempo de uso desse sistema pela empresa? Qual sistema atende esse
tempo apenas com pequenas atualizações e manutenção? Todas as respostas a essas perguntas ajudarão
você a escolher o sistema. Como vimos nos casos de sucesso, há um em que a implantação de um sistema de
prateleira foi su�ciente, fácil e rápido, mas, talvez, a taxa de crescimento de sua empresa e sua complexidade
não permitam sistemas assim.
 Saiba mais
A prática da programação está cada vez mais difundida. Apesar disso, existem, hoje, muitas linguagens
de programação e códigos, para as mais diversas aplicações. Um repositório de exemplos nas mais
diversas linguagens pode ser encontrado em https://github.com/, o famoso GitHub, em que muitos
desenvolvedores colocam suas linhas de código, e boa parte deles (dos códigos) é explicada.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Nesta aula, você conhecerá o conceito original de hackers, de onde vem essa expressão, como os hackers do
bem podem ser importantes para aumentar a segurançacibernética das empresas cada vez mais digitais, os
principais tipos de invasões e ataques e os prejuízos gerados pelos hackers criminosos.
Quando ouvimos a expressão hacker, remetemos a uma pessoa criminosa, mas, dentro do mundo digital,
existem pessoas que utilizam seus conhecimentos profundos de computação e redes para o bem, enquanto
outras, para o mal.
Aula 4
FALHAS EM PROGRAMAS VERSUS IMPORTÂNCIA DE
HACKERS PARA DETECÇÃO DAS FALHAS
Determinar as principais falhas e bugs apontados pelos usuários e testes encomendados para otimizar o
programa ou o software.
35 minutos
https://github.com/
Como cada vez mais as empresas estão conectadas, com e-commerces em franco crescimento, os dados
sensíveis também estão, assim como a possibilidade de invasões de criminosos cibernéticos. A importância de
conhecer as brechas de sistemas é de fundamental importância para as empresas se precaverem e evitarem
grandes prejuízos.
INVASÃO HACKER
Talvez, a de�nição de hacker ainda traga estranheza e descon�ança. Para entendemos o conceito de invasão
hacker, começaremos entendendo o que são hackers, como surgiram, a diferença dessas pessoas para os
crackers, entre outras de�nições na área de segurança cibernética e qual a sua relação com os testes de
softwares e sistemas.
O termo hacker tem como origem os carpinteiros que faziam móveis com machados. Na década de 1960, o
termo passou a ser utilizado dentro do contexto da informática para descrever projetos acadêmicos que
exigiam muita dedicação e concentração dos estudantes, em especial do Massachusetts Institute of
Technology (MIT), onde jovens estudantes começaram a interagir com computadores e programação ou, em
outras palavras, podemos dizer que o termo foi inicialmente designado dentro da informática para
especialistas em computação e programação (ULBRICH; DELLA VALE, 2004).
Por conta de criminosos que começaram a utilizar esses conhecimentos mais profundos de informática para
cometer ataques e crimes cibernéticos, a própria comunidade hacker criou o termo cracker para de�nir essas
pessoas. De acordo com McClure, Scambray e Kurtz (2014), muitas informações de segurança de uma
organização podem �car vulneráveis a ataques de criminosos com grandes conhecimentos de informática. O
Quadro 1 mostra quais são as possíveis informações organizacionais que podem estar vulneráveis a invasões
de hackers “do mal”:
Quadro 1 – Informações vulneráveis às invasões cibernéticas
Tecnologia Informações
Internet Nomes de domínio, blocos de rede e sub-redes, endereços IP especí�cos de sistemas que
podem ser acessados pela internet, serviços TCP e UDP em execução em cada sistema
identi�cado, arquitetura de sistemas, mecanismos de controle de acesso e listas de controle
de acesso relacionadas, sistema de detecção de intrusão, enumeração de sistemas, nomes
DNS dos equipamentos.
Intranet Protocolos de rede em uso, nomes de domínios internos, blocos de rede, endereços IP
especí�cos de sistemas que podem ser acessados pela Internet, serviços TCP e UDP em
execução em cada sistema identi�cado, arquitetura de sistema, mecanismos de controle de
acesso, sistemas de detecção de intrusão, enumeração de sistemas.
Acesso
Remoto
Números de telefone analógicos e digitais, tipo de sistema remoto, mecanismos de
autenticação, VPNs e protocolos relacionados.
Extranet Nomes de domínio, origem e destino das conexões, tipos de conexão, mecanismos de
controle de acesso.
Fonte: adaptado de McClure, Scambray e Kurtz (2014).
Para evitar as invasões de hackers, o administrador do sistema ou o responsável pela segurança de dados
deve conhecer a extensão de seus negócios, como suas atividades, seus fornecedores e seus clientes, em
suma, todas as organizações e pessoas envolvidas. Segundo McClure, Scambray e Kurtz (2014), o excesso de
informações do website da empresa ou a disponibilização de inventários de patrimônios em planilhas em
servidores de rede internet é o su�ciente para o início de uma invasão. E isso não se limita apenas à internet
da empresa. Dados de funcionários, listas de contatos, dentre outros bancos de dados, são, através de
mineração de dados (ou data-mining), utilizados por criminosos virtuais para arquitetar invasões de dados.
Estamos falando de empresas, mas os golpes podem acontecer com pessoas físicas, como invasões de contas
bancárias, ou usar computadores pessoais que tenham algum tipo de acesso à rede empresarial para realizar
ataques e invasões. Conforme os autores, há a possibilidade de fazer invasões partindo de páginas de buscas
populares.
Podemos dividir os tipos de invasão em três grupos principais:
• Invasão de usuários �nais em empresas e servidores: é a invasão através de brechas de segurança em
sistemas operacionais, como algumas versões do Windows, o que também vale para servidores controlados
por versões dos anos 2000 do Windows Server, por exemplo. Utilizamos aqui o Windows como exemplo, mas
esse tipo de ataque à ponta (ou usuário �nal e servidores) pode ocorrer em outros sistemas operacionais, à
medida que se tornam populares e de maior interesse por parte de hackers criminosos.
• Invasão de infraestrutura: é a invasão através, por exemplo, da rede sem �o de uma empresa, por meio da
detecção, com a utilização de equipamentos apropriados, de falhas ou brechas nessa rede.
• Invasão de aplicativos e de dados: é a invasão de aplicativos, geralmente disponíveis na web, em redes
locais ou em computadores locais, e seus dados. Com o aumento do uso da internet por usuários e a melhora
na usabilidade de aplicações web – com a Web 2.0 e 3.0, estas últimas se tornaram passíveis de ataques e
invasões.
VIDEOAULA: INVASÃO HACKER
A de�nição inicial de hacker não estava relacionada a pessoas criminosas dentro do meio digital, mas muitos
dos que detêm grande conhecimento de programação, redes e computação em geral acabaram utilizando
seus conhecimentos para atacar partes vulneráveis dos sistemas de empresas.
HACKERS DO BEM
A de�nição inicial dada aos hackers – pessoas com alto conhecimento de informática e, mais especi�camente,
redes e programação (ULBRICH; DELLA VALE, 2004) – contrasta com muitos hackers que escolheram o
caminho criminoso, os chamados crackers, como já mencionado. No entanto, o conhecimento profundo de
segurança da informação permite aos hackers do bem serem peças fundamentais para evitar, descobrir
falhas de segurança e implementar maiores camadas de segurança em redes, sistemas, estruturas e
softwares. Mesmo assim, a de�nição de hackers por alguns autores pode ser controversa. Lemos, Seara e
Pérsio (2002) explica, de forma sucinta, essa diferença:
A partir dessas de�nições, por vezes controversas, são listados aqui os tipos de hackers que existem
(SKOUDIS; LISTON, 2005):
• White Hats ou Gray Hats, que são os hackers do bem, considerados pelos autores como hackers que estão
“em cima do muro”, que fazem pequenos ataques do tipo deny of servic ou DOS, para derrubar páginas da
internet ou burlar a licença de programas.
• Black Hats, que são os já mencionados crackers, que os autores consideram como vândalos ou criminosos
digitais.
Amaral e Pretto (2012) consideram um terceiro grupo, ou subgrupo dos white hats, os ethical hackers, que
usam seus conhecimentos como atividade pro�ssional, contratados como terceiros ou colaboradores da
própria empresa e identi�cam vulnerabilidades dos sistemas e das redes. Segundo os autores, esse é um
mercado em crescimento, devido ao crescente aumento da segurança de dados das empresas e dos ataques
cibernéticos. Esse tipo de hacker pode ser considerado, dentre todos os tipos mencionados aqui, os
verdadeiros hackers do bem, que possuem as características dos primeiros hackers e utilizam essas
características para proteger empresa e pessoas.
Videoaula: Invasão hacker
Para visualizar o objeto, acesse seu material digital.
Os hackers são bem diferentes dos marginais ou vândalos da informática – os crackers. O
termo foi criado pelos próprios hackerscomo forma de diferenciação dos marginais da
cibercultura, embora na maioria das vezes a imprensa e a mídia em geral não façam essa
distinção, aumentando a má compreensão desses personagens da sociedade
informacional. Além de alertar as autoridades competentes de que seus sistemas não
estão seguros, e sim passíveis de ataques por parte de pessoas mal-intencionadas, eles
revelam o papel que as novas tecnologias de informação desempenham na sociedade
globalizada. 
— (LEMOS; SEARA; PÉRSIO, 2002, p. 27)
• Ulbrich e Della Vale (2004) mencionam outros tipos de hackers, como o curioso, que faz invasões por desa�o;
o vaidoso, que faz as invasões e as divulga na internet, para se promover; o patriota e o ativista, os quais,
geralmente, atribuem seus ataques e suas invasões a uma causa. Obviamente, o primeiro com motivos
relacionados ao seu país, e o segundo, atacando instituições e governos, desobedecendo a leis com a ideia de
que esteja fazendo um bem maior. Esse último, inclusive, pode “fazer o bem” por identi�car informações de
pessoas criminosas da vida real, como tra�cantes e terroristas
VIDEOAULA: HACKERS DO BEM
Conforme a de�nição original de hacker, muitos dos que detêm conhecimento amplo de computação podem
ser aliados para trabalhar com segurança de informação dentro de empresas e grandes companhias de
tecnologia, os hackers do bem. Os que utilizam seus conhecimentos para o mal são conhecidos como
crackers.
PREJUÍZOS CAUSADOS POR INVASÕES HACKERS
Com uma simples busca na internet por ataques cibernéticos, é possível veri�car os prejuízos que podem ser
causados pelos hackers do mal. De acordo com Silva (2021), em agosto de 2021, a empresa varejista Renner
�cou com seu site de e-commerce fora do ar por muitas horas, e é difícil de mensurar os prejuízos causados
por esse ataque. O hacker que faz esses tipos de ataques a grandes empresas, geralmente, pede uma espécie
de resgate, para que elas tenham de volta seus bancos de dados, muitas vezes criptografados.
Outro tipo de prejuízo que empresas poderão arcar é que com a Lei Geral de Proteção de Dados (LGPD). Os
dados expostos (dos clientes, por exemplo) geram multas, muitas vezes milionárias, e o valor está atrelado à
quantidade de dados expostos.
Ainda conforme relato de Silva (2021), a Kaspersky, que é uma empresa especializada em softwares antivírus e
de segurança cibernética, registrou um aumento de ataques e invasões do tipo ransomware em 767%, entre
2019 e 2020. Esse tipo de ataque – o ransomware – é um tipo de invasão e roubo de dados, em que há pedido
de resgate. Os prejuízos causados aos clientes da Kaspersky chegaram a um bilhão de dólares. Outra empresa
brasileira vítima de ataques foi a JBS, nos Estados Unidos. Ao contrário da Renner, no mesmo ano, preferiu
pagar o resgate dos dados aos hackers criminosos, que chegou a 11 milhões de dólares, o que não é
recomendado por especialistas.
Empresas, como Carrefour, no Brasil, frente à LGPD (que deve estar atrelada às políticas de segurança digital)
e já com conhecimentos da GDPR, que é a legislação de proteção de dados equivalente na Europa, onde a
empresa possui sede, se adequaram a essa legislação, o que envolveu, além dos especialistas em tecnologia
da informação e segurança de dados, os outros colaboradores da empresa.
Assim como mencionado no caso da empresa Carrefour, a melhor forma de evitar ataques, invasões e os
consequentes prejuízos, que são maiores, pois quanto maior a empresa, maior a prevenção e a constante
atualização de sistemas, além de ter como aliados os hackers do bem, que estão alinhados com a segurança
cibernética. Conforme Silva, Mesquita e Paiva (2018, p. 10):
Videoaula: Hackers do bem
Para visualizar o objeto, acesse seu material digital.
A importância de se proteger de ataques mal-intencionados que resultam em roubo de
dados con�denciais, negação de serviços, espionagem e modi�cação de sites aumenta a
responsabilidade individual e coletiva, implantando políticas de segurança e treinamentos
para a prevenção de incidentes indesejados. Violações de segurança de computador ou
rede são comuns, e ocorrem em todo o mundo todos os dias. Alguns são considerados
menores, com pouca perda de dados ou recursos monetários, mas muitos deles são
considerados importantes, ou mesmo catastró�cos. Os Hackers estão constantemente à
procura de vulnerabilidades para explorar. Quando as redes não são seguras, as
informações sobre organizações e indivíduos, e até mesmo o governo, correm o risco de
serem invadidas e expostas.
VIDEOAULA: PREJUÍZOS CAUSADOS POR INVASÕES HACKERS
Empresas podem estar vulneráveis a invasões de hackers. Nessas invasões ocorrem roubos de grandes
quantidades de dados, como de clientes e de dados sensíveis das empresas. Os criminosos pedem valores
milionários para o resgate dos dados, além do prejuízo causado pela insegurança dos clientes em ter seus
dados expostos.
ESTUDO DE CASO
Você é gerente de segurança digital de uma grande empresa varejista brasileira. Ela se encontra em franco
crescimento, com faturamento diário que chega às cifras dos milhões, o que a faz passar a ser mais presente
nas mídias comuns, bem como nas mídias sociais. Como é do seu conhecimento, quanto maior uma empresa,
maior o número de clientes e mais exposta na mídia ela está, como também estará mais exposta a possíveis
ataques de hackers criminosos. Para tanto e para se adequar à LGPD, você deve fazer adequações dentro do
seu departamento, que responde ao Diretor Geral de Tecnologia da Informação. Você deve, neste estudo de
caso, montar o escopo e o plano de ação detalhado para a diretoria da empresa, para a prevenção de ataques
cibernéticos. 
RESOLUÇÃO DO ESTUDO DE CASO
Para a resolução do estudo de caso, devem constar no escopo os possíveis prejuízos que a empresa pode ter
(sejam devido às multas por vazamento de dados – a LGPD deve ser citada neste caso –, sejam imensuráveis,
como a perda de con�ança na empresa varejista que você trabalha. No plano de ação, você deve inserir,
inclusive, a contratação de pessoas para sua equipe, incluindo um hacker do bem, que auxiliará a descobrir as
brechas existentes e as brechas que podem vir a aparecer com o crescimento da empresa, a intranet e a
extranet que a empresa usa e até as redes sem �o disponibilizadas aos clientes. 
 Saiba mais
Uma forma de conhecer as grandes invasões hackers da história do Brasil e do mundo e os prejuízos
gerados é pesquisando em páginas de tecnologia, como os links a seguir:
As empresas estão seguras? Parece que não. Disponível em: https://www.istoedinheiro.com.br/as-
empresas-estao-seguras-parece-que-nao/. Acesso em: 1º out. 2021.
Quais foram os maiores ataques hackers da história da internet? Disponível em:
https://gizmodo.uol.com.br/giz-explica-maiores-ataques-hackers-internet/. Acesso em: 1º out. 2021.
Videoaula: Prejuízos causados por invasões hackers
Para visualizar o objeto, acesse seu material digital.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
Aula 1
ANDERSON, D. Agile Management for Software Engineering: applying the theory of constraints for business
results. New Jersey: Prentice Hall, 2003.
REFERÊNCIAS
18 minutos
https://www.istoedinheiro.com.br/as-empresas-estao-seguras-parece-que-nao/
https://www.istoedinheiro.com.br/as-empresas-estao-seguras-parece-que-nao/
https://gizmodo.uol.com.br/giz-explica-maiores-ataques-hackers-internet/
ANDERLE, A. Introdução de BDD (Behavior Driven Development) como Melhoria de Processo no
Desenvolvimento Ágil de Software. UNISINOS: São Leopoldo, 2015.
BECK, K. et al. Manifesto for agile software development. 2001. Disponível em: http://agilemanifesto.org/.
Acesso em: 14 mar. 2022.
DUARTE, L. Scrum e métodos ágeis: um guia prático. 2 ed. Gravataí: Luiztools, 2021.
MARIOTI, F. Kanban: o ágil adaptativo. Engenharia de software magazine, São Paulo, ed. 45, 2017.
PINHEIRO, V.; VALENTIM, N. M. C.; VICENZI, A. M. R. Um comparativo na execução detestes manuais e testes
de aceitação automatizados em uma aplicação web. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE –
SBQS, 2015. Anais [...]. Manaus: Uninorte, 2015.
PRESSMAN, R. S. Engenharia de Software. Rio de Janeiro, RJ: McGraw Hill, 2002. 704p.
SBROCCO, J. H.; MACEDO, P. C., Metodologias Ágeis: engenharia de software sob medida. São Paulo, SP:
Érica, 2012. 256p.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo, SP: Pearson Addison-Wesley, 2007. 552 p.
Aula 2
BARTIE, A. Automação de Testes – Um caso de sucesso. iMasters, 2008. Disponível em:
https://imasters.com.br/desenvolvimento/automacao-de-testes-um-caso-de-sucesso. Acesso em: 13 set. 2021.
BERNARDO, P. C. Padrões de testes automatizados. 2011. Dissertação (Mestrado em Ciência da
Computação) – Universidade de São Paulo, São Paulo, 2011.
CAMPOS, M. Atualização: preciosismo ou necessidade? Aquarius, 2021. Disponível em:
https://www.aquarius.com.br/atualizacao-preciosismo-ou-necessidade/. Acesso em: 8 set. 2021.
CHIKOFSKY, E. Computer-Aided Software Engineering (CASE). Washington: IEEE Computer Society, 1993.
FARIAS, A. C. Ferramentas CASE: suporte, adoção e integração. 2001. Monogra�a (Graduação em Engenharia
de Software) – Universidade Federal de Pernambuco, Recife, 2001. Disponível em:
https://www.cin.ufpe.br/~acf/publications/CASETools-report.pdf.gz. Acesso em: 13 set. 2021.
GLASS, R. L. The Standish Report: Does It Really Describe a Software Crisis? Practical Programmer,
Communications of the ACM, v. 49, n. 8, 2006.
MARTINS, J. C.; TSCHANNERL, H. L. Testes de Software Aplicados à Orientação a Objetos. Bate Byte, 2021.
Disponível em: http://www.batebyte.pr.gov.br/Pagina/Testes-de-Software-Aplicados-Orientacao-Objetos#.
Acesso em: 13 set. 2021.
PELOSO, V. Ferramentas CASE: implementação de um protótipo para manutenção de banco de dados. 2014.
Monogra�a (Graduação em Engenharia de Comunicação) – Universidade São Francisco, Itatiba, 2014.
RAMOS, D. P. Ambientes de desenvolvimento de software (ADS) e ferramentas CASE: importância e
aplicações. 2011. Monogra�a (Especialização em Informática) – Universidade Federal de Minas Gerais, Belo
Horizonte, 2011.
REBÊLO, P. Windows 98: diferentes versões, instalações e problemas. UOL Tecnologia, 2008. Disponível em:
https://tecnologia.uol.com.br/ultnot/2008/06/27/ult4213u457.jhtm. Acesso em: 13 set. 2021.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo, SP: Pearson Addison-Wesley, 2007.
SOUZA, A. C. C. Uma contribuição à automatização da atividade de testes em realidade virtual. 2017.
Tese (Doutorado em Ciências) – Universidade de São Paulo, São Carlos, 2017.
TESTES automatizados e ferramentas de testes. Tecnisys, 2019. Disponível em:
http://www.tecnisys.com.br/noticias/2019/testes-automatizados-e-ferramentas-de-testes. Acesso em: 8 set.
2021.
VALENTIM, O. A. et al. Análise comparativa entre a implementação e atualização do sistema ERP R/3 da SAP
considerando os fatores críticos de sucesso descritos na literatura: um estudo de caso em uma empresa do
segmento de bebidas. Gest. Prod., São Carlos, v. 21, n. 1, p. 111-124, 2014. 
http://agilemanifesto.org/
https://imasters.com.br/desenvolvimento/automacao-de-testes-um-caso-de-sucesso
https://www.aquarius.com.br/atualizacao-preciosismo-ou-necessidade/
https://www.cin.ufpe.br/~acf/publications/CASETools-report.pdf.gz
http://www.batebyte.pr.gov.br/Pagina/Testes-de-Software-Aplicados-Orientacao-Objetos
https://tecnologia.uol.com.br/ultnot/2008/06/27/ult4213u457.jhtm
http://www.tecnisys.com.br/noticias/2019/testes-automatizados-e-ferramentas-de-testes
Aula 3
CALE, E. G.; ERIKSEN, S. E. Factors A�ecting the Implementation Outcome of a Mainframe Software Package – A
Longitudinal Study. Information & Management, v. 26, p. 165-175, 1994.
DEBASTIANI, C. A. De�nindo Escopo em Projetos de Software. São Paulo, SP: Novatec Editora 2016.
GESSER, C. E. Gerador de Analisadores Léxicos e Sintáticos. 2003. Trabalho de Conclusão de Curso
(Graduação em Ciências da Computação) – Universidade Federal de Santa Catarina, Florianópolis, 2003.
KURNIAWAN, Y. et al. Accounting Information Systems Implementation (A Case Study Approach). In:
INTERNATIONAL CONFERENCE ON INFORMATION MANAGEMENT AND TECHNOLOGY, 2., 2017, Yogyakarta.
Anais […]. Yogyakarta: ICIMTech, 2017.
LIU, C. et al. Software Reliability Testing in Practice: An Industry Case Study with a Typical Airborne Software
System. In: INTERNATIONAL CONFERENCE ON RELIABILITY, MAINTAINABILITY AND SAFETY, 10., 2014,
Guangzhou. Anais […].Guangzhou: WASET, 2014.
SBROCCO, J. H.; MACEDO, P. C. Metodologias Ágeis: Engenharia de Software sob Medida. São Paulo, SP: Érica,
2012.
SCHACH, S. Engenharia de software: os paradigmas clássico e orientado a objetos. 7. ed. São Paulo, SP:
McGraw-Hill, 2008.
SEABRA, R. D.; DRUMMOND, I. N.; GOMES, F. C. Análise Comparativa de Linguagens de Programação a partir
de Problemas Clássicos da Computação. Revista de Sistemas e Computação, Salvador,  v. 8, n. 1, p. 56-76,
2018.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo, SP: Addison Wesley, 2008.
ZAPALOWSKI, V. Análise Quantitativa e Comparativa de Linguagens de Programação. 2011. Monogra�a
(Graduação em Ciência da Computação) – Universidade Federal do Rio Grande do Sul, Porto Alegre, 2011.
Aula 4
AMARAL, S.; PRETTO, N. L. Ética, hacker e a educação. Campinas, SP: FE/UNICAMP, 2009.
LEMOS, A.; SEARA, S.; PÉRSIO, W. Hackers no Brasil. Revista Contracampo, n. 6, 2002.
MCCLURE, S.; SCAMBRAY, J.; KURTZ, G. Hackers Expostos: segredos e soluções para a segurança de redes.
Porto Alegre, RS: Grupo A, 2014.
ROCHA, J. V. Hackers e suas características. Novo Hamburgo, RS: Universidade Feevale, 2016.
SILVA, A. G.; MESQUITA, A. R. S.; PAIVA, C. E. Tecnologias e ferramentas para prevenção de ataques em redes
de computadores. Revista EduFatec: educação, tecnologia e gestão, v. 1, n. 2, São Paulo, 2018.
SILVA, B. As empresas estão seguras? Parece que não. Isto É Dinheiro, 2021. Disponível em:
https://www.istoedinheiro.com.br/as-empresas-estao-seguras-parece-que-nao/. Acesso em: 1º out. 2021.
SKOUDIS, E.; LISTON, T. Counter Hack Reloaded: a step-by-step guide to computer attacks and e�ective
defenses. 2. ed. Londres: Pearson, 2005.
ULBRICH, H. C.; DELLA VALLE, J. Universidade Hacker: desvendando todos os segredos do submundo dos
hackers. 4. ed. São Paulo, SP: Digerati, 2004.
https://www.istoedinheiro.com.br/as-empresas-estao-seguras-parece-que-nao/
Imprimir
INTRODUÇÃO
Estudante, qualidade e automação de testes é uma área em crescimento exponencial. Para dar continuidade
aos conhecimentos dessa disciplina, faz-se necessário introduzir os conceitos a respeito dos métodos ágeis e
algumas de suas ferramentas, para que você possa compreender melhor os aspectos por traz da testagem. 
Quando se fala a respeito dos testes, automaticamente, nos vem à mente “projeto de testes”. Dentro do
projeto de um novo produto, para se ter sucesso, é crucial que uma boa parte do valor gasto seja investido na
área de testes, pois eles possibilitam uma veri�cação do seu código, evitando erros, gargalos e,
consequentemente, prejuízos. Nessa aula, espero que você obtenha os conhecimentos necessários para
entender as características dos métodos ágeis e de duas metodologias associadas a eles, o BDD e TDD. Esses
conhecimentos lhe auxiliarão muito, uma vez que essas metodologias são recorrentes no mundo da
programação. Vamos aos estudos!
CONCEITOS SOBRE MÉTODOS ÁGEIS
Nesse bloco você aprenderá os conceitos relacionados aos métodos ágeis. O termo associado à metodologia
ágil é autoexplicativo. Ele visa ao aumento da performance nas organizações.  É um método para padronizar
ações nas organizações, independentemente do tipo de mercado ou do seu potencial produtivo. Quanto mais
rápido e com menor custo, melhor. Só que essa metodologia vai além, ela busca também a excelência, ou
seja, a qualidade dentro desses processos.
A metodologia ágil está muito voltada para equipes que buscamtrabalhar de maneira dinâmica, síncrona e
e�ciente, tirando o máximo de seus membros para entregar a melhor performance em determinado projeto.
Sendo assim, trabalhar projetos com métodos ágeis tende a trazer maiores resultados.
Entretanto, cabe ressaltar que a tecnologia está em constante evolução, mesmo assim ainda existe bastante
di�culdade na troca de informações e na comunicação quando o assunto é voltado aos projetos de softwares.
Dentro de um projeto, a comunicação é crucial para o sucesso ou o fracasso de um produto. É comum
existirem equipes que não conseguem se comunicar bem, devido aos seus diferentes níveis de
conhecimentos de programação, suas características e seus objetivos dentro do projeto.
Tem-se, no mesmo grupo de pessoas, o desenvolvedor, que faz o desenvolvimento da aplicação, tendo acesso
à classe, aos métodos. Independentemente da linguagem com a qual esteja trabalhando, ele tem acesso
direto ao código; os testers, que são voltados essencialmente para testar, sejam testes funcionais, de
usabilidade ou de performance. Eles focam nos testes em si, distanciando-se da equipe de desenvolvimento; o
QA, que é um pro�ssional responsável pela qualidade do produto, coordenando o planejamento, a estrutura e
a fabricação; outro stakeholder (parte interessada) nesses projetos é o P.O, que é, basicamente, o dono do
produto (WILDT et al., 2015; COHN, 2004).
Você observou que existem inúmeros pro�ssionais diferentes, preocupados com áreas distintas dentro de um
mesmo projeto, e todos eles podem testar o produto de alguma forma. É aí que se encontra o problema, pois
não se pode arriscar todo o trabalho do projeto escrevendo códigos que não serão entendidos por todos os
membros da equipe. Por exemplo: o desenvolvedor, que, em geral, é mais técnico, não pode correr o risco de
que o dono do produto  ou o responsável pela qualidade não consiga entender seu código. A equipe precisa
estar funcionando em sinergia. Em uma pesquisa empírica realizada por Koch e Oliveira (2010), os dados
coletados a partir de entrevistas deram a entender que, mesmo que todos os membros de uma equipe de
projetos utilizem determinada linguagem de programação, o maior risco levantado foi relacionado à
di�culdade de comunicação dentro da equipe.
Aula 1
MÉTODOS ÁGEIS: O BDD E O TDD
Compreender o BDD (Desenvolvimento Orientado por Comportamento) e o TDD (Desenvolvimento
Orientado a Testes), bem como as vantagens e desvantagens de aplicar. 
30 minutos
Foi diante dessa di�culdade que surgiram metodologias para lidar com esses problemas de comunicação,
como o BDD (Behavior Driven Development, ou Desenvolvimento Orientado ao Comportamento, em
português) e o TDD (Test Driven Development, ou Desenvolvimento Guiado por Testes, em português). Você
saberá mais sobre essas duas metodologias a partir do próximo bloco. 
VIDEOAULA: CONCEITOS SOBRE MÉTODOS ÁGEIS
Caro aluno, nesse bloco, entenderemos a demanda do mercado competitivo em relação à área de
programação, além da in�uência das equipes de métodos ágeis no aumento da performance nos projetos de
desenvolvimento de softwares.
DEFINIÇÃO E UTILIZAÇÃO DE BDD
Caro aluno, nesse bloco, falaremos sobre BDD, sua de�nição e utilização. Como vimos no bloco de conceitos
sobre métodos ágeis, um dos grandes problemas associado às equipes de projetos é a comunicação. O BDD
surge como uma possibilidade de solucionar tal problema. Usando uma linguagem mais comum, essa
metodologia busca facilitar a comunicação, principalmente quando falamos sobre equipes ágeis, nas quais
existem diversos pro�ssionais com diferentes características trabalhando no mesmo projeto.
Observando a di�culdade dos desenvolvedores em se comunicaram com leigos a respeito do funcionamento
dos códigos, Dan North viu a possibilidade de resolver esse gargalo. Em 2003, ele deu origem ao Behavior
Driven Development, o BDD, que em português signi�ca Desenvolvimento Guiado por Comportamento.
Atualmente, esse é um dos métodos mais utilizados em equipes de desenvolvimento ágil para softwares. Tal
técnica pode ser entendida como uma continuação ou mesmo um avanço da técnica conhecida como Test
Driven Development, o TDD, que em português signi�ca Desenvolvimento Guiado por Testes (veremos mais
sobre o TDD no próximo bloco). O BDD tem como prioridade criar sinergia entre os diversos membros dentro
das equipes de projetos ágeis, reduzindo as possíveis interpretações errôneas e as falhas originadas dessa má
comunicação, especi�cando regras de negócios enquanto as associa com linguagem de programação (NORTH,
2006).
Sendo assim, o BDD pode ser considerado uma prática de desenvolvimento ágil, uma vez que busca a
integração entre os negócios e a programação, e essa união é a principal característica das equipes de
projetos ágeis. Ao invés de impor restrições técnicas e individualizadas, o BDD incentiva a colaboração dentro
da equipe de projeto de softwares, facilitando a comunicação, inclusive com o próprio cliente, já que esse é o
principal interessado no resultado �nal do projeto.
Soares (2011) destaca que essa prática pode ser de�nida como a junção de diversas práticas ágeis na
formulação de softwares, com foco na linguagem e nas conexões usadas no período do processo de
desenvolvimento, permitindo uma melhor comunicação entre o desenvolvedor e a equipe, uma vez que se
utiliza uma linguagem de visão uni�cada e compartilhada entre a equipe envolvida no desenvolvimento do
projeto. North (2012) a�rma que o BDD é uma espécie de TDD, entretanto mais democrático, visando ser
entendido por uma gama maior de pessoas, como os donos do produto, os testadores, os QA, os gerentes e
outros membros das equipes de projetos. O BDD pode ser considerado uma comunicação-chave entre os
stakeholders, criando uma comunicação limpa e e�ciente, voltada para o projeto.
Caro aluno, já deu para perceber a importância do BDD no sucesso das equipes de projetos ágeis. A
comunicação é um fator-chave em todos os negócios, e na programação não é diferente. Os códigos são
importantes, mas ter a possibilidade de interpretá-los, deixando-os mais acessíveis para os diferentes
pro�ssionais, é o que torna o BDD especial, mas ele não seria possível sem o chamado TDD, assunto que
introduziremos no próximo bloco. Vamos aos estudos!
VIDEOAULA: DEFINIÇÃO E UTILIZAÇÃO DE BDD
Caro aluno, nesse bloco, veremos um pouco mais sobre o desempenho das equipes de projetos ágeis e o
empecilho da comunicação dentro dos processos de desenvolvimento de softwares. Abordaremos o BDD e a
sua importância para democratizar a linguagem de programação dentro das equipes de projetos ágeis,
facilitando os processos e aumentando a performance. 
Videoaula: Conceitos sobre métodos ágeis
Para visualizar o objeto, acesse seu material digital.
PRINCÍPIOS DE TDD E UTILIZAÇÃO
Caro aluno, nos blocos passados, vimos a importância dos métodos ágeis e o uso do BDD como prática para
facilitar a comunicação em equipes ágeis. Nesse bloco, conheceremos um pouco mais sobre o TDD, prática
muito utilizada e que antecede o BDD.
É importante que você entenda que projetos ágeis voltados para desenvolvimento de software sofreram
alterações com o passar dos anos, sempre se transformando em busca de atender às demandas do mercado
consumidor. Nesse quesito, a programação não se desvincula dos outros mercados, ela tem por objetivo
atender à demanda dos clientes. E, como nos outros nichos de mercado, faz-se necessário também o alto
rendimento das equipes, trabalhando em menor tempo, com maior performance e mantendo o controle da
qualidade, evitando ao máximo as falhas. Diante dessas cobranças, o mercado de desenvolvimento de
softwares foi se adaptando, adotando metodologias ágeis e o gerenciamento dos seus projetos,
desenvolvendo parâmetros de performance e padronizando sua escrita de códigos. Mesmo assim, as falhas
permanecem, e o tempo de testagem ainda é um grande gargalo nos projetos de desenvolvimento de
softwares. Para tentar mitigaressas falhas e utilizar o tempo de testagem de maneira otimizada, surgiu o TDD.
O chamado Test Driven Development, ou Desenvolvimento Guiado por Testes, é uma das práticas de
desenvolvimento utilizado por equipes de projetos ágeis. O nome dessa metodologia é autoexplicativo, uma
vez que ela utiliza testes automatizados para dar suporte aos desenvolvedores ainda nas fases iniciais do
desenvolvimento de software. O fato de o desenvolvimento se basear nos testes pode parecer um pouco
estranho à primeira vista, mas �que tranquilo, pois esse estranhamento é comum até mesmo entre os
desenvolvedores. É comum também se questionar o fato de que nesse método se pensa no teste primeiro e,
depois, no desenvolvimento, uma vez que a cultura de desenvolvimento costuma ter como base o
desenvolvimento primeiro e, depois, os testes. Todavia, existe um motivo para escrever os testes antes
mesmo de se iniciar a escrita dos códigos: os desenvolvedores se asseguram que uma parte considerável do
seu sistema possua um teste que valide seu funcionamento (ANICHE, 2014).
O TDD se diferencia a partir do ponto em que auxilia a focalizar os problemas certos na hora certa, fazendo
com que o projeto de produto permaneça o mais limpo possível e com uma quantidade de falhas
consideravelmente menor. Usar o TDD, ou seja, escrever o teste antes do código, incentiva o uso da escrita de
códigos de maneira simples, passando mais con�ança, melhorando sua compreensão e possibilitando a
automação dos testes, uma vez que foram estabelecidos antes do código, e o desenvolvedor estará preparado
para possíveis falhas, evitando surpresas desagradáveis, como falhas gerais ao �nal do projeto (BECK, 2002).
Na aula “Estudando mais profundamente o TDD”, você entenderá melhor sobre o desenvolvimento e o ciclo
do TDD. Bons estudos!
VIDEOAULA: PRINCÍPIOS DE TDD E UTILIZAÇÃO
Caro aluno, nesse bloco, veremos como o tempo gasto em testes in�uencia na entrega �nal de um projeto de
desenvolvimento de software. Os testes tomam muito tempo e, mesmo assim, inúmeros projetos sofrem
falhas e têm seu resultado �nal bem aquém daquilo que foi desejado pelo consumidor �nal. 
ESTUDO DE CASO
O mercado competitivo in�ige cobranças cada vez mais rígidas para a área da programação. Com o passar do
tempo, os métodos ágeis foram sendo aprimorados para atender a essas demandas. Equipes de projetos
ágeis envolvem pro�ssionais diferentes, cada um com suas funções e particularidades dentro do projeto. 
Você foi contratado por uma organização para liderar uma equipe que visa projetar um software que facilite a
tomada de decisão relacionada à compra e venda de ações no mercado �nanceiro. Esse software tem que
avaliar o histórico das ações e indicar os melhores investimentos baseados em parâmetros pré-estabelecidos. 
Videoaula: De�nição e utilização de BDD
Para visualizar o objeto, acesse seu material digital.
Videoaula: Princípios de TDD e utilização
Para visualizar o objeto, acesse seu material digital.
Sua equipe está enfrentando um problema de comunicação, o desenvolvedor é excelente, entretanto os
outros membros possuem di�culdades em entender seus códigos, e você acaba não conseguindo explicar
para o cliente as particularidades na evolução do projeto. 
Diante disso, quais as possibilidades, enquanto gerente do projeto, que você enxerga que possam ser
tomadas para facilitar o processo comunicativo da sua equipe e atingir o máximo de resultado no projeto
desse software?
RESOLUÇÃO DO ESTUDO DE CASO
Problemas, em sua maioria, não possuem verdades absolutas, mas, com base na aula “Métodos ágeis: o BDD
e o TDD”, é possível indicar soluções pertinentes para o acontecido nesse estudo de caso. 
A primeira coisa que você precisa entender é se o problema de fato é o entendimento dos códigos em relação
ao programador. Mesmo o estudo de caso indicando que esse seja o caso, a vida real sempre exibe
complexidade, e avaliar o cenário e as possibilidades é seu dever. 
Dito isso, busque soluções baseadas no Desenvolvimento Orientado por Comportamento, uma vez que ele
usa uma linguagem mais simples e voltada para a adaptação dos negócios à programação. É importante que
você explique ao desenvolvedor que, por mais que seus códigos sejam excelentes, vocês estão lidando com
um mercado competitivo e necessitam se adaptar às demandas que só uma equipe em sinergia conseguirá
atender.  
 Saiba mais
Uma boa dica para entender melhor o contexto dos métodos ágeis é um livro que está presente na sua
biblioteca virtual: Métodos Ágeis para Desenvolvimento de Software. Acesse através do link a seguir:
https://integrada.minhabiblioteca.com.br/reader/books/9788582602089/pageid/106. Acesso em: 11 mar.
2022.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Caro aluno, nessa aula, você aprofundará seu conhecimento a respeito do BDD, o Desenvolvimento Orientado
por Comportamento. Você verá tanto a forma como se desenvolve o BDD, seu ciclo e a importância do
brainstorming como ferramenta de aprimoramento dessa metodologia. 
Você já viu anteriormente que a qualidade e automação de testes é uma área com grande potencial de
crescimento no mercado competitivo. Para se entregar um produto de qualidade e dentro das características
solicitadas pelo cliente, é necessário realizar testes e manter os padrões de qualidade. O BDD é uma
ferramenta que pode auxiliar neste quesito, principalmente por atacar um ponto crucial, que é gargalo nas
equipes de desenvolvimento de software: a comunicação. Então, vamos aos estudos para entender um pouco
mais sobre o BDD. 
DESENVOLVIMENTO GUIADO POR BDD
Aula 2
ESTUDANDO MAIS PROFUNDAMENTE O BDD
Para se entregar um produto de qualidade e dentro das características solicitadas pelo cliente, é
necessário realizar testes e manter os padrões de qualidade.
30 minutos
https://integrada.minhabiblioteca.com.br/reader/books/9788582602089/pageid/106
Caro aluno, nesse bloco, falaremos de maneira mais aprofundada a respeito do Behavior Driven
Development, ou Desenvolvimento Guiado por Comportamento, o BDD. Como você se lembra, ele surge
como uma possibilidade de acertar um gargalo recorrente nas equipes de desenvolvimento de softwares, que
é a comunicação, fazendo uso de uma linguagem mais comum, que possa ser entendida por todas as partes
interessadas do projeto, e aliando as regras de negócios à linguagem de programação.
O BDD funciona focado no entendimento do requisito do projeto, auxiliando as partes interessadas a inferir
esforço em pontos considerados críticos no projeto, como a identi�cação e a compreensão do contexto por
trás dos usuários, com uma visão intensa sobre a comunicação (SMART, 2014). Essa metodologia incentiva a
participação de todos os envolvidos no projeto, sejam eles desenvolvedores, analistas de negócios, testers, o
dono do produto (P.O) e as demais áreas técnicas e não técnicas.
O BDD surgiu como uma tentativa de aperfeiçoar o TDD, deslocando-se um pouco dos conceitos de teste, uma
vez que muitos desenvolvedores não gostavam de realizar testes antes de desenvolver os códigos. Com isso,
Dan North, percursor do BDD, empregou seu esforço para trabalhar com frameworks que removessem as
referências dos códigos a testes, modi�cando o vocabulário a partir do contexto de “comportamento”
(NORTH, 2006). Sanchez (2006) mostra alguns exemplos desse novo vocabulário, como o uso de Context ao
invés de TestCase; Should ao invés de Assert; Speci�cation ao invés de Test.
O BDD não visa anular o TDD, pelo contrário, seu intuito é adicionar a ele um conjunto de benefícios,
incluindo: uma melhor comunicação entre os times de desenvolvimento, uma vez que, na grande parte
das empresas, as equipes possuem di�culdade de comunicação; divisão de conhecimento, compartilhando
informações e criando sinergia dentro de uma equipe multifuncional; documentação dinâmica, uma vez que
os frameworks de BDD possibilitam a geração de documentação de maneira mais prática,evitando esforços
secundários; uma visão holística, sugerindo que tanto os analistas como os testadores escrevam uma base,
um cenário, antecipadamente ao desenvolvimento dos códigos em si, tornando possível que eles tenham um
panorama geral das características solicitadas para o projeto (NORTH, 2006).  Enquanto o TDD se concentra
em envolver o design do código, o BDD se estabelece a partir do comportamento do sistema. Assim, enquanto
o BDD cria um cenário, o TDD realiza as funcionalidades da programação dentro deste cenário. North (2006)
ainda destaca que o BDD pode extrair as características solicitadas pelo cliente durante o levantamento dos
requisitos do projeto. Tal aspecto facilita a comunicação e o entendimento da equipe.
Dito isso, no próximo bloco, falaremos da criação de diferentes cenários para testagem de programas através
do BDD. Foco nos estudos!   
VIDEOAULA: DESENVOLVIMENTO GUIADO POR BDD
Caro aluno, nesse bloco, você aprenderá algumas características mais aprofundadas a respeito do BDD.
Entenderá os motivos da facilidade da comunicação e o uso de cenários baseados em comportamento e como
ele associa as regras dos negócios à linguagem de programação.
CICLO DO BDD – CRIAÇÃO DE DIFERENTES CENÁRIOS PARA TESTAGEM DO PROGRAMA
Caro aluno, nesse bloco, daremos continuidade ao nosso processo de aprendizado, aprofundando nossos
conhecimentos a respeito do BDD, entendendo a criação de diferentes cenários para testagem de programas.
O BDD tem por característica uma visão voltada para a linguagem e as interações decorrentes do
desenvolvimento dos softwares. As equipes aproveitam esse aspecto, uma vez que, durante o
desenvolvimento dos códigos, o uso dessa técnica permite uma comunicação mais e�ciente entre as equipes
no projeto, porque, a partir dela, os desenvolvedores escrevem testes a partir de uma linguagem estruturada
em combinação com sua linguagem nativa (SMART, 2014).
Existem três princípios que norteiam a utilização da prática BDD:
• Nada além do su�ciente: não se deve realizar menos do que o necessário para obter as especi�cações
estabelecidas, entretanto realizar mais do que o necessário pode ser um esforço que gera desgaste sem
sentido para a equipe.
• Entregar valor às partes interessadas: se a ação que você estiver realizando não agrega valor para a
equipe ou para o produto, pare de realizá-la imediatamente.
Videoaula: Desenvolvimento guiado por BDD
Para visualizar o objeto, acesse seu material digital.
• Tudo deve se basear em comportamento: do código às especi�cações para aplicá-lo, tudo deve ser
realizado a partir da mesma linguística, para descrever comportamento.
Ademais, como dito no bloco anterior, não conseguimos destacar as características do BDD sem citar o TDD. É
necessário destacar o papel do TDD ao in�uenciar o BDD, descrevendo suas proximidades e diferenças. Então,
enquanto o TDD se concentra em envolver o design do código, o BDD se estabelece a partir do
comportamento do sistema. Assim, enquanto este cria um cenário, aquele realiza as funcionalidades da
programação dentro deste cenário.
North (2006) destaca que o BDD pode extrair as características solicitadas pelo cliente durante o levantamento
dos requisitos do projeto. Essa prática se baseia no uso de cenários utilizados para registrar os
comportamentos que são esperados de determinado software, fazendo com que seja possível automatizar
esses cenários para dar validade a algum comportamento.
Tal aspecto facilita a comunicação e o entendimento da equipe. Ele ainda ressalta que não se pode utilizar um
template arti�cial, ao ponto de gerar restrições aos analistas, nem engessado demais, ao ponto de não
atender às expectativas do cliente. Tem de existir um equilíbrio, dando estrutura su�ciente para fragmentar a
história e automatizar as partes. Sendo assim, estabeleceram-se critérios de aceitação para os cenários: Given
(Dado), referente a algum contexto inicial, representando uma pessoa ou um papel a ser desempenhado;
When (Quando), referente a quando algum evento acontecer, alguma funcionalidade; Then (Então), quando
se veri�ca, para gerar benefício ou valor à funcionalidade, assegurando os resultados. Dessa maneira, em
Given (dado) serão determinados todos os requisitos precisos antes, para que, When (quando) o fenômeno
ocorrer, Then (então) se veri�ca o resultado (NORTH, 2006; COHN, 2004).
Destacadas as características dos cenários, no próximo bloco, conheceremos uma importante ferramenta
usada junto à prática BDD, o brainstorming. Vamos aos estudos?
VIDEOAULA: CICLO DO BDD – CRIAÇÃO DE DIFERENTES CENÁRIOS PARA TESTAGEM DO
PROGRAMA
Caro aluno, nesse bloco, você aprenderá mais sobre a criação de diferentes cenários para testagem no BDD,
entendendo os princípios que norteiam essa prática e identi�cando características voltadas ao
comportamento e os possíveis resultados dessa prática.
A IMPORTÂNCIA DO BRAINSTORMING E O BDD
Caro aluno, destacamos algumas vezes a importância da comunicação dentro das equipes de
desenvolvimento de softwares e como o BDD possibilita essa facilidade através do seu modo de operação por
cenários a partir de uma linguagem que associa a regra dos negócios à linguagem de programação. Nesse
bloco, conheceremos o brainstorming (tempestade de ideais), a sua importância e sua associação com o BDD.
A tempestade de ideias pode ser entendida como um processo realizado por um grupo de indivíduos, no
nosso caso, dentro das equipes de desenvolvimento de softwares. A ferramenta consiste na perspectiva de
captar ideias dos indivíduos participantes. Essas ideias podem ser concebidas de forma livre, sem nenhuma
crítica, e o mais rápido possível. Para que funcione bem, a equipe deve possuir de cinco a doze membros, e
recomenda-se que a participação seja por vontade própria, com regras bem de�nidas e dentro de um prazo
estabelecido. É interessante o uso de facilitadores, membros que sejam treinados para lidar com a equipe
(MARSHALL JUNIOR et al., 2015).
O brainstorming tem como objetivo gerar e detalhar ideias com um determinado foco. No caso das esquipes
de desenvolvimento de softwares, em geral, é lidar com os requisitos solicitados pelo cliente. Além disso, as
ideias precisam ser originais e em um ambiente sem inibições. Dentro dessa prática, busca-se a diversidade
nas ideias diante de um momento de criatividade em grupo (MARSHALL JUNIOR et al., 2015). Essa ferramenta
pode contribuir muito para o desenvolvimento de equipes ágeis, facilitando ainda mais a comunicação e
potencializando os resultados do uso do BDD.
Ainda segundo Marshall Junior et al. (2015), essa ferramenta possui algumas características importantes, são
elas: capacidade de autoexpressão, desfazendo-se de inibições e preconceitos vindos da equipe e da própria
pessoa; liberação da criatividade; capacidade de conviver com diferenças; ausência de julgamento
Videoaula: Ciclo do BDD – Criação de diferentes cenários para testagem do programa
Para visualizar o objeto, acesse seu material digital.
prévio; registro de ideias; capacidade de síntese; delimitação de tempo; ausência de hierarquia
(durante o processo). Ademais, o autor ainda caracteriza três fases típicas relacionadas à prática da
tempestade de ideias:
1. Objetividade na apresentação do tema.
2. Documentação das ideias após serem geradas.
3. Analisar e selecionar as ideias.
Ainda cabe destacar uma variação do brainstorming que é o brainwriting, conhecido como brainstorming
fechado. Nessa prática, existe uma diferença central, as ideias e opiniões apresentadas são feitas por escrito,
sem exposição oral na parte de exposição das ideias. Essa ação é realizada com o intuito de reduzir a chance
de ocorrerem críticas ou inibições sobre a fala dos membros da equipe. Todo o restante das etapas se
assemelha bastante à tempestade de ideias tradicional.    
O uso dessa técnica potencializa ainda mais as características comunicativas do BDD, criando mais interação
entre as diversas partes interessadasda equipe do projeto. Essa prática pode ser utilizada para discutir
especi�cações do cliente, propor soluções para problemas com códigos, montagem de cenários e
interpretação de aspectos comerciais. Todas as nuances podem e devem ser utilizadas pelas equipes ágeis na
busca de otimizar sua performance.
VIDEOAULA: A IMPORTÂNCIA DO BRAINSTORMING E O BDD
Caro aluno, nesse bloco, você aprenderá sobre o uso da tempestade de ideias, suas principais características,
regras e utilidade. Além disso, você entenderá de que maneira o uso dessa técnica pode aperfeiçoar e
otimizar os resultados do Desenvolvimento Orientado por Comportamento, o BDD.
ESTUDO DE CASO
Você é o desenvolvedor de uma empresa de programação e foi indicado para fazer parte de uma equipe ágil
de desenvolvimento de software em um projeto para um dos principais clientes da sua organização. É uma
oportunidade ímpar na sua carreira, uma vez que trabalhará com excelentes pro�ssionais e em um projeto
grande, que gerará bastante valor ao seu portfólio. 
Ao se reunir com a equipe e receber a solicitação do cliente (que está na reunião), você percebeu que existe
uma di�culdade na comunicação, uma vez que está difícil entender as especi�cações do cliente, assim como a
dinâmica do grupo está abalada. Mesmo a equipe possuindo excelentes pro�ssionais, o ruído na comunicação
está tornando o início do projeto bastante con�ituoso, gerando atrasos e, consequentemente, prejuízo. Ao se
deparar com essa situação, o gerente de projetos pediu ajuda e perguntou se alguém enxerga alguma saída
para a continuidade do projeto. Essa é a sua oportunidade! Qual proposta você sugeriria ao gerente de
projetos para lidar com essa situação?
RESOLUÇÃO DO ESTUDO DE CASO
Caro aluno, usando os conhecimentos adquiridos nessa aula, tome a frente e responda ao gestor de projetos. 
Primeiro, sugira o uso do BDD como prática para programar. Como você é o desenvolvedor, o fato de querer
simpli�car o código e o deixar acessível ao entendimento de todos será visto com bom tom pela equipe. 
Depois, sugira realizar uma tempestade de ideias com a participação do cliente, para que vocês consigam
entender melhor as perspectivas e as possibilidades, a �m de solucionar as questões envolvidas nas
características do produto solicitado. 
Com essas duas ações, uma potencializará a outra e, assim, a comunicação e a sinergia entre a equipe
evoluirão. 
Videoaula: A importância do brainstorming e o BDD
Para visualizar o objeto, acesse seu material digital.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
 Saiba mais
Deixo como indicação o livro Treinamento de equipes ágeis, que pode ser acessado na sua biblioteca
virtual a partir do link: https://integrada.minhabiblioteca.com.br/reader/books/9786555206340/pageid/0.
Acesso em: 11 mar. 2022
INTRODUÇÃO
Caro aluno, nessa aula, aprofundaremos nossos estudos a respeito do Test-Driven Development, ou
Desenvolvimento Orientado a Testes (TDD). A atualidade trouxe grandes transformações em busca de atender
de maneira mais e�ciente às solicitações dos clientes com demandas por softwares. Parte disso, traz de
maneira ainda mais forte a necessidade da qualidade e automação dos testes, uma vez que a otimização na
programação também segue as premissas do mercado competitivo tradicional. Entregar o máximo no menor
tempo possível, com o menor custo, e eliminar as falhas, mantendo o mais alto nível de qualidade. Nessa aula,
você conhecerá mais profundamente essa metodologia que coloca o teste como prioridade na busca pela
redução das falhas. 
DESENVOLVIMENTO GUIADO POR TDD
Caro aluno, a área de desenvolvimento de software está em crescimento constante e, assim como as demais
áreas do mercado, as equipes que trabalham com programação também precisam ser competitivas. Ser
competitivo passa por otimizar os processos, realizando as etapas no menor tempo possível, com o menor
custo, evitando falhas e mantendo a qualidade no máximo.
As equipes responsáveis por projetos de desenvolvimento de software estão sempre se atualizando para
manter essa competitividade. Entretanto, um grande gargalo nesse modelo de mercado é a testagem, que
consome muito tempo e, mesmo assim, boa parte dos projetos �ca abaixo das expectativas dos clientes e
gera muitas falhas. Você, na aula “Métodos ágeis: o BDD e o TDD”, aprendeu que o Test-Driven Development,
ou Desenvolvimento Orientado por Testes (TDD) surge como possibilidade de mitigar esse gargalo, colocando
os testes como prioridade no projeto.
Como você já sabe um pouco sobre o TDD, nós, agora, entenderemos um pouco mais a respeito de suas
características e de seu funcionamento. Essa metodologia se baseia nos testes. A escrita do teste é realizada
antes mesmo da própria escrita do código. Isso faz com os desenvolvedores se assegurem de que uma parte
considerável do seu sistema possua um teste para validar sua operação (ANICHE, 2014).
Beck (2003) destaca que o TDD deixa os projetos de software mais limpos, à medida que ele direciona o
projeto indicando os problemas na hora certa, e isso reduz a quantidade de falhas no projeto. Ele ainda a�rma
que esse método encoraja a simpli�cação dos códigos, e que códigos simples inspiram maior con�ança.
No desenvolvimento do TDD, a implementação do código só vem depois da realização da escrita dos testes.
Cria-se o teste primeiro, e o programador precisa compreender o problema para que possa realizar os testes.
A partir dessa ótica, evita-se que o desenvolver acabe retardando a compreensão do problema e tenha como
resultado códigos mais �dedignos às especi�cações do cliente. Outra característica importante é que os testes
cobrem o sistema como um todo, uma vez que são feitos antes de o sistema estar pronto, permitindo que o
programador analise diversas possibilidades antes de escrever o código, criando um software totalmente
testado. Outras características do desenvolvimento do TDD são o maior controle frente a mudanças, já que os
Aula 3
ESTUDANDO MAIS PROFUNDAMENTE O TDD
Nessa aula, você conhecerá mais profundamente essa metodologia que coloca o teste como prioridade
na busca pela redução das falhas.
26 minutos
https://integrada.minhabiblioteca.com.br/reader/books/9786555206340/pageid/0
testes automatizados previnem os possíveis bugs com possíveis modi�cações no código, e maior
con�abilidade no resultado do projeto, por entregar um produto altamente testado (BECK, 2003; ANICHE,
2014).
Caro aluno, destacado o desenvolvimento do TDD, cabe ressaltar um aspecto importante em relação ao ciclo
do TDD e seu funcionamento, que é assunto do nosso próximo bloco: testar, falhar, aperfeiçoar o programa e
refatorar. Vamos lá? 
VIDEOAULA: DESENVOLVIMENTO GUIADO POR TDD
Caro aluno, nesse bloco, falaremos sobre o desenvolvimento guiado pelo TDD, entendendo seus principais
aspectos, métodos e vantagens. Aproveitaremos para destacar algumas preocupações com esse método,
como uma certa resistência cultural por parte dos desenvolvedores. Além disso, você também verá as
principais características e funcionalidades do TDD.
CICLO DO TDD – O QUE É O CICLO DO TDD, TESTAR, FALHAR, APERFEIÇOAR O PROGRAMA E
REFATORAR
Caro aluno, nesse bloco, veremos mais sobre o que é o ciclo do TDD, testar, falhar, aperfeiçoar o programa e
refatorar. A técnica do TDD se concentra em um ciclo curto de ações chamado de Red, Green, Refactor, ou
vermelho, verde, refatorar, em português. Tal ciclo deve ser seguido quando se inicia a programação do
projeto a partir do Desenvolvimento Orientado a Testes (TDD). O vermelho quer dizer que o teste deve ser
escrito de uma forma que falhe. A escrita se inicia por um teste que falhará, obviamente por não existir um
código escrito ainda. O verde vem após a escrita do código, que passa (é validado) ao ser testado; a
refatoração é a etapa que otimiza tanto o código quanto o teste, visando simpli�car e padronizar os processos
de escrita.
Você deve ter percebido que esse ciclo temcerta familiaridade com o de melhoria contínua, muito conhecido
na área da gestão da qualidade. E realmente existe tal semelhança, uma vez que o TDD busca melhorar
continuamente o desenvolvimento do projeto, evitando falhas e otimizando os códigos.
Nesse ciclo, é possível perceber que o TDD prioriza os testes automatizados, optando por deixar a codi�cação
para depois, e sempre refatorando quando for necessário, em busca da simplicidade e otimização. A Figura 1
exempli�ca o ciclo, o qual, apesar da simplicidade, possui uma lógica extremamente otimizada.
Figura 1 – Ciclo do TDD
Fonte: elaborada pelo autor.
Conforme destacado na Figura 1, o ciclo do TDD segue uma ordem em busca de um código limpo. Entretanto,
Beck (2003) salienta que muitos obstáculos podem impedir que o programador faça um código limpo ou
mesmo um código que funcione corretamente. Sendo assim, ele destaca duas regras, que são simples, mas
in�uenciam nesse aspecto. A primeira é escrever um código novo apenas quando um teste automatizado for
falho, e a segunda é sempre eliminar um código duplicado. Essas duas regras implicam a ordem estabelecida
na Figura 1: 
•  Vermelho: escrever um teste simples que falhe e que não complique o início. 
•  Verde: fazer o teste funcionar de forma rápida, entretanto escrevendo o su�ciente para que isso ocorra. 
•  Refatorar: excluir os códigos duplicados, criado apenas para fazer o teste funcionar. Esse ciclo ainda pode
ser desmembrado em subfases. 
Videoaula: Desenvolvimento guiado por TDD
Para visualizar o objeto, acesse seu material digital.
No vermelho: 
1.  Escreva o teste.
2.  Veja o teste falhar. 
No verde: 
1.  Escreva o código.
2.  Veja o teste passar. 
No refatore: 
1.  Refatore o código.
2.  Implemente o código.
Todas essas fases, obtidas através do desenvolvimento orientado por testes, possibilitarão a entrega de um
código limpo, otimizado e o mais próximo possível das especi�cações do produto. Dito isso, destacaremos um
pouco mais a fase de fatoração, que é o tema do próximo bloco. 
VIDEOAULA: CICLO DO TDD – O QUE É O CICLO DO TDD, TESTAR, FALHAR, APERFEIÇOAR O
PROGRAMA E REFATORAR
Caro aluno, nesse bloco, você entenderá mais sobre o ciclo do TDD: o vermelho, verde e refatore, que se
baseia na lógica de testar, falhar e aperfeiçoar o programa. Você verá as principais características desse teste
e os cuidados a serem tomados na sua aplicação.
A REFATORAÇÃO DO CÓDIGO DE PRODUÇÃO E O TDD
Caro aluno, no bloco passado, você entendeu o ciclo que rege o Desenvolvimento Orientado por Testes, suas
fases e funções. Nesse bloco, vamos nos atentar um pouco mais à fase �nal do ciclo vermelho, verde e
refatorar. Destacaremos as características e os procedimentos relacionados à fase de fatoração, além das
vantagens relacionadas a esse ciclo no TDD.
Antes de mergulhamos na fatoração, cabe destacar algumas vantagens relacionadas a esse ciclo (ANICHE,
2014):
1. O foco está no teste, e não na implementação. Quando o desenvolvimento começa a partir do teste, o
programador se concentra apenas na função da classe, o que o ajuda a entender melhor o contexto dos
cenários de teste.
2. O código já nasce testado. Se o programador realizar o ciclo de forma correta, a consequência será que
todo o código escrito terá, no mínimo, um código escrito que valide seu funcionamento.
3. Simplicidade. Às vezes, menos é mais. A constante busca por um código mais simples faz com que o
programador deixe de lado soluções desnecessárias, que estão presentes em diversos sistemas.
4. Melhor re�exão sobre o design de classe. Um dos grandes problemas dos modelos tradicionais, nos
quais os testes são escritos posteriormente, é a falta de sinergia ou o excesso de acoplamento, muito em
função da preocupação uni�cada na ideia de implementação, deixando de lado como a classe deve se
comportar com as outras. Quando se inicia pelo teste, organizam-se melhor os parâmetros, aumentando a
qualidade do design das classes.
Diante dessas vantagens, cabe ressaltar, em especial, uma das características que tem sua posição de
destaque no clico dessa metodologia: a fase de refatoração do código. Nela, o desenvolvedor tem a
preocupação de otimizar a escrita e o teste, deixando ambos o mais simples possível, excluindo a duplicação
de código e padronizando as características e os parâmetros estabelecidos.  A partir dessas ações
estabelecidas no refatoramento, o código �ca mais fácil de ser compreendido, mantido ou mudado, tendo
como resultado uma redução no acoplamento e a preparação para execução de futuras funcionalidades
(BECK, 2003).
Videoaula: Ciclo do TDD – O que é o ciclo do TDD, testar, falhar, aperfeiçoar o programa e refatorar
Para visualizar o objeto, acesse seu material digital.
Entretanto, é sempre bom ressaltar que, no refatoramento do código, é importante que o responsável pelo
desenvolvimento cheque se a refatoração causou alguma falha nas funcionalidades já existentes no sistema,
levando sempre em consideração os testes a partir de cada mudança realizada, para se ter certeza de que o
sistema não sofreu modi�cações de forma incorreta. Dessa maneira, o código evoluirá gradativamente. De
acordo com a interpretação do problema, ele se adaptará e se tornará mais robusto. Quando os cenários de
teste forem feitos em seu total, o processo se encerra. Quanto mais feedbacks o responsável pelo
desenvolvimento do projeto receber, maior será a qualidade do código, reduzindo os custos para consertar
possíveis defeitos (ANICHE, 2014; BECK, 2003).  
VIDEOAULA: A REFATORAÇÃO DO CÓDIGO DE PRODUÇÃO E O TDD
Caro aluno, nesse bloco, você verá a refatoração do código de produção e a sua função dentro do
Desenvolvimento Orientado por Testes e entenderá o que representa esse terceiro item no ciclo Vermelho,
Verde, Refatore. Essa etapa tem um lugar especial no ciclo e ajuda na manutenção e padronização do código.
ESTUDO DE CASO
Caro aluno, dentro das equipes ágeis focadas em desenvolvimento de softwares, é comum ver resultados
muito abaixo das expectativas dos clientes. Parte dos projetos entregues tem seu tempo gasto na busca por
soluções de falhas e bugs que surgiram no meio do processo produtivo, fazendo com que o produto não
alcance as especi�cações do cliente, perdendo tempo e dinheiro tentando solucionar problemas em códigos
complexos e, por vezes, desnecessários.
Você foi contratado para tentar mudar o panorama de uma equipe que está passando por esses problemas.
Quais as suas indicações para solucionar tal acontecimento? 
RESOLUÇÃO DO ESTUDO DE CASO
Caro aluno, o primeiro passo, em toda resolução de problema, é analisar o contexto. De acordo com o
problema, essa equipe usa códigos complexos e, por vezes, desnecessários. Nessa aula, você observou que
isso é justamente o contrário do que o método TDD prega, e foi justamente o motivo para o início de seu uso.
Use seus conhecimentos adquiridos em aula para propor o uso da metodologia TDD. Seja �rme em relação
aos benefícios e às possibilidades de soluções dos problemas através do uso do ciclo Vermelho, Verde,
Refatore. Existe certa resistência cultural ao uso do TDD, uma vez que ele inverte a lógica implementada por
grande parte dos programadores. Então, ataque essa questão deixando claro que essa modalidade reduzirá o
tempo gasto com falhas, simpli�cará o código e passará mais con�ança ao seu cliente. Dessa forma, você
poderá levar grandes resultados a essa equipe.
 Saiba mais
Como convite à leitura sobre o tema, deixo o link do artigo: Desenvolvimento orientado a testes em
sistemas web: https://unoesc.emnuvens.com.br/apeuv/article/view/15087/7445. Acesso em: 11 mar.
2022. 
Videoaula: A refatoração do código de produção e o TDD
Para visualizar o objeto, acesse seu material digital.
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
https://unoesc.emnuvens.com.br/apeuv/article/view/15087/7445
INTRODUÇÃO
Caro estudante, durante essa unidade, você aprendeu sobre as equipeságeis e a importância da comunicação
e dos testes dentro da programação de softwares. Entender o funcionamento das equipes ágeis te possibilitou
se adaptar às dinâmicas na programação de softwares e, ao aprender sobre o BDD e o TDD, você
compreendeu as principais técnicas utilizadas para ajustar dois grandes gargalos: a comunicação e os testes.
Nessa aula, veremos o que o futuro pode reservar para a qualidade e a automação de testes, as tendências,
as principais características, o tipo de pro�ssional e o campo de atuação. Falaremos também sobre a internet
das coisas e o futuro da automação. Vamos lá?
O FUTURO DA TESTAGEM E DA QUALIDADE NA PROGRAMAÇÃO DE SOFTWARES
Caro estudante, a área de programação de softwares tem crescido bastante nos últimos anos. Por mais que a
área da tecnologia se destoe um pouco das demais áreas, ela ainda segue uma premissa: funciona dentro de
um mercado competitivo, no qual existe concorrência, e a excelência é buscada a todo instante. É necessário
gerar lucro e, para isso, é preciso reduzir os custos, mantendo a qualidade. Qualidade é a palavra-chave dessa
disciplina, junto aos testes, os quais, por sua vez, buscam obter qualidade nos códigos. Nesse bloco, você
vislumbrará um pouco mais sobre o futuro da testagem e da qualidade dentro da área de programação de
softwares.
Falar de futuro em programação é um pouco diferente. Nessa área, nós vemos o futuro acontecer, por assim
dizer, a cada descoberta, a cada método e tecnologia. Mas, nesse bloco, vislumbraremos um futuro de duas
subáreas que são e serão importantes para o seu desenvolvimento pro�ssional. Para isso, daremos um foco
maior na atuação pro�ssional ligada à qualidade.
Dentro das equipes ágeis, existe um pro�ssional chamado QA, do inglês Quality Assurance, algo como
garantia de qualidade, na tradução literal. Como o próprio nome diz, esse pro�ssional é responsável por
manter a qualidade dentro do projeto de desenvolvimento de softwares. E quando se fala no futuro da
qualidade e automação de testes dentro da programação, é necessário destacar esse pro�ssional (RIOS;
MOREIRA, 2006).
Dentro de alguns anos, espera-se uma transformação intensa na forma de trabalho do QA, deixando de
executar uma função que faz parte das suas atribuições atuais, que é a execução de testes, a qual,
geralmente, acontece no �m do projeto (exceto com uso do TDD, como você viu na aula sobre o assunto), e
comece a inferir seu conhecimento como ator principal na mudança de cultura. Passar a atuar como um
agente que incita a transformação, moldando equipes ágeis a respeito de testes e de qualidade. Sob a aba
desse pro�ssional, a qualidade deixará de ser um quesito centralizado, passando a ser uma responsabilidade
coletiva, compartilhada (ABREU; DEUS, 2021).
Abreu e Deus (2021) ainda completam que a qualidade de software adquiriu posição de destaque nos últimos
tempos, devido, em grande parte, à aceleração da digitalização das empresas, que foi estimulada pela
modi�cação brusca no per�l de consumo causada pela pandemia do novo coronavírus. Diante disso, essas
mudanças são projetadas para um futuro ainda mais próximo, que necessitará de pro�ssionais de teste e de
qualidade mais atentos ao todo, tomando posição de destaque nas equipes ágeis e no controle qualitativo dos
produtos.
Aula 4
O FUTURO DA TESTAGEM E DA QUALIDADE NA
PROGRAMAÇÃO DE SOFTWARES
Nessa aula, veremos o que o futuro pode reservar para a qualidade e a automação de testes, as
tendências, as principais características, o tipo de pro�ssional e o campo de atuação.
25 minutos
Neste bloco, tratamos de maneira geral da qualidade e da importância do pro�ssional ligado à qualidade
dentro do mercado, além das possibilidades e dos modos de trabalho esperados no futuro. No próximo bloco,
nos atentaremos às tendências em relação ao futuro das testagens.
VIDEOAULA: O FUTURO DA TESTAGEM E DA QUALIDADE NA PROGRAMAÇÃO DE SOFTWARES
Caro estudante, nesse vídeo, será abordado o futuro da qualidade e da testagem dentro da programação de
softwares. Falaremos sobre as expectativas e sobre os Quality Assurance, pro�ssionais que trabalham na área
da qualidade dentro das equipes de programação de softwares.
TENDÊNCIAS E REQUISITOS DO FUTURO DAS TESTAGENS
Caro estudante, no bloco anterior, você vislumbrou possibilidades na carreira de QA e as perspectivas do
futuro para a área da qualidade. Nesse bloco, daremos continuidade a essas expectativas diante da evolução
da área de programação.
É notável o crescente interesse, em especial de alguns desenvolvedores, no que diz respeito à qualidade de
software. O entendimento que tal área tem grande potencial já faz tempo. Barbosa et al. (2000) indicam que,
de modo particular, a indústria tem se conscientizado da importância da atividade de teste, que pode ser
contributiva para o aprimoramento qualitativo de determinado produto, enquanto também pode representar
um custo considerável dentro dos orçamentos nas organizações. Qualidade e custo são características
corriqueiras no mercado competitivo. Quando se quer entregar o máximo de qualidade, pretende-se reduzir o
custo ao máximo e, como você observou na aula “Entendendo mais profundamente o TDD”, testes podem
ocupar uma parte considerável dos custos.
Por isso, Barbosa et al. (2000) destacam que se torna imprescindível que, no processo das equipes ágeis
desenvolverem os softwares, sejam utilizados técnicas, métodos e ferramentas que viabilizem realizar as
testagens de forma padronizada, aumentando a produtividade e a qualidade, além de reduzir os custos. Uma
dessas técnicas você já conheceu, como citada anteriormente, o TDD, que viabiliza uma escrita simples,
priorizando a testagem e alcançando os objetivos competitivos dentro do mercado.
O teste de software in�uencia diretamente a qualidade do sistema e garante que esse sistema consiga de fato
atender às especi�cações propostas, conforme aquilo que o cliente solicitou. O futuro da testagem é sobre
pensar profundamente e explorar. Na medida que a so�sticação do software aumenta, as abordagens
tradicionais para os testes precisam acompanhar essa evolução. Em um ambiente dominado pela IoT (Internet
das Coisas), IA (Inteligência Arti�cial) e outras tantas evoluções, as abordagens precisam evoluir. Quando se
lida com sistemas que são mais inteligentes, fazer as testagens pode não ser uma ação tão simples. Algumas
vezes, as expectativas não são vislumbradas, e prever a reação dos sistemas se torna algo difícil. Para o futuro,
os testadores precisarão cada vez mais explorar e ser criativos ao criarem seus cenários para lidar com esses
sistemas mais robustos e suas reações. Com certeza, precisarão também de sensibilidade para lidar com
essas reações e o signi�cado delas para os clientes (JONES, 2017).    
Jones (2017) a�rma que a testagem de software já passou por mudanças drásticas devido às práticas ágeis. As
equipes ágeis atuam em uma velocidade formidável, com interação contínua, e isso fez surgir a necessidade
de novas habilidades. O autor ainda a�rma que os testadores foram obrigados a testar muito mais do que
antes e que estão disponibilizando informações cruciais e defendendo os projetos de seus clientes mais cedo
no ciclo de entrega.
Você pôde perceber que o futuro da testagem está atrelado ao avanço tecnológico do mundo onde vivemos e,
por isso, no próximo bloco, destacaremos uma dessas evoluções, a IoT, ou internet das coisas.   
VIDEOAULA: TENDÊNCIAS E REQUISITOS DO FUTURO DAS TESTAGENS
Caro estudante, nesse vídeo, trataremos das expectativas quanto ao futuro das testagens, os principais
desa�os e o que o mercado pro�ssional espera dos pro�ssionais da área. 
Videoaula: O futuro da testagem e da qualidade na programação de softwares
Para visualizar o objeto, acesse seu material digital.
Videoaula: Tendências e requisitos do futuro das testagens
Para visualizar o objeto, acesse seu material digital.
A INTERNET DAS COISAS (IOT) E O FUTURO DA AUTOMAÇÃO
Caro estudante,a qualidade e a testagem na programação de softwares andam lado a lado. Quando se pensa
no futuro da automação de testes e nas perspectivas para os testadores, é necessário entender que a
evolução dos softwares avança junto à execução da função de testar. Os métodos e as técnicas tradicionais
precisam lidar com um mundo onde já se faz realizada a Inteligência Arti�cial, a Internet das Coisas e o
Machine Learning. Para entender um pouco mais desse novo mundo, o presente bloco esclarecerá um pouco
mais sobre a Internet das Coisas.
A Internet das Coisas, em suma, é um sistema de dispositivos de computação que estão inter-relacionados e
conseguem, através dessa inter-relação, transferir dados entre essa rede sem a necessidade de uma pessoa
interagir com o sistema. Para facilitar o entendimento, imagine o seguinte: um objetivo dentro da Internet das
Coisas pode ser um cachorro com uma coleira com geolocalização, ou um sistema de irrigação no plantio, ou
um carro com sensores para alertar a proximidade de outros automóveis, ou qualquer produto natural ou
arti�cial que por ventura tem a capacidade de receber um endereço de IP e, a partir disso, consegue realizar
transferências de dados dentro de uma rede. 
Essa tecnologia vem crescendo cada vez mais e, quando se aborda o futuro da automação, é necessário levar
essa tecnologia em conta. Esse tipo de automação consegue entender melhor as necessidades dos clientes,
trazendo dados que, ao serem convergidos em informações, ajudam nas tomadas de decisão das
organizações.
Faccioni Filho (2015) destaca que a IoT é um conceito que vai além do âmbito das tecnologias, pois, na
realidade, não deriva dela, e sim a utiliza para cumprir determinadas funcionalidades.  São diversas as
tecnologias que se associam ao conceito de IoT. As suas funcionalidades, ou melhor, as funcionalidades dos
objetos dentro da IoT já estão impostas pelo mercado competitivo, e as tecnologias associadas continuam em
desenvolvimento constante. Você perceberá que diversas empresas de tecnologia estão na corrida para criar
sua linha de produtos e dispositivos para IoT. Skarpness (2014) destaca que esses dispositivos farão parte de
sistemas inteligentes, conectando-se a um montante extraordinário de outros dispositivos e gerando soluções
e análises para valorizar os vínculos e o entendimento das perspectivas dos clientes.
Agora, trazendo um pouco para a perspectiva dos desenvolvedores e das equipes ágeis, é fato que, como
destacado pela Jones (2017), será necessário maior empenho e aprendizado para lidar com a diversidade de
tecnologias e possibilidades. No entanto, esse quesito também pode ser entendido como uma multiplicação
de novas soluções, como destacado por Faccioni Filho (2015), que cita as novas expressões, como smart
buildings, smart cities e todas as variações de uma “sociedade automatizada”. O autor ainda destaca que
essas soluções são apenas a superfície do futuro da automação, o qual está próximo, e as equipes ágeis
devem se ajustar a isso.
VIDEOAULA: PREJUÍZOS CAUSADOS POR INVASÕES HACKERS
Caro estudante, nesse vídeo, abordaremos o avanço tecnológico na área de desenvolvimento de software, em
especial, as características da Internet das Coisas (IoT), e trataremos do futuro da automação.
ESTUDO DE CASO
Estudante, o mercado competitivo está em constante evolução e, como você aprendeu nessa aula, a área de
qualidade e automação de testes também está. A evolução vem acompanhada dos desa�os, e lidar com eles é
o que lhe ajudará a ser um pro�ssional mais assertivo. 
Diante disso, apresentaremos um problema a ser solucionado: você foi contratado como QA de uma
renomada organização de software, a qual se encontra em um processo de transição, evoluindo seu portfólio
com a intenção de assumir projetos com as mais novas tecnologias. Você foi selecionado para ajudar a de�nir
as principais características para a área de testagem e qualidade. O que você pode oferecer de mais atual para
o planejamento da organização?  
RESOLUÇÃO DO ESTUDO DE CASO
Videoaula: Prejuízos causados por invasões hackers
Para visualizar o objeto, acesse seu material digital.
Caro estudante, é importante entender que não existe uma única resposta para esse problema. A primeira
coisa que se deve fazer é analisar a organização, quais suas prioridades e perspectivas. Depois disso, já que o
desejo da organização é ingressar em projetos mais atuais e se preparar para o futuro, use os conhecimentos
dessa aula para sugerir mudanças na organização, principalmente no que diz respeito à testagem e à
qualidade, tratando essa área como algo integral dentro dos projetos, do início ao �m, deixando de ser um
processo uni�cado e se tornando um processo de entendimento coletivo. A partir dessas indicações, será
possível montar equipes ágeis preparadas para lidar com os desa�os do futuro.
 Saiba mais
Como indicação, deixo para você o link de um vídeo da Engenharia Detalhada, que explica
detalhadamente o que é a internet das coisas: https://www.youtube.com/watch?v=2TXOZFmhGGo.
Acesso em: 11 mar. 2022. 
Resolução do Estudo de Caso
Para visualizar o objeto, acesse seu material digital.
Aula 1
ANICHE, M. Test-Driven Development: Teste e Design no Mundo Real com. NET. São Paulo, SP: Casa do
Código, 2014.
BECK, K. Test Driven Development: By Example. Boston/EUA: Addilson-Wesley Professional, 2002.
COHN, M. User stories applied: for agile software development. Boston: Addison-Wesley Professional, 2004.
NORTH, D. Introducing BDD. DAN NORTH & ASSOCIATES LTD, 2006. Disponível em:
http://dannorth.net/introducing-bdd/. Acesso em: 7 nov. 2021.
KOCH, R. L.; OLIVEIRA, L. R. Riscos na Utilização de Métodos Ágeis na Gestão de Projetos de Software. 2010. In:
CONVIBRA ADMINISTRAÇÃO – CONGRESSO VIRTUAL BRASILEIRO DE ADMINISTRAÇÃO, 12., 2010, [S. l.]. Anais
[...]. [S. l.], ENSP, 2010.
NORTH, D.  BDD is like TDD if. Dan North & Associates, 31 maio 2012. Disponível
em: https://dannorth.net/2012/05/31/bdd-is-like-tdd-if/. Acesso em: 14 mar 2022.
SOARES, Ismael. Desenvolvimento orientado por comportamento (BDD) — Um novo olhar sobre o TDD. Java
Magazinne, Rio de Janeiro, v. I, n. 91, 2011. Disponível em: https://www.devmedia.com.br/desenvolvimento-
orientado-por-comportamento-bdd/21127. Acesso em: 14 mar. 2022.
WILDT, D. et al. Extreme Programming: práticas para o dia a dia no desenvolvimento ágil de software. São
Paulo, SP: Casa do Código, 2015.
Aula 2
MARSHALL JUNIOR, E. B. M. I. et al. Gestão da qualidade e processos. Rio de Janeiro, RJ: FGV, 2015.
NORTH, D. Introducing BDD. Dan North & Associates LTD, 2006. Disponível em:
http://dannorth.net/introducing-bdd/. Acesso em: 7 nov. 2021.
SANCHEZ, I. Introdução ao desenvolvimento orientado a testes. Coding Dojo Floripa, 7 nov. 2006. Disponível
em: https://dojo�oripa.wordpress.com/2006/11/07/introducao-ao-desenvolvimento-orientado-a-testes/.
Acesso em: 14 mar. 2022.
REFERÊNCIAS
10 minutos
https://www.youtube.com/watch?v=2TXOZFmhGGo
https://dannorth.net/2012/05/31/bdd-is-like-tdd-if/
https://www.devmedia.com.br/desenvolvimento-orientado-por-comportamento-bdd/21127
https://www.devmedia.com.br/desenvolvimento-orientado-por-comportamento-bdd/21127
https://dojofloripa.wordpress.com/2006/11/07/introducao-ao-desenvolvimento-orientado-a-testes/
SMART, J. BDD in Action: Behavior-driven development for the whole software lifecycle. Nova Iorque: Simon
and Schuster, 2014.
Aula 3
ANICHE, M. Test-Driven Development: Teste e Design no Mundo Real com. NET. São Paulo, SOA: Casa do
Código, 2014.
BECK, K. Test-driven development: by example. Boston: Addison-Wesley Professional, 2003.
Aula 4
ABREU, B.; DEUS, J. QA do futuro: aliança entre olhar humano e automação. IT Forum, 2021. Disponível em:
https://cio.com.br/noticias/qa-do-futuro-alianca-entre-olhar-humano-e-automacao/ . Acesso em: 17 nov. 2021.
BARBOSA, E. F. et al. Introdução ao teste de software. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE
SOFTWARE, 14., 2000, João Pessoa. Anais[...]. João Pessoa, PB: SBES, 2000.
FACCIONI FILHO, Mauro. BMS 2.0 - Nova geração de sistemas de automação e gestão predial. Congresso
Netcom, São Paulo, Aranda Eventos, 2015.
JONES, A. O futuro dos testes de software. São Paulo: Angie Jones, 2017. Disponível em:
https://angiejones.tech/the-future-of-software-testing/ . Acesso em: 17 nov. 2021.
RIOS, E.; MOREIRA, T. Teste de software. Rio de Janeiro, RJ: Alta Books, 2006.
SKARPNESS, M. Preparing the Data Center for the Internet of Things. Intel Software and Services Group,
2014.
https://cio.com.br/noticias/qa-do-futuro-alianca-entre-olhar-humano-e-automacao/
https://angiejones.tech/the-future-of-software-testing/