122910

Prévia do material em texto

Estratégias e planejamento de teste de
software
Você vai aprender a elaborar planos e casos de teste, conhecer estratégias de teste e desenvolvimento de
software, aplicar testes caixa branca e preta, além de utilizar TestLink, Cucumber, Selenium e a técnica
BDD.
Prof. Carlos Alberto de Farias
1. Itens iniciais
Propósito
O domínio de estratégias de teste e desenvolvimento de software é essencial para profissionais de TI
garantirem a qualidade dos sistemas. Esse conhecimento permite planejar, automatizar e validar
funcionalidades, assegurando que o produto final atenda aos requisitos dos usuários e aos padrões do
mercado.
Objetivos
Aplicar estratégias de teste de software, diferenciando os tipos de teste caixa branca e caixa preta em
contextos específicos de desenvolvimento.
 
Definir a elaboração e a realização de planos e casos de teste com o uso da ferramenta TestLink,
integrando UML e casos de uso no planejamento.
 
Desenvolver rotinas de teste automatizado com Cucumber e Selenium WebDriver, elaborando testes de
aceitação com base em requisitos e na técnica BDD.
Introdução
Sem estratégia, até mesmo as ações mais simples podem não alcançar os resultados esperados. Quando
falamos sobre o desenvolvimento de softwares, essa premissa é ainda mais evidente: sem planejamento e
uma boa estratégia de testes, um sistema pode apresentar falhas críticas, impactando diretamente a
experiência do usuário e a confiabilidade do produto.
 
Neste conteúdo, você será apresentado às principais estratégias de teste e desenvolvimento de software.
Vamos explorar como essas estratégias se integram ao ciclo de vida do desenvolvimento e como tomar
decisões acertadas sobre quando e onde aplicar cada uma delas. Um dos focos será a diferenciação entre os
testes caixa branca e caixa preta, compreendendo suas abordagens e aplicações práticas.
 
Você também aprenderá a importância da elaboração de planos e casos de teste bem estruturados para
garantir a qualidade do sistema. Para isso, conhecerá a ferramenta TestLink, que auxilia na documentação e
execução desses testes de maneira prática e organizada.
 
Além disso, abordaremos a utilização da UML e dos casos de uso como recursos valiosos para o planejamento
de testes mais eficazes. Avançando no conteúdo, exploraremos frameworks modernos como o Cucumber e a
automação com o Selenium WebDriver, aprendendo a desenvolver rotinas de teste mais eficientes e alinhadas
com as expectativas do usuário final.
 
Por fim, será apresentada a técnica BDD – Behavior Driven Development (Desenvolvimento Orientado por
Comportamento) – uma abordagem que aproxima as equipes técnicas e os stakeholders, promovendo maior
clareza nos requisitos e nos testes de aceitação. Prepare-se para aplicar esse conhecimento de forma prática
e estratégica no desenvolvimento de softwares mais seguros e funcionais.
• 
• 
• 
1. Estratégias do processo de Teste de Software
Estratégias de teste de software
O planejamento e a realização das atividades de teste definem a estratégia de testes de software.
Uma estratégia de teste de software:
 
Define, para cada etapa do processo de engenharia de software, técnicas de projeto de casos de teste
e métodos de teste específicos.
 
Integra, em uma série bem planejada de passos que resultam na construção bem-sucedida de
software, métodos de projeto de caso de teste.
 
Acomoda testes de baixo e de alto nível.
 
Oferece orientação ao profissional.
 
Oferece um conjunto de marcos de referência ao administrador.
 
Deve ser mensurável.
 
Integra métodos de projetos de casos de teste em uma série bem planejada de passos, objetivando a
construção bem-sucedida do software.
Atenção
Em um primeiro momento, você pode não entender, mas o software é testado para promover erros que
foram feitos inadvertidamente no momento em que foi construído. 
Leia o texto para conhecer quem faz a estratégia e a atividade de teste.
Estratégia e atividade de teste
Quem faz a estratégia e a atividade de teste?
Estratégia de teste de software: desenvolvida pelo gerente de projeto, o engenheiro de software ou o analista
de teste.
• 
• 
• 
• 
• 
• 
• 
 
Atividade de teste: a equipe de desenvolvimento do software e, para grandes projetos, um grupo de teste
independente.
Atenção
Atividades de teste e de depuração são atividades diferentes, mas a depuração deve acontecer em
qualquer estratégia de teste. 
Por que é importante?
O teste responde (e é responsável) por mais esforço que qualquer outra atividade de engenharia de software.
Caso seja feito ao acaso, teremos tempo e esforço desperdiçados.
Quais são os passos?
Vejamos por uma visão bem simplista: o teste começa no “varejo” e acaba no “atacado”. Mas o que seria isso?
 
O varejo são os testes unitários, e o atacado são os testes de integração, depuração na satisfação dos
requisitos do cliente.
 
As características genéricas de estratégias de teste são:
 
Teste efetivo – A equipe deve conduzir revisões técnicas formais (erros serão eliminados antes do
teste);
 
Início do teste – O teste começa no nível de componente e segue “para fora”, em direção à integração
de todo o sistema;
 
Atividade de teste - Inicia-se no nível de módulos e prossegue para fora, na direção da integração de
todo o sistema;
 
Diferentes técnicas de teste são apropriadas a diferentes pontos de tempo;
 
Fornecem roteiro - Descrevem os passos a serem conduzidos como parte do teste, como:
 
Quando os passos são planejados e executados?
 
Quanto de esforço, tempo e recursos são necessários?
• 
• 
• 
• 
• 
◦ 
◦ 
O que deve incorporar uma estratégia?
O planejamento de teste;
 
O projeto de casos de teste;
 
A execução e o teste;
 
A coleta e a avaliação de dados (resultado).
Atenção
A estratégia deve ser flexível, para promover um planejamento razoável e acompanhamento gerencial ao
projeto. 
Veja, a seguir, um exemplo de uma estratégia (workflow) para sistemas bancários multicanais.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Exemplo de estratégia.
• 
• 
• 
• 
Vejamos o que acontece nessa estratégia de teste: como não foi realizada por outros canais, ficou evidente
que não foram realizados testes multicanais, e nesse caso, todos os participantes (em separado) têm a
percepção de que os testes realizados pelo canal foram satisfatórios.
Algumas estratégias de teste
Teste de unidade
É caracterizado por concentrar-se em cada unidade do software, de acordo com o que é
implementado no código fonte.
Cada módulo é testado individualmente, garantindo que ele funcione adequadamente.
Utiliza as técnicas de teste de caixa branca.
Teste de integração
É caracterizado por concentrar-se no projeto e na construção da arquitetura de software.
Os módulos são montados ou integrados para formar um pacote de software.
Utiliza principalmente as técnicas de teste de caixa preta.
Teste de validação
Os requisitos estabelecidos como parte da análise de requisitos de software são validados em relação
ao software que foi construído.
Ao término da atividade de teste de integração, o software está completamente montado como um
pacote.
Os erros de interface foram descobertos e corrigidos, e uma série final de testes de software — os
testes de validação — pode iniciar-se.
Teste de sistema
Caracteriza-se por testar, como um todo, o software e outros elementos do sistema.
Envolve uma série de diferentes testes, cujo propósito primordial é pôr completamente à prova o
sistema baseado em computador.
Alinhamento estratégico
Como fazer para que a busca pela melhoria do desenvolvimento de software seja realmente efetiva?
Podemos alinhar a engenharia de software aos objetivos de negócio da empresa.
Atenção
As decisões e rumos tomados pelas áreas que utilizam a Engenharia de Software devem sempre estar
alinhados à estratégia da empresa, fazendo com que a área de desenvolvimento se torne uma
ferramenta para aumentar o valor do negócio da organização. 
Nesse caso,teste da caixa preta.
C Teste de integração e teste de unidade.
D Teste de regressão e teste fumaça.
E Teste de sistema e teste de integração.
A alternativa A está correta.
• 
• 
• 
• 
• 
Os testes de alto nível não requerem o conhecimento da estrutura interna do sistema. São eles: teste de
sistema e teste de aceitação. Portanto, a única opção correta é a opção A.
Questão 2
O termo automação de teste de software significa a utilização:
A De um software que imita a interação com a aplicação no que se refere ao teste tal qual um ser
humano faria.
B Do desenvolvimento de scripts de testes para simular a massa de teste a ser utilizada.
C De casos de testes automatizados que imitam a interação com a aplicação.
D De uma metodologia de teste para simular os sistema em produção.
E De um ambiente de teste, de ferramentas e de uma massa de teste.
A alternativa A está correta.
Com a automação de testes, pode-se alcançar uma execução muito confiável.
Questão 3
Para a implementação de um projeto de automatização de testes, precisamos de:
A Recurso, infraestrutura, ferramenta e metodologia.
B Ferramenta, equipe de teste, processo de teste e caso de teste.
C Scripts, software de teste, testador e um sistema para testar.
D Ferramenta, equipe de teste, sistema para testar e hardware.
E Hardware, software, script e os dados para teste.
A alternativa A está correta.
Esses são os itens básicos para a implementação de um projeto de automação de testes.
Questão 4
Nos testes de validação, os mecanismos de testes estão segmentados em dois níveis: testes de baixo nível e
de alto nível. Descreva quais os testes que são considerados de alto nível e quando são aplicados.
Chave de resposta
Teste de sistema: refere-se ao comportamento de todo o sistema/ produto definido pelo escopo de um
projeto ou programa de desenvolvimento.
Nesse tipo de teste, o ambiente de teste deve corresponder o máximo possível ao objetivo final, ou ao
ambiente de produção, para minimizar os riscos de falhas específicas de ambiente de serem encontradas
durante o teste.
Teste de aceite: é de responsabilidade do cliente. Ele irá validar todas as funcionalidades do sistema.
4. Conclusão
Considerações finais
Neste conteúdo, abordamos a importância das estratégias de teste no desenvolvimento de software,
destacando como o planejamento adequado pode evitar falhas e garantir sistemas mais robustos e confiáveis.
Iniciamos com a compreensão das estratégias que integram as atividades de desenvolvimento e teste,
aprofundando a diferenciação entre os testes caixa branca e caixa preta e suas respectivas abordagens.
 
