Conceitos de testes de software

O que são testes de software?

Os testes são processos que representam uma sequência de ações executadas com o objetivo de encontrar problemas no software, o que aumenta a percepção da qualidade geral dele e garante que o usuário final tenha um produto que atenda às suas necessidades (PINHEIRO, 2015). 

Fonte: Shutterstock.

Deseja ouvir este material?

Áudio disponível no material digital.

Convite ao estudo

Prezada aluna, caro aluno, iniciamos aqui mais uma unidade do nosso conteúdo de Engenharia de Software e aproveitamos a oportunidade para desejar, desde já, que você tenha um excelente aproveitamento dos temas que nela serão abordados.

Não é de hoje que a elevada qualidade de um produto, além de alguns outros fatores de natureza mais subjetiva, é o que conta para fazer dele um produto de sucesso em seu segmento. Um carro, um aparelho de televisão ou um telefone celular, por exemplo, tendem a seguir como produtos comercialmente viáveis se atenderem a certos requisitos de qualidade identificados com os seus propósitos e com o nicho a que se destinam. Naturalmente essa premissa também continuará sendo verdadeira se usarmos um software como exemplo e, nesse contexto específico, as providências para se garantir bons níveis de qualidade vêm sendo aprimoradas, especialmente aquela que é o tema central desta unidade: o teste de software.

Durante os três encontros desta unidade, teremos a oportunidade de conhecer detalhes sobre o processo de teste. Na primeira seção, trataremos do processo comum através do qual os testes são planejados, executados e têm seus resultados analisados. Nesse conjunto de informações, serão inseridos, também, conceitos de casos de testes e de depuração, além da abordagem de validação e de verificação, importantes providências de qualidade relacionadas aos testes. Já na segunda seção, os testes serão classificados e discutidos segundo uma tipificação própria, que leva em conta – entre outros fatores – o ambiente em que o software é executado e o paradigma de programação usado em sua construção. Esses tipos incluirão testes de funcionalidade, testes estruturais, voltados a aplicações móveis, e a aplicações orientadas a objetos.

Por fim, na última seção, nosso foco estará voltado aos testes automatizados e às ferramentas que viabilizam essa prática. Além disso, trataremos de aspectos de gerenciamento de testes e do desenvolvimento orientado a testes, que constitui um meio bastante ágil de se testar funcionalidades do sistema. Esperamos que seu aproveitamento nesta unidade seja pleno e que o conteúdo nela desenvolvido possa ser aproveitado para aumentar sua capacidade de aplicar testes com excelência e para torná-lo apto a compreender a real importância dessa prática em um projeto de software.

Bom estudo!

Praticar para aprender

Consideremos um sistema minuciosamente planejado, construído com base na metodologia mais moderna que existe e codificado por desenvolvedores experientes e de alto nível. Imagine agora que, diante desse cenário de excelência técnica – e da expectativa de já contar com um produto de alta qualidade –, o líder do projeto tenha deixado a realização dos testes a critério apenas dos desenvolvedores, sem se importar em definir um plano para sua elaboração. Bem, o que viria a seguir seria, provavelmente, um retumbante insucesso no projeto e a possibilidade de a equipe arcar com grande quantidade de retrabalho.

Para que uma situação como essa não faça parte da sua realidade profissional, esta seção se incumbirá de abordar elementos de planos de testes e, nesse contexto, discutirá o papel dos casos de testes e da depuração de código como ferramentas essenciais em seu cumprimento. Nossa jornada, no entanto, se inicia com a conceituação de validação, de verificação e de alguns aspectos elementares de teste de software, na condição de elemento constituinte do conjunto de providências a serem tomadas para a garantia da qualidade de um produto de software.

