Imprimir

TÉCNICAS DE TESTES
 Aula 1 - Técnicas de testes

 Aula 2 - Técnicas de testes I

 Aula 3 - Técnicas de testes II

 Aula 4 - Testes em metodologias ágeis

 Aula 5 - Revisão da unidade

 Referências

Aula 1

TÉCNICAS DE TESTES
Aqui exploraremos os fundamentos das técnicas de teste de software, além de conceituarmos o teste de
unidade e os testes de caixa preta e testes de caixa branca.

INTRODUÇÃO

Olá, estudante! Muito seja muito bem-vindo a esta aula sobre testes de software! Aqui exploraremos os
fundamentos das técnicas de teste de software, além de conceituarmos o teste de unidade e os testes de
caixa preta e testes de caixa branca. Começaremos nossa jornada pelo mundo dos testes de software,
estabelecendo os fundamentos essenciais que são a base de qualquer estratégia de teste. Em seguida,
mergulharemos nos testes de unidade, uma prática fundamental para identificar e corrigir erros no nível mais
granular do código-fonte. Posteriormente, exploraremos os testes de caixa preta e branca, abordando como
essas técnicas se diferenciam e quando são mais apropriadas.

Ao final desta aula, você estará equipado com um entendimento dessas técnicas e será capaz de aplicá-las de
em seus projetos de desenvolvimento de software. Portanto, prepare-se para adquirir conhecimento valioso
que o tornará um testador de software mais competente e confiável.

Então prepare-se para embarcar nessa jornada e conhecer as técnicas de testes utilizadas atualmente. Bons
estudos!
CONHECENDO O MUNDO DOS TESTES

Para iniciar sua jornada, é crucial compreender os fundamentos das técnicas de teste de software. O teste de
software é um elemento de algo maior: Verificação e Validação, também conhecido como V&V. Esse processo
crítico visa identificar defeitos, erros e problemas em um sistema de software, por meio da criação de casos
de testes e dos resultados esperados.

Os testes podem ser classificados em diferentes tipos, como testes de unidade, testes de integração, testes de
sistema e testes de aceitação, entre outros. Cada tipo de teste tem um foco específico e é aplicado em
momentos distintos do processo de desenvolvimento. Pressman & Maxim (2021) apresentam a Figura 1,
exemplificando e relacionando o processo de desenvolvimento de software com diferentes camadas de
testes, utilizando um modelo em espiral. Em cada etapa do processo de software, uma ou mais técnicas de
testes podem ser utilizadas para verificação e/ou validação. Para melhorar a qualidade do software,
recomenda-se aplicar mais de uma técnica de teste em cada camada do processo.

Nesta aula iremos focar em duas dessas técnicas: os testes de unidade e os testes de caixa preta e caixa
branca. Os outros níveis de testes serão abordados em aulas subsequentes.

Figura 1 | Espiral de testes

Fonte: Presman e Maxim (2021, p. 375).

Os testes de unidade, também conhecidos como testes unitários é uma técnica de testes focada em verificar
as menores partes do código, como funções, métodos ou classes, de forma isolada. O princípio-chave é isolar
uma unidade de código e testá-la independentemente de outras partes do sistema (Pezzè; Young, 2008).

Essa técnica é aplicada durante a fase de codificação ou implementação do projeto e usualmente é feita pelos
próprios desenvolvedores, mas também pode ser codificada pelos membros da equipe de qualidade. Caso
seja encontrado algum erro, o desenvolvedor pode corrigi-lo antes mesmo que o código seja integrado ao
sistema como um todo. Isso contribui para a promoção da manutenção do código e sua confiabilidade, visto
que, caso uma unidade (função) do código seja alterada, o teste garante que ela continue funcionando como
deveria. Caso seu objetivo tenha sido alterado intencionalmente, o teste unitário também deve ser adaptado.

Os testes de caixa preta estão focados na funcionalidade externa do software, sem a necessidade de conhecer
a estrutura interna do código. Os testadores avaliam o comportamento do software com base nos requisitos e
nas entradas específicas.

Por outro lado, os testes de caixa branca examinam o código-fonte interno do software. Os testadores e/ou
desenvolvedores projetam casos de teste com base na estrutura do código e na lógica subjacente. Isso ajuda a
identificar possíveis erros de programação e garante que todas as partes do código sejam testadas
minuciosamente.

Ambos os tipos de testes são executados manualmente em cima de uma versão executável do software, não
sendo obrigatório que ele esteja 100% concluído, mas que tenham alguns fluxos já criados, como o log in em
uma plataforma.

Em conclusão, a compreensão dos fundamentos das técnicas de teste de software, integradas ao processo
mais amplo de Verificação e Validação (V&V), é essencial para garantir a qualidade e confiabilidade dos
sistemas de software. Lembre-se que a diversidade de tipos e níveis de testes, como os testes de unidade,
caixa preta e caixa branca, desempenham papéis cruciais em diferentes estágios do desenvolvimento.
COMPREENDENDO MELHOR OS TERMOS

Os testes de software fazem parte do conceito V&V. De acordo com Pressman & Maxim (2021, p. 373) esses
conceitos podem ser definidos como: “Verificação refere-se ao conjunto de tarefas que garantem que o
software implemente corretamente uma função específica. Validação refere-se ao conjunto de tarefas que
asseguram que o software foi criado e pode ser rastreado segundo os requisitos do cliente”.

Outro ponto que deve ser compreendido e reforçado é a diferença entre erro, defeito e falha. O erro, ou
engano, pode ser descrito como uma interação humana que resulte em algo não desejado no sistema. O
defeito é uma inconsistência na implementação do programa. Já a falha é a realização do defeito ou vários
defeitos. É importante notar que se algo estiver implementado incorretamente, mas nunca for utilizado,
nunca resultará em uma falha (Gonçalvez et al., 2019).

Figura 2 | Relação erro, defeito e falha

Fonte: elaborada pelo autor.

Outra coisa que você deve compreender são os casos de testes. Na maioria das técnicas de testes, são
planejados cenários ou casos que serão testados, tentando cobrir todos os fluxos possíveis do sistema,
incluindo casos em que esperamos que o sistema retorne um erro.

Para que os testes sejam criados corretamente, deve-se primeiro analisar a função, identificando quais dados
ela aceita como entrada e quais são as possíveis saídas. A partir disso, os casos de testes e os resultados
esperados podem ser elaborados.

Tomando como exemplo o cenário da calculadora, e que uma de suas funções no código é responsável
apenas por somar dois números, um caso de teste para essa função seria: ao receber dois números inteiros e
positivos, a função deve retornar um número inteiro equivalente à soma. Outro caso de teste seria quando a
função recebe um número inteiro positivo e um número inteiro negativo, resultando em diferentes
possibilidades: o retorno pode ser um número negativo, um número positivo, ou zero.

Usualmente, os testes unitários são configurados para serem executados automaticamente em determinados
momentos, como no final do processo de compilação.
O método da caixa preta é valioso para verificar se o software atende aos requisitos especificados, ou seja, se
o programa está fazendo o que foi solicitado pelo cliente, sem necessariamente importar-se com a maneira
como é feito internamente, então pode-se dizer que o teste de caixa preta se foca nos requisitos funcionais
(Pressman & Maxim, 2021, p. 388). Retomando o exemplo da calculadora, se um dos requisitos do cliente é
que o programa some dois números, no teste de caixa preta, o foco está na verificação se, ao digitar os
números para a soma, o programa apresenta a resposta correta na tela.

Já nos testes de caixa branca, a ênfase está na estrutura do código. Essa abordagem é eficaz para identificar
falhas na implementação e garantir que todas as partes do código sejam testadas minuciosamente. Aqui, é
necessário criar casos de testes olhando o fluxo do código do programa, considerando quais são os dados de
entrada, por quais funções esses dados devem passar e como devem se comportar dependendo do seu tipo,
e qual é o retorno esperado (Gonçalvez et al., 2019, p. 38).

No exemplo da calculadora, o resultado correto na tela não é o suficiente para aceitar o sucesso do teste, pois
além de mostrar o resultado correto na tela, os números recebidos devem passar pelas funções corretas e
serem tratados da maneira como foi planejado, caso contrário o teste pode ser considerado como um teste
falho.