Exploramos também a elaboração de planos e casos de teste como parte essencial do processo, introduzindo
a ferramenta TestLink para auxiliar na organização e execução dessas tarefas de forma prática. Além disso,
discutimos o uso da UML e dos casos de uso como ferramentas de apoio para a estruturação eficiente dos
testes.
 
Avançamos no conteúdo com a apresentação do framework Cucumber e da automação de testes utilizando o
Selenium WebDriver, destacando a construção de rotinas automatizadas que contribuem para maior agilidade
e precisão na verificação de funcionalidades.
 
Encerramos com a técnica BDD (Behavior Driven Development), que propõe uma abordagem colaborativa
entre equipes técnicas e usuários, facilitando a compreensão dos requisitos e a validação do comportamento
esperado do sistema.
 
Assim, consolidamos conhecimentos fundamentais para a atuação profissional na área de qualidade de
software, oferecendo uma base sólida para a aplicação prática de testes que asseguram a entrega de
soluções tecnológicas alinhadas às necessidades dos usuários e às exigências do mercado.
Explore +
Leia os textos:
 
Laboratório de testes com TestLink na página SlideShare.
 
Teste de Software Moderno: Estratégias de Testes na página do Medium.
 
TestLink: gerenciando atividades de teste na página DevMedia.
 
Testlink - uma ferramenta de gerenciamento de testes de software. 
 
Assista ao vídeo Cucumber na página do Labs Bluesoft.
Referências
BARTIÉ, A. Garantia de qualidade de software. 1. ed. Rio de Janeiro: Campus, 2002.
 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. 2.ed. UML: Guia do usuário. Rio de Janeiro: Campus, 2005.
• 
• 
• 
• 
• 
• 
https://cdn-conteudo.ensineme.com.br/Testlink_c0c539bebb.pdf
 
CAETANO, C. Automação e gerenciamento de testes: aumentando a produtividade com as principais
soluções open source e gratuitas. Consultado na internet em 06 jun. 2019.
 
COCKBURN, A. Escrevendo casos de uso eficazes. Porto Alegre: Bookman, 2005.
 
CUCUMBER. Executable Specifications. Consultado na internet em 06 jun. 2019.
 
GITHUB. Join GitHub today. Consultado na internet em 1 jun. 2019.
 
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientado a objetos e ao
desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007.
 
LINHA DE CÓDIGO. CAETANO, C. Automação e gerenciamento de testes: aumentando a produtividade
com as principais soluções open source e gratuitas. Consultado na internet em 06 jun. 2019.
 
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: Makron Books, 1995.
 
RUBY. Documentação. Consultado na internet em 06 jun. 2019.
 
SELENIUM. Selenium Documentation. Consultado na internet em 06 jun. 2019.
 
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
	Estratégias e planejamento de teste de software
	1. Itens iniciais
	Propósito
	Objetivos
	Introdução
	1. Estratégias do processo de Teste de Software
	Estratégias de teste de software
	Atenção
	Estratégia e atividade de teste
	Atenção
	Atenção
	Conteúdo interativo
	Algumas estratégias de teste
	Teste de unidade
	Teste de integração
	Teste de validação
	Teste de sistema
	Alinhamento estratégico
	Atenção
	Exemplo
	Exemplo
	Teste caixa branca e teste caixa preta
	Caixa branca
	Técnicas empregadas no teste caixa branca
	Teste caixa branca e teste caixa preta
	Teste caixa branca
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	Teste caixa preta
	Conteúdo interativo
	Conteúdo interativo
	Conteúdo interativo
	Abordagens de teste
	Conteúdo interativo
	Caixa branca
	Caixa preta
	Abordagens de teste
	Baseados na estrutura interna
	Conteúdo interativo
	Baseados em requisitos
	Baseado em grafo
	Particionamento de equivalência
	Análise de valor-limite
	Matriz ortogonal
	Conteúdo interativo
	Verificando o aprendizado
	2. Plano de Testes e Casos de Teste
	Gestão de testes
	Conteúdo interativo
	Utilizando a ferramenta TestLink
	TestLink
	Motivação para o TestLink
	Desvantagem dessa ferramenta
	Saiba mais
	O que é plano de testes?
	Conteúdo interativo
	Atenção
	Elaboração do plano de teste
	Requisitos a serem testados
	Estratégias e ferramentas de teste
	Equipe (responsabilidades e requisitos humanos) e infraestrutura
	Cronograma de atividade
	Documentação
	Planejamento e execução dos testes
	Planejar teste
	Executar teste
	Planejamento e execução
	Principais erros
	No propósito da atividade de teste
	No planejamento dos testes
	No pessoal contratado para testar
	Na execução dos testes em si
	Na aplicação da tecnologia nos testes
	Conteúdo interativo
	Importância da UML e casos de uso para a elaboração dos planos de teste
	Utilização da UML no processo iterativo e incremental
	Defeitos no desenvolvimento de software
	Exemplo simples de ciclo de vida de desenvolvimento de software
	Métodos de análise de documentos
	Diagrama de estado
	Exemplo
	Conteúdo interativo
	Diagrama de atividades
	Conteúdo interativo
	Modelo de casos de uso
	Comentário
	Verificando o aprendizado
	3. Teste de Aceitação
	O que é um teste de aceitação?
	Defeito
	Erro
	Falha
	Exemplo
	Desenvolvimento de rotinas de teste com base no framework Cucumber e automação com Selenium WebDriver
	Ferramentas de teste automatizado de software
	Infraestrutura
	Metodologia
	Ferramenta
	Atenção
	Automação com ferramenta CucumberCucumber
	Exemplo
	Conteúdo interativo
	Saiba mais
	Elaborando testes de aceitação com usuário final
	Conteúdo interativo
	Teste de aceitação formal
	Teste de aceitação informal
	Teste beta
	Conteúdo interativo
	Relacionando requisitos a expectativas de teste
	Estratégia de teste
	Atenção
	Exemplo
	Testes baseados em requisitos
	Requisitos de negócio
	Requisitos de usuário
	Requisitos funcionais
	Requisitos não funcionais
	Requisitos detalhados
	Requisito de teste
	Metodologias utilizadas para testes de aceitação
	Fases da Metodologia MTS
	Comentário
	Fase de teste de unidade
	Fase de teste de integração
	Fase de teste de sistema
	Fase de teste de homologação
	Fase de teste de implantação
	BDD - Behavior Driven Development (Desenvolvimento Orientado por Comportamento)
	Conteúdo interativo
	Metodologias de desenvolvimento
	Princípios do BDD
	Como é o ciclo do BDD?
	Funcionamento do BDD
	Conteúdo interativo
	Verificando o aprendizado
	4. Conclusão
	Considerações finais
	Explore +
	Referênciasé necessário que as empresas associem a Engenharia de Software às melhores técnicas a serem
adotadas pelos profissionais relacionados com a produção de software. Será que todas as empresas têem
essa visão ou apenas uma visão limitada?
 
Temos basicamente três níveis na empresa. A Engenharia de Software não deve apenas ficar no nível
operacional, pois este cobre apenas parte das dificuldades, sendo que os problemas de maior impacto na
organização aparecem nos níveis tático e estratégico.
Exemplo
As empresas frequentemente apontam que sua área de desenvolvimento de software não conhece ou
entende seu próprio negócio; Que utiliza indiscriminadamente tecnologias e ferramentas em seus
produtos sem se preocupar se haverá ganho ou se o cliente está preparado para absorvê-las; Que se
preocupa tanto com as próprias atividades que cria obstáculos, burocracia ou dificuldades para ser
acionada por outras áreas; Empresas que, por exemplo, atuam desenvolvendo produtos de software
customizados para outras organizações têm por estratégia minimizar seus custos. 
Assim, as práticas adotadas devem favorecer essa estratégia, tais como:
 