Uma empresa de desenvolvimento de software em que você trabalha vem aplicando testes com sucesso em seus produtos e tem obtido satisfatório nível de qualidade em suas entregas. No entanto, os gestores da empresa detectaram aumento na quantidade de manutenções corretivas em seus programas, motivado sobretudo por problemas de baixa complexidade no código e, teoricamente, de resolução simples. Os gestores imaginam que, atentos aos defeitos potencialmente mais danosos, os testadores não têm dado a devida relevância aos problemas simples.

Na busca por soluções para esses casos, os gestores colocaram a depuração do código como elemento fundamental em qualquer procedimento de teste e forneceram diretrizes para ampliar a aplicação desse recurso nos casos em que ele já era utilizado. Em uma de suas primeiras experiências na utilização sistemática da depuração, a equipe da qual você faz parte detectou a ocorrência de alguns defeitos no código que lhe foi confiado. Embora esses defeitos tenham se manifestado através da ferramenta, a equipe não sabia, de imediato, como localizá-las no código. A solução do caso passava, então, pela aplicação do processo de depuração, conforme designado pelos gestores. Em contato com o desenvolvedor, você tomou conhecimento que ele suspeitava de um certo trecho do código em que o problema poderia estar localizado. Expresso em pseudocódigo, esse trecho era o seguinte:

Utilizando,