Em resumo, podemos então dizer que o defeito é a concretização da falha e o erro e a interação do usuário
com esse defeito, além disso para que os testes possam trazer os melhores resultados é necessário a
elaboração criteriosa dos casos de testes, lembre-se disso!

CRIANDO CASOS DE TESTES

No exemplo da calculadora, o V&V pode ser aplicada considerando a seguinte perspectiva: a verificação,
realizada antes e durante o desenvolvimento do código e dos testes, assegura que a calculadora faça
corretamente o que foi elencado nos requisitos. Já a validação certifica-se de que a calculadora atende às
reais necessidades dos usuários, ou seja, se o produto entregue para o cliente é de fato uma calculadora
funcional.

Considerando que o usuário cometeu um erro ao digitar os números 5,5 e 6,5 para realizar a soma e obteve
como resultado 11. Essa falha ocorreu porque, ao executar a função de soma, apresentada na Figura 4, o
código possui um defeito ao aceitar apenas números inteiros como entrada, desconsiderando os valores da
casa decimal e usando apenas a parte inteira para calcular a soma.

Atualmente, há diversas linguagens de programação no mercado com bibliotecas e frameworks para a criação
de testes unitários, como o Junit em JAVA, Pytest em Python, Nunit em C#, entre outros.

Cada uma dessas bibliotecas possui suas especificidades na hora de configurar e executar os testes. O código
abaixo mostra um exemplo de teste unitário para o cenário da função de soma da calculadora, utilizando o
Junit em JAVA.
 1 import static [Link];
2 import [Link];
3
4 public class CalculadoraTest {
5 @Test //Anotação que indica a função como um teste
6 public void testSoma() {
7 //Aqui é criada uma instância para meu Objeto da calculadora
8 Calculadora calc = new Calculadora();

9 //ASSERTEQUALS é uma função presente na biblioteca do JUnit que recebe dois

parâmetros,

10 //indicando para o JUnit se a comparação dos mesmos é verdadeira ou falsa.

11 //Nesse caso estamos passando o número 4 (resultado esperado)

12 //e o resultado da função somar (Resultado obtido)

13 //se ambos foram iguais, o teste foi aprovado.

14 assertEquals(4, [Link](2, 2));

15 }

16 }

Ao contrário de outros testes e até mesmo do teste de caixa branca, para os testes de caixa preta não é
necessário conhecimento em programação. Veja agora o caso de teste para a operação de soma da
calculadora.

Caso de teste 1: Dados de entrada 2 e 3. Resultado esperado: 5

Caso de teste 2: Dados de entrada −2 e 5. Resultado esperado: 3

Caso de teste 3: Dados de entrada 0 e 0. Resultado esperado: 0

Com os casos de testes criados, basta utilizar a calculadora desenvolvida, inserir os dados selecionados e
verificar se o resultado exibido é igual ao resultado esperado.

Passando para os testes de caixa branca, é necessário analisar o código da função e seus fluxos, como
mostrado no trecho de código logo a seguir:

1 public static Object adicao(int a, int b) {

2 if (a < 0) {
3 return "Erro: Números negativos não são suportados.";
4 } else if (b == 0) {
5 return "Erro: A segunda entrada não pode ser zero.";
6 } else {
7 int resultado = a + b;
8 return resultado;
9 }

10 }
11

Caso de teste para entradas válidas:

 Entrada: a=3,b=5

Saída esperada: 8

Caso de teste para número negativo:

Entrada: a=−2,b=4

Saída esperada: "Erro: Números negativos não são suportados."

Como o acesso ao código, é possível criar casos de testes detalhados para percorrer todas as linhas do código
dentro da função, incluindo os casos em que o fluxo de execução passa pelas condições de tratamento de
erros. Muitas vezes, esses fluxos não são dedutíveis apenas analisando o sistema como um usuário comum.

Finalizando, vimos alguns exemplos práticos da construção de casos de testes e a criação de testes unitários
com o auxílio do JUnit. Vimos também a diferença nos casos de testes para as técnicas de teste de caixa
branca e teste de caixa preta, e que para planejar e executar o teste de caixa preta não é necessário ter
conhecimento em programação.

E assim finalizamos esta aula! Eu espero que você tenha aproveitado e até a próxima!

VIDEO RESUMO

Olá, estudante!

Neste vídeo, você verá os fundamentos das técnicas de testes, mergulhando na essência dos testes unitários
para a validação de componentes individuais. Em seguida, desvendará os mistérios dos testes de caixa preta e
caixa branca, revelando como garantem a robustez do código. Uma jornada imperdível para desenvolvedores
em busca de aperfeiçoamento em testes!

 Saiba mais
Para aprofundar melhor o seu conhecimento sobre as técnicas de caixa preta e caixa branca, você pode
ler mais nos capítulos 19.4 e 19.5 do livro Engenharia de Software, de Pressman e Maxim.

Ficou curioso e quer saber mais sobre o JUnit? O site a seguir apresenta um exemplo mais completo
junto com um tutorial. O site está em inglês, mas não se preocupe que o tutorial em questão está todo
em português.
 Aula 2

TÉCNICAS DE TESTES I
Nesta aula iremos abordar três novas técnicas de testes, sendo a primeira a técnica de testes de
integração que se concentram na verificação da interação entre módulos ou as funções.

INTRODUÇÃO

Olá, estudante! Te desejo boas-vindas! Nesta aula iremos abordar três novas técnicas de testes, sendo a
primeira a técnica de testes de integração que se concentram na verificação da interação entre módulos ou as
funções. Em seguida, será apresentada a técnica de testes de aceitação, em que confirmamos se o software
atende às expectativas dos usuários. Por fim, será vista a técnica de testes de sistemas, que examinam o
sistema completo, avaliando seu desempenho, sua segurança e sua conformidade.

Esses testes desempenham papéis cruciais na verificação e validação de sistemas, garantindo não apenas a
funcionalidade individual de componentes, mas também a harmonia e eficácia da integração das partes do
sistema.

Prepare-se para aprofundar o seu conhecimento em testes de software essenciais para a construção de
software e para a qualidade e software.

EXPLORANDO AS CAMADAS DE TESTES NO DESENVOLVIMENTO DE SOFTWARE: DA INTEGRAÇÃO À

VALIDAÇÃO FINAL

Para assegurar a qualidade no desenvolvimento de software, uma variedade de técnicas de teste pode ser
empregada, abrangendo desde abordagens voltadas ao teste dos componentes mais elementares e simples
do sistema até a validação definitiva com a participação do cliente.

Dito isso, começaremos os estudos desta aula com uma pergunta: se, após executarmos os testes unitários,
todos os testes das unidades forem aprovados, por que duvidar que o sistema irá funcionar ao integrar as
unidades? Realmente podemos considerar que se as partes funcionam, o todo também funcionará, mas
apesar desse pensamento, para facilitar essa compreensão vamos fazer uma analogia, considere um carro,
uma coisa é testar individualmente se cada roda gira, outra é testar se as rodas viram para o lado correto ao
virarmos o volante. Agora vamos trazer para o contexto da computação, um exemplo de testes de integração
seria avaliar se a função da minha aplicação consegue consultar o banco de dados corretamente. Para termos
essa garantia utilizamos os testes de integração. Segundo Pressman & Maxim (2021):
 O teste de integração é uma técnica sistemática para construir a arquitetura de software,
ao mesmo tempo em que se realizam testes para descobrir erros associados às interfaces.
O objetivo é construir uma estrutura de programa determinada pelo projeto a partir de
componentes testados em unidade.

Após ter sido garantido que as unidades do sistema estejam funcionando de maneira integrada, pode-se dizer
que temos em mãos uma versão prévia do sistema, em que conseguimos ver rotinas funcionando por
completo. A partir disso você deve começar a pensar: está funcionando, mas será que era isso que o cliente
queria? Tendo essa ideia em mente, você pode utilizar outra técnica de testes para fazer essa validação, a
técnica de testes de aceitação.

A frase de Valente (2021, cap. 8) traz uma sumarização do que é essa técnica: “São testes realizados pelo
cliente, com dados do cliente. Os resultados desses testes irão determinar se o cliente está de acordo ou não
com a implementação realizada”. Sendo assim, essa técnica de testes foca mais em garantir que os requisitos
do sistema estão corretos, do que encontrar falhas.