Implantar processos e ferramentas que tornem o desenvolvimento mais barato, já incluídos os custos
da execução do processo e das licenças (no nível operacional).
 
Gerenciar e reduzir a ociosidade da equipe no período entre-projetos (no nível tático).
 
Estabelecer um programa corporativo de premiação de produtividade (no nível estratégico).
 
Agora que entendemos que a Engenharia de Software deve atuar nos três níveis (Estratégico, Tático e
Operacional), seus princípios de melhoria cíclica (processo de melhoria contínua) podem ser aplicados com
sucesso.
• 
• 
• 
Exemplo
Ciclo de melhoria: Primeiro é feito um diagnóstico sobre como o desenvolvimento de software na
empresa precisa melhorar, em todos os níveis; Depois, os itens diagnosticados são priorizados com base
no impacto no negócio, e os mais críticos são escolhidos; Ações para resolver os itens selecionados são
então definidas e implementadas, observando o que precisa ser feito para que a ação gere resultados
efetivos em todos os níveis; Finalmente, avalia-se o resultado da solução e o impacto positivo nos
negócios. 
As soluções de Engenharia de Software sempre contribuirão para agregar valor ao negócio com
esses ciclos de melhoria adequadamente aplicados, e o software será efetivamente uma peça
fundamental na estratégia da empresa.
Teste caixa branca e teste caixa preta
Existem duas estratégias utilizadas para conduzir o processo de validação de software.
 
Caixa branca.
 
Caixa preta.
 
Estas estratégias não são excludentes; muito pelo contrário, elas são complementares.
 
Conhecendo os detalhes internos de um produto, os testes são executados para assegurar que “todas
as engrenagens estejam articuladas”, assim:
 
Operação interna de acordo com a especificação;
 
Todos os componentes internos foram adequadamente exercitados (teste caixa branca [aberta],
white-box testing, teste estrutural).
 
Conhecendo-se a função que um produto deve realizar, os testes são executados para demonstrar que
cada função está completamente operacional (teste caixa preta [fechada], black-box testing, teste
funcional).
 
Caixa branca
Arquitetura interna do software → Estrutura de controle (programa) → Caso de teste
Técnicas empregadas no teste caixa branca
• 
• 
• 
◦ 
◦ 
• 
Avaliação das estruturas de sequência, decisão e repetição, através da simulação de situações que exercitem
todas as estruturas utilizadas na codificação adequadamente.
 
Vamos entender o que é um caso de teste, utilizado em teste caixa branca e preta.
 
É o documento que registra todo o planejamento dos testes e o que será testado. Deve identificar o maior
número de cenários e variações possíveis, assim como os resultados esperados. Normalmente o desenho de
um cenário de teste é mental.
 
Leia o texto para entender melhor sobre o teste caixa branca e teste caixa preta.
Teste caixa branca e teste caixa preta
Teste caixa branca
É feito a partir das estruturas de controle do programa, através do maior número possível de cenários de
testes que atendam ao maior número possível de situações.
 
Exemplo:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Notação para grafo de fluxo (de programa).
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Nessa notação, cada círculo representa um ou mais comandos nó de desvio do programa fonte.
 
Exemplo:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
O teste caixa branca é considerado um teste procedural. Então, quais são os exames de detalhes desses
testes procedurais?
 
Teste de caminhos lógicos - Casos de teste para exercitar conjuntos específicos de condições e/ou
laços;
 
O estado do programa - Examinado em vários pontos para determinar se o estado esperado ou
declarado corresponde ao estado real.
 
• 
• 
Importante: Não é possível testar todos os caminhos lógicos de um programa grande.
 
A abordagem deste tipo de teste tem as seguintes peculiaridades:
 
Seleção de um número limitado de caminhos a serem exercitados;
 
Estruturas de dados importantes podem ser investigadas para validação;
 
Pode haver combinação dos dois tios de teste, funcional e estrutural, para validar a interface do
software e assegurar (seletivamente) que as operações internas do software estejam corretas.
 
A estrutura de controle do projeto procedimental deve ter casos de teste que:
 
Garantam que todos os caminhos independentes dentro de um módulo tenham sido percorridos pelo
menos uma vez;
 
Exercitem todas as decisões lógicas em todos os seus ramos de saída;
 
Executem todos os laços nos seus limites e dentro de suas fronteiras operacionais;
 
Exercitem estruturas de dados internas para assegurar sua validade.
 
Observe as tabelas a seguir.
Descrição do caso
de teste
Uma descrição da condição, caminho do programa ou objetivo que
este conjunto de dados implementa / executa.
Entradas de teste Os objetos ou campos que os atores interagem e os valores dos dados
de entrada pelo ator quando executa este caso de teste.
Resultados
esperados
Estado resultante ou dado recebido após completa execução do caso
de teste.
Tabela. Modelo de caso de teste do RUP.
Carlos Alberto de Farias.
Id Cenário / Condição Dedos de
entrada Resultados esperados
1112
Efetuar login - Operação com
sucesso
Login - Válido
Password -
Válido
Usuário logado, página principal
exibida
• 
• 
• 
• 
• 
• 
• 
Tabela. Exemplo de caso de teste.
Carlos Alberto de Farias.
Teste caixa preta
Também conhecidos como testes comportamentais, destacam os requisitos funcionais do software e utilizam
técnicas para garantir que os requisitos do sistema sejam amplamente atendidos pelo software construído.
 
Esses testes não requerem o conhecimento da tecnologia empregada e dos conceitos de implementação do
software, o que os diferencia dos testes caixa branca.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Exemplo:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Para o teste caixa preta, devemos verificar:
 
Requisitos (importante conhecer);• 
 
Características (importante conhecer);
 
Comportamentos (importante conhecer);
 
Maior variedade de cenários (maiores simulações avaliadas).
 
O que é necessário que o profissional de testes conheça no teste caixa preta para que o software seja
avaliado através dos resultados gerados pela aplicação? Os requisitos, suas características e comportamentos
esperados.
 
Nesse caso, quanto maior a variedade de cenários, maior será o conjunto de simulações que serão avaliadas e
comparadas com os requisitos da aplicação, implementados através da construção de casos de testes.O que é importante o testador saber:
 
Como a validade funcional é testada;
 
Como o comportamento e o desempenho do sistema são testados;
 
Que classes (módulos – procedimentos e dados [sistema]; classes – atributos e métodos [objeto]) de
entrada farão bons casos de teste;
 
Se o sistema é particularmente sensível a certos valores de entrada;
 
Como as fronteiras de uma classe de dados podem ser isoladas;
 
Que taxas e volumes de dados o sistema pode tolerar;
 
Que efeito “combinações específicas de dados” terá sobre a operação do sistema?
 
Assista ao vídeo e aprenda sobre casos de teste.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Abordagens de teste
Segundo Bartié (2002), há várias formas de identificar e planejar os casos de testes a serem aplicados nos
testes de validação; porém, o direcionamento dos testes (conhecido com testdrive) baseia-se exclusivamente
em:
 
Requisitos da solução tecnológica a ser desenvolvida (teste caixa preta); ou
 
Estrutura interna do código-fonte a ser implementado (teste caixa branca).
 
Assista ao vídeo e aprenda como aprofundar as técnicas de caixa branca.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Caixa branca
Testes baseados na estrutura interna
• 
• 
Caixa preta
Testes baseados nos requisitos
Leia o a seguir para entender melhor sobre esses testes.
Abordagens de teste
Baseados na estrutura interna
Os testes requerem conhecimento profundo da tecnologia empregada e do projeto desenvolvido, de forma a
praticarem adequadamente todas as estruturas internas do projeto.
 
Este tipo de teste requer que o testador tenha um amplo conhecimento interno do software e subdivide-se
em:
 
Teste de caminho básico.
 
Teste de fluxo de dados.
• 
• 
 
Teste de ciclo.
 
Teste de condição.
 
Vejamos cada um deles.
Teste de caminho básico
 
Permite ao projetista do caso de teste apartar uma medida da complexidade lógica (medida usada como guia
para definir um conjunto básico de caminhos de execução) de um projeto procedimental e usá-la para definir
um conjunto básico de caminhos de execução.
 
Os casos de teste apartados para exercitarem o conjunto básico têm a garantia de executar cada instrução do
programa pelo menos uma vez durante a atividade de teste.
Teste de fluxo de dados
 
Tenta encontrar erros nas seguintes categorias:
 
Seleciona caminhos de teste de um programa de acordo com as localizações de definições e usos de
variáveis no programa;
 
Seleciona caminhos de teste de um programa que contenha instruções de laços e if aninhados.
 
Vejamos um exemplo demonstrando como usar o teste de fluxo de dados em um grafo de fluxo:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
• 
• 
• 
• 
Teste
do
ciclo
 Tipos de