início
 inteiro i, v, f=0;
 faça {
  escreva ("Informe um valor entre 1 e 10");
  leia (valor);
 enquanto (valor < 1 e valor > 10)

 para (i=1, i<=valor, i++) f=f*i;
 imprima f.
fim.

Para solucionar este caso, as atribuições dadas a você foram as seguintes:

• Transformar o pseudocódigo em um código-fonte, na linguagem de programação à sua escolha.
• Como as linguagens mais recentes colocam à disposição do desenvolvedor um ambiente integrado de desenvolvimento, você terá acesso ao modo de depuração oferecido por esse ambiente. Encontre-o e familiarize-se com ele.
• Submeta o código-fonte ao processo de depuração, incluindo as seguintes ações:
  1. Execução do código passo a passo.
  2. Inspeção de, ao menos, uma variável do programa.
• Ao final, descreva o(s) defeito(s) encontrado(s) no código por meio do uso do recurso da depuração.

Bom trabalho!

conceito-chave

Já vai longe o tempo em que um sistema computacional tinha sua execução restrita apenas a um computador de mesa e servia a propósitos típicos do meio corporativo, como controle de vendas e de estoques. Atualmente, há uma grande variedade de equipamentos que dependem de sistemas para executarem suas funções de modo muito mais flexível e confiável do que seria sem uma aplicação computacional. Exemplos não faltam e nossos carros e televisores são apenas dois deles. Há programas sendo executados em todos os lugares e controlando dispositivos indispensáveis em nosso cotidiano. Mas o que aconteceria se esses programas falhassem?

Para que essa pergunta não precise ser respondida da pior forma, a Engenharia de Software desenvolveu mecanismos para que os produtos de software – tantos os comuns quanto os que dão “inteligência” aos nossos equipamentos – criados pelos desenvolvedores passassem por processos que atestassem sua aptidão para executar suas funções de forma adequada e com elevados níveis de qualidade. Esses processos incluem a verificação, a validação e os testes de software e, se por meio de uma análise menos atenta eles podem parecer idênticos, uma conceituação apropriada servirá para esclarecer seus conceitos e diferenciá-los.

Gerenciamento da Qualidade do Software

No entanto, antes de individualizarmos esses termos, vale a pena posicioná-los em um contexto mais amplo, relacionado à qualidade de um produto, e conhecido por Gerenciamento da Qualidade do Software (ou Software Quality Management). Nesse contexto, a verificação e a validação são colocadas como ações intimamente relacionadas, destinadas à averiguação da conformidade do produto com as necessidades do cliente e comumente referenciadas em conjunto, sob a sigla V&V.

De acordo com uma importante publicação da área de Engenharia de Software (IEEE, 2014), o objetivo da V&V é ajudar a organização que desenvolve software a incorporar qualidade ao sistema durante o ciclo de vida, por meio de avaliações objetivas de produtos e de processos. Tais avaliações demonstram se os requisitos são corretos, completos, precisos, consistentes e testáveis. Os processos de V&V determinam se os produtos desenvolvidos em certa atividade estão em conformidade com os requisitos dela e se o produto satisfaz seu uso pretendido.

As atividades de V&V, portanto, não são aplicadas unicamente a um programa ou função, mas a qualquer artefato que seja criado como resultado de determinada etapa do ciclo de vida de um produto. Os requisitos, o projeto e a implementação do produto são artefatos que podem (e devem) passar por verificações e validações.

Nesse sentido, a IEEE (2014) estabelece que a verificação é uma tentativa de garantir a correta construção do produto, com vistas a atender as especificações impostas aos produtos de saída em atividades anteriores. Já a validação é uma tentativa de garantir que o produto certo seja construído, ou seja, que ele atenda a sua finalidade específica.

Schach (2009) relaciona os conceitos de verificação e de validação a momentos específicos do ciclo de vida de um produto de software. Nesses termos a verificação se refere ao processo de determinar se um fluxo de trabalho foi executado corretamente ou não, e ela ocorre ao final de cada fluxo de trabalho. Já a validação é o processo intensivo de avaliação que ocorre imediatamente antes de o produto ser entregue ao cliente; seu propósito é o determinar se o produto como um todo satisfaz ou não às suas especificações.

Embora sejam expressões parecidas e estejam inseridas em um contexto único, verificação e validação não são a mesma coisa. Santos e Oliveira (2017) resumem assim os termos: verificação refere-se à garantia das especificações do software em uma determinada fase do desenvolvimento, enquanto a validação se refere à garantia do produto de software como um todo. A validação é uma fase mais geral, na qual o produto criado é confrontado com as expectativas do cliente.

Observadas sob uma perspectiva teórica, expressões como “incorporar qualidade ao sistema” e “verificar se uma atividade está em conformidade com os requisitos” podem transmitir uma falsa sensação de simplicidade procedimental. Entretanto, a aplicação de procedimentos de verificação e validação requerem planejamento cuidadoso e precisão na execução. O objetivo do planejamento de V&V é garantir que cada recurso, função e responsabilidade sejam claramente atribuídos.

Nessa fase de planejamento, devem ser especificados os recursos, suas funções e atividades, bem como as técnicas e ferramentas a serem usadas. A compreensão dos diferentes propósitos de cada atividade de V&V ajuda no planejamento cuidadoso das técnicas e dos recursos necessários para cumprir seus propósitos. O planejamento também deve abordar a gestão, a comunicação, as políticas e os procedimentos das atividades de V&V.

Conforme mencionamos, a verificação e a validação estão incluídas em um escopo mais abrangente e estão vinculadas à Garantia da Qualidade do Software (Software Quality Assurance ou SQA). Na visão de Pressman e Maxim (2016), a verificação e a validação incluem grande variedade de atividades de SQA, quais sejam as revisões técnicas, auditorias de qualidade, monitoramento do desempenho, simulação, estudo de viabilidade, teste de usabilidade e testes de aceitação e de instalação. Os autores complementam que, embora a aplicação de teste tenha um papel extremamente importante em V&V, muitas outras atividades são necessárias.

À propósito, a menção aos testes vem a calhar. Como podemos posicioná-lo nesse contexto? O teste é a última frente de preservação da qualidade, mas não pode ser entendido como a garantia total de que a produção entregue pelas equipes está livre de defeitos. O teste proporciona o último elemento a partir do qual a qualidade pode ser estimada e, de forma mais pragmática, os defeitos podem ser encontrados. A qualidade é incorporada ao software por meio da correta aplicação das técnicas da Engenharia de Software e é confirmada durante o teste (PRESSMAN; MAXIM, 2016).

Testes de software

Um teste não é um procedimento isolado que pode ser concluído por um único membro da equipe. Embora seja comum tratá-lo por “teste”, sua execução depende de um conjunto de ações e procedimentos executados por vários elementos da equipe de desenvolvimento. Por isso, melhor seria chamá-lo de processo de teste, já que formalmente ele representa uma sequência de ações executadas com o objetivo de encontrar problemas no software, o que aumenta a percepção da qualidade geral dele e garante que o usuário final tenha um produto que atenda às suas necessidades (PINHEIRO, 2015).

É necessário, no entanto, destacar que o objetivo do teste não é o de garantir que um programa seja absolutamente livre de defeitos, mas o de encontrar problemas no software. Por mais que essa premissa nos soe estranha (e um pouco frustrante) ela deriva do fato de que nenhum teste é capaz de assegurar 100% de ausência de defeitos em um sistema. Logo, se o processo de teste não revelar defeitos, há que se aprimorar o processo de forma geral. Não se pode considerar que o sistema não possui problemas se o teste não os revelar.

Mas, afinal, o que é teste de software? Como ele se efetiva? Há um plano a ser executado?

É natural que uma definição retirada de uma publicação de caráter estritamente técnico peça uma explicação que a aproxime da percepção comum que temos a respeito de teste.

A expressão “verificação dinâmica” indica que aplicar um teste significa, necessariamente, executar o programa. Além disso, essa execução deve ser baseada em entradas previamente selecionadas. Conforme estudaremos em detalhes na sequência, casos de teste são entradas fornecidas ao programa e às respectivas saídas esperadas. Na teoria, as entradas possíveis para um programa são infinitas, daí a necessidade de restringi-las em um “conjunto finito de casos de teste” escolhidos criteriosamente.

Bem, mas como os testes são feitos? Há uma ferramenta computacional que os execute? Nas seções futuras desta unidade, teremos a oportunidade de abordar esses assuntos com mais riqueza de detalhes, mas convém termos agora uma rápida visão de um programa sendo testado. Para que isso seja possível, algumas premissas devem ser apresentadas:

• O programa em teste foi criado e está sendo executado no Eclipse, um importante ambiente integrado de desenvolvimento (ou IDE – Integrated Development Environment) utilizado principalmente para criação e para teste de aplicações Java.
• O tipo de teste em questão é o de unidade. Por meio dele, apenas uma unidade do programa (uma função ou uma classe, por exemplo) é testada e não o programa todo.
• A ferramenta utilizada para a efetivação do teste é o JUnit, que já se encontra instalada nativamente no Eclipse.

Na Figura 3.1, você vê uma classe – chamada CalculoTest –, que representa um caso de teste. Note que há variáveis com os valores 10 e 5 e uma terceira variável que contém o valor esperado para a execução da unidade que, no caso, realiza uma operação de soma.

A classe a ser testada para este caso de teste está descrita na Figura 3.2 e se chama Calculo.

A execução da classe CalculoTest através do JUnit retornará sucesso para o caso de teste em questão. Dessa forma, uma função pode ser testada por meio dessa ferramenta.

Plano de testes

Bem, como já compreendemos o conceito de teste, sua efetivação dependerá apenas da iniciativa do seu desenvolvedor em executar o programa com base em alguns casos de teste, não é mesmo? Responder “sim” a essa pergunta equivale a ignorar uma etapa absolutamente indispensável neste contexto: o planejamento.

Pressman e Maxim (2016) ensinam que teste é um conjunto de atividades que precisam ser planejadas com antecedência e executadas com base em um procedimento padrão, fato que motiva a criação de um modelo para o teste. Tal modelo, segundo os autores, deverá prever o emprego de técnicas específicas no projeto de casos de teste e no método de teste.

Uma definição que deve fazer parte do plano de testes é a de quem deve executá-los. Schach (2008) pondera que a realização dos testes equivale a um processo destrutivo e, como era de se esperar, um programador não desejará “destruir” seu próprio trabalho. Por isso, atribuir a atividade de teste ao mesmo time que desenvolveu o produto certamente não é uma boa ideia, já que é grande a chance de a equipe entender que deve proteger seu programa e não deve criar testes que possam revelar, de fato, problemas no código.

Outra razão para evitar a designação dos criadores do programa como seus testadores é o fato de que um terceiro poderá detectar uma falha no entendimento dos requisitos que passou despercebida ao programador e que foi implementada incorretamente. Um teste feito por outras pessoas pode aumentar a chance de descoberta do problema antes que ele tenha reflexos na operação do cliente.

Isto posto, é necessário mencionar que um plano de teste é normalmente separado em quatro grandes etapas:

• Planejamento: nesta etapa deve ser definido quem executa os testes, em que período, com quais recursos (ferramentas e computadores, por exemplo) e qual será a técnica utilizada (técnica estrutural ou técnica funcional, por exemplo).
• Projeto de casos de teste: aqui são definidos os casos de teste que serão utilizados no processo. No próximo item, esse conceito será detalhado.
• Execução do programa com os casos de teste: nesta etapa, o teste é efetivamente realizado.
• Análise dos resultados: aqui se verifica se os testes retornaram resultados satisfatórios.

A Figura 3.3 ilustra um modelo de plano de teste.

Bem, aparentemente os casos de teste são, de fato, o elemento central no processo de teste.

Casos de teste 

Um caso de teste é o par formado por uma entrada possível a ser dada no programa e a correspondente saída esperada, também dada pelo programa e de acordo com os requisitos previamente especificados. Nesse caso, devemos entender o conceito de entrada como o conjunto de dados necessários para uma execução do programa e o de saída esperada como o resultado daquela execução ou de função específica. Com um exemplo esses conceitos serão mais bem esclarecidos: imagine que você esteja testando um programa (ou função) que promove a validação de datas inseridas pelo usuário. Um caso de teste possível seria formado pelo par (31/12/2020; válida). Ao receber a entrada 31/12/2020, a função de validação deveria retornar “data válida”.

A boa escolha dos casos de teste é fator crítico para o sucesso da atividade. Um conjunto de casos de teste de baixa qualidade pode não exercitar partes críticas do programa e, em consequência disso, acabar não revelando defeitos no código. O que aconteceria, por exemplo, se o responsável pelos testes usasse apenas datas válidas como entradas? No mínimo, a parte do programa que trata das datas inválidas não seria executada, o que prejudicaria a confiabilidade do processo de teste e do produto testado.

Será, entretanto, que os casos de teste apresentam apenas esse aspecto? Observe o desenvolvimento de outro exemplo: imagine que o cenário de teste agora seja a checagem da funcionalidade de login em um sistema de reserva de passagens feito por agentes de viagens. A verificação a ser feita se apoia na resposta do sistema a diversos padrões de entrada de nome de usuário e de senha. Selecionamos três deles para fins de exemplificação:

1. Checagem da resposta do sistema no caso de o agente entrar com nome de usuário e senha válidos.
2. Checagem de resposta do sistema no caso de o agente entrar com nome de usuário e/ou senha inválidos.
3. Checagem de resposta do sistema no caso de o agente pressionar a tecla Enter com o campo de nome de usuário vazio.

Para que possamos tornar mais específico nosso cenário, trataremos apenas do primeiro item e, com base nele, apresentamos o Quadro 3.1, que descreve um caso de teste relacionado. 

Dessa forma, o caso de teste estará mais bem detalhado e as condições para que seja verificado estarão especificadas por completo. Note que até os passos para a realização do teste – que nos parecem tão óbvios – estão descritos nele. Fica claro que o sucesso no procedimento de testes está diretamente relacionado à boa escolha e ao bom uso dos casos de teste. Idealmente, cada conjunto de casos de teste deverá estar associado a um grande requisito diferente a ser testado. Para que não se corra o risco de defini-los incorretamente, é necessário planejamento e bom conhecimento da aplicação. Uma boa forma de se abordar o problema é a que segue, segundo Pinheiro (2015): definir o ambiente no qual o teste será realizado, definir a entrada desse caso de teste, definir a saída esperada para cada entrada e definir os passos a serem realizados para executar os testes.

Quando um caso de teste é executado, seu resultado deve ser coletado. Podemos assumir diferentes abordagens para definir o resultado da aplicação de um caso de teste específico. A mais comum define as seguintes opções (PINHEIRO, 2015):

• Passou: todos os passos do caso de teste foram executados com sucesso para todas as entradas.
• Falhou: nem todos os passos foram executados com sucesso para uma ou mais entradas.
• Bloqueado: o teste não pôde ser executado, pois o seu ambiente não pôde ser configurado.

Depuração

Enquanto testar significa executar o software para encontrar defeitos desconhecidos, a depuração (ou debug) é a atividade que consiste em buscar a localização desses defeitos no código. O fato de saber que há um problema causador de erro no programa não significa, necessariamente, que o testador sabe também em qual ou em quais linhas o problema está. Os ambientes de programação atuais oferecem recursos para depuração do programa e, durante esse processo, o valor assumido pelas variáveis sob inspeção em cada passo do algoritmo pode ser observado. Além disso, alguns pontos de parada da execução do programa podem ser inseridos no código. Tudo para possibilitar que o testador identifique e isole o defeito no código.

Na visão de Pressman e Maxim (2016), a depuração ocorre como consequência de um teste bem-sucedido, ou seja, quando um caso de teste descobre um defeito. Nesse caso, a depuração é o processo que encontra e remove o erro. Embora não seja um teste, ela ocorre como um desdobramento dele e começa com a execução de um caso de teste. O procedimento de depuração pode apresentar um entre dois resultados possíveis:

• A causa é encontrada e corrigida e a depuração daquele problema é bem-sucedida.
• A causa não é encontrada e, nesse caso, o profissional que está realizando o procedimento tenta outro caso de teste que lhe pareça mais adequado para aquela causa.

A Figura 3.4 ilustra um procedimento de depuração:

A figura anterior nos revela o passo a passo do processo de depuração:

1. A depuração começa com a execução de um caso de teste.
2. Os resultados são avaliados e o desempenho apurado é diferente do desempenho esperado para aquele caso de teste.
3. Quando as causas do defeito são plenamente identificadas, o problema é corrigido. Não havendo a perfeita correspondência entre o problema e a causa, procuram-se causas suspeitas.

Observe a natureza cíclica do procedimento e a colocação de “causas suspeitas” como um dos elementos do ciclo. Essa nomenclatura revela que, embora a depuração deva obedecer a um processo ordenado, ela depende bastante ainda da experiência e da sensibilidade do testador. Um engenheiro de software, ao avaliar os resultados do teste, pode perceber sintomas de um problema e não a sua manifestação inequívoca, o que usualmente indica que a manifestação externa do problema e a sua real causa interna podem não ter nenhuma relação aparente uma com a outra.

Nesse ponto, vale a pena observarmos um caso em que a depuração é necessária e, para esse fim, utilizaremos uma aplicação simples em Java e o ambiente integrado de desenvolvimento Eclipse. Originalmente a aplicação deve permitir a digitação de cinco números inteiros e, ao final, informar o maior número digitado. No entanto, o comportamento do programa não é o esperado e alguns recursos de depuração do ambiente de desenvolvimento devem ser usados para que os defeitos sejam encontrados. O Código 3.1 exibe o código-fonte da aplicação.

import java.util.Scanner;
public class Maior {
	public static void main (String args[]) {
		Scanner entrada = new Scanner(System.in);
	    int i, x=0, valor;
	    for (i=1;i<7;i++) {
	       System.out.printf("\nDigite o %d valor: ",i);
	       valor = entrada.nextInt();
	       if (valor < x) x = valor;
	     }
	     System.out.printf("\nO maior valor inserido eh: %d ",x);
	}
}

Há dois defeitos nesse código: o primeiro está situado na linha 6: ao invés de permitir a digitação de cinco números, a aplicação solicitará que seis números sejam digitados, dada a comparação feita com valor menor que 7 e não menor que 6. O segundo defeito está situado na linha 9, local em que o teste para apuração do maior valor a cada iteração está invertido. Assim, o valor que retornará a aplicação será o menor e não o maior, como se espera.

A utilização dos recursos de depuração do Eclipse começa com a mudança da perspectiva de visualização. Na opção de menu Window, acesse Perspective > Open Perspective > Debug, conforme ilustra a Figura 3.5. Essa providência fornece um padrão de dados adequado para a execução da depuração.

O primeiro passo efetivo do processo se dá com a marcação da linha do programa em que se deseja iniciar, de fato, a depuração. Essa ação é realizada por meio do posicionamento do cursor na linha desejada e o acesso à opção Run > Toggle Breakpoint. Uma marca na parte esquerda da linha será criada e, nesse momento, você estará apto a executar a aplicação no modo Debug, conforme mostra a Figura 3.6. Posicione o mouse sobre a classe (cujo nome deve aparecer no lado esquerdo da tela), acione o botão direito do mouse sobre ela e acesse a opção Debug As.

Neste momento a aplicação será executada no modo de depuração e os valores das variáveis poderão ser verificados passo a passo. Dessa forma, será mais fácil identificar as anomalias inseridas no código e corrigi-las.

Essa foi a base introdutória de testes que queríamos compartilhar com você. Há muito ainda a tratar sobre esse procedimento, mas é com a correta compreensão dos conceitos fundamentais que teremos sucesso na continuidade do nosso estudo. Iniciamos a seção tratando da conceituação de verificação e de validação e, na sequência, abordamos o conceito de testes. Depois o situamos como um procedimento e demos a ele uma sequência de etapas. Nesse mesmo contexto, tratamos do plano de testes e demos relevância ao papel do desenvolvedor no processo de teste de seu próprio produto. Por fim, abordamos os casos de teste e a depuração como elementos que darão subsídio à continuidade dos nossos estudos sobre teste.

Faça valer a pena

Referências

HOW to write a TEST CASE? Software Testing Tutorial. [S.l.: s.n.], 2014. 1 vídeo (3 min). Publicado pelo canal Guru99. Disponível em: https://bit.ly/3poU6ZV. Acesso em: 14 de dez. 2020.

IEEE Computer Society. Guide to the Software Engineering Body of Knowledge. Piscataway: The Institute of Electrical and Electronic Engineers, 2014.

MEDEIROS, M. P. JUnit Tutorial. DevMedia, [S.l.], 2009. Disponível em: https://bit.ly/3sY9ApL. Acesso em: 17 dez. 2020.

PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice Hall, 2004.

PINHEIRO, V. Um comparativo na execução de testes manuais e testes de aceitação automatizados em uma aplicação web. SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE (SBQS), 14., 2015, Manaus. Anais [...]. Manaus: Uninorte, 2015.

PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.

SANTOS, L. D. V., OLIVEIRA, C. V. S.; Introdução à Garantia de Qualidade de Software. Timburi: Cia do e-book, 2017.

SCHACH, S. R. Engenharia de Software: os paradigmas clássicos e orientados a objetos. 7. ed. São Paulo: McGraw-Hill, 2009.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2018. E-book. Disponível em: https://bit.ly/3a6T5PN. Acesso em: 6 dez. 2020.

WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsiever, 2013.