Por fim, o último tópico que será abordado nesta aula será os testes de sistemas, que seria mais um nível de
teste do que uma técnica, visto que aqui dentro podem ser feitos diversos testes. Segundo Zanin & Morais
(2017), o teste de sistema é o tipo de testes mais comum nas empresas, constituindo-se como uma avaliação
completa do sistema em seu conjunto, verificando sua funcionalidade global, feito, usualmente, de maneira
manual.

Conforme orientação do conselho brasileiro de qualificações de software, o Brazilian Software Testing

Qualifications Board – BSTQB, os testes de sistemas vão além da funcionalidade, trazendo testes não
funcionais para validar características que vão além do funcionamento direto do sistema, tópicos como a
usabilidade, segurança, eficiência de performance, também são avaliados (BSTQB, 2023). Em resumo, os
testes de sistemas representam a avaliação final e abrangente do software, englobando tanto aspectos
funcionais quanto não funcionais.

Em conclusão, os testes de integração garantem uma arquitetura sólida, enquanto os de aceitação buscam a
conformidade com os requisitos do cliente. Já os testes de sistemas representam a avaliação completa,
abordando tanto aspectos funcionais quanto não funcionais.

SE APROFUNDANDO NAS CAMADAS DE TESTES

O teste de integração está a um nível acima dos testes de unidade, pois seu objetivo é focar nas diferentes
unidades do sistema e verificar se elas integram corretamente umas com as outras. Considere novamente o
exemplo da calculadora, você terá funções responsáveis pelas operações básicas, e um módulo responsáveis
por capturar e mostrar os dados da tela e enviar para as funções básicas.
O teste de unidade considera cada uma dessas funções individualmente, mas o teste de integração irá
analisar e desenhar o caso de teste considerando mais de uma função. Então você terá, por exemplo, um
teste que irá receber os dados do input, tratar eles conforme desejado, enviar para uma função de operação
matemática, tratar o resultado de retorno e mostrar na tela novamente. A Figura 1 traz esse comparativo
entre o teste de unidade e o teste de integração.

Figura 1 | Diferenciando teste unitário do teste da integração

Fonte: elaborada pelo autor.

Lembrando que o teste de integração pode ser feito integrando duas funções apenas, ou como no exemplo,
em mais de uma função, desde que elas possam ser consideradas um módulo.

Vimos que o teste de aceitação é feito com o cliente presente observando ou pelo próprio cliente, simulando,
com a maior precisão possível, o contexto real a qual o sistema irá rodar, em que o cliente irá validar os
requisitos do sistema e dar sua aprovação ou rejeição. Usualmente os testes de aceitação são executados ao
final do ciclo de desenvolvimento, podendo ser no final da sprint do Scrum ou na entrega do produto no
modelo cascata.

Suponha que um dos requisitos apresentados pelo cliente seja que a calculadora mantenha um histórico das
últimas cinco operações realizadas pelo usuário possa voltar para elas caso deseje, então o sistema deve
suprir esse requisito, caso contrário quando o cliente utilizar o sistema notará que esse requisito não foi
atendido, e solicitará alteração no sistema para implementar o que foi pedido originalmente, ou seja, um teste
de aceitação falhado.

Os testes de sistemas representam uma fase crucial no ciclo de vida do desenvolvimento de software, visando
avaliar a eficácia do sistema como uma entidade completa. Por focar em testar o sistema como um todo, a
equipe de qualidade executa testes funcionais, ou seja, testes focados na funcionalidade do sistema, feitos de
maneira manual ou automatizada, em que o testador, ou a ferramenta de automatização, pode utilizar o
sistema em sua totalidade, ou focar em uma tarefa específica implementada pela equipe de desenvolvimento,
buscando erros no sistema.

Além desses testes funcionais, a equipe de qualidade pode desenhar testes para verificar pontos não
funcionais, mas importantes para a qualidade e para o contexto que o sistema está inserido, como utilizar o
teste de carga, que será visto na próxima aula, para validar se o sistema web irá aguentar uma carga elevada
de visitas.

Lembre-se de que o teste de integração pode validar apenas duas funções ou, como exemplificado, de várias
funções agrupadas como módulos. Além disso os testes de aceitação são conduzidos em etapas finais de
desenvolvimento, permitindo que o cliente tenha uma visão mais completa do produto. Por fim, os testes de
sistemas avaliam além das funcionalidades a capacidade do sistema suportar diferentes cargas de dados,
evidenciando o compromisso com a qualidade em diferentes dimensões.

EXEMPLIFICANDO CASOS DE TESTES

Agora, começamos pelo teste de integração e usamos o exemplo conhecido da calculadora, mas vamos
adicionar mais uma camada, essa calculadora salva o histórico das operações do usuário em uma tabela no
banco de dados. Então agora temos três módulos: o módulo de E/S, o Módulo de operações e o módulo de
comunicação com o banco. Vamos descrever um caso de teste para o salvamento das operações no banco.

Caso de teste 1: Salvar corretamente a operação

Dados de entrada: 3+5*8.

Resultado esperado: A operação: 3+5*8 bem como seu resultado deve aparecer na tabela do banco.

Caso de teste 2: Carregar corretamente a operação

Dados de entrada: pedido de histórico do usuário

Resultado esperado: a lista com as operações deve ser carregada corretamente do banco, para uma
lista no código e retornar essa lista para a função de escrever na tela.

Quando estamos testando integrações de funções ou módulos que não possuem uma interface com o
usuário, esses casos de testes podem ser codificados em funções semelhantes as que foram apresentadas na
aula passada nos exemplos de testes unitários, caso contrário podem ser feitos manualmente.

Sua empresa estipulou que logo que os testes de integração forem aprovados, e tivermos uma prévia do
sistema, temos que submetê-lo para um teste de aceitação, dito isso sua equipe marcou um encontro com o
cliente. Durante o encontro você deixa o cliente interagir com o sistema, apresentando quais requisitos já
estão presentes na versão em questão.

No entanto, durante a reunião, o cliente encontra uma inconsistência, relacionada ao seguinte requisito: a
calculadora deve oferecer resultados precisos, evitando erros de arredondamento que possam comprometer
a precisão dos cálculos, deve-se considerar uma precisão de cinco casas decimais. Contudo, o sistema só
estava fazendo operações até duas casas decimais. Você volta da reunião com esse feedback do cliente e sua
equipe começa a corrigir o erro para em evento futuro possam fazer um novo teste de aceitação com o
cliente.

Durante o desenvolvimento da calculadora, toda vez que uma nova funcionalidade ou um requisito era
implementado, um protótipo era enviado para a equipe de qualidade que executava testes no sistema para
verificar suas funcionalidades, ou seja, testes funcionais, e a cada teste executado era criado um relatório com
as tarefas aprovadas, e as tarefas falhadas, detalhando o motivo da falha.

Além disso, a equipe de qualidade também aplica outro teste para validar questões não funcionais, então em
todos os protótipos recebidos a equipe aplica testes de usabilidade, para garantir que a calculadora se
mantenha amigável ao usuário e aos testes de performance, para garantir que não ocorram travamentos ou
lentidões na execução de cálculos.

Neste exemplo da calculadora, testamos a comunicação entre módulos, validamos requisitos com o cliente e
asseguramos precisão nos cálculos. A sinergia entre os testes de integração, aceitação e os funcionais e não
funcionais culmina em um produto robusto e confiável. Dessa maneira, finalizamos o conteúdo desta aula!
Bons estudos!

VÍDEO RESUMO

Olá, estudante! Neste vídeo apresentarei a você o teste que está a um nível acima do teste de unidade, o teste
de integração, que se destaca em avaliar a interação entre diferentes partes do sistema. Além disso, você
também verá que o teste de aceitação é uma etapa crucial no qual o cliente coloca o software à prova. E por
fim, o vasto mundo dos testes de sistemas, um nível que abrange a avaliação completa do software, indo além
das funcionalidades.

 Saiba mais
Quer se aprofundar mais sobre os novos testes vistos nesta aula e o seu papel dentro do ciclo de
software? O livro Testes de software e gerência de configuração, traz o capítulo Níveis de teste, que pode
te interessar. O livro pode ser acessado neste link:

Vai lá e dá uma conferida! Vale muito a pena!

Está gostando da área de testes e quer se aprofundar? Talvez até prestar a prova de certificação
internacional Certified Tester Fundation Level?

Aula 3

TÉCNICAS DE TESTES II
 Vamos explorar a fundo três técnicas vitais no universo dos testes de software.