abordagens:
 Simples; Aninhados; Concatenados; Não
estruturados.
 Simples -
conjunto
de testes
pode ser
aplicado a
ciclos
simples,
nos quais
“n” é o
número
máximo
de
passadas
permitidas
através
do ciclo.
 Aninhados -
testa se os
ciclos mais
internos que
são
aplicados à
abordagem
de ciclos
simples e os
outros
externos
permanecem
com o valor
mínimo.
 Concatenados Os ciclos
concatenados
podem ser
testados
usando a
abordagem
definida para
simples, se
cada ciclo for
independente
do outro.
 Se dois ciclos
forem
concatenados
e a contagem
para o ciclo 1
for usado valor
individual para
o ciclo 2, então
os ciclos não
são
considerados
independentes.
 Quando os
ciclos não são
independentes,
é
recomendada
a abordagem
aplicada a
ciclos
aninhados.
(Pressman,
2011)
 Não
estruturados
- segundo
Pressman,
sempre que
possível,
essa classe
de ciclos
deverá ser
redesenhada
para refletir
o uso das
construções
de
programação
estruturada.
Baseados em requisitos
• • • • • • • 
Os testes são baseados nos documentos de requisitos e modelados através de especificações funcionais e
suplementares. Os requisitos devem ser decompostos em casos de testes de forma a avaliarem todos os
cenários existentes e validarem todas as variações. (Bartié, 2002)
 
Baseado em grafo.
 
Particionamento me equivalência.
 
Análise do valor limite.
 
Teste de matriz ortogonal.
 
Vejamos cada um deles a seguir.
Baseado em grafo
A teoria dos grafos é um ramo da matemática que estuda as relações entre os objetos de um
determinado conjunto. Para tal, são empregadas estruturas chamadas de grafos, G, onde V é um
conjunto não vazio de objetos denominados vértices e A é um conjunto de pares não ordenados de V,
chamado de aresta.
Esse tipo de teste leva em consideração os objetos modelados no software e as relações que os
unem. A ideia é definir uma série de testes que examinam se os objetos têm a relação esperada uns
com outros.
Quando se tem uma coleção de nós que representam objetos, ligações que representam as relações
entre objetos, pesos de nó que descrevem as propriedades de um nó e pesos de ligação que
descrevem alguma característica de uma ligação, isso é um grafo.
• 
• 
• 
• 
Particionamento de equivalência
1. Se uma condição de entrada específica um intervalo, são definidas:
Uma classe de equivalência válida;
Duas classes de equivalência inválida.
2. Se uma condição de entrada requer um valor específico, são definidas:
Uma classe de equivalência válida;
Duas classes de equivalência inválida.
3. Se uma condição de entrada específica um membro de um conjunto, são definidas:
Uma classe de equivalência válida;
Uma classe de equivalência inválida.
4. Se uma condição de entrada for booleana, são definidas:
Uma classe válida;
Uma inválida.
Exemplo: Um programa valida um campo numérico no qual valores:
Inferiores ou iguais a zero são rejeitados;
Entre 1 e 150 são aceitos;
Maiores ou iguais a 151 são rejeitados.
Neste caso:
Partição válida: valores entre 1 e 150;
Partição inválida: valores acima ou abaixo do valor válido.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Análise de valor-limite
Técnica que complementa o particionamento de equivalência, levando em consideração, na
construção dos casos de teste, os valores limites das condições de entrada e saída.
Exemplo: Um campo de entrada referente a data do nascimento e que aceita valores entre 1950 até
2018 terá como valores limites:
Valor limite mínimo inválido: 1949;
Valor limite mínimo válido: 1950;
Valor limite máximo válido: 2018;
Valor limite máximo inválido: 2019.
Matriz ortogonal
Em álgebra linear, uma matriz ortogonal é uma matriz quadrada real M cuja inversa coincide com a sua
transposta, isto é: note que uma matriz é ortogonal se e somente se as colunas são vetores
ortonormais (vetores ortogonais e unitários).
Pode ser aplicada em problemas nos quais o domínio de entrada é relativamente pequeno, mas muito
grande para acomodar um teste exaustivo.
Seu objetivo é a construção de casos de teste com uma visualização geométrica associada aos
valores de entrada de uma aplicação.
Exemplo: Na função enviar para uma aplicação de web, são passados quatro parâmetros: P1, P2, P3 e
P4, nos quais cada parâmetro assume três valores discretos.
P1 assume os seguintes valores:
P1 = 1, enviar agora;
P1 = 2, enviar após meia-hora;
P1 = 3, enviar após 1 hora.
P2, P3 e P4 também assumem valores, 1, 2 e 3, significando outras funções de envio.
Assista ao vídeo e aprenda como aprofundar as técnicas de caixa preta.
• 
• 
• 
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Verificando o aprendizado
Questão 1
A equipe de desenvolvimento recebe o documento de resultados de testes gerado pelos homologadores.
Responda:
 
a. Qual processo os desenvolvedores devem executar agora?
 
b. Como se desenvolve esse processo?
 
c. Que documentos são utilizados como apoio a esse processo?
Chave de resposta
a. Agora os desenvolvedores devem fazer a depuração.
b. A depuração é desenvolvida com os seguintes passos:
1º) Localizar o erro;
2º) Planejar o reparo do erro;
3º) Repararo erro;
4º) Refazer os testes.
c. São utilizados os seguintes documentos: Resultado de testes, especificação e casos de teste.
Questão 2
O gerente de um departamento de sistemas decidiu que os produtos de software criados pela equipe A serão
homologados pela equipe B e vice-versa. Percebeu-se com o tempo, no entanto, o surgimento de diversos
conflitos entre as equipes A e B. Responda:
 
a. Qual a origem desses conflitos?
 
b. Indique uma proposta de solução para minimizá-los.
Chave de resposta
a. A origem do problema é que os desenvolvedores testam os produtos para “provar que funcionam”,
enquanto os homologadores testam para “provar que não funcionam”, agravados no caso pela proximidade
entre as equipes e pela constante troca de papéis no processo.
b. A sugestão para minimizar os conflitos é a criação de um grupo independente de teste (ITG).
Questão 3
A equipe Z realizou a codificação de uma nova tela para o sistema de controle de estoque. O objetivo da
equipe é garantir que não existam erros, considerando apenas a parte “nova” do produto. Responda:
 
a. Qual o tipo de teste que deve ser realizado?
 
b. Quais diferentes visões devem ser consideradas ao aplicarmos este tipo de teste?
Chave de resposta
a. O tipo de teste a ser realizado é o teste de unidade.
b. As visões que o teste de unidade considera são:
Interface;
Estrutura lógica de dados;
Caminhos independentes;
Condições limite;
Caminhos de manipulação de erro.
Questão 4
Ao testarmos a emissão de um relatório novo criado no sistema, para nossa surpresa, ao confirmarmos a
impressão, o sistema emite a mensagem invalid type conversion in line 453, e o relatório não é emitido.
Responda:
• 
• 
• 
• 
• 
 
a. Qual visão do teste de unidade não foi aplicada neste caso?
 
b. Que cuidados devemos ter nesta visão dos testes de unidade?
Chave de resposta
a. A visão dos caminhos de manipulação de erro.
b. Devemos cuidar para que não ocorram os seguintes problemas:
A descrição do erro é ininteligível;
O erro mencionado não corresponde ao erro encontrado;
A condição de erro provoca a execução no sistema antes da mensagem de manipulação de erro;
O processamento da condição está errado;
A descrição não é esclarecedora o suficiente.
• 
• 
• 
• 
• 
2. Plano de Testes e Casos de Teste
Gestão de testes
A gestão de testes tem grande importância junto ao ciclo de vida de desenvolvimento do software.
 
Por isso, ao gerir os testes, nos permitimos documentar e evidenciar cada etapa da execução dos testes do
projeto. A gestão de testes nos possibilita também uma visão completa de sua evolução e da qualidade do
software.
Por que usar ferramentas de gerenciamento de testes?
Essas ferramentas oferecem um repositório central e padronizado, no qual os testadores poderão:
 
Criar uma coleção de casos de teste (suítes com os casos de teste);
 
Atribuir essas suítes aos seus respectivos testadores;
 
Acompanhar a situação da execução dos testes;
 
Emitir relatórios com métricas e estatísticas.
O que é uma suíte de teste?
Conforme o livro Garantia da qualidade de software, a suíte (ou situação) de teste finaliza o processo de
detalhamento dos testes de validação e:
 
Estabelece como será testado um determinado conjunto de casos de uso;
 
Define quais procedimentos e em que ordem serão executados;
 
Possibilita validar o comportamento dos vários cenários de determinados requisitos de software.
 
Para as suítes de teste, devemos abordar os seguintes itens:
 
Identificação das suítes de testes;
• 
• 
• 
• 
• 
• 
• 
• 
 
Definição das suítes de teste;
 