INTRODUÇÃO

Olá, estudante! Seja bem-vindo a mais uma aula. Vamos explorar a fundo três técnicas vitais no universo dos
testes de software. O primeiro será teste de regressão que recebe este nome, pois seu objetivo é garantir que
as funcionalidades já implementadas e testadas se mantenham funcional enquanto o sistema cresce.

O segundo será o teste de carga, uma técnica essencial para avaliar a capacidade do software lidar com
demandas crescentes e identificar possíveis gargalos de desempenho e por fim, veremos o teste de
segurança, que tenta verificar se os mecanismos de proteção são robustos o suficiente para aguentar ataques.

Então prepare-se para aprofundar seus conhecimentos e consolidar habilidades essenciais no vasto campo
dos testes de software.

GARANTINDO A SOLIDEZ DO SOFTWARE: UMA JORNADA PELOS TESTES DE REGRESSÃO, CARGA E

SEGURANÇA

Durante o desenvolvimento de um software a equipe, conforme avançava, aplicava testes nas novas
funcionalidades do sistema, corrigindo os problemas encontrados o mais rápido possível para dar por
encerrada aquela etapa, no entanto, em um estágio avançado de desenvolvimento ao apresentar uma versão
beta ao cliente percebeu que diversas funcionalidades antigas não estavam mais funcionando, ou seja, o
sistema regrediu.

Isso ocorreu, pois testavam apenas as novas funcionalidades inseridas e esqueceram de testar se isso não
impactaria no funcionamento do que já existia no sistema. Para evitar esse problema a equipe pode utilizar a
técnica chamada de testes de regressão, exemplificado na Figura 1 e descrito por Gonçalvez et al. (2019)
como: “O teste de regressão é, via de regra, a realização de todos os testes novamente, como se fossem a sua
repetição.

Figura 1 | Ilustrando a regressão

Fonte: elaborada pelo autor.

A cada vez que o software sofre uma modificação, todas as suas partes são testadas novamente, a fim de
identificar problemas. Então, o teste de regressão é aplicado ainda na fase de desenvolvimento do projeto, e
por ser feito nessa fase ajuda a encontrar e corrigir problema antes que se propaguem.

O teste de carga tem por objetivo, assim como o nome diz, testar que o sistema suporta diferentes níveis de
cargas ou em condições específicas, como o número simultâneo esperado na aplicação. Muitas vezes os
autores trazem o teste de carga como uma especificação do teste de performance, destes, temos Gonçalvez et
al. (2019) que dividem o teste de performance em teste de carga, teste de estresse e teste de estabilidade.

Além disso, os autores definem o teste de carga como:

Verifica o software como um todo, em condições normais de uso, avaliando o tempo de

resposta das operações, quantas operações podem ser executadas em determinado
período de tempo, quantos usuários simultâneos gravando dados podem existir, entre
outros aspectos.
— (Gonçalvez et al., 2019, p. 181)

Resumindo, o teste de carga tem por objetivo principal identificar os limites e as capacidades do sistema,
identificando quais são os gargalos do sistema.

Outra técnica de muita importância dentro do processo de desenvolvimento de software são os chamados
"testes de segurança". Esse tipo de teste é frequentemente utilizado não apenas por ser necessário proteger e
garantir a segurança dos dados do usuário, mas também para garantir a segurança da própria empresa
contra eventuais ataques ao seu software por terceiros.

Segundo a cartilha versão 1.0 de 2016 de orientação para o certificado de Security tester da própria BSTQB, os
testes de segurança não podem garantir, com 100% de certeza, que um sistema fique a salvo, mas eles
ajudam a identificar riscos e avaliar a eficácia das defesas do sistema.

Vale ressaltar que os testes de segurança são vastos e podem ser aplicados de diferentes formas e em
diferentes locais do sistema, indo desde a verificação de segurança em processos simples como criptografia
de senhas dos usuários, até a execução automatizada de ataques de força bruta sobre vulnerabilidades
conhecidas no mercado.

Para finalizar, o percurso pelo desenvolvimento de software evidencia a relevância de abordagens de teste
abrangentes, e nestes, o teste de regressão destaca-se como uma salvaguarda preventiva, prevenindo que
alterações impactem negativamente em funcionalidades já validadas. Enquanto isso, o teste de carga emerge
como um indicador crítico de desempenho, revelando limites e gargalos. Já os testes de segurança trazem a
garantia da proteção dos dados da empresa e do cliente.
FORTALECENDO O CICLO DE DESENVOLVIMENTO: EXPLORANDO TESTES DE REGRESSÃO, CARGA E

SEGURANÇA

O teste de regressão é responsável por verificar se o sistema mantém seu comportamento correto, mesmo
que receba alterações durante o processo de desenvolvimento. No entanto, para que os testes de regressão
sejam bem-sucedidos, é necessária uma estratégia bem definida, pois se criarmos casos de testes de baixa
relevância, ou que focam em partes do sistema que não recebem atualização, será um gasto de tempo
indevido.

Tendo isso em vista, é necessário mapear o sistema e criar casos de testes para os diferentes fluxos, e a partir
disso podemos implementar uma bateria de testes automatizados que serão sempre executados da mesma
maneira para garantir a estabilidade do sistema.

No entanto, também é possível executar os testes de regressão de maneira manual, e neste caso fica inviável
cobrir todo o sistema, então para esses casos podemos assumir duas estratégias, sendo que a primeira foca
em aplicar o teste de regressão nos pontos mais críticos do sistema, elencados previamente. Já a segunda
estratégia foca em aplicar o teste focando nos fluxos que podem ter sido afetados pelas alterações mais
recentes. A escolha das estratégias deve ser tomada conforme a necessidade e disponibilidade do seu time,
mas lembre-se, quando mais cobrir menor a chance de deixar passar algo.

Voltando para o teste de carga, vimos que ele serve para identificar os limites e gargalos do sistema, como
ilustrado na Figura 2, então é por meio dele que iremos identificar qual parte do sistema apresenta um maior
risco para o desempenho geral, e a partir disso podemos focar com maior precisão os esforços para otimizar
uma sessão específica do sistema.

Figura 2 | Gargalo no processamento da carga do sistema

FaFonte: elaborada pelo autor.

A execução bem-sucedida do teste de carga começa com a definição correta dos cenários, visto que um
cenário mais desenhado pode resultar em testes com resultados errados, dando uma falsa impressão de que
o sistema irá aguentar uma carga, mas quando é liberado para o cliente, não é o que acontece.
Usualmente os testes de cargas são feitos de forma otimizada, ainda mais se o sistema for grande e suportar
uma carga elevada de dados, sendo assim são utilizadas ferramentas para auxílio, como o JMeter, que é uma
ferramenta em java para simular muitos usuários virtuais e monitorar o desempenho do sistema.

Ao elaborar os testes de segurança é necessário ter bem definido quais são os pontos que se deseja verificar a
segurança e quais são os ativos valiosos para a empresa e a classificação de sua confidencialidade, como a
empresa pode definir que uma documentação específica só pode ser acessada apenas por usuários que
detêm uma determinada autorização, sendo assim uma informação privada, então isso deve ser um dos
pontos a ser testado.

Além disso, deve-se levar em conta o tipo de sistema que temos em mãos, visto que um sistema web, que
possui uma API Rest no backend precisa se preocupar com a validade de permissões de acesso em cada
endpoint, para não deixar nenhuma rota liberada, questão essa que uma aplicação puramente desktop não
precisa considerar, no entanto, essa aplicação já precisa se preocupar com acesso de memória e injeção de
arquivos nas pastas de instalação.

Resumindo, os testes de regressão podem ser aplicados de maneira automatizada ou manual, aplicando duas
estratégias que focam apenas nos pontos críticos, ou então nas funcionalidades alteradas. No tocante ao teste
de carga, sua execução eficaz depende da definição precisa de cenários, destacando-se a importância de
ferramentas auxiliares para a simulação dos cenários. Quanto aos testes de segurança, se deve sempre
analisar o contexto a qual sua aplicação estará inserida para projetar o teste.

NOS BASTIDORES DA CALCULADORA: TESTANDO REGRESSÃO, CARGA E SEGURANÇA COM

PRECISÃO

Vamos agora trazer os conceitos já vistos sobre testes de regressão para um cenário, o nosso querido
exemplo da calculadora. Suponha que durante o processo de desenvolvimento a cada nova funcionalidade
inserida testes eram feitos.