Prerrequisitos de cada suíte;
 
Definição dos procedimentos de execução dos testes.
 
Cronograma detalhado.
O que é um caso de teste?
É o documento de registro de todo o planejamento dos testes, estabelecendo o que será testado.
 
Sua finalidade é identificar o maior número de cenários e variações de determinado requisito de software.
 
Determina as informações empregadas durante os testes dos cenários e os resultados esperados,
estabelecendo a massa crítica de testes para validar os requisitos do software.
 
Os itens abordados são:
Identificação das condições de testes;
 
Identificação dos casos de testes;
 
Definição de cada caso de teste identificado;
 
Detalhamento da massa de entrada;
 
Arquitetura do ambiente de teste;
 
Critérios especiais para a geração da massa de testes (d+0, d-30, m+1, a+18);
 
Responsáveis pelo levantamento;
 
Cronograma detalhado;
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
 
Definir agenda de levantamentos (como testar).
 
Existe uma norma (IEEE 829) que propõe um padrão de documentação a ser seguido pelas organizações:
 
a. Esta norma, do Instituto de Engenheiro Eletricistas e Eletrônicos (ou Padrão 829 para Documentação de
Teste de Software), é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito
estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de
documento;
 
b. Propõe um padrão de documentação que deveria ser obedecido por todas as organizações que trabalham
com teste de software.
 
Assista ao vídeo e aprenda sobre gerenciamento de testes.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Utilizando a ferramenta TestLink
Além dos casos de teste, precisamos também do plano de teste.
 
Necessidade dos planos de testes:
 
Permitem que membros da equipe de teste acompanhem os casos de teste, executem e vejam os
resultados esperados.
 
A ferramenta também permite a geração de relatórios que auxiliam o coordenador da equipe a priorizar
e atribuir tarefas.
 
Permitem adicionar os resultados de cada um dos testes executados e também visualizar os resultados
globais deles.
 
Para auxiliar nessa documentação de teste, existem várias ferramentas disponíveis, e uma delas é o TestLink.
Leia o texto seguinte para conhecer sobre essa ferramenta.
TestLink
Trata-se de uma aplicação open source voltada para a gestão de testes, desenvolvida e mantida por várias
equipes ao longo dos anos. Oferece suporte para criação, execução e manutenção de casos de teste, planos
de testes e requisitos.
 
• 
• 
• 
• 
Permite a geração de relatórios gerenciais e estatísticos sobre os testes executados e a integração com
outras ferramentas de gerenciamento de bugs. (Caetano, 2007).
 
Conheça as características e funcionalidades do TestLink.
 
É baseado em planos e casos de teste;
 
Suporta o gerenciamento de múltiplos projetos;
 
Possibilita a criação de um repositório (banco de dados) centralizado para todos os casos de teste e os
resultados;
 
Possibilita a integração com ferramentas de gestão de defeitos, como Mantis, Jira e Bugzilla;
 
Possibilita a geração de relatórios;
 
Permite autenticação via LDAP (é uma forma abreviada de falar Active Directory (que é um serviço de
diretório feito pela Microsoft). Significa Lightweight Directory Access Protocol e consiste em um meio
para consultar itens em qualquer serviço de diretório que a suporta.).
 
Ele é muito importante para o processo de desenvolvimento do software, porém é preciso mantê-lo sempre
atualizado.
 
Com o uso do Testlink, é possível:
 
Escrever, e consequentemente documentar, os casos de teste;
 
Reduzir a duplicação de esforços, pois a existência de uma base de documentação permite o
reaproveitamento de esforços passados, sem a necessidade de criar todos os casos de testes
novamente.
Motivação para o TestLink
De acordo com o Manual de TestLink, a ferramenta possibilita:
 
Criar vários projetos;
 
Exportar e importar casos de teste facilmente;
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
https://cdn-conteudo.ensineme.com.br/Testlink_user_manual_0346b00b8b.pdf
https://cdn-conteudo.ensineme.com.br/Testlink_user_manual_0346b00b8b.pdf
 
Atribuir casos de teste para usuários específicos;
 
Gerar planos e relatórios de teste em vários formatos;
Desvantagem dessa ferramenta
Não dispõe de um mecanismoque mapeie e gerencie automaticamente casos de uso como casos de teste.
Saiba mais
Leia o artigo TestLink: gerenciando atividades de teste. 
O que é plano de testes?
Assista ao vídeo entenda o plano de testes.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Um documento de plano de testes (eventualmente definido na etapa de análise de requisitos) define quantos
e quais testes serão realizados. Um plano tem o papel semelhante ao de um “mapa”. Sem ele, nenhum
participante dos testes conhecerá seus objetivos, nem aonde quer chegar e, o pior de tudo, jamais terá a
certeza de ter alcançado sua meta.
 
O propósito desse planejamento é monitorar a execução de atividades, sendo também importante conhecer o
papel dos riscos no planejamento e diferenciar as estratégias de planos.
 
O planejamento engloba três atividades principais:
 
1. Definir um cronograma de atividades.
 
2. Fazer alocação de recursos.
 
3. Definir marcos de projeto: estabelecer os marcos a serem alcançados, com o objetivo de fazer o
acompanhamento.
 
Esse planejamento é acompanhado da atividade de monitoração ou supervisão, que objetiva avaliar se o
progresso que tem sido alcançado está em conformidade com o que foi estabelecido no plano.
 
• 
• 
O plano de teste é um dos oito documentos descritos na IEEE 829. De acordo com ela, a estrutura do plano de
teste consiste de uma série de partes (ou seções) descritas a seguir, na elaboração do plano de teste.
 
O plano de teste é um dos documentos produzidos na condução de um projeto. Quem pode elaborar esse
documento é o gerente de projeto ou o gerente de testes.
 
O que visa o plano de teste?
 
Planejar as atividades a serem realizadas;
 
Definir os métodos a serem empregados;
 
Planejar a capacidade necessária;
 
Estabelecer métricas e formas de acompanhamento do processo.
 
É importante que o plano contenha os seguintes itens:
 
Uma introdução com identificação do projeto (definições, abreviações, referências), definição de
escopo e objetivos;
 
O conjunto de requisitos a serem testados;
 
Os tipos de testes a serem realizados e ferramentas utilizadas;
 
Os recursos utilizados nos testes;
 
Um cronograma de atividades (e definição de marcos de projeto).
Atenção
O planejamento é necessário a fim de antecipar o que pode ocorrer e provisionar os recursos
necessários nos momentos adequados. 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Elaboração do plano de teste
Sem planejamento, fica mais difícil o desenvolvimento de qualquer projeto. O plano é como se fosse um mapa;
com ele, podemos chegar ao nosso destino.
Requisitos a serem testados
Relacionar os itens de teste, descrevendo todos os elementos que serão testados;
Descrever, isoladamente, funcionalidades a serem e a não serem testadas.
Vejamos alguns exemplos de requisitos a serem testados: desempenho, segurança, interface de
usuário, controle de acesso, funcionalidades.
Estratégias e ferramentas de teste
Descrever a estratégia do teste, geralmente para cada grupo de funcionalidades das seções
anteriores;
Abordar questões como atividades e ferramentas usadas no teste;
Descrever o critério de sucesso ou falha do caso de teste e outra descrevendo o critério de
suspensão e requisitos de reinício, como por exemplo atividades que devem ser feitas antes de
reiniciar o teste após um evento de suspensão;
Listar o conjunto de ferramentas utilizadas.
Equipe (responsabilidades e requisitos humanos) e infraestrutura
Mostrar as necessidades físicas para a realização do teste. Exemplo: hardware e software, e
como elas podem afetar a execução do teste;
Mostrar os diferentes papéis desempenhados no projeto de teste;
Os recursos humanos e requisitos de treinamento da equipe de teste.
• 
• 
• 
• 
• 
• 
• 
• 
• 
Cronograma de atividade
Descrição de marcos importantes das atividades (incluindo as datas de início e fim da
atividade). Exemplo: projeto de testes, execução de testes ou avaliação de testes;
Riscos e contingências.
Documentação
Relação dos documentos pertinentes ao projeto;
Aprovações;
Assinatura dos líderes do projeto, aprovando o documento.
Planejamento e execução dos testes
O planejamento faz parte da primeira fase do processo de revisão. Devemos selecionar a equipe, alocar as
funções, definir os critérios de entrada e de saída para os diversos tipos de revisão e selecionar quais partes
dos documentos serão observados.
 
O planejamento tem que estar de acordo com o alinhamento estratégico da empresa.
• 
• 
• 
• 
• 
Planejar teste
O objetivo de planejar teste é definir o plano de testes para o projeto. Devem ser identificados os
tipos de testes e os artefatos que devem ser testados, sempre usando os fatores de criticidade das
ameaças.
A coordenação dessa atividade é feita pelo gerente de teste e pelo gerente de projeto.
Para planejar o teste, devem ser identificados vários artefatos como: programas, rotinas, sub-rotinas,
arquivos, equipamentos, softwares de transmissão, sistemas operacionais, instalações e outros.
Dependendo do domínio, eles devem ser eleitos para fazer parte de um conjunto de artefatos sujeitos
a testes de missão crítica.
Executar teste
Tem como objetivo testar os artefatos selecionados na macroatividade anterior, conforme definido no
plano de testes. Dependendo do grau de criticidade do sistema, será necessária também a
verificação desse artefato. Essa verificação deve ser executada através de uma revisão por pares
além do teste, conforme planejado.
Planejamento e execução
Vamos tomar como exemplo um sistema crítico.
 
Quando iniciarmos a atividade de planejamento dos testes, devemos fazer a revisão dos requisitos, a
homologação oficial dos mesmos com os especialistas do domínio e usuários responsáveis e/ou
homologadores e o planejamento e a elaboração de testes de aceitação.
 
Atividades de testes do ciclo de desenvolvimento de uma aplicação que devem começar no início do projeto:
 
Fixação da estratégia de teste e conceitos de testes;
 
Análise de risco, levantamento das ameaças, estimativa dos gastos com os testes, recursos humanos,
máquina e tempo necessário para executar os testes;
 
Elaboração do plano de testes;
 
Treinamento da equipe de testes, se necessário;
 
Estabelecer processos e métricas (não confundir com medidas) de controle;
 
Definir recursos de hardware, computadores (equipamentos), mesas, cadeiras etc.;
• 
• 
• 
• 
• 
• 
 
Providenciar recursos de software, bases de dados (definir bases de teste), confidencialidade,
confiabilidade, coerência, controle de versão, ferramentas de testes etc.
 
Deve-se sempre verificar o que foi feito para corrigir problemas, antes de seguir para o desenvolvimento.
 
Ao olharmos para a frente, devemos fazer perguntas tais como:
 
Os requisitos críticos podem ser testados?
 
Os custos previstos são sustentáveis?
 
Se as respostas forem corretas, então não haverá problemas para que esses requisitos sejam implementados.
 
Se não existir um caminho claro de como os requisitos vão ser testados, então é provável que não se tenha
ideia de como fazer para implementar esses requisitos. (SPILLNER, 2002).
Principais erros
Os principais erros que são cometidos foram resumidos em um artigo publicado por Brian Marick em 1997.
Foram identificados cinco grupos importantes de erros comumente cometidos por quem testa softwares, nos
seguintes pontos:
No propósito da atividade de teste
Ocorre quando o ator que controla a execução não entende bem o sentido de testar e não aproveita
os resultados de forma eficaz.
Os erros comuns são:
Atribuir a responsabilidade pela qualidade unicamente à equipe de teste;
Achar que a tarefa de equipe de testes é simplesmente encontrar erros;
Não encontrar os erros importantes;
Oferecer estatísticas de erros sem o contexto relevante.
• 
• 
• 
• 
• 
• 
• 
No planejamento dos testes
Esses erros estão relacionados à fase de planejamento dos testes:
Concentrar-se exageradamente em teste funcional;Não enfatizar o teste de configuração;
Deixar o teste de carga para o final do processo;
Não testar a documentação nem a instalação;
Teimosia em aplicar um plano de teste ineficaz.
No pessoal contratado para testar
Ao montar a equipe que conduzirá os testes, é importante se concentrar nos seguintes erros comuns
e tentar evitá-los:
Usar o teste como um trabalho temporário para programadores novos;
Recrutar ex-programadores (os que não são os melhores) para a equipe de teste;
Usar testadores que não conhecem o domínio da aplicação;
Não contratar pessoal de suporte técnico e documentação;
Insistir que testadores sejam programadores;
Não utilizar uma equipe de teste diversificada.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Na execução dos testes em si 
Durante a execução dos testes, um conjunto de problemas comuns é:
Dar mais atenção à execução dos testes do que ao seu projeto;
Não rever os projetos de teste;
Ser específico demais nas entradas e procedimentos do teste;
Não notar nem explorar irregularidades peculiares;
Elaborar suítes de teste compreendidas apenas por seus criadores;
Adicionar apenas testes de regressão quando problemas são encontrados;
Não manter um histórico de anotações para os próximos testes.
Na aplicação da tecnologia nos testes
A aplicação de tecnologia à atividade de teste é muitas vezes benéfica, mas nem sempre, e nunca
desenfreadamente.
A seguir, os erros que envolvem o foco tecnológico do teste:
Tentar automatizar todos os testes;
Esperar reexecutar testes manuais;
Usar ferramentas de automação de interface para reduzir o custo do teste;
Não analisar a cobertura de código em absoluto.
Assista ao vídeo e aprenda sobre casos de uso e casos de teste.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Importância da UML e casos de uso para a elaboração dos
planos de teste
Utilização da UML no processo iterativo e incremental
A UML é independente do processo de desenvolvimento.
 
Vários processos podem utilizar a UML para modelagem de um sistema OO.
Quando os artefatos de software são construídos através da UML, eles evoluem à medida que as iterações
são realizadas, assim:
 
A cada iteração, novos detalhes são adicionados a esses artefatos;
 
Além disso, a construção de um artefato fornece informações para adicionar detalhes a outros.
Defeitos no desenvolvimento de software
Defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de
desenvolvimento de um software. (PRESSMAN, 2005).
Exemplo simples de ciclo de vida de desenvolvimento de software
Os requisitos expressos pelo cliente são relatados textualmente em um documento de especificação de
requisitos.
 
O documento é transformado em casos de uso que, no que lhe diz respeito, foi o artefato de entrada para o
projeto do software e definição de sua arquitetura utilizando diagramas de classes da UML.
 
Para chegarmos ao produto final, uma série de transformações é realizada. Vamos mostrar uma imagem
clássica que expressa exatamente essa ideia por meio de uma metáfora.
• 
• 
• 
Como o cliente explicou...
Como o líder de projeto entendeu...
Como o analista projetou...
Como o programador construiu...
Como o consultor de negócios descreveu...
Como o projeto foi documentado...
Que funcionalidades foram instaladas...
Como o cliente foi cobrado...
Como foi mantido...
Como o cliente realmente queria...
Métodos de análise de documentos
Qualquer documento pode conter elementos essenciais para auxiliar na localização de novos casos de testes
e no refinamento e ampliação do esforço de planejamento.
 
Supondo o uso da orientação a objeto juntamente com a linguagem UML como padrão de documentação, as
principais fontes para extrair os casos de testes são: diagrama de estado e de atividades.
Diagrama de estado
Representa um estado ou situação em que um objeto pode se encontrar no decorrer da execução de
processos de um sistema. O objeto passará do estado inicial para o final por meio de uma transição.
 
Pense no diagrama de estado do ciclo de vida de um vídeo.
Exemplo
Cada transição de um estado para outro vídeo deverá ser considerada um caso de teste (cenário
positivo), enquanto que as transições proibidas deverão ser inseridas como cenários negativos, que
também deverão ser testadas. 
Representação do diagrama de estado:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Diagrama de atividades
Representa todo o fluxo de processamento de um determinado evento de negócio, revelando todos os
caminhos alternativos (cenários positivos) e as situações que impossibilitam a finalização desse evento
(cenários negativos).
 
Deve revelar o conjunto completo de casos de testes que precisarão ser inseridos no planejamento de testes.
 
Representação do diagrama de atividades:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Modelo de casos de uso
Casos de uso são coleções de cenários relacionados de sucesso e fracasso, que descrevem atores usando
um sistema como meio para atingir um objetivo. (Larman, 2007).
Comentário
Deve-se observar que casos de uso não são diagramas. Eles são modelados basicamente redigindo
textos. Entretanto, a UML define um diagrama para representar casos de uso. Os casos de uso são
escritos em diferentes tipos de formalidade (resumido, informal e completo), dependendo da
necessidade, mas é no modo completo que todos os passos e variantes são descritos, com
precondições e garantias de sucesso. 
O cenário de sucesso principal (ou fluxo básico) descreve o caminho de sucesso que satisfaz os interessados.
 
As extensões (ou fluxos alternativos) descrevem instruções condicionais ou desvios do cenário de sucesso.
Uma extensão é composta por uma condição e um tratamento. A condição deve ser algo que possa ser
detectado pelo sistema ou ator. O tratamento é uma sequência de passos. (Larman, 2007)
 