Em um determinado momento, foi implementada uma nova rotina responsável por limpar todo o histórico
das operações do usuário, uma melhoria em relação à opção já existente, de apagar uma operação específica
do histórico. Nesse caso, um teste de regressão focado apenas na nova funcionalidade inserida, seria retestar
a rotina de apagar apenas uma operação do histórico, inserir novas operações no histórico e visualizar as
operações do histórico, e só se tudo isso estiver ok, o teste de regressão estaria aprovado.

Agora se quiséssemos assumir a estratégia de testarmos apenas pontos críticos e não os alterados, quais são
os pontos críticos da nossa calculadora que não podem parar de funcionar? Fazer as operações corretamente,
mesmo que o histórico tenha algum defeito, se as operações ainda funcionam podemos assumir, para esse
caso, que o teste de regressão foi aprovado.

Como já definimos em aulas anteriores, a nossa calculadora armazena o histórico de operações no usuário e
para isso o usuário precisa de logar no sistema. Considerando esse cenário podemos ter o seguinte teste de
carga aplicado:
 Objetivo do teste:
Avaliar a capacidade de resposta da calculadora com o log in simultâneo de diversos usuários,
incluindo consultas no histórico de operações.

Cenário:
Usuários Simultâneos: 100.

Taxa de transações: 10 transações por segundo.

Duração: 30 minutos.

Fluxo:
Os usuários devem se logar no sistema de maneira concorrente, e executar operações matemáticas
na calculadora de maneira ininterrupta por um período de 30 minutos, e ao fim de cada operação
devem verificar o histórico.

Métrica de avaliação:
Tempo de resposta dos resultados das operações e do retorno do histórico.

Utilização de recursos de máquina, como CPU, disco e memória.

Análise das taxas de erro, como falha no log in, atrasos ou falha no processo nos cálculos e no
retorno do histórico.

Após executar esse cenário de testes, deve-se analisar os relatórios gerados pela ferramenta, assumindo que
foi utilizado o JMeter, e verificar se os dados condizem com o resultado esperado, que deve ser previamente
estipulado pela sua equipe.

Tendo testado diversos cenários de cargas e garantido o funcionamento regressivo do nosso sistema, agora
vamos focar na segurança. Um bom exemplo de testes de segurança que podemos aplicar para a nossa
calculadora é a injeção de SQL, visto que esta possui um campo para digitação livre e acesso ao banco de
dados. A injeção de SQL ocorre ao inserir uma consulta em SQL para ver se o sistema possui algum
tratamento para esse tipo de input. Se retornar à consulta inserida, o sistema é falho.

Outro exemplo para o contexto da calculadora é o acesso ao histórico das operações, no qual o testador deve
tentar solicitar o histórico de operações de um usuário que não seja o dele, e se conseguir, é uma
vulnerabilidade de segurança que pode ser explorada para obter outros dados além das operações. Seria
possível ficar dando exemplo de testes de segurança por longas páginas, mas ficaremos por aqui, visto que,
como já mencionado, os testes de segurança variam muito em relação ao tipo de sistema e aos dados valiosos
que se deseja proteger.

No contexto da calculadora, foram abordados os testes de regressão, destacando a importância de

estratégias bem definidas para avaliar mudanças, exemplificamos casos de testes para a adição de uma nova
funcionalidade. Além disso, foi explorado um cenário de teste de carga, avaliando a capacidade de resposta da
calculadora com 100 usuários simultâneos realizando operações e consultando o histórico. Por fim, foram
introduzidas diferentes perspectiva de testes de segurança, concentrando-se em exemplos como a injeção de
SQL e o acesso indevido ao histórico de operações.
VIDEO RESUMO

Olá, estudante! Neste vídeo vou apresentar para você três testes presentes dentro dos testes de sistemas,
sendo eles o teste de regressão, que garantem a estabilidade do software ao longo do tempo, o teste de carga
que avalia a capacidade do sistema sob demandas crescentes e garantindo uma experiência do usuário
consistente e o teste de segurança, que assegura a robustez contra explorações maliciosas.

 Saiba mais
Para entender melhor como os testes abordados em aula se encaixam no processo de testes, recomendo
a leitura do capítulo de tipos de testes do livro Teste de software e gerência de configuração, disponível
na biblioteca virtual.

Quer conhecer um pouco mais sobre o JMeter e sua abrangência de uso? Esse artigo traz um exemplo de
um projeto utilizando a ferramenta, que você pode seguir para ver como funciona.

Aula 4

TESTES EM METODOLOGIAS ÁGEIS

Começaremos a abordar as Metodologias Ágeis e Automação, em que entenderemos como elas
proporcionam uma abordagem flexível e eficiente no ciclo de desenvolvimento.

INTRODUÇÃO

Olá, estudante, seja bem-vindo a mais uma envolvente aula sobre o mundo dos testes. Começaremos a
abordar as Metodologias Ágeis e Automação, em que entenderemos como elas proporcionam uma
abordagem flexível e eficiente no ciclo de desenvolvimento.

Em seguida compreenderemos os princípios e benefícios do Desenvolvimento Orientado a Testes (TDD),

Desenvolvimento Orientado a Funcionalidades (FDD) e Desenvolvimento Orientado ao Comportamento (BDD).
Essas abordagens moldam a maneira como desenvolvemos software, garantindo que os testes sejam uma
parte intrínseca do ciclo de vida do desenvolvimento.

Por fim exploraremos o Extreme Programming (XP), uma metodologia ágil focada em pequenas e médias
equipes para que elas possam colaborar de maneira eficaz, promovendo a simplicidade, a comunicação,
constantes e práticas que visam entregar software de alta qualidade. Complementando essa abordagem, a
inspeção foca na revisão sistemática do código-fonte, buscando identificar e corrigir possíveis problemas
antes que impactem o produto final.
Prepare-se para aprofundar seus conhecimentos e consolidar habilidades essenciais no vasto campo das
metodologias ágeis e práticas de desenvolvimento de software.

AGILIZANDO O DESENVOLVIMENTO DE SOFTWARE

Nos primórdios do desenvolvimento de software notou-se a necessidade da criação de processos

estruturados de desenvolvimento para organizar e melhorar o processo de construção de um software, visto
que muitas empresas atrasavam a entrega de seus contratos, como apontado por Valente (2021, cap. 2), que
apresenta um estudo feito pela empresa Standish Group, em que mostra que até 1994 mais de 55% dos
projetos de software atrasaram o planejamento inicial em 51% e chegando até em 200%.

Com o passar do tempo diversas metodologias foram surgindo como o modelo em cascata, modelo em V,
RUP, entre outros. No entanto, todos esses processos não são considerados adaptativos, coisa que no
processo de desenvolvimento atual é crucial, visto que requisitos mudam a todo o momento.

Até que um grupo se forma para criar uma nova filosofia e assim surgiu o Manifesto Ágil, um documento
contendo quatro valores e doze princípios para nortear as metodologias de desenvolvimento ágeis. Para
definir e sumarizar o que é um método ágil, podemos utilizar a descrição de Morais & Zanin (2017, p. 80):

Em métodos ágeis, coloca-se o cliente como centro de todo o processo e, desta forma, mudanças de
requisitos e negociações com o cliente são bem-vistas o tempo todo. Os métodos ágeis seguem a essência do
modelo iterativo e incremental, trabalhando com entregas contínuas e frequentes. Paralelo a isso, os métodos
ágeis acrescentam valores relacionados a tornar o espaço de trabalho colaborativo no sentido de que todo o
produto é responsabilidade de todos os membros do time.

Tendo conceituado o que é métodos ágeis, podemos conhecer os diversos métodos ágeis disponíveis,
começando com o Test driven development (TDD) ou desenvolvimento orientado a testes. Esse método tem
como diretriz efetuar primeiro o planejamento e a programação do teste e a partir disso programar as
funcionalidades do sistema, e assim garantindo que a funcionalidade será desenvolvida de forma correta
conforme o que foi planejado.

Figura 1 | TDD
 Fonte: elaborada pelo autor.

Outra metodologia é o Behavior Driven Development (BDD) ou desenvolvimento baseado em

comportamento, uma metodologia que visa estruturar o código do sistema a partir da descrição do
comportamento especificado pelo usuário nos requisitos (Morais e Zanin, 2017, p. 80).

Figura 2 | BDD

Fonte: elaborada pelo autor.

Já a metodologia Feature Driven Development (FDD) ou desenvolvimento baseado em funcionalidades,

fragmenta os projetos de gestão em feature, que podem ser consideradas funcionalidades que tem maior
relevância para o cliente no contexto do software, e essas fatures deverão receber mais atenção pela equipe
de desenvolvimento do que o restante das funcionalidades, sendo desenvolvidas em até duas semanas
(Maschietto et al., p. 136).

Além dessas metodologias temos outras metodologias e frameworks no mercado, alguns inclusive que fazem
uso de alguma dessas metodologias já citadas anteriormente, um exemplo é o framework XP (Extreme
Programming).

Esse framework descreve um conjunto de regras e práticas que são aplicadas em cima de quatro atividades
principais: Planejamento, Projeto, Codificação e Testes (Pressman e Maxim, 2021, p. 46). Essas atividades são
executadas em ciclos incrementais, ou seja, no fim de cada ciclo um protótipo do sistema em um estado de
desenvolvimento mais avançado que no ciclo anterior.

Concluindo, conceituamos o manifesto ágil que norteia o desenvolvimento ágil, que possui uma abordagem
centrada no cliente, promovendo mudanças contínuas nos requisitos e nas entregas iterativas. Vimos também
os métodos TDD, BDD e FDD, que oferecem diretrizes específicas para o desenvolvimento orientado a testes,
comportamento e funcionalidades. Por fim, vimos um o XP que possui quatro atividades executadas em ciclos
incrementais.
EXPLORANDO OS FUNDAMENTOS E MÉTODOS ÁGEIS: PADRÕES, CICLOS E PRÁTICAS NO

DESENVOLVIMENTO DE SOFTWARE

O manifesto ágil apresenta quatro valores que definem o desenvolvimento ágil, conforme a Figura 1. Podemos
ler cada linha como: Software em funcionamento mais que documentação abrangente. Interpretando assim:
Em uma metodologia ágil é mais importante focarmos a energia da equipe na entrega de um software
funcionando corretamente do que criar uma extensa documentação, mas a documentação ainda deve ser
criada, só não será o foco principal. Essa interpretação pode ser aplicada para os outros valores.

Figura 3 | Valores do manifesto ágil

Fonte: elaborada pelo autor.

Além disso os métodos ágeis têm por características criar ciclos curtos de desenvolvimento, sendo que no fim
de cada ciclo o sistema recebe um incremento de funcionalidade. A figura a seguir representa isso.

Figura 4 | Desenvolvimento usando um processo ágil

Fonte: Valente (2021, cap. 2).

Pressman e Maxim (2021) trazem a Figura 5 para exemplificar o funcionamento do TDD. Antes de ser criado o
primeiro código do sistema, os desenvolvedores planejam e implementam os testes, para então finalmente
implementar o código da funcionalidade, lembre-se de que nunca se deve codificar funcionalidades que não
tenham testes já implementados. Depois da funcionalidade estiver criada, o teste é aplicado, se ocorrer tudo
bem segue-se o processo, caso contrário volta e corrige a funcionalidade e assim por diante.
 Figura 5 | O fluxo de desenvolvimento guiado por teste

Fonte: Pressman e Maxim (2021, p. 598).

Já o BDD tem por objetivo melhorar a comunicação na equipe, e inclusive pode conter dentro de si o TDD. A
ideia do BDD é que assim que seja entendido o comportamento de uma funcionalidade, é feita uma reunião
entre os membros da equipe (Desenvolvedores, QA e outros membros), para que seja feito um entendimento
do que deve ser testado, o porquê de um teste falhar e onde iniciar os testes, sendo assim o BDD traz uma
melhoria na comunicação, uma visão melhorada do todo e uma documentação mais dinâmica.

Por fim o FDD, trabalha com o conceito de funcionalidades tendo dentro de si cinco processos:

Desenvolver um modelo geral: é feita uma análise geral dos requisitos e criado um modelo abrangente
do sistema.

Criação da lista de funcionalidades (Features): o modelo geral é destrinchado em uma lista de

funcionalidades.

Planejamento por funcionalidade: são planejadas as equipes responsáveis.

Modelagem por funcionalidade: é feita a modelagem a nível de diagramas e código, criando as classes,
métodos e atributos da funcionalidade.

Construção por funcionalidade: efetivamente é feito a codificação da funcionalidade, testes e no fim, o

lançamento.

Uma representação visual dessas etapas pode ser vista na Figura 6.

Figura 6 | O fluxo de desenvolvimento guiado por teste

Fonte: elaborada pelo autor.

O framework XP, traz quatro atividades que são executadas em ciclos incrementais. A Figura 4 ilustra essas
atividades junto com seus conceitos-chaves. A atividade de planejamento começa com o “ouvir” o usuário,
resultando em “histórias” que descrevem o resultado e as funcionalidades pedidas pelo cliente. A partir disso
clientes e desenvolvedores trabalham juntos para decidir a prioridades das históricas para cada ciclo.

A atividade do projeto segue o princípio Keep it simple, stupid! (KISS), em resumo, não complique, foque em
fazer apenas o especificado, sem criar ou manter coisas que talvez sejam usadas no futuro. Além disso são
utilizados cartões CRC (classe-responsabilidade-colaborador), que ajudam a exemplificar o sistema no
contexto de orientação a objeto.

Figura 7 | Processo do XP

Fonte: Pressman e Maxim (2021, p. 46).

A atividade de codificação é onde as histórias são traduzidas para código efetivamente, mas antes disso são
criados os testes, pois um dos princípios da XP é utilizar a metodologia TDD. Além disso a programação em
pares é bastante incentivada na equipe.

Por fim a atividade dos testes consiste em aplicar os testes no sistema, inclusive o teste de aceitação com o
cliente, a qual irá avaliar se o sistema está de acordo com as histórias elencadas para aquele ciclo. Se estiver
tudo correto, uma versão é lançada, um ciclo é encerrado e outro é iniciado, seguindo assim até o fim do
projeto.

Nesse bloco vimos os pilares do manifesto ágil, explicando sua importância na priorização de valores no
desenvolvimento de software. Além disso, explora métodos ágeis como TDD, BDD, FDD e XP, destacando suas
abordagens e práticas. Os ciclos curtos e incrementais, a comunicação efetiva da equipe e o foco na entrega
de funcionalidades relevantes ao cliente são aspectos-chave dessas metodologias.
NOS BASTIDORES DA CALCULADORA: TESTANDO REGRESSÃO, CARGA E SEGURANÇA COM

PRECISÃO

Considere que a sua equipe foi contratada para desenvolver um sistema de umacalculadora web, sendo
necessário o desenvolvimento FrontEnd, BackEnd e banco de dados. Além disso, lembre-se de que os
princípios das metodologias ágeis são a utilização de ciclos de desenvolvimentos curtos, onde no início de
cada ciclo são planejadas as tarefas que serão executadas, mas sempre estando aberto a mudanças que o
cliente possa sugerir durante o processo. Independente da metodologia que sua equipe escolha para o
desenvolvimento, a primeira etapa sempre deve ser uma conversa com o cliente para entender suas
necessidades.

Caso você tenha optado por utilizar apenas o TDD no seu processo, o que deve ser feito? Primeiramente deve-
se identificar as funcionalidades ou os requisitos do sistema, que foram coletados durante a conversa com o
cliente, e então começar a codificar os testes, por exemplo a função de somar, no qual o teste pode ser visto a
seguir:

1 @Test
2 public void testSomar() {

3 Calculadora calculadora = new Calculadora ();

4 int resultado = [Link](2, 3);
5 assertEquals(5, resultado);
6 }

E depois que temos o teste pronto, cobrindo todas as possibilidades de entradas e saídas da função somar,
codamos efetivamente a função.

1
2 public int somar(int a, int b) {
3 return a + b;
4 }

Agora caso você opte por utilizar o BDD, você deve fazer inicialmente uma reunião com todos os membros da
equipe para que todos estejam na mesma página em relação ao que é o projeto. Após isso são criados os
cenários do projeto usando o padrão: Given, When, then, ou em português: dado, quando, então. Para ficar
mais fácil de entender olhe o exemplo a seguir sobre o cenário de soma:

Given a calculadora

When eu somo 3 e 3

Then o resultado deve ser 6