Os casos de uso devem ser expressos em níveis de intenções e responsabilidades, independente de
tecnologias, especialmente relacionadas à interface com o usuário. Deve-se especificar o que o sistema deve
fazer, e não como deve ser feito. (Larman, 2007)
A documentação dos casos de uso é uma excelente descrição de testes funcionais, pois já contém um
levantamento de todas as condições que podem causar falhas e os respectivos tratamentos. Pelo menos
um caso de teste é necessário para cada extensão.
Cockburn 2005.
Os casos de uso também podem ser usados como base de casos de testes e em testes de regressão. 
Booch; Rumbaugh; Jacobson, 2005.
Verificando o aprendizado
Questão 1
Baixe o software TestLink e faça um teste para alguns casos de teste que você deverá desenvolver. Faça
também uma pesquisa sobre os temas relacionados com o assunto para saber que abordagens estão sendo
utilizadas no cenário atual do desenvolvimento de software.
Chave de resposta
Organizar os casos de teste de forma clara mostra que você está desenvolvendo uma boa compreensão
do processo de testes. Caso tenha encontrado dificuldades com o TestLink, saiba que isso é normal no
início e faz parte do aprendizado prático.
Entender como os testes são realizados atualmente no mercado é fundamental. Se sua pesquisa trouxe
exemplos ou comparações entre ferramentas, isso certamente agregou valor ao seu trabalho.
Continue estudando e praticando. Aprender a utilizar ferramentas como o TestLink é um diferencial
importante para quem deseja atuar com qualidade de software e desenvolvimento.
Questão 2
No caso de teste através do método de análise de documentos, caso estejamos utilizando a orientação a
objeto em conjunto com a linguagem UML como padrão de documentação, quais as principais fontes para
extrair os casos de testes?
A Diagrama de atividades e de estado.
B Diagrama de estado e o código-fonte.
C Somente o código-fonte.
D Diagrama de atividades e o código-fonte.
E Caso deuso e diagrama de condição.
A alternativa A está correta.
Não se conseguem extrair casos de testes com os outros diagramas.
Questão 3
Na empresa, seu chefe solicitou que você elaborasse a documentação da abordagem da equipe de software
para os testes a serem realizados em uma importante aplicação web da sua empresa.
 
Essa documentação deve conter a definição do plano que descreve a estratégia global e o procedimento,
designando as etapas específicas do teste, assim como os tipos de testes que serão aplicados.
 
Nesse caso, qual documento você deverá elaborar?
A Massa de teste
B Caso de uso
C Script de teste
D Caso de teste
E Especificação de teste
A alternativa E está correta.
Neste caso, a especificação de teste é um documento que especifica um procedimento de teste com
objetivo determinado. Assim, é dada a condição de entrada e o resultado esperado após a execução do
teste.
Questão 4
Existem determinadas ferramentas que possibilitam o gerenciamento e o controle do processo de execução,
reexecução e medição dos testes automatizados e a integração entre as demais fases.
 
O objetivo dessas ferramentas é executar os testes selecionados no planejamento, tendo como principais
características: a análise de cobertura, a execução de scripts, simuladores de performance e testadores de
memória.
 
Neste caso, são classificadas como ferramentas:
A De suporte aos testes.
B De modelagem e automação.
C De revisões e inspeções.
D De planejamento de testes.
E De execução e conferência.
A alternativa E está correta.
 As outras informações não são ferramentas.
Questão 5
Existem diferentes papéis com diferentes reponsabilidades dentro de uma equipe de teste independente.
Marque a opção INCORRETA:
A Gerente de teste: responsável pela liderança de um projeto de teste específico.
B Analista de teste: responsável pela modelagem e elaboração dos casos de testes e scripts de teste.
C Arquiteto de teste: responsável pela montagem do ambiente de teste (infraestrutura) e escolha de
ferramentas.
D Testador: responsável pela execução dos casos de teste e scripts de teste.
E Product Owner: responsável pela análise dos dados de teste.
A alternativa E está correta.
Este é o único que não pode elaborar o plano de teste.
3. Teste de Aceitação
O que é um teste de aceitação?
O teste de aceitação é aquele feito para aproximar o cliente final do resultado esperado pelo sistema. Já um
teste de software é um processo sistemático que tem por objetivo identificar prováveis defeitos.
 
Para isso, verifica-se se o software realiza suas tarefas de forma correta, conforme os requisitos fornecidos
pelas partes interessadas do sistema e também se faz o que não deveria fazer.
 
Alguns conceitos que devem ser entendidos:
Defeito
Contempla um ato inconsistente realizado por um indivíduo ao tentar compreender uma informação.
Pode ser uma instrução ou um comando incorreto.
Erro
É um defeito encontrado em um artefato de software. Exemplo: diferença entre um valor obtido e um
valor esperado.
Falha
É o comportamento do software diferente do esperado pelo usuário final.
Exemplo
Exemplo de falhas: um bug gerado por um programador pode ocasionar um erro que irá gerar uma
situação de inconsistência em uma determinada funcionalidade. Lembrar a regra de 10 de Myers. 
Desenvolvimento de rotinas de teste com base no framework Cucumber e
automação com Selenium WebDriver
Ferramentas de teste automatizado de software
Um projeto de automação de software é um investimento alto e de longa duração. Os dirigentes das
organizações têm expectativas em relação a custos e aos benefícios trazidos pela sua implementação.
 
Cuidados a serem tomados:
Infraestrutura
É a disponibilidade de máquina e seus recursos. O projeto em desenvolvimento (em fase de testes)
deve ser dedicado para o projeto de automação de testes.
Metodologia
É a existência de metodologias de desenvolvimento e testes consolidadas e usadas, que possam se
integrar com a ferramenta escolhida.
Ferramenta
Selecionar a ferramenta certa, adequada à tecnologia usada e que possa se integrar com as
metodologias de desenvolvimento e teste.
Quais casos de testes são candidatos a automatização?
A cada nova versão de um software, será é necessário realizar um novo conjunto de testes, ampliando
as melhorias que foram implementadas.
 
É necessário reexecutar um conjunto de casos de testes (todos ou partes), de forma a avaliar se as
mudanças realizadas danificaram ou modificaram outras partes do software que já funcionava.
Para isso, precisamos ter a seguinte situação:
 
Preparação do ambiente.
 
Execução de testes.
 
Conferência dos testes.
 
Os testes automatizados não podem substituir os testes manuais;, eles são complementares.
Atenção
Todo caso de teste é naturalmente candidato a automação, mas com toda a certeza nem todos são
recomendáveis para a automação. 
• 
• 
• 
• 
• 
Automação com ferramenta Cucumber
A automação de testes é o processo da escrita de um programa para executar esses testes funcionais.
 
Vantagem:
 
Economia de tempo e recursos durante a execução dos testes;
 
Possibilidade de executar os mesmos testes repetidas vezes.
Por que automatizar os testes?
Por causa da qualidade final do produto, pois a execução de todos os testes funcionais que existem no
sistema garante uma menor incidência de erros e falhas no programa.
 
Os testes automatizados como Cucumber e automatizados com Selenium WebDriver, são aplicados quando
houver há tarefas repetitivas, aplicações com longos ciclos de vida e teste que devem feitos com maior
frequência.
Cucumber
O Cucumber é um framework BDD (Behavior-Driven Development ou Desenvolvimento Orientado a
Comportamento), open source, baseado em RSpec.
 
O programa executa testes de aceitação automatizado escrito em estilo de BDD. Tem um analisador de
linguagem simples chamado Gherkin, que permite que os comportamentos esperados sejam especificados em
um idioma lógico, para que os clientes possam entender.
 
Três passos para tratarmos o Cucumber:
 
Escrever uma estória e executá-la (feature);
 
Criar o arquivo de passos a partir dos snippets;
 
Dar implementação aos passos.
• 
• 
• 
• 
• 
Exemplo
O objetivo de negócio “negociação de câmbio” que contém um banco e conta bancária. Nesse exemplo,
vamos ver as funcionalidades que devemos assegurar que operem: Primeira: consiste em possibilitar que
o usuário realize as operações de câmbio utilizando sua conta, como: 1.1. Fazer saque e depósito,
considerando as seguintes restrições: 1.1.1. Só liberar o saque se o valor deste for menor ou igual ao valor
do saldo disponível na conta; 1.1.2. Só liberar o depó]sito se o valor deste for menor ou igual ao valor do
limite disponível na conta. Segunda: possibilitar o usuário a realizar operações básicas de câmbio no
banco, que são: 2.1. Obter o total de dinheiro no banco; 2.2. Obter o total de contas criadas no
banco. Para utilizar o Cucumber em nossos testes, precisamos instalar a Gem, a fim de que o programa
em Ruby possa entender o contexto e ter seus comandos reconhecidos. Como conseguir isso? Digitando
o comando 'gem install cucumber’ no Cmder e pressionar [Enter]. Ao final da instalação, uso e teste, o
cenário e passos são executados com sucesso. 
Assista ao vídeo e aprenda sobre a automatização dos testes.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Saiba mais
Veja mais no vídeo: Cucumber no site Labs Bluesoft. 
Clique aqui para visualizar todos os passos e o resultado da instalação, teste e uso do Cucumber e automação
com Selenium.
Elaborando testes de aceitação com usuário final
Assista ao vídeo e aprenda sobre as metodologias para testes de aceitação.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Os testes de aceitação fazem parte do teste de validação de alto nível. Nesses testes, os mecanismos estão
segmentados em dois níveis:
Baixo nível: Caracterizados por exigirem dos profissionais de testes um profundoSegurança;
Testabilidade;
Portabilidade.
Requisitos detalhados
Servem de base para o projeto físico e a programação. Informam como os requisitos funcionais e não
funcionais serão implementados.
Requisito de teste
Informa em algumas linhas como o requisito será testado. A partir do requisito de teste, podemos
especificar os casos de testes, que são detalhamentos do requisito de teste.
Exemplo: Continuando com o exemplo de saques na conta, para uma aplicação que permita saques
entre R$100,00 e R$ 500,00 múltiplos de 20, um requisito de teste poderia ser “realizar saques
superiores a R$ 500,00”.
Esse requisito de teste poderia gerar um caso de teste com o valor de R$520,00, cujo resultado
esperado é “saque inválido”.
Metodologias utilizadas para testes de aceitação
Fases da Metodologia MTS
Segundo Sommerville, a MTS segue o princípio do “V”. Estabelece que, para cada fase de construção no
desenvolvimento de sistemas, deve existir uma fase de teste correspondente.
• 
• 
• 
• 
• 
• 
• 
 