A partir desses cenários, criamos os testes da aplicação, os quais podemos utilizar bibliotecas especializadas
como o cucumber em JAVA para facilitar o trabalho, e só então começamos a implementar as funcionalidades.
Se você optou por utilizar o FDD, após a reunião com o cliente deve-se criar um modelo geral com as
funcionalidades da calculadora como todas as funções responsáveis pelas operações matemáticas, funções de
interação com o usuário, as funções de interação e gerenciamento do banco de dados.

Após, deve-se listar essas funcionalidades como tarefas de desenvolvimento e planejar sua execução, um
exemplo seria a função de soma que deve ser planejada e atribuída a um time que iniciará o desenvolvimento
da funcionalidade e logo após dos testes, para no fim apresentar ao cliente.

Por fim, caso sua equipe decida utilizar o XP, o planejamento se dará em ciclos curtos (até duas semanas), por
exemplo, sua equipe após conversar com o cliente decidiu que a primeira coisa que será implementada será a
interface FrontEnd, então nesse primeiro ciclo, é feito o planejamento, a divisão de tarefas e o implementação
dos testes, afinal o XP utiliza TDD, desenvolvimento da funcionalidade com ênfase na prática de programação
em pares, para no fim fazer o teste de aceitação do sistema até o momento, ou seja, da interface.

Ao encerrar o primeiro ciclo, inicia-se o planejamento do segundo, que nesse nosso exemplo será a
implementação das funções de operações matemáticas, no qual repetiremos os mesmos passos do ciclo
anterior, planejando, dividindo tarefas, implementando os testes, implementando as funcionalidades e
apresentando o cliente. Essas atividades se repetem até que todos os requisitos pedidos pelo cliente estejam
finalizados e a entrega do produto for feita.

Nesse texto vimos que existem diversos processos de metodologias ágeis disponíveis para o uso, e que cada
um possui suas especificidades de uso, a escolha de qual processo sua equipe vai utilizar irá depender das
necessidades da equipe e da adaptação ao processo, pois membros da equipe podem não se adaptar ao XP
por exemplo e se sentirem mais confortáveis em usar o SCRUM, outra metodologia ágil que não abordamos
nesta aula. Então análise as necessidades da sua equipe e escolha a metodologia mais próxima das
necessidades.

Bons estudos!

VIDEO RESUMO

Bem-vindos ao nosso vídeo sobre Metodologias Ágeis! Além de conhecermos o Manifesto Ágil, que originou
todo o movimento, exploraremos as diferenças entre os processos de TDD, FDD e BDD e como cada um pode
ser utilizado para aprimorar o desenvolvimento e garantir a qualidade. Você também irá descobrir como o XP
contribui para entregas rápidas e de qualidade. Então prepare-se e vamos mergulhar nesse universo de
práticas ágeis para impulsionar seus projetos!

 Saiba mais
Ficou curioso sobre o manifesto ágil? Leia ele na íntegra em:
[Link]
 Quer se aprofundar mais em Extreme programming (XP), conhecendo melhor seus princípios e valores?
O capítulo 2.3 do livro Engenharia de software moderna, de Valente, traz um bom detalhamento sobre o
tema.

Para criar esta aula, a leitura do livro: Processos de desenvolvimento de software, foi bem útil,
principalmente o capítulo: Test-driven development, na página 205. Se quiser saber mais sobre TDD,
recomendo a leitura. O livro está disponível na biblioteca virtual.

Aula 5

REVISÃO DA UNIDADE

TESTES DE SOFTWARE: A CHAVE PARA QUALIDADE

Olá, estudante! Vamos iniciar relembrando que as técnicas de testes de software são utilizadas para identificar
defeitos, erros e falhas, a fim de garantir a qualidade do software entregue ao cliente. Mas não fique achando
que basta abrir o sistema quando ele estiver pronto para tentar encontrar um Bug, existem diversas técnicas
de testes que devem ser aplicadas em diferentes etapas das processo de desenvolvimento do sistema.
Conforme pode ser visto na Figura 1.

Figura 1 | Espiral de testes

 Fonte: Presman e Maxim (2021, p. 375).

No primeiro nível está o teste de unidade que é construído ainda durante a fase de desenvolvimento, pois
foca-se na verificação isolada da menor unidade do sistema, a função. Ao desenhar esses testes podemos
seguir dois conceitos, caixa branca, na qual a pessoa que desenha o teste unitário conhece o código do
sistema e cria casos de testes para cobrir todas as linhas. Mas você também pode seguir com a ideia de caixa
preta, no qual quem escreve os casos de testes, não possui conhecimento do código, criando os casos
baseados apenas nos requisitos do sistema.

No nível acima dos testes unitários temos os testes de integração, tendo o seu propósito definido como:
encontrar problemas gerados a partir da integração dos diferentes componentes ou das unidades do
software (Gonçalvez et al., 2019).

Subindo mais nos níveis dos testes, temos o teste de validação, ou também chamados de teste de aceitação, o
qual valida os requisitos do cliente. Usualmente esse teste é aplicado na fase final do ciclo de
desenvolvimento, seja nos métodos ágeis, ou em métodos sequenciais. Nesses testes os usuários
selecionados, recebem a tarefa de simular todas as operações que o sistema deve executar de maneira
rotineira (Gonçalvez et al., 2019).

No último nível você encontrará o teste de sistema. Esses testes estão no último nível não por serem feitos
por último no processo, mas sim pois testarem questões mais elevadas no conceito do software. Esses testes
são os mais comuns utilizados nas empresas, segundo Morais e Zanin (2017), e testam questões funcionais
como os requisitos e as questões não funcionais, como desempenho, carga e segurança.
Aproveitando o gancho, dos testes de carga validam o sistema em situações normais de uso, avaliando atraso
no tempo de resposta e o número de operações suportadas (Gonçalvez et al., 2019). Resumindo, eles
identificam gargalos, vazamentos de memória e garantem a estabilidade em situações de demanda intensa.

Já o teste de segurança tenta verificar se as linhas de defesa implantadas no sistema vão protegê-lo contra
ataques (Presman e Maxim, 2021). Diferentes testes podem ser aplicados baseados no contexto de cada
sistema, por exemplo, softwares que não possuem controle de log in, não precisam se preocupar com testes
relacionados à quebra de senha por força bruta.

Os testes de regressão são aplicados após alterações no código para garantir que as modificações não afetem
negativamente as funcionalidades existentes. Essenciais para evitar retrocessos não intencionais.

As metodologias ágeis surgiram a partir do manifesto ágil que define valores e pilares para orientar os
processos em equipes ágeis. Alguns exemplos são o TDD que envolve a criação de testes antes do código,
garantindo que cada funcionalidade seja validada. O BDD que alinha desenvolvedores, testadores e partes
interessadas na criação de testes baseados no comportamento esperado do sistema. E por fim, o FDD que
fragmenta projetos em features, priorizando as funcionalidades mais relevantes. Além disso também
conceituamos o Extreme Programming (XP) uma metodologia ágil que enfatiza práticas como programação
em pares, desenvolvimento incremental e feedback contínuo.

Concluindo, a integração eficaz de diversas práticas de teste ao longo do ciclo de vida do desenvolvimento,
aliada a metodologias ágeis e à automação, é essencial para garantir a qualidade e a confiabilidade dos
softwares modernos. A partir desses entendimentos apresentados você já tem o conhecimento necessário
para aplicar esses conceitos no seu dia a dia como membro de uma equipe de qualidade.

REVISÃO DA UNIDADE

Olá, estudante! Neste vídeo iremos ver o universo dos testes de software! Abordarei testes, desde as menores
unidades, passando pelas integrações, encarando a aceitação do usuário e testando o sistema olhando para
questões funcionais e não funcionais. Além disso, apresentarei métodos ágeis como o TDD, FDD e BDD, bem
como práticas como XP. Explore neste vídeo os detalhes que moldam a qualidade do código e do sistema
como um todo. Aproveite.

ESTUDO DE CASO

Tendo visto várias técnicas de testes de software e métodos de desenvolvimento ágil vamos tentar aplicar
esses conceitos aprendidos nas aulas, contextualizando a sua aprendizagem colocando-o em um cenário
fictício. Imagine a seguinte situação, você foi recrutado para liderar uma equipe de qualidade em uma
empresa no ramo de investimento, sendo que seu principal produto é uma plataforma web voltada para
investimento de renda variável. Essa empresa já possui um tempo de mercado e por isso já possui sua cultura
já enraizada, ou seja, já possui processos definidos com os quais as equipes já estão familiarizadas e de certo
modo confortáveis. Com seu crescimento recente a gerência notou que era necessário a criação de uma
equipe de qualidade.

Após se enturmar com a equipe você recebe o brieafing sobre o que é esperado da sua equipe:

“A nossa empresa tem a cultura de produzir com velocidade e sempre lançar novidades para o cliente, nunca
passamos mais do que duas semanas sem lançar uma atualização com novidades, só que a satisfação do
cliente está baixa e a principal reclamação são os bugs ocorridos e a quantidade de vezes que precisamos
lanças versões com correções. Atualmente, para manter um mínimo de qualidade toda vez que um Dev
finaliza uma tarefa, ele cria um Merge request (ou Pull Request, dependendo de como você conhece) e o
código é avaliado por outros dois colegas necessitando as duas aprovações para ir para a master, mesmo
assim funcionalidades que já estavam funcionando param de funcionar com frequência. Além disso,
precisamos garantir que o desempenho do sistema esteja fluido sem travamentos. Então queremos que você
organize a equipe de qualidade para sanar esses problemas, mas não podemos utilizar um processo muito
rígido e que atrase o lançamento das versões no formato que já possuímos pois faz parte da nossa cultura.
Um último detalhe é que estamos com poucos desenvolvedores disponíveis no momento, então precisamos
que os novos processos de qualidade não consumam muito tempo deles”

Utilize o briefing passado para planejar qual metodologia e quais técnicas de testes devem ou podem ser
aplicadas nessa nova empresa que você agora é membro. Identifique os pontos-chaves nesse briefing e utilize
os conceitos das técnicas de testes e métodos ágeis para criar soluções de qualidade para essa empresa.

 Reflita
Este estudo de teste foi criado com base em uma ampla variedade de experiências empresariais reais, e
tem por objetivo fazer com que você consiga identificar as demandas esperadas de sua equipe de
qualidade resultantes de uma interação com as lideranças de sua empresa, em um cenário muito
comum no dia a dia da qualidade, a resistência dos processos pela gerência.

O briefing apresenta demandas do que a liderança necessita de você, algumas dessas demandas são
claras e objetivas, outras podem estar escondidas ou ainda nem são conhecidas.

No entanto, lembre-se de que é necessário analisar não apenas o pedido pelos donos da empresa, mas
também verificar se existem outras necessidades que você ache importante com sua expertise de
qualidade, bem como considerar as restrições impostas pela empresa, mesmo que o cenário ideal seria
ter um processo bem definido e aplicar mais de uma técnica de testes, muitas vezes a empresa não
consegue se acostumar e você deve se adaptar a isso, achando alternativas para garantir cada vez mais
níveis altos de qualidade de software.
RESOLUÇÃO DO ESTUDO DE CASO

Começaremos analisando o briefing apresentado para identificar as demandas e as restrições da empresa.

Logo na primeira frase temos o trecho: “produzir com velocidade” indicando que a empresa já utiliza ou está
aberta a utilizar conceitos ágeis. Na frase seguintes temos “duas semanas sem uma atualização com
novidades”, esse período descrito já passa uma indicação do intervalo dos ciclos de desenvolvimento e pode-
se utilizar isso para planejar um fluxo de testes ou aplicar uma metodologia já estabelecida como o XP.

Contudo, em contradição a isso temos a frase “mas não podemos utilizar um processo muito rígido”, então
aqui temos que cuidar para planejar algo que não traga tanta rigidez ao processo, então talvez utilizar todos
os processos do XP não seja a melhor ideia pois no processo de planejamento do ciclo temos a utilização de
cartões CRC e outras técnicas que demandam mais tempo, além disso, também é mencionado que a empresa
possui poucos devs, então utilizar programação em pares poderá atrapalhar a produção de código desejado
pela gerência, então optaremos por metodologias mais simplificadas como o TDD.

Tendo o TDD definido os testes unitários devem ser implementados antes das novas funcionalidades,
contudo, para as funções que já existiam, quando elas sofrerem atualizações os testes devem ser
implementados. Inclusive pela frase: “Dev finaliza uma tarefa ele cria um Merge request” podemos deduzir
que a empresa utiliza um controle de versionamento como o GitLab, assim pode-se criar uma rotina
automatizada dentro do Git para sempre que uma Merge request for submetido, os testes unitários serão
executados automaticamente.

Seguindo na avaliação, temos agora: “mesmo assim funcionalidades que já estavam funcionando param de
funcionar”, aqui podemos identificar a necessidade de teste de regressão. Lembrando, os testes de regressão
podem ser aplicados apenas em funcionalidades que possam ser afetadas pelas atualizações ou elencar
pontos críticos que nunca podem parar de funcionar. Para esse cenário você pode utilizar as duas estratégias,
mas de maneiras distintas. Elenque junto com os líderes quais são as principais funcionalidades que devem se
manter funcionando a qualquer custo e que devem sempre ser testadas. Pelo sistema ser uma aplicação web,
você pode facilmente automatizar esses testes, com auxílio do Cypress por exemplo, e executá-los para
validar essas funcionalidades, além disso faça testes manuais de regressão para as funcionalidades afetadas
pela atualização.

O último pedido no briefing pode ser visto nessa frase “precisamos garantir que o desempenho do sistema
esteja fluido”, ou seja, você precisa aplicar uma técnica de testes de desempenho como o teste de carga.

Agora você atendeu a todos os pedidos do briefing e conseguiu se adaptar à restrição, também pode
adicionar mais uma técnica que não estava na lista, os testes de sistemas, que serão feitos manualmente por
membros da equipe de qualidade em cima de cada tarefa listada para a atualização.

Assim terminamos o nosso estudo de caso, espero que tenha gostado da ideia e que ela tenha servido para
exemplificar melhor a aplicação das diversas técnicas vistas em aula em uma situação mais próxima da
realidade.
RESUMO VISUAL

Fonte: elaborada pelo autor.

Fonte: elaborada pelo autor.

 REFERÊNCIAS

Aula 1

GONÇALVEZ, P. F. et al. Testes de software e gerência de configuração. Porto Alegre: SAGAH, 2019.

PEZZÈ, M.; YOUNG, M. Teste e análise de software: processos, princípios e técnicas. Porto Alegre: Bookman,
2008.

PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software. Porto Alegre: AMGH, 2021.

Aula 2

BRAZILIAN SOFTWARE TESTING QUALIFICATIONS BOARD – BSTQB. Certified Tester Foundation Level Syllabus.
BSTQB, versão 4.0, 2023. Disponível em: [Link] . Acesso em:
Acesso em: 18 nov. 2023.

MORAIS, I. S.; ZANIN, A. Engenharia de software. Porto Alegre: SAGAH, 2017. Disponível em:
[Link] Acesso em: 18 nov. 2023.

Valente, M. T. Engenharia de software moderna. 2021 Disponível em:

[Link] Acessado em: 18 nov. 2023.

Aula 3

BRAZILIAN SOFTWARE TESTING QUALIFICATIONS BOARD – BSTQB. Certified Tester, Security Tester Syllabus.
BSTQB, versão 1.0, 2016. Disponível em: [Link] Acesso em: 2
dez. 2023.

GONÇALVEZ, P. F. et al. Testes de software e gerência de configuração. Porto Alegre: SAGAH, 2019.
Disponível em: [Link] Acesso em: 27 nov. 2023.

Aula 4

MORAIS, I. S.; ZANIN, A. Engenharia de software. Porto Alegre, SAGAH, 2017. Disponível em:
[Link] Acesso em: 3 dez. 2023.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre: AMGH, 2021.

 VALENTE, M. T. Engenharia de software moderna. 2021 Disponível em:
[Link] Acesso em: 3 dez. 2023.

Aula 5

GONÇALVEZ, P. F. et al. Testes de software e gerência de configuração. Porto Alegre: SAGAH, 2019.
Disponível em: [Link] Acesso em: 14 dez. 2023.

MORAIS, I. S.; ZANIN, A. Engenharia de software. Porto Alegre: SAGAH, 2017. Disponível em:
[Link] Acesso em: 14 dez. 2023.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre: AMGH, 2021.

Imagem de capa: Storyset e ShutterStock.