Aquilo que é definido nos levantamentos com o usuário será testado na fase de homologação, e o que é
especificado para os programas será testado nos testes de unidade.
 
Os testes podem, e é aconselhado que sejam, planejados e projetados antes das fases de testes: uma vez que
os requisitos estejam definidos, já podemos especificar os testes que devem ser realizados para validá-los.
 
Conectando estes dois princípios, com certeza o que é feito em uma determinada fase de construção será
testado numa fase de testes correspondente.
Comentário
O que é definido nos levantamentos com o usuário será testado na fase de homologação, e a
especificação desses testes pode ser realizada ainda na fase de levantamento. 
Como a MTS define cada uma das fases de testes?
Fase de teste de unidade
Através de testes caixa preta e caixa branca, fazemos a verificação de um componente de software
para saber se o sistema satisfaz os requisitos detalhados especificados.
Fase de teste de integração
Através de testes caixa preta e caixa branca, fazemos a verificação das interfaces entre componentes
de um software, para saber se o sistema satisfaz aos requisitos detalhados especificados.
Fase de teste de sistema
Nesta fase, é considerado um sistema integrado de hardware e software para verificar se o sistema
satisfaz os requisitos de usuário, funcionais e não funcionais especificados.
Fase de teste de homologação
Fase executada pelos usuários, na qual são verificados os requisitos de usuário e funcionais
referentes aos critérios de aceitação para permitir ao cliente determinar se aceita o sistema ou não.
Fase de teste de implantação
Nesta fase, são verificados os requisitos de negócio.
Se, com a implantação do sistema, as vendas cresceram em 30%; se a agilização de um determinado
processo foi alcançada.
Verificam-se também todos os requisitos referentes à diminuição do risco de solução de continuidade
do negócio devido à implantação do sistema.
Para facilitar o teste, devemos fazer um checklist dos requisitos especificados inicialmente.
BDD - Behavior Driven Development (Desenvolvimento
Orientado por Comportamento)
Assista ao vídeo e aprenda análise de cenários em BDD.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Metodologias de desenvolvimento
Vejamos algumas: o TDD (Test Driven Development) e o BDD (Behaviour Driven Development).
O TDD é uma abordagem de desenvolvimento de software em que os testes direcionam a implementação do
software. O desenvolvimento deve ser guiado a testes, e um teste unitário deve ser escrito antes que uma
funcionalidade do sistema o seja.
 
O objetivo desta metodologia é fazer com que o teste passe com sucesso, significando que assim a
funcionalidade está pronta e conta com garantia de qualidade. Favorece o design de software e expressa o
comportamento do código.
 
O BDD tem uma abordagem no estilo TDD. A documentação é executável, melhora o desempenho dos times e
pode ser utilizada por todos os envolvidos no projeto.
 
No BDD, o desenvolvimento deve ser guiado aos comportamentos que o sistema deve apresentar. Desta
forma, um comportamento (requisito/ especificação) é priorizado em relação ao teste unitário, o que não
exclui a execução do fluxo do TDD neste processo.
 
O Behavior Driven Development (BDD) não é uma metodologia de desenvolvimento de software, nem
tampouco um substituto para as metodologias XP, Scrum, Kanban, OpenUP, RUP ou qualquer metodologia que
o mercado atualmente oferece.
 
Na realidade, o BDD incorpora e melhora as ideias de muitas dessas metodologias, ajudando, melhorando e
tornando a vida da equipe de software mais fácil.
Princípios do BDD
O bastante é o bastante
Trabalhar para atingir as expectativas das partes interessadas, mas evitar fazer mais do que o
necessário.
 
Entregar valor às partes interessadas
Se estivermos fazendo algo que não entrega valor ou não aumenta a sua habilidade de entrega de
valor, é melhor parar e fazer outra coisa.
 
Tudo é sobre o comportamento
Assim como podemos descrever o comportamento a partir da perspectiva das partes interessadas,
também podemos descrever o comportamento de um código a partir de outro código que o utiliza.
Como é o ciclo do BDD?
1. Partes interessadas discutem os requisitos:
 
Os requisitos são organizados em funcionalidades;
 
Podem ser quebrados em estórias;
 
Fazem sentido para as partes interessadas.
 
2. Partes interessadas, analista e testador determinam o escopo das estórias (narrativo):
 
O analista pensa na funcionalidade de uma forma geral;
 
O testador pensa em cenários concretos, com valores de entrada e saída.
 
3. Os cenários prioritários são identificados:
 
As partes interessadas especificam exatamente o que quer que seja entregue;
 
Os desenvolvedores implantam o bastante para satisfazer os cenários e nada mais. 
 
4. Por último, os desenvolvedores
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
 
Automatizam os cenários que orientam o desenvolvimento;
 
Descrevem o comportamento esperado;
 
Implantam os comportamentos.
Funcionamento do BDD
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Exemplo:
 
Vamos explicar usando o seguinte exemplo: uma equipe praticante de BDD decide implementar uma nova
funcionalidade. Para isso, eles trabalham em conjunto com os usuários e outras partes interessadas para
definir as histórias e cenários do que os usuários esperam dessa funcionalidade.
 
Os usuários ajudam a definir um conjunto de exemplos concretos que ilustram resultados que a nova
funcionalidade deve fornecer.
 
Esses exemplos devem ser criados utilizando um vocabulário simples para ser facilmente compreendidos
pelos usuários finais e membros da equipe de desenvolvimento de software.
 
São expressos usando: cenário (scenario), dado (given), quando (when) e então (then).
 
Com base no BDD, a equipe identificou e especificou o objetivo de negócio, definido com um exemplo
concreto.
 
Como fica no nosso exemplo de saldo de conta:
 
Cenário: transferir dinheiro para uma conta poupança;
• 
• 
• 
• 
 
Dado que eu tenho uma conta corrente com 2.000.00;
 
E que eu tenho uma conta de poupança com 3.000,00;
 
Quando eu transferir 1.000,00 a partir de minha conta corrente para a minha conta poupança;
 
Então eu deveria ter 1.000,00 em minha conta corrente;
 
E eu deveria ter 4.000,00 em minha conta poupança.
 
Depois de especificada a nova funcionalidade, sempre que possível estes exemplos concretos serão
automatizados sob a forma de especificações executáveis, que tanto validam o software quanto fornecem
uma documentação atualizada, tanto técnica quanto funcional.
Verificando o aprendizado
Questão 1
Nos testes de validação, os mecanismos de testes estão segmentados em dois níveis distintos de testes de
baixo nível e de alto nível. Assinale a ÚNICA opção que apresenta os 2 testes de alto nível:
A Teste de sistema e teste de aceitação.
B Teste da caixa branca eCucumber
	Exemplo
	Conteúdo interativo
	Saiba mais
	Elaborando testes de aceitação com usuário final
	Conteúdo interativo
	Teste de aceitação formal
	Teste de aceitação informal
	Teste beta
	Conteúdo interativo
	Relacionando requisitos a expectativas de teste
	Estratégia de teste
	Atenção
	Exemplo
	Testes baseados em requisitos
	Requisitos de negócio
	Requisitos de usuário
	Requisitos funcionais
	Requisitos não funcionais
	Requisitos detalhados
	Requisito de teste
	Metodologias utilizadas para testes de aceitação
	Fases da Metodologia MTS
	Comentário
	Fase de teste de unidade
	Fase de teste de integração
	Fase de teste de sistema
	Fase de teste de homologação
	Fase de teste de implantação
	BDD - Behavior Driven Development (Desenvolvimento Orientado por Comportamento)
	Conteúdo interativo
	Metodologias de desenvolvimento
	Princípios do BDD
	Como é o ciclo do BDD?
	Funcionamento do BDD
	Conteúdo interativo
	Verificando o aprendizado
	4. Conclusão
	Considerações finais
	Explore +
	Referências