Teste de Software – Testes Manuais

Hoje chamado de ‘Teste Humanizado’, o teste funcional

manual está voltando a ter a atenção das equipes de teste. Visto
que o software e todo o negócio é agora voltado para o ‘foco no
cliente’, um robô, somente, não atende as expectativas dos
nossos usuários.
Então, este livro está focado no ‘teste nosso de cada dia’, os
testes manuais (caixa preta) de uma forma direta e
descomplicada.
          
                                 Sejam todos bem-vindos!
 Teste de Software – Testes Manuais

O que é Teste de Software?

Por que o Teste é Importante?

Metodologias – Cascata, Ágil, BDD

Processo de Teste.

Perfil do Analista de Teste no método Ágil.

Técnicas e Tipos de Teste.

Gestão de Defeitos / Relatar Bug.

Roteiro de Teste Funcional – Precondição, Passo e Resultado esperado

e a estrutura GHERKIN – Dado, Quando, Então.
 Dedico este livro ao Criador por ter norteado meus caminhos e
dado capacidade para o que eu não poderia fazer sozinha. Dedico
para as pessoas queridas que confiaram, torceram e trabalharam
direta ou indiretamente para que eu pudesse crescer.
 Sumário
Lista de Figuras
INTRODUÇÃO
Teste de Software
Regra 10 de Myers
O termo BUG
O que é Teste de Software?
Por que o teste é importante?
Quando deve ser iniciado o Teste?
O mito do “Testar é Fácil”
Carreira na área de Teste de Software
Conhecimentos técnicos e gerenciais do analista de teste
Conhecimentos Técnicos:
Conhecimentos Gerenciais:
Processo de Desenvolvimento de Software
Fases do Processo de Desenvolvimento do Software
Iniciação
Elaboração
Construção
Finalização
Metodologias de Desenvolvimento de Software
Cascata
Prototipação
Tipos de Prototipação
Fidelidade dos Protótipos
Scrum - Metodologia Ágil
Como é o SCRUM:
Cinco principais práticas do Scrum:
Quadro KANBAN
Perfil do Analista de Teste no Método ágil
Metodologia BDD
Processo de Teste
Capacitação da Equipe de Teste
Organograma da equipe de teste
Melhoria do Processo de Teste
CMMI
 CMMI Representação Contínua
CMMI Representação por Estágios
Risco no Processo de Teste
Gestão de Risco
Fases da Gestão de Risco:
Técnicas de Teste, Tipos de Teste e Níveis de Teste
Massa de Dados
Níveis de Teste – Quando Testar?
Caixa Branca – Teste Estrutural
O que é Automação de Teste?
O que deve ser automatizado?
Tipos de teste Caixa Branca
Caixa Preta – Teste Funcional
Tipos de Teste Caixa Preta
Usabilidade
Layout
Ortografia
Funcionalidade
Requisitos
Caixa Cinza
Gestão, Classificação e Priorização de Bugs
Quando um bug pode ser detectado?
Gestão de Defeitos
Elementos da Gestão de Defeitos
Prevenção
Identificação
Solução
Melhoria do Processo
Relatório de Gestão
Ciclo de Vida de um defeito
Ferramenta Mantis
Métricas de Teste
Como não medir:
Relacionamento entre os indicadores
Como obter qualidade no Teste de Software
Artefatos elaborados pela Equipe de teste
Artefatos produzidos pela Equipe de Teste:
Check List de Entrada de Artefatos
 Plano de Teste
Roteiro de Teste Funcional
Relato de Erro
Sumário de Teste
Controle de Atividades
Equipe bem treinada e valorizada faz a diferença
O resultado final depende da capacitação da equipe
Equipe de teste motivada - trabalho de excelência
Conclusão
Fixação do Conteúdo
Templates
Template - Plano de Teste:
Template - Roteiro de Teste Funcional:
Roteiro de teste - Gherkin
Exemplo de passo a passo Gherkin
Template - Sumário de teste:
Relatar Erros:
Excel
Word
Glossário e Conceitos
Referências Bibliográficas
 Lista de Figuras
Figura 1 – Representação da Regra 10 de Myers
Figura 2 – Representação da Metodologia Cascata
Figura 3 – Representação dos Passos da Prototipação
Figura 4 – Representação do quadro Kanban
Figura 5 – Representação de um modelo de Processo de Teste
Figura 6 – Representação do Organograma de uma Equipe de Teste
Figura 7 – Representação do Ciclo da Gestão de Defeitos na visão
do PMI
Figura 8 – Pacotes/Módulos do projeto
Figura 9 – Representação da visão do Teste de Sistema
Figura 10 – Teste Manual de Ortografia
Figura 11 – Teste de Requisitos
Figura 12 – Representação do Ciclo de Vida de um Defeito
Figura 13 – Tela inicial – Mantis
Figura 14 – Tela Minha Visão – Mantis
Figura 15 – Tela Relatar Caso – Selecionar Projeto – Mantis
Figura 16 – Tela Relatar Caso – Mantis

Figura 17 – Tabela de Relacionamento entre Indicadores

Figura 18 – Processo BDD

 
 INTRODUÇÃO
Testes Manuais – Teste da técnica Caixa Preta, são aqueles que
validam as Regras Negociais, os padrões de Tela, as Mensagens do
sistema, Formato, Tipo, Tamanho e características de campos, uso de
Hints e Ajuda, Padrão de Cores especificados pelo cliente, Ortografia,
etc. Testes manuais são aqueles que nós, Analistas de Teste, fazemos
antes que o sistema seja implantado para o cliente. Vamos ver aqui
todos os tipos de validações manuais com ênfase na importância, na
necessidade e na relevância deste tipo de validação de sistema.
E o Teste automatizado?
Testes automatizados não são apenas clicar em um play, deve-se
investir em infraestrutura, servidores potentes, treinamentos, pagamento
da licença de uso da ferramenta (se for o caso), manutenção da
ferramenta para adaptação ao sistema da empresa, enfim, os
investimentos para testes automatizados são demasiadamente grandes
para que, apenas por capricho, sejam feitos scripts que não serão
reaproveitados para sistemas que não precisariam deste recurso. 
Testes automatizados, além de investimento, é preciso escopo para ser
realizado. Não se automatiza caminhos condicionais e exceções. Testes
automatizados não substituirão os testes manuais, até mesmo por que,
testes automatizados não conseguem avaliar ‘expectativa do cliente’. O
mais importante: Um tipo de teste não anulará o outro. Os tipos de teste
se complementam, sempre.
 Teste de Software
Em 1979 Glenford Myers publicou o livro The art of software
testing falando sobre teste de software e uma coletânea de matérias
sobre teste. É considerado como o marco do Teste de Software.
Inclusive, dia 20 de fevereiro é considerado o ‘Dia do Teste’ em
referência ao lançamento do primeiro livro que trouxe a expressão Teste
de Software e nomeou nossa área e profissão. Este livro estabeleceu
conceitos que ainda usamos, entre eles, Classes de Equivalências e
Valores Limites. Myers fez uma análise sobre o custo da correção e o
tempo em que um defeito (Bug) é encontrado, a Regra 10 de Myers
continua sendo usada.
 Regra 10 de Myers
Esta regra mostra a visão da redução de custo com o teste. A
regra diz que, o custo da correção dos erros cresce 10 vezes para cada
estágio em que o projeto avança. Logo, quanto mais cedo iniciamos o
teste, mais barato será a correção do defeito encontrado.
Vamos ver a seguir um gráfico que mostra como o pensamento
de Myers demonstra que, quanto mais tarde encontrarmos os defeitos,
mais caros eles serão.

Figura 1 – Regra 10 de Myers

 

Fonte: Elaborada pela Autora

 O termo BUG
Há divergências quanto ao surgimento deste termo. Uns atribuem
a Grace Hopper, que não conseguia saber qual problema do Harvard
Mark II, um computador de última geração da época que ocupava uma
sala inteira. Depois de procurar, a cientista descobriu que o problema
era uma mariposa que atraída pelas luzes ficou presa entre uma das
peças da máquina causando o defeito.
Há quem diga que foi um termo inventado por Thomas Edison
quando um inseto causou problemas em seu fonógrafo, em 1878.
Mas, o que importa para nós é que Bug são os defeitos
encontrados no software que estamos testando.
 O que é Teste de Software?
Qualidade é uma área ampla da Engenharia de Software que
garante a qualidade do produto através da normatização de processos
de desenvolvimento. O processo de desenvolvimento norteia como um
software será construído. O desenvolvimento envolve várias áreas
como: Requisitos, Banco de Dados, Desenvolvimento (Codificação),
Teste de Software e Encerramento do Projeto. Neste livro, focaremos
apenas na disciplina de Teste de Software.
Teste de Software é um processo normatizado que usa técnicas
de execução de sistema para encontrar defeitos antes que este seja
entregue ao cliente – usuário final. Estas técnicas combinadas e a
expertise do Analista de Teste aumenta a confiabilidade do usuário no
software, pois, este tem a garantia de que o sistema foi validado quanto
as regras negociais e o atendimento de suas expectativas.
Os Analistas de Testes exploram as falhas de um sistema e
tentam, através de combinações incorretas expor as vulnerabilidades do
software. Por estas características das atividades de teste, dizemos que
ela tem a natureza ‘destrutiva’. Aumenta a segurança e confiabilidade do
sistema através da apresentação dos seus defeitos.
 Por que o teste é importante?
Vimos anteriormente, com a regra 10 de Myers, que o custo da
correção aumenta à medida que as fases do projeto avançam. Então,
sabemos que o custo de um defeito é muito menor se encontrado ainda
na fase de levantamento de requisitos, quando os artefatos ainda estão
sendo elaborados e homologados. Quando os defeitos são encontrados
pelos desenvolvedores, na fase de codificação, o custo aumenta, mas
ainda estamos em fase de construção e estes defeitos não afetarão
tanto o prazo e o custo do projeto. Na fase de Teste de Software, os
defeitos custam um pouco mais, mas, ainda sem prejuízos. É aqui que
validamos os documentos RN – Regras de Negócio, MSG – Documento
de Mensagem, Documento de Design com os padrões de tela, campos,
cores, disposição de tabelas, formas de resultados, uso de hints, etc, e
as ECU – Especificação de Caso de Uso.
Então, vamos listar os benefícios do teste para os sistemas:

Economia – Defeitos encontrados antes do sistema ser implantado.

Custo de correção mais barato.
Negócio – A certeza de que o negócio foi validado e que o sistema
atenderá ao usuário.
Segurança – Validação de perfis, acesso, apresentação de relatórios
específicos.
Confiança – Aumento da confiabilidade no sistema com a certeza de
que ele foi devidamente testado antes da entrega ao usuário.

Qualidade – Aumento da qualidade do sistema pois este foi

forçado a dar respostas para situações inesperadas, validando
condições limites e os documentos do projeto.

Concluímos aqui que nenhum sistema pode ser entregue sem

teste. Por menor que seja, é preciso que este seja validado por um
profissional capacitado para evitar que bugs sejam encontrados pelos
usuários causando não apenas mal-estar entre empresa e cliente, mas,
evitando multas e retrabalho. É de suma importância que os softwares
passem pela mão do especialista em teste antes que este seja
implantado, para que as possibilidades de erros sejam mapeadas e
evitadas.
 Quando deve ser iniciado o Teste?
O ideal é que o Teste esteja desde o princípio do projeto, com a
verificação dos artefatos de requisitos, para que a contribuição da
equipe seja desde o início, evitando que possíveis defeitos passem para
outras fases do projeto. As metodologias que deixam o teste para o final,
correm grande risco de atraso e até de baixa qualidade no teste, pois,
prazo, sempre foi um problema na área de TI e, deixar todas as
avaliações para o fim pode acarretar grande número de bugs, vários
ciclos de teste e correções, fazendo com que o atraso seja inevitável. Ao
deixar o tempo de teste reduzido, a qualidade fica comprometida e os
benefícios do teste são afetados. É preciso ter uma boa gestão para que
as fases se complementem e não se atropelem. Prejudicar o tempo de
teste faz com que os sistemas sejam implantados ainda com defeitos,
ou, em uma situação calamitosa, sem nenhum ciclo de teste.

O mito do “Testar é Fácil”

Algumas pessoas têm uma ideia distorcida sobre testar. O uso do

sistema sem técnica e sem ‘procura de falhas’ não pode ser descrito
como teste. Antes da visão sobre a necessidade de um especialista para
validar o software antes da entrega para o usuário final os próprios
desenvolvedores testavam o software, sem a visão do usuário, com
ferramentas de teste unitário. Ou então, funcionários de outros setores
que estivessem com pouca demanda recebiam a ‘tarefa’ de usar o
sistema e falar se iria acontecer alguma coisa errada. Altos índices de
insatisfação, multas, cancelamentos de contratos, devoluções de
software e muito, muito retrabalho mudou esta situação.
Para efetuar o teste é necessário um especialista, focado em
achar falhas, em validar as regras de negócio, em entender a
necessidade do usuário e a melhor forma de utilização de um sistema. É
preciso inteligência, minuciosidade, curiosidade, proatividade, boa
redação, conhecimento avançado na língua em que o sistema foi
desenvolvido, saber se expressar corretamente, abstração e
abrangência sobre as falhas do sistema, etc. Testar não é uma tarefa
fácil, e nem corriqueira que qualquer um possa fazer.
 Carreira na área de Teste de Software
A pior coisa para um segmento é ele ser visto como ‘passagem’.
Por algum tempo, a equipe de teste foi vista como uma ‘porta de
entrada’ para a Fábrica de Software e o mundo da TI. O objetivo era ser
programador, analista de requisitos, gerente de projetos, DBA, arquiteto
de softwares e afins. Um prejuízo muito grande para a equipe, por dois
motivos: Primeiro, a pessoa pode estar tão engajada em aprender a
área que almeja que não fará seu trabalho com a dedicação que é
necessária. Segundo o colaborador é dedicado, aprende, mas, não
permanece, pois, o objetivo a ser alcançado era outro e após processos
seletivos ele consegue mudar de área.
E a equipe de teste? Fica sempre com novatos, estagiários ou
trainees? Se isso acontecer a equipe ficará sempre sem um
especialista, sem o analista que após a experiência resolve problemas e
propõe soluções e melhorias.
O analista de teste não é aquele que não deu certo como
programador ou em qualquer outra área. O analista de teste é quem tem
aptidão e o perfil para atuar nesta área tão importante, que é, o último
estágio entre a empresa e o usuário final.
 Conhecimentos técnicos e gerenciais do analista de
teste

É preciso que o analista de teste tenha aptidões específicas para

que atue com excelência no seu trabalho, vamos definir algumas delas.
 Conhecimentos Técnicos:
Princípios da Engenharia de Software;

Conhecimentos em Redes de Computadores;

Conhecimentos em Banco de Dados;

Conhecimentos em Sistemas Operacionais;

Conhecimentos em Gestão de Configuração de Mudança;

Conhecimentos em Análise e Métricas de Teste;

Conhecimentos em Análise de Requisitos e os artefatos gerados

Qualidade de Software.

Esses conhecimentos são necessários para que o analista saiba

identificar os bugs, saber a quem recorrer após uma falha, informar
estimativas de prazo e qualidade do sistema. É necessário que este
profissional saiba um pouco sobre os princípios de todas as áreas para
entender nomenclaturas, participar de reuniões e verificar documentos
caso seja necessário.
 Conhecimentos Gerenciais:
Organização;

Planejamento;

Motivação;

Trabalho em equipe e com cliente/usuários;

Boa comunicação;

Resolução de Conflitos.
 Processo de Desenvolvimento de Software
É um processo organizado que norteia o desenvolvimento do
software desde a fase de levantamento de requisitos até a fase final de
entrega. Este processo é chamado também de Ciclo de Vida de
Desenvolvimento de Software. As fases desse processo veremos a
seguir.
Fases do Processo de Desenvolvimento do
Software
 Iniciação
Define o escopo do Software – reuniões com cliente e venda do
sistema.
 Elaboração
Definição de qual metodologia será usada para o desenvolvimento
do sistema, levantamento de requisitos e elaboração destes, definição
de arquitetura, banco de dados, cronogramas e etc.
 Construção
Nesta fase é construído o sistema: desenvolvimento e teste de
software. É criada uma versão homologável para entrega.
 Finalização
Aqui temos uma versão para implantação e o teste de Aceitação feito
pelo cliente.
 Metodologias de Desenvolvimento de Software
Metodologias são os passos que descrevem como um software
será desenvolvido. São vários tipos de metodologias. Veremos a seguir
três tipos: Modelo Cascata, Modelo Prototipação e Scrum – Metodologia
Ágil de Desenvolvimento de Software.
 Cascata
Modelo em que cada fase só se inicia após a anterior ser
completamente finalizada. É necessário para esse tipo de metodologia
requisitos abrangentes e estáveis, quando a duração do projeto é
pequena (até dois anos, ao menos). O sistema é entregue todo, de uma
só vez. Os passos estão na representação abaixo

Figura 2 – Representação da Metodologia Cascata

 

Fonte: Elaborada pela Autora.

Neste processo, pode acarretar muitos atrasos e problemas, pois,

caso haja divergência ou alterações, o processo terá que passar fase a
fase até que retorne e seja feito outro ciclo de teste. Essa burocracia,
digamos assim, faz com que essa metodologia não tenha sucesso em
caso de instabilidade da documentação ou sucessivas alterações de
escopo.
 Prototipação
É uma representação visual do produto que está sendo
desenvolvido. É um conteúdo que possui, geralmente, os mesmos
materiais do produto final e traz os mecanismos necessários para o
fazer funcionar.
 
Toda a ideia que envolve a prototipação está voltada para o tempo e
o custo de desenvolver algo que possa ser testado pelos usuários.
 Tipos de Prototipação
Horizontal – Exibe a interface do usuário sem ter o foco nas
funcionalidades por trás dos botões – demonstra superficialmente toda a
interface.
Vertical – Foco nas funcionalidades do sistema. Possui poucas
tarefas, mas funcionalmente aprofundadas. Permite testar uma pequena
parte do sistema.
 Fidelidade dos Protótipos
Alta fidelidade – tem muita proximidade com a interface final do
sistema.
Baixa Fidelidade – Envolve a utilização de materiais que estão mais
distantes da versão final do sistema. É uma representação artística que
omite detalhes do produto real.
Passos da Prototipação

Figura Passos da Prototipação - Fonte: Elaborada pela autora.

 Este modelo de desenvolvimento apresenta vantagens e atrativos
que não estão nas demais metodologias de construção de software.
Algumas vantagens são:
 
Redução das divergências entre usuários e
desenvolvedores.
Serviços esquecidos podem ser detectados.
Serviços confusos podem ser identificados.
Um sistema funcional está disponível nos primeiros estágios
do desenvolvimento.
O protótipo pode ser usado para treinamento do usuário.
Aproximação do sistema com as necessidades do usuário.
Melhoria da qualidade do projeto.
Facilidade de manutenção.
Redução no esforço de desenvolvimento.
 Scrum - Metodologia Ágil
As metodologias tradicionais trazem consigo alguns problemas
que é preciso eliminar hoje em dia. Um deles é o tempo de entrega. O
cliente não quer mais esperar 2 anos para ver seu sistema funcionando
ou só no final saber como a construção foi feita. Documentações
extensas, processos burocráticos e projetos gigantes não estão mais em
alta no mercado de sistemas da informação.

​ termo metodologias ágeis tornou-se popular em 2001, quando 17

O
especialistas em processo de desenvolvimento de software,
estabeleceram princípios comuns compartilhados por todos esses
métodos. O resultado foi a criação da Aliança Ágil e o estabelecimento
do Manifesto Ágil.

O foco no desenvolvimento e nas entregas conquistam cada vez

mais espaço nas fábricas de softwares. A metodologia ágil transformou
a forma de desenvolvimento. A documentação não tem o valor que as
metodologias tradicionais dão, o que importa é o time. Pessoas e
conhecimento é o centro da MA (Metodologia Ágil).
 A facilidade de se moldar as situações é outro diferencial. Como
não há um processo longo e alterações documentais adaptar-se as
mudanças de escopo é fácil, rápida e indolor. É preciso que o time seja
maduro para que as informações, ainda que não documentadas
formalmente com templates e palavras chaves obrigatórias, sejam
retidas na empresa e que não se percam após a entrega dos módulos e
a finalização do projeto.
 Como é o SCRUM:
✓      Entregas intermediárias.
✓      Gerenciar riscos em projetos de desenvolvimento.
✓      Não esconder riscos.
 Cinco principais práticas do Scrum:
✓      Clientes devem se tornar parte do time de desenvolvimento.
✓      Devem existir entregas intermediarias frequentes.
✓           O time de desenvolvimento deve estar alerta aos riscos do
projeto e desenvolver ações de tratamento aos riscos.
✓       Não esconder problemas e riscos (atrasos, dependência de
outro setor/profissional, etc.).
✓       Transparência no planejamento e no desenvolvimento da
Sprint.
 Quadro KANBAN
O quadro KANBAN norteia as atividades da equipe Scrum. Nele
estão as tarefas que devem ser feitas na Sprint na coluna ‘Aguardando’.
As atividades em andamento são aquelas que ainda estão sendo
executadas. Na coluna ‘Finalizado’ estão as tasks que foram terminadas
por seu responsável.
Uma das grandes questões é: Quando uma tarefa foi finalizada?
Quando o desenvolvedor terminou de construir ou quando terminou de
testar? Afinal, após o teste é preciso fazer o merge, a build e o
desenvolvedor participa dessas etapas. A definição varia de equipe para
equipe. Algumas consideram que o fim é quando está em produção e
outras que só termina após o teste ser realizado, e para isso criam
tarefas para o merge, para correção de bugs, para implantação e etc.

Exemplo do quadro KANBAN:

Figura 4 – Representação do quadro Kanban

Fonte: Elaborada pela autora
 Perfil do Analista de Teste no Método ágil
O analista de teste em uma equipe ágil deixa de ter o perfil
preventivo – receber documentos e neles encontrar os defeitos após
tudo construído – e passa a ter o perfil reativo – procurar as definições,
ser pró ativo, juntar-se ao time durante as reuniões de definição de
escopo e trabalho em conjunto com os desenvolvedores e analistas.
É preciso que o profissional seja organizado para manter a
rastreabilidade do seu trabalho e guardar informações importantes sobre
os projetos que trabalhou. É necessário que, de uma maneira ágil, o
analista de teste faça a gestão do teste, dos defeitos encontrados, das
correções – nas datas de correção, do reteste e ainda fazer um relato de
erro que os desenvolvedores tenham compreensão do bug encontrado e
consigam reproduzi-lo com eficiência.
Não é uma tarefa fácil mudar de paradigmas e não ter mais as
informações do projeto a mão, mas correr atrás delas com os clientes e
analistas. É preciso haver uma mudança de conceitos e ter a
consciência de que o trabalho é importante e deve ser feito com
excelência.
Por causa da falta de ‘cobrança’ em documentos, o testador pode
ficar acomodado e não manter as informações corretamente ou deixar
de realizar a gestão do teste e das evidências encontradas.
É muito importante que, independente da cobrança, o analista de
teste saiba qual o objetivo da sua função. É importante fazer
corretamente a gestão dos defeitos – classificar, categorizar, nomear,
evidenciar, informar datas de teste e reteste, etc. Mesmo que não tenha
uma ferramenta para essa gestão ou não haja necessidade imposta pela
empresa nesses dados, eles são de fato, o resultado do nosso trabalho
e independente do regime ou metodologia devemos mantê-los durante a
vida útil do projeto/sistema.
 Metodologia BDD
O BDD é uma metodologia de desenvolvimento ágil, que envolve não
somente o analista de teste, mas todos os membros da equipe. ​
O que o BDD propõe, é que assim que o analista de negócio entende
o que precisa ser implementado, que ele se reúna com o desenvolvedor
e o QA para discutirem sobre a funcionalidade proposta.

O BDD funciona de maneira mais ampla. Enquanto o TDD está

focado na fase de desenvolvimento, o BDD é aplicado de ponta a ponta
no processo de construção do software, abrangendo todas as fases.
​A alma do BDD está em conversas e alinhamentos constantes e
entendimento compartilhado entre todos os membros do time. No
processo de BDD consta as seguintes fases: Descoberta, Definição,
Formalização e Entrega Como vemos na imagem abaixo:

Figura 18 – Processo

Fonte: Elaborada pela autora.

 Processo de Teste
O processo de teste está dentro do processo de desenvolvimento
do software. Como uma equipe independente temos nosso processo
definido e artefatos próprios.
O processo se inicia com o recebimento de um novo projeto na
equipe, pelo Líder de Teste, onde este avaliará os artefatos enviados
pela equipe de requisitos e criará o artefato – Plano de Teste. Este Plano
de Teste traz consigo informações sobre o escopo do projeto, os
responsáveis pelas fases do projeto dentro do processo de teste, os
módulos que serão executados, as horas gastas para elaboração dos
artefatos e da execução do teste, os tipos de teste que serão realizados
de acordo com a necessidade do cliente.
 Após a primeira fase de análise de artefatos e aprovação pelo
líder, o Analista de Teste irá traduzir os artefatos da equipe de
Requisitos no artefato chamado Roteiro de Teste Funcional. Documento
que é dividido em fluxos, para cada Especificação de Caso de Uso é
elaborado um RTF e ele traz os casos de teste para execução.
Composto por Pré-Condição, Passo a Passo, Resultado Esperado e
Resultado do teste, o RTF não é uma cópia do ECU, mas, é um
documento que sozinho, pode ser usado para validar o sistema em sua
completude – Mensagens, Regras, Padrões e Exceções. Fora deste
escopo é preciso a expertise do Executor de Teste para que a qualidade
do sistema seja garantida

Na fase de Execução, todas as etapas convergem para que o

teste seja bem-sucedido. Não adianta ótimas documentações se o teste
efetivamente não for realizado com excelência. O responsável pela
execução do teste usará o RTF para validar os itens documentados e,
sua expertise entrará em ação para ir além e, através do seu olho
crítico, levar o sistema ao limite e validar mais do que o documentado.
Além da validação, outra tarefa importante é o Relato de Bug. O Bugs
devem ser relatados de forma clara e objetiva para que o desenvolvedor
possa entender e corrigir efetivamente o problema. Ele deve ser bem
escrito e evidenciado com as respectivas telas incorretas.

Exemplo de um Processo de Teste simples:

F

igura 5 – Representação de um modelo de Processo de Teste

Fonte: Elaborada pela autora
 Capacitação da Equipe de Teste
Durante muito tempo considerou-se que qualquer um exercia a
atividade de teste. No princípio os desenvolvedores testavam
rapidamente seu código e isso bastava. Após um tempo algumas
pessoas aleatórias eram escolhidas para ‘ver como estava o sistema’.
Cada dia mais essa necessidade de seriedade no Teste foi aumentando
e com isso a capacitação das pessoas que trabalhavam nesta área foi
requerida. O entendimento dos artefatos produzidos pelas outras
disciplinas só pode ser concebido por alguém da área de TI e que esteja
engajado no trabalho que está realizando. Teste não é uma tarefa fácil.
Teste é uma tarefa que requer disciplina, crítica, minuciosidade,
disposição, leitura e entendimento de vários artefatos, concentração,
dentre outras características que fazem com que a capacitação seja
indispensável.
Para realizar a execução do teste é preciso saber das técnicas e
ir além. É preciso curiosidade para fazer com que o sistema seja levado
além do que está especificado. É inaceitável hoje pessoas
desqualificadas atuarem nesta disciplina tão importante que é o último
estágio entre a empresa desenvolvedora e o usuário final. Não é mais
concebível que profissionais medianos usem esta disciplina como ‘porta
de entrada’ na área de Tecnologia e que, enquanto estão na equipe,
estão se capacitando para outras carreiras. A área de Teste de Software
precisa de dedicação constante para que o processo de qualidade seja
executado com excelência.
 Organograma da equipe de teste
Os perfis das equipes de teste vão variar de acordo com as
empresas. Há empresas que contratam Analistas de Teste que cuidam
de todo o processo. Há fábricas que precisam de perfis separados para
que deem vazão no alto fluxo de demandas. Então os perfis vão variar
de acordo com o tamanho da equipe, o tamanho do projeto, a
necessidade da empresa, etc.
Num organograma de uma Fábrica de Teste, com alta demanda
de trabalho e vários clientes para Teste de Software temos:

Figura 6 – Representação do Organograma de uma Equipe de Teste

Fonte: Elaborada pela autora

 Melhoria do Processo de Teste
Como vimos, processo é um passo a passo sistemático para
desenvolvimento de um produto. Todo processo estabelecido precisa ser
avaliado e melhorado para atender a novas demandas de projeto que
surgem a cada dia. No processo de teste essas avaliações e medições
servem para atestar a eficácia do teste, o que está sendo coletado como
métrica – se é relevante para o projeto, se o teste em si está sendo
colaborativo para o projeto como um todo, se as medidas tomadas
através dos dados obtidos pelo teste estão apresentando o resultado
esperado, etc.
Há diversos modelos de melhoria de processo, TMM, CTP, STEP,
TPI, mas, o mais conhecido é o CMMI, e é este modelo que vamos falar
a seguir.
 CMMI
CMMI - O  CMMI  (Capability Maturity Model Integration) é um
modelo de referência que contém práticas que são necessárias à
maturidade em disciplinas específicas.
O SEI -Software Engineering Institute - da Universidade Carnegie
Mellon desenvolveu o CMMI que é uma evolução do  CMM  e traz um
modelo único para o processo de melhoria, integrando diferentes
modelos e disciplinas. O CMMI foi baseado nas melhores práticas para
desenvolver e manter produtos.
O CMMI possui duas representações: "contínua" ou "por
estágios". Estas representações permitem à organização utilizar
diferentes caminhos para a melhoria de acordo com seu interesse. 
 CMMI Representação Contínua
Nesta representação temos os níveis que devem ser alcançados
pela empresa (Capability Levels):

Nível 0: Incompleto (Ad-hoc)

Nível 1: Executado
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Gerenciado Quantitativamente (Quantitatively managed)
Nível 5: Otimizado (Optimizing)
A capacidade é medida por processos separados, e aqui é possível
ter um processo no nível 3 e outro no nível 5, isso varia de acordo com
os interesses da empresa.

Explicando os Níveis
01 -   O processo apenas completa o trabalho.
02 - Planejamento da execução e confronto do resultado com o que
foi planejado.
03 - Constrói-se diretrizes do processo que existe e estas são
documentadas formalmente.
04 - O processo é gerido quantitativamente através de relatórios,
estatísticas e técnicas adotadas pela empresa.
05 - O processo é norteado pela qualidade do que foi implantado e é
alterado e adaptado para atender às necessidades
negociais/estratégicas da empresa.
 CMMI Representação por Estágios
Nesta representação são avaliados os níveis de maturidade em
uma sequência pré-determinada e cada uma deve ser considerada, pois
serve de base para os próximos níveis (Maturity Levels):
Nível 1: Inicial (Ad-hoc)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Gerido quantitativamente
Nível 5: Em otimização
​Aqui a maturidade é organizada por um conjunto de processos e é
necessário que todos os processos avaliados estejam neste nível de
maturidade para que a empresa seja certificada. Exemplo: Se quase
todos os processos forem nível três, mas apenas um deles estiver no
nível dois a empresa não irá conseguir obter o nível 3 de maturidade.
 Risco no Processo de Teste
A área de Risco é extensa e muito complexa. Para todo processo
é preciso que sejam avaliados os riscos inerentes ao implantá-lo e é
imprescindível que os resultados obtidos com esse processo sejam
satisfatórios para a empresa que o adotou.

Vamos focar nos riscos no processo de teste, aqueles que podem

fazer com que nosso processo não seja eficiente ou que nos impeça de
completar o trabalho de teste de software.
Os riscos mais comuns no processo de teste são:
Orçamento – Ao final do projeto, caso a metodologia só preveja o
teste no final, pode faltar dinheiro para o investimento em teste ou caso
a equipe de teste faça parte do cronograma e seja preciso contratar um
colaborador com mais experiência, o orçamento não priorizará a
contratação.
Documentação (na metodologia tradicional) - Documentação mal
escrita ou inexistente, compromete a qualidade do trabalho e a entrega
das necessidades do cliente corretamente validadas.
Escopo - A constante alteração de escopo – requisitos eternos – é
um grande risco na nossa área, pois ele compromete o trabalho que
recomeça do zero a cada alteração.
Qualificação da Equipe - Equipe sem treinamento, interesse,
disposição e conhecimento é uma grande fonte de risco para o processo
de teste. A eficácia do resultado do teste será colocada em risco caso
haja esse problema.
Ambiente de Teste - A falta de um ambiente de teste isolado e que
represente a produção (ambiente do cliente com seu banco de dados) é
um fator de risco para o resultado do teste. Não há como saber se uma
pesquisa foi feita corretamente com dados fictícios, por exemplo.

Ferramentas - A falta das ferramentas necessárias para atingir um

resultado para um teste específico faz com que a credibilidade do teste
seja contestada.
Metodologias - A falta de um processo para recebimento de
demanda e entrega põe em risco a eficiência do teste.
 Prazo - Cronograma apertado para entrega do resultado.
Pessoas - Não só treinamento, mas a personalidade põe em risco
não só o processo de teste, mas também o processo de
desenvolvimento. Desmotivação, revolta, etc., contaminam um ambiente
que precisa de ajustes e dificulta o andamento do processo.
Stakeholder - O cliente que deveria ser o maior interessado, as
vezes, não age como tal. A falta de definição e de respostas as dúvidas
obtidas na hora do teste pode ser um risco a qualidade e ao prazo de
entrega do teste.
 Gestão de Risco
Após vermos quais os riscos, vamos agora falar sobre a gestão
deles, afinal, saber o que pode acontecer e não saber o que fazer não
adianta, não é? Vamos então usar o conceito do PMI sobre
gerenciamento de risco.
O  Project Management Institute  (PMI®) é uma instituição
internacional sem fins lucrativos que associa profissionais de gestão de
projetos. O esquema básico do PMI é:    
Figura 7 – Representação do Ciclo da Gestão de Defeitos na visão do PMI

Fonte: Elaborado pela autora

 Fases da Gestão de Risco:
Identificação - Avaliar e ver quais os Riscos que podem acontecer no
seu projeto/Processo.
Análise - Analisar e ver quais os procedimentos que devem ser
tomados para evitar o problema ou, qual decisão tomar se ele acontecer.

Classificação - Classificar em ordem de importância e prejuízo os

riscos encontrados.

Planejamento - Fase que constrói os planos para Mitigar ou

Contingenciar o risco.

Rastreamento - Saber onde, quando e como os riscos irão acontecer.

Controle - Após identificar, analisar, classificar, elaborar planos e

rastrear é preciso manter o controle dos riscos.

Todo o processo continua durante o dia a dia do projeto/processo,

afinal, a cada fase podemos encontrar novos desafios e problemas que
devemos analisar.
 Técnicas de Teste, Tipos de Teste e Níveis de Teste
As Técnicas de Teste abordam como serão conduzidos os testes.
Daí, fazemos a pergunta básica: Como Testar? Para esta pergunta
temos duas respostas: Testaremos com a técnica Caixa Branca ou
testaremos com a técnica Caixa Preta. Veremos um pouco sobre a
técnicACaixa Branca e o foco deste livro que é a técnica Caixa Preta.

Outra pergunta seria: O que testar? Se faremos o teste Estrutural

– parte interna do software ou realizaremos o teste Funcional – parte
externa. Dentro de cada técnica temos seus determinados tipos de teste
e os veremos mais à frente, cada um em seu tópico específico. Grave
apenas a pergunta feita por esta abordagem – O que testar? Teste
Estrutural ou Funcional?
 Massa de Dados
Massa de dados nada mais é que os registros utilizados na
execução o teste. Estes registros podem vir do cliente, através da cópia
do banco de dados idêntico ao da produção ou produzidos pelos
analistas de teste, com o preenchimento das tabelas básicas durante a
execução de teste.
As massas criadas durante os testes manuais devem ser claras,
objetivas e, se possível, ter relação com o sistema que está sendo
testado. Afinal, nossos clientes, durante o teste de aceitação, usam essa
base para homologação do sistema.
As massas criadas por ferramentas não precisam ser reais ou ter
relação com o sistema, afinal, o intuito da ferramenta é validar
performance, banco de dados, tempo de reposta e outros aspectos que
os usuários não terão contato. Geralmente, antes da homologação os
dados dessas massas criadas são apagados do banco de dados (BD).
 Níveis de Teste – Quando Testar?
O Nível de Teste requer resposta para a seguintes perguntas:
Quando Testar? Quando faremos os determinados tipos de teste? Em
que fase do projeto de desenvolvimento as técnicas e os tipos de teste
serão aplicados? Temos então quatro níveis de teste conhecidos:
Unitário/Unidade, Iteração/Módulo, Integração/Sistema e Aceitação.
O nível de teste Unitário/Unidade – refere-se ao teste de código,
feito pelo programador, debugando seu próprio código e suas
integrações (de código) para ver se há algum erro. Então, neste nível é
aplicado a técnica Caixa Branca e o tipo do teste leva o mesmo nome do
nível – Teste Unitário.
O nível de Teste de Iteração/Módulo – refere-se ao teste feito
após o término de cada iteração/módulo de um projeto para ver se o que
está no caso de uso e nos demais documentos foram implementados
corretamente. A técnica aplicada é a Caixa Preta e o tipo de teste é o
Funcional (e suas várias ramificações). Ele valida as telas que são
liberadas para a equipe de teste. Nem todo projeto é programado para
ser entregue completo. Hoje, a estratégia é fazer pequenas entregas
para que o cliente possa acompanhar o andamento do projeto. Iteração
ou Módulo é o nome dado ao grupo de casos de uso que passarão pelo
processo de desenvolvimento.

Figura 08 – Pacotes/Módulos do projeto

Fonte: Elaborada pela autora

 O nível de Teste de Integração/Sistema – refere-se ao teste do
software como um todo, ver o relacionamento entre telas,
funcionalidades, resultados de pesquisa, etc. A técnica é Caixa Preta e o
tipo é o Funcional.
Figura 9 – Representação da visão do Teste de Sistema

Neste nível de teste, já não procuramos os bugs de ortografia,

contradições entre tela e UC. Estes testes foram feitos durante as
iterações. Agora, é validado o relacionamento entre as telas, resultados
de pesquisa após inclusão e como o sistema se comporta como um
todo. Outros bugs podem ser encontrados? Podem, claro, porém, que
estes não sejam remanescentes do nível anterior, mas, uma nova
situação causada pelo motivo da integração.
O nível de teste de Aceitação – refere-se ao teste feito na
implantação do software. Quem faz esse teste é o cliente. Sobre os tipos
de teste de aceitação veremos mais à frente. A técnica usada é a Caixa
Preta e o tipo de teste é o Funcional.
 Caixa Branca – Teste Estrutural
O conceito é: O tipo de teste que espera resposta da parte interna
do software. É uma forma de não confundir os dois conceitos. Embora
sejam totalmente diferentes, ainda causa muitas dúvidas para quem
está começando na área. O Teste Caixa Branca é aquele que força a
parte interna do software a responder em condições fora do normal.
Mas, o que é o normal? O normal e anormal é decidido pelo cliente que
solicita e informa até onde o software deve ser forçado.

Exemplo:

Teste de Estresse. O cliente informa que em um determinado

período do ano o site da sua empresa chega a ter mais de 20 mil
acessos simultâneos e que, com esses acessos, o site é derrubado e
isso não pode acontecer. Bom, temos então aí o escopo para um teste
Caixa Branca. O analista de requisitos, que ao levantar os dados do
projeto identificar esse ‘gargalo’ irá descrever essa situação em algum
de seus documentos. Quando O Líder de teste tiver
 acesso aos documentos do projeto, para iniciar o processo, validará
esta informação e então no Plano de Teste já constará a necessidade
desta técnica de teste.
Mas, não é só a necessidade do teste que deve ser esclarecida.
Qual a melhor ferramenta para que este teste seja executado? E antes
disso, a empresa tem condições para oferecer esse tipo de teste?
O teste Caixa Branca – Teste automatizado – requer uma
infraestrutura e capacitação que nem todas as empresas estão
dispostas a investir. Servidor robusto para aguentar a ‘imitação’ dos
acessos simultâneos, capacitação do Automatizador de Teste e, às
vezes, a licença da ferramenta de automação.
 O que é Automação de Teste?
Automatizar teste é a realização do teste através de uma
ferramenta de automação. É gerado um script (código na linguagem da
ferramenta) no qual os passos do teste são gravados e salvos. Esse
script será reutilizado quando houver a necessidade de testar
novamente esta mesma funcionalidade. A automação também faz testes
que, humanamente, seria impossível, como no caso de milhares de
acessos simultâneos.
Para automação precisamos levantar os seguintes dados:
✓      Necessidade de processador de memória do servidor;
✓       Qual sistema operacional deve ser instalado e a configuração
das variáveis de ambiente;
✓      Qual requisito mínimo de Rede;
✓           Quais as ferramentas necessárias para executar o teste
automatizado, a integração dos testes automatizados,
visualização de Log, versão de homologação do script de
automação;
✓      Configuração de Banco de Dados de teste
✓      Massa de Dados necessária para realizar o teste automatizado
 O que deve ser automatizado?
O escopo para automação deve ser muito bem elaborado, não há
motivo para automatizar sistemas que estão em constante manutenção
e mutação. Os scripts servem apenas caso os campos, seus nomes e
seus dados não sejam alterados. Os testes automatizados devem servir
para Ganhar Qualidade, Reduzir Tempo e Reduzir Custo, caso essas
três máximas não sejam respondidas com um sonoro SIM, é melhor
repensar sobre automação para o seu projeto. É preciso, para oferecer
automação, além da infraestrutura, capacitação da equipe de teste ou,
escolher o colaborador que tenha habilidade para esta tarefa. Este perfil
– Automatizador – deve ter conhecimento intermediário em Lógica de
Programação e em alguma linguagem atual, para que ele seja capaz de
fazer a manutenção do código gerado pela ferramenta e sanar
problemas que possam vir a acontecer, como por exemplo, a ferramenta
não capturar um determinado ‘click’ ou o preenchimento de um campo.
O automatizador deverá conseguir manipular o código da ferramenta
para que esses passos sejam incorporados ao script.
 Tipos de teste Caixa Branca
Alguns dos tipos de teste caixa branca são:

Unitário – Feito pelo desenvolvedor em seu próprio código. Aqui o

desenvolvedor executa caminhos lógicos, insere valores falsos e
verdadeiros, vê se todos os laços foram cobertos corretamente e se a
estrutura está sendo corretamente validada.

Conformidade – Confirma se o software foi desenvolvido de acordo

com os padrões, normas, procedimentos e guias de TI. O código é
avaliado por um especialista (desenvolvedor ou arquiteto) e este é
verificado quanto a sua integridade e escrita.

Contingência – Valida a recuperação do software após uma falha de:

servidores, páginas, links, etc.
Estresse – Observa o software em condições limites de execução:
dados, acessos, downloads, etc.

Segurança – Aqui são usadas ferramentas para tentar acesso e

quebras de senhas.

Volume – Valida através de uma ferramenta a inserção de um grande

volume de dados e o comportamento do Banco de dados.

Configuração – Valida se o sistema funciona em diferentes

configurações de hardware e software.

Instalação – Valida se o sistema foi instalado corretamente e

condições adversas como espaço insuficiente de disco ou interrupções
de energia.

Os testes Caixa Branca podem variar de nomenclatura, mas

nunca de objetivo. O objetivo é validar e obter resposta da parte interna
do software. Código, Banco de Dados, BI, funções e todos os itens
internos do Software.
 Algumas ferramentas e seus respectivos tipos de Teste:
Testes Funcionais em Aplicações WEB

Selenium - http://seleniumhq.org
Watir - http://wtr.rubyforge.org
BadBoy - http://www.badboy.com.au
actiWATE - http://www.actiwate.com
Canoo WEBTest - http://WEBtest.canoo.com
Apodora - http://www.apodora.org
                            Testes de Desempenho

JMeter - http://jakarta.apache.org/jmeter

Tutorial JMeter - Testes Automatizados

http://www.devmedia.com.br/usando-o-jmeter-para-teste-de-
performance/20302
                            Testes Unitários
PHPunit.

JUnit (http://junit.sourceforge.net/).  

TestNG (http://testng.org).

NUnit (http://www.nunit.org/).
 Caixa Preta – Teste Funcional
Teste Caixa Preta, teste funcional, teste manual, teste
exploratório, etc. Os testes Caixa Preta tem o objetivo de validar o
software na visão do usuário. Telas, campos, nomes de campos,
mensagens de ajuda, mensagens de alerta, cores, tipos de paginação....
Um mundo de validações que devem ser levadas a sério. É por conta
destas validações que resolvi escrever este livro. 
Com o advento da automação, da rapidez, da agilidade, achou-se
que, os testes manuais ficariam obsoletos, mas não ficaram.  A visão do
usuário sobre o sistema que ele pagou jamais será obsoleta. Os testes
manuais confirmam não só os documentos elaborados pela equipe de
requisitos, mas, as expectativas do cliente. Aquele olhar crítico
construtivo do Analista de Teste sobre o software traz incontáveis
benefícios ao sistema e evita retrabalhos e reclamações dos usuários.
Vou mais que conceituar os tipos de teste. Quero incluir vários exemplos
de como testamos e os tipos de testes para melhor visualização do
processo. Vamos lá!
 Tipos de Teste Caixa Preta
Usabilidade – Valida a forma como o software pode ser navegado.
Exemplos:

- Passar pelos campos de um formulário com a tecla Tab

Parece simples, mas, em formulários extensos a melhor
funcionalidade é esta! Quem hoje usa o mouse para passar os campos?
Quem hoje digita Nome, mouse, Endereço, mouse, CEP, mouse, DDD,
mouse, Telefone, mouse. O mouse é para clicar no campo seguinte.
Quem trabalha com formulários digita no campo Nome <TAB>,
Endereço <TAB>, etc.  O preenchimento do formulário fica mais rápido,
prático e a usabilidade da tela, ótima.

- Hint
Hint é aquela frase que ao passar o mouse sobre um campo ela
explica o que ele faz. Existem botões, campos ou links que não são tão
didáticos quanto pensamos. Nós que temos a documentação do projeto
em mãos é fácil. Mas e o usuário? Às vezes, o usuário final do software
não é o mesmo que requisitou. Quem requisita é o Dono da empresa
para o seu setor de RH, por exemplo. Então é importante que este
auxiliador esteja no lugar certo e principalmente, informando uma
mensagem coerente e ortograficamente correta.
 - Selecionar TODOS
Durante um teste onde o resultado da pesquisa nos dá mais de
50 registros por página, onde estes registros são selecionáveis, é
imprescindível um check box Selecionar Todos.  Assim como no seu e-
mail que, ao acessar uma pasta que não lhe interessa mais seu
conteúdo, você pode ir no Check Box e Selecionar todas as mensagens
apresentadas da tela e excluir. Já pensou ter que selecionar um a um?
Isso torna o trabalho prático e com a usabilidade em dia.

- Títulos da Grade de Dados = Links de Ordenação

Mas, como assim? Simples. Voltemos a nossa pesquisa. Temos
colunas na grade de dados que são: Nome, CPF, Inscrição, Status e
Data de Inclusão. Os dados deverão vir organizados de acordo com a
coluna Data de Inclusão por default. O nome do cliente é Alcir da Silva e
o operador não sabe a data de inclusão dele no sistema. A pesquisa foi
por Alcir, e vieram 400 registros. E aí? Iremos de página a página,
1,2,3...? Títulos que ordenam dados, faz com que a coluna NOME
organize crescente e decrescentemente os registros.

Enfim, poderíamos fazer um livro somente sobre tipos de bugs de

usabilidade. Porém, com esses exemplos vemos como devemos validar
a usabilidade. Devemos diminuir o número de cliques ao máximo
possível, esclarecer campos dúbios, melhorar mensagem, trocar
campos para que a seleção seja melhor efetuada. Tudo que puder ser
feito para que a experiência do cliente ao usar o software seja
agradável, nós devemos validar e sugerir, caso ele não tenha sido
previsto no documento de requisito.
 Layout – Testes que validam a composição da tela.
Um software robusto, com um BD bem modelado, e um código
bem escrito é obrigação da empresa que desenvolve o software, mas,
além de funcional, o sistema deve ser ‘bonito’. Nossos clientes não vão
usar o BD para inserir dados. Eles usarão as telas para cadastro e
inserção de registros. Essas telas devem ser bonitas. Os campos devem
estar alinhados, as mensagens em pop ups, as cores devem ser sóbrias
– caso não tenham sido pré-definidas pelo cliente. Esse tipo de teste
também é conhecido como ‘perfumaria” ou “cosmético” já que é
justamente para melhorar a aparência do sistema.

Mas nem só de melhorias vive o teste de Layout. Muitas vezes,

um campo que cabe 2000 caracteres deve ser apresentado em uma
grade de dados e ao ser pesquisado ‘quebra’ a página, fazendo uma
barra de rolagem horizontal aparecer, desconfigurando a tela. Essas
questões de quebra de campos, resultados de pesquisa, mensagens
que escondem nomes de campos também entram nessa categoria.
Dicas:
 Ortografia – Erros ortográficos em geral.
Palavras escritas incorretamente são bugs de ortografia, porém, a
falta de preposição também é. No desenvolvimento a linguagem
utilizada para nomes de campos acompanham a nomenclatura de banco
de dados e isso muitas vezes se reflete na tela, o que para nós é
considerado bug, exemplo:

Figura 10 – Teste Manual de Ortografia

Fonte: Elaborada pela autora

Lembrando que, os termos estrangeiros também deverão ser

validados. Se nosso sistema fizer uso de palavras estrangeiras, estas,
deverão estar ortograficamente corretas.

Funcionalidade – Teste das funcionalidades da Tela.

Esse é fácil. Incluir, inclui? Alterar, altera? Excluir, excluí? São
validadas todas as funcionalidades do sistema de acordo com o que foi
documentado. Clicou em Confirmar e apresentou tela amarela é
Funcionalidade.  Solicitou pesquisa por NOME e o resultado foi por CPF
é funcionalidade. Seguem abaixo dicas básicas de validação de
funcionalidade, mas para o iniciante na área é muito bom ter este check
List:
 Requisitos – Teste dos Requisitos do sistema.
Todos os testes não são de requisitos por que tudo é baseado
nos UCs gerados? Sim. Porém, a classificação diferenciada dos bugs
ajuda no entendimento e visualização por parte do desenvolvedor.
Está descrito no UC que o botão confirmar deve incluir os dados
na tela e o sistema depois dessa ação apresenta uma tela amarela
cheia de códigos. Classificá-lo como erro de funcionalidade ajudará o
entendimento do que deve ser corrigido e, principalmente, da gravidade
do bug. Classificar um erro de inclusão como “Erro de Requisitos” faz
com que ele pareça menos grave do que um “Erro de Funcionalidade”.
Então, por isso, há a classificação específica de alguns bugs. Falaremos
sobre a classificação dos bugs a frente.
Quanto ao teste de Requisitos, temos primeiro que compreender
o conceito de Verificação e Validação, os famosos VER e VAL.
Verificação – é o teste feito nos artefatos. Leitura, análise e
comparação dos dados. Coerência, facilidade de entendimento, falta de
informações relevantes, etc.
Validação – é o teste do sistema. Teste da tela. Teste Caixa Preta
e todos seus tipos. O teste de requisito faz-se nos dois casos.
 No VER, assim que os documentos chegam da equipe de
requisitos eles são analisados e já são testados. Sugestões e dúvidas
fazem com que bugs não cheguem ao processo de desenvolvimento.
Por isso é tão importante a participação desde o início do processo da
equipe de teste.
No VAL, alguns erros são classificados como sendo de requisitos.
Quais? Aqueles que não entram em nenhuma outra classificação.
Exemplo:
Figura 11 – Teste de Requisitos

 
Fonte: Elaborada pela autora

Este é um erro de funcionalidade? Não, ele nem tem função, é

só uma label. É de usabilidade? Não, não prejudica o uso do sistema. É
um erro de Layout? Não, não está feio, está até bonito. É um erro de
Ortografia? Não, RG é uma sigla correta. Então, o classificamos como
Erro de Requisito, por que no documento ele é descrito de um jeito e a
tela apresenta de outro.
O não cumprimento de alguma Regra Negocial (diferença entre
Mensagens, Frases, Textos, etc.) está nesta categoria. E por exclusão
das outras, qualquer outro tipo de bug pode também ter esta
classificação.
 Caixa Cinza
O teste caixa cinza é a mescla das duas técnicas de teste. O
analista de teste não valida somente a visão do usuário, mas também a
estrutura do software. Por exemplo: ao incluir, alterar e excluir um
arquivo pelo sistema e ver a gravação dos dados no BD é um teste
caixa cinza.
 Gestão, Classificação e Priorização de Bugs
Algumas literaturas fazem distinção entre Falha, Erro e Defeito.
Cada um conceituado de uma forma dando a cada nomenclatura um
motivo diferente. Vou listar aqui os mais conhecidos. Contudo,
trataremos os erros, defeitos e falhas como BUG. Na vida da equipe de
teste, dificilmente trabalharão com esses conceitos, mas, caso a
empresa queria separá-los não é difícil a adaptação. E mais importante
que esta nomenclatura, é a classificação do bug.
Defeito – Passo, processo ou definição de dados incorretos
Engano – Ação humana que produz um resultado incorreto
Falha - Desvio entre o resultado/comportamento
Bug - Erro de lógica de programação
Gerir defeitos é muito importante para a atividade de teste.
Através desta gestão damos respostas para os Gerentes e decisões são
tomadas a partir delas. Decisões importantes, como: Posso colocar em
produção? Preciso renegociar prazo? Quanto tempo preciso incluir no
cronograma para reorganizar as entregas? etc.
 Quando um bug pode ser detectado?
Sabemos que bugs são encontrados desde o início do processo
de desenvolvimento, com a verificação dos documentos do projeto até o
momento da validação do sistema. E como já vimos, a cada fase, a
correção vai ficando mais cara.
 Gestão de Defeitos
Elementos da Gestão de Defeitos
Prevenção – Prevenir se dá no momento da verificação. Onde os
documentos, ainda sendo homologados, já são verificados pela equipe
de teste e sugestões de melhoria e alterações já são registradas.

Identificação – Identificação se dá no momento do teste do sistema.

Nesta identificação classificamos e priorizamos os bugs de acordo com
a gravidade que eles afetam o sistema.

Solução – Definição do processo de correção e notificação da

resolução do defeito para revalidação.

Melhoria do Processo – Ajustar o processo atual para as

necessidades do projeto/cliente. Retirada de métricas através dos
registros, analisando o tipo de criticidade do bug, a quantidade de
ocorrência destes e a complexidade do sistema. Por exemplo, um
sistema simples que teve o registro de muitos bugs de funcionalidade
pode sinalizar uma deficiência de treinamento na equipe de
desenvolvimento.

Relatório de Gestão - O relatório mostra como foram os testes

quanto bugs foram encontrados e sua classificação, as dificuldades que
foram encontradas, mudanças de escopo, mudança de equipe, etc. O
relatório de teste pode ser o Sumário de teste. A nomenclatura utilizada
pouco importa, o que é relevante são os dados contidos e entregues ao
GP.

A gestão do bug pode ser feita através de uma ferramenta

Bugtracker que faz o processo de registro, envio para o desenvolvedor
responsável e retorno para revalidação do analista de teste. Uma
ferramenta muito conhecida e grátis é o Mantis. Mas,
independentemente de ferramenta, o Analista de Teste deve fazer este
trabalho em uma planilha do Excel, se for o caso. Não é desculpa a falta
de ferramenta para a gestão do trabalho. É preciso ser proativo neste
caso e gerir você mesmo seu trabalho.
 Ciclo de Vida de um defeito
Para melhor visualização segue um esquema do ciclo de vida de um
defeito:

Figura 12 – Representação do Ciclo de Vida de um Defeito Fonte: Elaborada pela autora

 Ferramenta Mantis
​ Mantis é uma ferramenta de gestão de defeitos que serve para a
O
rastreabilidade do ciclo de vida do defeito.
​Nele podemos relatar o bug com os detalhes necessários, enviar
anexo com imagem e atribuir ao desenvolvedor responsável. Além deste
bug estar em uma estrutura que é possível saber de qual projeto ele
pertence.
​Na internet podemos ver como ele funciona, acessando com login
anônimo ou fazendo uma inscrição para manipular melhor os itens do
bugtracker:

Figura 13 – Tela inicial – Mantis

Fonte:
http://www.mantisbt.org/bugs/login_page.php?return=%2Fbugs%2Faccount_page.php
 Figura 14 – Tela Minha Visão – Mantis.

Fonte:
http://www.mantisbt.org/bugs/login_page.php?return=%2Fbugs%2Faccount_page.php
 A visão do Mantis é totalmente configurável. As telas apresentadas
aqui são a visão desejada para o projeto.
Quando uma ferramenta de gestão de defeitos é escolhida por uma
empresa, a visão dos itens importantes para aparecer na primeira tela
será decido em conjunto com a equipe de projetos, levando em
consideração o projeto, escopo, necessidades dos envolvidos e tudo
que nortear o objeto de teste.
O mais importante que quero trazer com essas telas:
 
É preciso ter a rastreabilidade e relatos conscientes dos
defeitos encontrados no sistema. Seja com ferramenta, seja com
planilha, seja com e-mails.
 
É preciso organizar e rastrear os bugs, suas classificações, seu
status e claro, o retrabalho – seja por problemas de documentação,
ambiente, entendimento da descrição, etc.
 
Figura 15 – Tela Relatar Caso – Selecionar Projeto – Mantis.

Fonte:
http://www.mantisbt.org/bugs/login_page.php?return=%2Fbugs%2Faccount_page.php

Figura 16 – Tela Relatar Caso – Mantis.



 
Fonte: http://www.mantisbt.org/bugs/login_page.php?return=%2Fbugs%2Faccount_page.php
 Como vimos, os campos para relato de bug também são
configuráveis. Mas, sabemos o que não pode faltar, não é? Resumo,
descrição com o passo a passo e a tela para reprodução da falha não
podem ficar de fora de um bom relato de erro. A classificação e
priorização também ajuda o desenvolvedor a decidir qual item atacar
primeiro.
 Métricas de Teste
Quando questionada sobre como poderíamos medir o produto do
Teste pensei em todas as questões que poderiam gerar embasamento
para valorizar o serviço de Teste de Software. A equipe usa a
Metodologia Scrum e como essa metodologia ágil não valoriza a
documentação, é mais complicado para nós analistas de teste. Sem
dados completos, e às vezes sem dado algum para teste, vamos na
experiência e na conversa com usuários e analistas para validar as
funcionalidades e o registro dos bugs, não para rastreabilidade, apenas
para que o desenvolvedor possa resolver o problema do sistema.
Bom, vamos as minhas sugestões de como seria a melhor
maneira de medir o Teste:
Medida – variável onde o valor é atribuído como resultado de uma
medição

Métrica – atributo mensurável de um produto/processo

Medição – Determinação de uma medida

 Indicador – Informação utilizada para compreender o
processo/produto que está sendo medido.
O teste de Software não gera produto, mas sim, presta um
serviço para o processo de desenvolvimento de software, daí a
dificuldade de definir indicadores para medição do processo.
 Como não medir:
Horas de Teste
Este indicador não seria verídico já que ficamos envolvidos em
um Teste durante duas semanas, mas que, verdadeiramente, só
testamos durante 2 horas.
          O que faz demorar o tempo entre um teste e outro de uma mesma
funcionalidade? Ambiente, Tempo de correção, Atualização que não deu
certo...  Esses fatores fazem com que as horas de teste não
correspondam ao tempo que a tarefa ficou aberta.

Bugs por desenvolvedor

Medir qualidade através de bugs individuais pode gerar
constrangimento e a recusa de correção. Muitas vezes o desenvolvedor
tenta provar que a ocorrência “não é um erro”, pois o bug (falha no
software) pode atribuir uma visão negativa sobre o seu trabalho.
Como medir

O serviço do teste de software é encontrar defeitos, expor o

software e, assim, aumentar a qualidade e a confiabilidade no sistema.
Então não podemos fugir dos indicadores orientados a Bugs, porém
podemos mudar o foco da medição – Não focar no desenvolvedor, mas
sim, atentar para a categorização dos bugs e seus impactos sobre o
sistema.

Indicadores Sugeridos:

1 - Índice de Severidade de Bugs encontrados.

Com esta medida os bugs são registrados e classificados quanto a sua

severidade em relação ao sistema:

Mínimo – Nenhuma interferência no sistema.

Pequeno/Baixo– Pouca interferência no sistema.

Médio – Média Interferência no sistema.

Grande/Alto – Interferência que impede a continuidade de um

determinado teste.

Travamento/Crítico – Interferência    impeditiva de utilização de todo o

sistema em teste.
 2 - Categorização dos Bugs encontrados

Com esta medida os bugs são registrados e classificados quanto a

sua Categoria em relação ao sistema:

Funcionalidade – Erros decorrentes da funcionalidade do sistema.

Usabilidade – Erros  decorrentes da usabilidade do sistema.

Layout – Erros  decorrentes da interface do sistema.

Ortografia – Erros ortográficos.

Especificação – Erros decorrentes da falta de definição negocial e

especificação do sistema.

Build/Atualização/Ambiente – Erros decorrentes de atualização de

ambientes, erros das builds disponibilizadas, erros de ambiente na hora
do teste do sistema.
 Relacionamento entre os indicadores
Pode-se usar somente um dos indicadores acima para a
medição, porém, é melhor fazer o relacionamento entre os indicadores e
medir através do Índice de Classificação de Bugs – Severidade x
Categoria.

Os indicadores sugeridos acima se relacionam para mostrar

como está a qualidade do sistema, como por exemplo: os erros de
funcionalidade sempre são de severidade Grande ou travamento, afinal,
impedem o andamento do caminho funcional do sistema, o custo de
correção é maior e o prejuízo para o sistema também.
Com esse relacionamento conseguimos identificar a classificação
de erros (Mínimos / Pequenos / Médios / Grandes e Travamentos) e qual
Severidade (indicativo de prioridade de correção) aconteceu por item de
teste (Tela / Módulo / UC) realizado.

Figura 17 - Tabela de Relacionamento entre Indicadores

Fonte: Elaborada pela autora

 Como obter qualidade no Teste de Software
Só o teste não é parâmetro para um software de qualidade. É preciso
aliar ao teste de software outras questões que garantam a confiabilidade
e eficiência do trabalho. Exemplo:
Processo de Desenvolvimento Estruturado – é preciso um mínimo de
estrutura para se desenvolver um software. Esta estrutura nos garante
um passo a passo de como e quando chegarão as demandas e a forma
correta de demonstrar os resultados.
Documentação Consistente – caso a metodologia seja baseada em
documentação, esta deve ser consistente e não ter alterações
periódicas. A cada alteração, o trabalho do teste recomeça e com isso,
novos bugs e novas visões do software surgem. Uma documentação
falha resulta em um trabalho sem confiabilidade.
Controle de Versões – é preciso que haja um controle de alteração
das versões de documentos, códigos, BDs, etc. Não pode acontecer de
o desenvolvedor ter uma versão 1.1 do requisito e a esquipe de teste
ainda ter a 1.0. São necessárias ferramentas que façam esse trabalho
(SVN, VSS, Docs Open, etc.) ou pastas compartilhadas com um
histórico atualizado.
Planejamento – Planejar as ações, ainda que a cada duas semanas,
como no Scrum, é necessário para o bom andamento do trabalho do
teste. O ‘Teste Surpresinha’ faz cair a qualidade do trabalho.

Gerenciamento – O GP deve se envolver diretamente com a área de

teste. Sabendo das necessidades de informação, infraestrutura e
reuniões.
Reuniões de Repasse – A cada módulo/projeto é importantíssimo
que o analista de requisitos repasse a equipe de teste os pormenores do
projeto, regras de negócio, expectativa do cliente e etc.
Capacitação – Treinamento da equipe de teste. Equipe bem treinada
e motiva eleva a qualidade e eficiência do Teste de Software.
 Artefatos elaborados pela Equipe de teste
Cada empresa e metodologia pede um tipo de artefato para sanar
as necessidades do projeto/sistema. Não há um documento padrão
seguido por todas as equipes e empresas do mundo. É preciso saber
como o processo de teste na empresa foi montado para então, ver quais
documentos devem ser produzidos.

Os templates deste livro foram produzidos por mim e tiveram

como base os documentos das empresas que trabalhei, porém com
alterações de escopo, pois, para mim, o ‘menos é mais’ e informação
em excesso acaba se perdendo. Os documentos de sistema devem ser
objetivos e sucintos, apresentando o conteúdo correto para melhor
visualização do usuário que os utilizam como base de análise para
homologação ou validação do sistema.
 Artefatos produzidos pela Equipe de Teste:
Check List de Entrada de Artefatos
Planilha que norteia a entrada de artefatos na equipe de teste.
Contém os itens que devem ser levados em consideração na
documentação de sistema para o início da elaboração dos demais
artefatos de teste.

Plano de Teste
Contém os casos de uso, telas e projeto que serão testados,
responsáveis pelo teste, elaborar roteiros, criar ambiente, quais erros
podem ser encontrados, riscos do processo, etc. É o planejamento
inicial do Teste sobre a demanda enviada para a equipe.

Roteiro de Teste Funcional

Passo a passo que norteia o teste de software. Cada UC gera um
RTF. Este documento traduz TODOS os artefatos de requisitos. Não é
uma cópia do UC ou da modelagem. É uma tradução, para linguagem
de teste, dos passos, regras de negócios, mensagens apresentadas e
padrão de telas. O executor de teste usa somente esse artefato para
realizar o teste.
 Relato de Erro
Este documento é enviado para o desenvolvedor demonstrando o
passo a passo da execução do teste e a evidência de defeito.

Sumário de Teste
Documento de finalização do teste. Contém o relatório com os
bugs encontrados por tela/módulo, classificados e discriminados. Aqui
informamos se houve algum contratempo, alteração de escopo, causa
de atraso e etc.

Controle de Atividades
Controle das atividades do analista de teste. Caso a empresa não
tenha uma ferramenta de gestão de atividades é preciso que o
profissional de teste faça esse controle e mantenha a rastreabilidade
das suas atividades. Proatividade neste caso é fundamental, pois, para
o teste, os dados das execuções são as provas do trabalho. Até por que,
ao final do teste temos apenas o software funcional. Os bugs estão
fechados e os roteiros completamente executados. São os bugs e os
ciclos de teste que mostram as horas e o trabalho do analista de teste.
Outros Artefatos...
​Você como responsável pela área de teste certamente, caso ainda
não exista, terá que desenvolver a estratégia de teste e a política de
teste da empresa. A política irá nortear todo o teste da empresa, com
sua missão e os mais importantes conceitos a respeito do que a
empresa pensa sobre teste de software.
 
A estratégia de teste pode ser uma ou várias, por que pode ser
criada para cada projeto, iteração ou módulo. Essa decisão – de como
será criada a estratégia de teste – deve ser feita em conjunto com o
gerente ou a equipe de projetos, pois é quem diz como o projeto será
conduzido: cascata ou ágil; com entregas em iterações ou módulos, etc.
 
De acordo com o Syllabus 2018 “Uma estratégia de teste fornece
uma descrição geral do processo de teste comumente no nível do
produto ou organizacional. ” A estratégia pode ter diferentes tipos:
analítica, baseada em modelo, dirigida, reativa... depende do foco e do
objetivo do projeto. O ideal é combinar várias estratégias e abordagens
para atender prontamente o escopo do projeto que está sendo testado.
 
 Equipe bem treinada e valorizada faz a diferença
Durante meus anos como profissional de teste de software, o
maior desafio que identifiquei para as equipes foi, ou ainda é,
demonstrar a importância do Teste de Software para o produto final.
Provar que o Teste não é um custo, como alguns Gerentes ainda veem,
mas sim um investimento em qualidade. Ainda que consuma um pouco
mais de tempo do projeto, as atividades de teste são de suma
importância. É importante que o software passe pelos olhos atentos do
especialista antes da entrega ao usuário final.
Essa maratona de provar que teste é investimento e não custo
leva as equipes a se sentirem um pouco desvalorizadas, já que, só o
fato de ser cogitada a possibilidade da dispensabilidade do teste, pode
fazer o analista pensar: se pode ser dispensado, é realmente
importante? SIM! É importantíssimo! O que ocasiona a dispensa do
teste nunca é operacional, mas sim, financeiro. O tempo de atraso pode
gerar multa. Aumento do tempo de projeto aumenta o preço e daí o
cliente pode não aceitar a proposta. A dispensa do Teste de Software
nunca é por que ‘não é necessário’. O teste sempre é necessário.
Dispensar o teste é brincar de ‘roleta russa’, pois, por mais experiente e
eficiente que seja a equipe de desenvolvimento, entregar um software
com apenas testes unitários e de integração de código pode ser
desastroso. A visão do usuário deve ser sempre validada por
especialistas experientes e capacitados para evitar que erros bobos
sejam pegos pelos usuários finais. A reputação da equipe de projeto é
posta à prova quando bugs primários são entregues aos clientes.
No MBA, meu trabalho de conclusão falou exatamente sobre a
importância do teste para o software e, principalmente, a valorização da
equipe de teste. Uma equipe bem treinada, motivada, que sabe seu
valor e a importância do seu trabalho agrega um valor considerável ao
sistema.
A falta de reconhecimento do trabalho da equipe de teste faz com
que a área em si seja desvalorizada pelos superiores e por quem
trabalha nela. Os mais novos na área podem inclusive ser contaminados
por essa visão de ‘porta de entrada na TI’ ou ‘Teste é dispensável’ por
não terem o conhecimento da importância da nossa disciplina.
 O resultado final depende da capacitação da
equipe
Enquanto a equipe de teste for segregada ou composta por
qualquer perfil, como já vimos neste livro, o serviço de teste terá falhas
básicas e não será levado a sério. É preciso investir em treinamento e
capacitação para que a equipe possa atender as demandas da
empresa. Novas tecnologias pedem novas ferramentas ou uma nova
visão de teste e para isso, é importante que a empresa tenha
consciência que sua equipe de teste deve acompanhar as necessidades
dos clientes e das demandas do projeto para apresentar um trabalho de
excelência.
Não adianta economizar quando se fala em treinamento. Treinar
a equipe corretamente traz segurança para a empresa de que as
necessidades dos seus clientes serão atendidas.
Devem-se observar os seguintes itens para o treinamento da Equipe:

1 – A carga horária das aulas práticas não deve ser muito pequena.
Já que os resultados deste treinamento serão cobrados de imediato.

2 – Referente à quantidade de pessoas por curso, é importante para

empresa que todos aprendam a ferramenta embora a princípio um
apenas ficaria responsável pela automação.

3 – É preciso verificar antes do curso a capacidade das máquinas,

pois precisaremos da instalação do software solicitado pelo instrutor.

Este treinamento não deve ser visto como custo, mas como
investimento para a empresa. A equipe estará qualificada e melhor
preparada para atender as necessidades dos clientes.

É preciso aprender não só o uso da fermenta, mas, instalação,

manutenção, validação de dados não capturados, alteração de script se
necessário e outros fatores que um curso teórico praticamente não
oferece.
 Equipe de teste motivada - trabalho de excelência
Uma equipe que sabe o valor do seu trabalho emprega mais
atenção nas suas atividades, sabendo que não existe ‘bug sem
importância’, apenas os de prioridade baixa. Com a ciência da
importância do Teste para o projeto a equipe se sente à vontade para
expressar melhor sua visão sobre o sistema e o projeto, dar estimativas
reais de prazo comparando a quantidade de bugs encontrados que
podem prejudicar o sistema – e sem receber olhares fuzilantes por conta
de possíveis atrasos. Ao contrário disso, a equipe receberá olhares
agradecidos pelo bom trabalho realizado.
A melhor motivação é um plano de carreira com possibilidade de
ascensão na área, com plano de cargo e salários, gratificações pelas
certificações adquiridas, tempo de experiência e claro, confiança e
respeito pelo trabalho realizado.
 Conclusão
Conhecemos a importância do Teste de Software, a importância
do uso de técnicas para fazê-lo, a necessidade de pessoas capacitadas
e treinadas para compor a equipe e que o teste manual é extremamente
importante para o sistema. Vimos a importância da automação de teste
e que este não anulará as validações da visão do usuário que são tão
necessárias. Concluímos então o óbvio, que as técnicas de teste não se
anulam, elas se completam. Todos as validações devem ser feitas em
um sistema antes de sua entrega para o cliente, não sendo uma mais
valiosa que outra, apenas separadas pela necessidade e foco do
trabalho requisitado pelo usuário.
Como analistas temos que entender de todos os tipos de teste,
porém, para o sucesso, é preciso focar em nosso perfil, aquilo que
fazemos melhor, no que nos destacamos. Se seu perfil é voltado para
automação, estude ferramentas, tipos de testes automatizados,
facilitadores destes testes e melhores relatórios de gerenciamento.
Capacite-se, certifique-se e vá rumo aquilo que você faz com maestria.
Se o seu perfil é o teste manual, capacite-se e certifique-se de modo
que seja excelente o seu trabalho, suas formas de análise da
necessidade do cliente e relatórios de avaliação do sistema.
O mais importante é estarmos felizes em nossas carreiras. A
satisfação nos ajuda a passar pelos dias de trabalho e nos motiva a
cada dia sermos melhores.
Teste Caixa Branca ou Teste Caixa Preta o importante é a
necessidade do cliente e a excelência no trabalho realizado.
Algumas frases inspiradoras:
“Seu trabalho vai preencher uma parte grande da sua vida, e a única
maneira de ficar realmente satisfeito é fazer o que você acredita ser um
ótimo trabalho. E a única
maneira de fazer um excelente trabalho é amar o que você faz. ”
Steve Jobs.

“Escolha um trabalho que você ama e você nunca terá que trabalhar
um dia sequer na vida.” Confúcio.
 “Eu quase ia dizer para você fazer o que ama, mas não é bem assim.
As pessoas mais felizes e bem-sucedidas não amam o que fazem. Elas
são obcecadas em resolver algo que importa a elas.”    Drew Houston,
fundador do Dropbox.

“Em um momento decisivo, a melhor coisa que você tem a fazer é o

certo. A pior é não fazer nada” – Theodore Roosevelt.
 Fixação do Conteúdo
Estes exercícios são para fixação do conteúdo teórico. A prática
mostra-nos verdadeiramente como é a rotina e o dia a dia da equipe de
TI, mas, precisamos estar bem embasados teoricamente para saber
como proceder na realidade.
Vale lembrar que aqui não é prova, não vale ponto extra, nem
nada que nós como alunos precisamos para ‘passar de ano’. Aqui é uma
lista que nos dá condições de fixar o conteúdo de teste e o mundo que o
envolve. Esta lista é para que possamos nos preparar para as perguntas
e questões que possivelmente veremos nas entrevistas de empregos. 
Além da prática na elaboração de artefatos de teste, é preciso ter a
teoria para responder as famosas provinhas que são feitas pelos
recrutadores.
Aproveite para tirar dúvidas, pesquisar por aquilo que não ficou bem
entendido. Responda com suas palavras as questões a seguir.
Mãos à Obra!
 1 – O que é Teste de Software?
2 – Qual a importância do Teste de Software para o projeto?
3 – Testar é Fácil?
4 – Defina o processo de Desenvolvimento de Software e descreva
suas fases.
5 – Quais as metodologias usadas para desenvolver um software?
Você conhece alguma que não está descrita neste livro? Descreva-a.
6 – O que você entende do método Scrum e suas especificidades?
Descreva-os.
7 – Quando deve ser iniciado o Teste no processo de
Desenvolvimento de Software?
8 – Descreva o Processo de Teste e suas fases.
9 – Quais os Riscos mais conhecidos no Processo de Teste?
10 – Defina Teste Caixa Preta - Funcional.
11 – Defina Teste Caixa Branca - Estrutural.
12 – Defina Teste Caixa Cinza.
13 – O que teste de Usabilidade?
14 – O que é teste de Layout?
15 – O que é teste de Ortografia?
16 – O que é teste de Funcionalidade?
17 – O que se entende por Teste de Requisitos?
18 – O que é Automação de Teste de Software?
19 – O que deve ser automatizado?
20 – Como um Bug pode ser detectado?
21 – Como pode ser feita a Gestão de Defeitos?
22 – Descreva os elementos da Gestão de Defeitos.
23 – Quais as melhores métricas de Teste? Por que?
24 – Como obter qualidade com Teste de Software?
25 – O que é RTF – Roteiro de Teste Funcional?
26 – O que é Plano de Teste?
27 – O que é Sumário de Teste?
28 – Como deve ser feito o Relato de Erro?
29 – Explique a Regra 10 de Myers.
30 – Quais as principais características Técnicas e Gerenciais para
sermos um bom Analista de Teste?
 Templates
Os templates (modelos) são apenas dicas para que o Analista de
Teste possa sugerir ou até mesmo montar o processo de teste na
empresa em que trabalha caso ela não tenha os mesmos definidos para
seu Processo de Teste. TODOS os listados abaixo foram elaborados por
mim para este livro.
 Template - Plano de Teste:
O plano de teste é feito no início, quando o projeto de teste chega a
equipe.
Antes de elaborarmos este artefato, caso nos seja possível analisar
os artefatos que são entregues pela equipe de Requisitos e Banco de
dados:
Casos de Uso
Documento de Mensagem
Documento de Regra de Negócio
Diagrama de Sequência
Diagrama de Casos de Uso
Modelo de BD - banco de dados
MER - modelo entidade - relacionamento
Plano de Arquitetura de Software
ERS - especificação de requisito de software
Fazemos análises para saber se o projeto tem condições de ser
testado e se as documentações estão coerentes para que o RTF -
roteiro de teste funcional seja elaborado
 O PTE é composto das seguintes informações:
CAPA: com o nome do projeto e nome do cliente
Histórico de Revisões – quadro que apresenta as alterações do
artefato ao longo do andamento do projeto
Sumário
Introdução:
​Escopo
​Referências
Características do PTE:
​Restrições
​Premissas
​Riscos Iniciais
​Responsáveis pelo projeto: Líder de teste, analista de teste e
executor de teste
​Metas
​Critérios de aprovação
​Pacotes/Módulos/Tela/Projeto
​Ferramentas que serão utilizadas na execução do teste
​Artefatos utilizados fora os Casos de Uso para elaborar o PTE
​Ambiente de teste

Processo de Gerenciamento
Programação do Plano de teste: Quantidade de Horas para Teste
e quantidade de horas para Elaborar Roteiro de Teste Funcional.
Exemplo:
Analisar a complexidade dos UC’s:
 Cadastro do Aluno - 7 casos de Uso

Casos de Uso e Complexidade:

• Incluir Cadastro do Aluno – Complexidade Média

• Alterar Cadastro do Aluno – Complexidade Média

• Excluir Cadastro do Aluno – Complexidade Média

• Pesquisar Cadastro do Aluno - Complexidade Média
• Incluir Forma de Pagamento do Curso – Complexidade Alta
• Alterar Forma de Pagamento do Curso – Complexidade Alta
• Pesquisar Forma de Pagamento do Curso – Complexidade Alta

Tabela de Definição de Complexidade do UC x Horas para

elaboração do Artefato Roteiro de Teste Funcional

Para Elaborar o Roteiro de Teste Funcional

 Quantos casos de uso temos e suas complexidades?
Temos 7 UCs e suas complexidades são conforme abaixo.:

       

4 casos de Uso que levarão a média de 2 horas para serem

elaborados os RTF’s.
Total de Horas: 4*2 = 8 horas
Dias de Trabalho: 8(horas) dividido por 6 (horas reais produtivas)
= 1,3 dias

       
3 casos de Uso que levarão a média de 4 horas para serem
elaborados os RTF’s.
Total de Horas: 4*3 = 12 horas
Dias de Trabalho: 12 (horas) dividido por 6 (horas reais
produtivas) = 2 dias

Então, para elaboração do roteiro de teste funcional a estimativa

é de 4 dias úteis. Sugiro que coloque o que chamamos de “gordurinha”
neste prazo para contarmos com algum imprevisto.
 Tabela de Definição de Complexidade do UC x Horas de Teste por
Caso de Uso
 

Para o teste
Quantos casos de uso temos e suas complexidades?
Temos 7 UCs e suas complexidades são conforme abaixo.:

4 casos de Uso que levarão a média de 6 horas para serem

testados.
Total de Horas: 6*4 = 24 horas
Dias de Trabalho: 24 dividido por 6 (horas reais produtivas) = 4
dias
 3 casos de Uso que levarão a média de 8 horas para serem
testados.
Total de Horas: 8*3 = 24 horas
Dias de Trabalho: 24 dividido por 6 (horas reais produtivas) = 4
dias

Então, para execução de teste a estimativa é de 8 dias úteis.

Sugiro que coloque o que chamamos de “gordurinha” neste prazo para
contarmos com algum imprevisto.
 Template - Roteiro de Teste Funcional:
Este artefato é a junção de TODOS os artefatos enviados pela
equipe de requisitos
Não é uma cópia do caso de uso, nossa nomenclatura é
diferente. Nós não referenciamos mensagens ou regras de negócios.
Nós as escrevemos literalmente, não sendo necessário nenhum outro
documento além do RTF para execução do teste.
É preciso atenção pois este documento pode nortear os testes de
aceitação.
Ele é composto por
Precondição - item que deve acontecer antes da ação. Ex. Estar
logado com determinado usuário // incluir um válido ou inválido
// preencher campos corretamente, etc.
Descrição dos passos - Este item é a AÇÃO. É o PASSO. É o que
você FAZ para conseguir o resultado esperado.
Resultado Esperado: Depois da precondição e da ação o que o
sistema deve fazer? O que o sistema deve dar como resposta? Aqui
colocamos a descrição da tela, a descrição dos campos bem como suas
nominações: Campos, combo boxes, text areas, radio buttons, check
boxes, list boxes, suas obrigatoriedades, quantidade de caracteres,
valores deafult e mais tudo que pode ser validado logo na primeira
leitura pelo executor de teste,
 Padrão de Tela: É a representação gráfica da tela, para que o
executor veja cores, padrão de campos, disposição dos itens na tela,
etc.

Massa de Teste
A massa de teste  deve ser usada em caso específico, onde há
valor correto de entrada e saída válida para orientar o executor de teste.
A massa de teste inventada pode ser facilmente trocada pelos
dados contidos na coluna precondição. E MAIS: O mínimo esperado de
um executor de teste é inventar dados para executar o teste.
 Exemplo RTF com massa de teste
2 – Casos de Teste
2.1 - Fluxo: Incluir Dados do Candidato (Ver Tela)
 
 2.1.1 – Padrão de Tela: Tela Incluir Cadastro

 
2.1.2 – Massa de Teste

Vamos agora ver a escrita de um Roteiro de Teste incluindo

as precondições - o mesmo caso acima. Note que não temos
mais a necessidade de massa de teste, pois a precondição nos
mostra como preparar o cenário pra conseguirmos o resultado
esperado.:
 2 – Casos de Teste
2.1 - Fluxo: Incluir Dados do Candidato (Ver Tela)
 2.1.1 – Padrão de Tela: Tela Incluir Cadastro
 
 Roteiro de teste - Gherkin
Gherkin é a linguagem comum usada no BDD. que com uma sintaxe e
semântica simples define um padrão para a documentação de cenários
de uso de um sistema. No BDD a especificação é feita maneira
independente da plataforma de execução focando no comportamento do
sistema. Ela nos dá a flexibilidade e a rapidez necessária para
entendimento e visualização dos requisitos de negócio do sistema.
 
A estrutura é.: Dado, Quando, E e Então.
 
Dado - é a precondição. Aquilo que temos que ter antes de começar
o teste.

Quando - é o passo. O caminho que temos que fazer para chegar no

resultado esperado

E - Uma condicional, opcional, que pode ser usada para ajudar na

escrita dos cenários.
 
Então - é o nosso resultado esperado. Então, é isso que deve
acontecer no sistema....
 Exemplo de passo a passo Gherkin

 
 Template - Sumário de teste:
O sumário de teste é a documentação que fazemos NO FINAL do
projeto de teste, para entrega. Reúne dados de como foram os testes,
os casos de uso/telas/módulos testados
Os insumos para o documento são retirados da planilha para gerar
gráficos de bugs por tela/Caso de Uso.
Os dados para a planilha são retirados dos BUGS cadastrados e
classificados corretamente
Seja através de um bugtracker - como o Mantis
Ou uma planilha de cadastro de atividades.
Por isso é preciso registrar e classificar os bugs, caso contrário, os
dados do sumário serão pobres e apenas textos, sem atrativos e
demonstrabilidade da execução do teste.
O SMT é composto pelos itens:

CAPA: com o nome do projeto e nome do cliente Histórico de

Revisões – quadro que apresenta as alterações do artefato ao longo do
andamento do projeto

Sumário
Introdução:
​Escopo – casos de uso/telas/módulos testados
​Referências – cadastro de bugs
Sumário dos Resultados dos Testes
​Considerações
Relatórios
​Gráficos ou Classificação dos bugs, exemplo:
 
Conclusões ➔​Avaliação dos Testes.
 Relatar Erros:
Excel

Grade com as opções de classificação dos erros:

Grade com especificação das informações contidas no relato de

erro.:
 
Word              

 
 Glossário e Conceitos
Artefato – Termo usado para designar os documentos produzidos
para o sistema.
Banco de Dados – Disciplina que cria, modela e implanta o banco
de dados de um projeto. É feito por um analista de banco de dados –
DBA
ECU – Especificação de Caso de Uso. Dividido em Fluxo Principal,
Fluxos Alternativos, Fluxos de Exceção e Pontos de extensão traz em
seu conteúdo o funcionamento e as regras de cada tela do sistema.
Engenharia de Software – Área da Computação que especifica a
manutenção e o desenvolvimento de sistemas de software aplicando
práticas da Gerência de projetos e outras disciplinas visando
produtividade, organização e qualidade.
GP – Gerente de Projetos.
Hint – Frase de ajuda que é exibida quando passamos o mouse por
cima de uma label, campo, ícone, etc.
Label – Palavra ou Frase de uma tela que não é editável.
MA – Metodologia Ágil que serão apresentadas pelo sistema.
MSG – Documento de Mensagem – Documento que especifica todas
as mensagens que serão apresentadas pelo sistema.
Processo de Desenvolvimento – Processo que norteia como um
software será desenvolvido. Este processo pode
 ser feito em vários modelos – tradicionais, como o Modelo Cascata,
espiral ou Prototipação. Ou por Contemporâneos - modelos ágeis, como
o Scrum.
PTE – Plano de Teste.

Requisitos – Disciplina que faz entrevistas com os clientes, coleta os

dados e os transforma em Especificações que norteiam o
desenvolvimento do projeto.
RTF – Roteiro de Teste Funcional
RN – Regras Negociais – Documento coma s regras de negócio que
norteiam os campos e as telas do sistema.
SCRUM – Metodologia ágil de desenvolvimento de software. Não
foca em documentação, mas na entrega contínua. Envolvimento de todo
o time com reuniões diárias para relatar o que fez, o que está fazendo e
o que fará. Usa o quadro Kanban para nortear as atividades do time ágil
expondo em post its as tarefas que são Novas, as que estão Em
Andamento e as que estão Prontas. O Scrum Master faz a função de
‘gerente’, porém a equipe deve ser auto gerenciável. O PO – Prodct
Owner é o cliente interessado no produto e produz o Backlog que é a
lista de tarefas priorizadas que serão realizadas pela equipe.
Script – Nome da linguagem que a ferramenta de automação
produz.
UC – Use Case.
 Referências Bibliográficas
AMARAL, Douglas. Como surgiu a expressão Bug? Publicação:
18/09/2013 Visualização: 30/04/2016
http://recantododragao.xpg.uol.com.br/2013/09/18/como-surgiu-a-
expressao-bug/.
COSTA, Ana Paula; DI VINCENZO, Leandro; DOMINGUES,
Aristides. A IMPORTÂNCIA DO TESTE PARA O PRODUTO FINAL:

Equipe bem treinada e valorizada faz a diferença na qualidade.

[Trabalho de conclusão de curso] Brasília: Centro Universitário Euro
Americano, Curso de Especialização em Teste de Software, 2010.
DIGITAL, Nômades. 40 frases inspiradoras para quem quer largar o
emprego e abrir seu próprio negócio. Publicação: 05/01/2015
Visualização: 02/08/2016 http://nomadesdigitais.com/40-frases-
inspiradoras-para-quem-quer-largar-o-emprego-e-abrir-seu-proprio-
negocio/.
HELM, Rafael; WILDT, Daniel. Histórias de Usuário. 2º Edição.
HistóriasDeUsuário.com.br.
ISTQB. Certified Tester - Foundation Level Extension Syllabus Agile
Tester. Versão 2014br.
ISTQB. Certified Tester -  Foundation Level Syllabus. Versão 2011br
ISTQB. Certified Tester -  Foundation Level Syllabus. Versão 2018br
ISTQB. Certified Tester - Foundation Level Extension Syllabus Agile
Tester. Versão 2014br.
 ISTQB. Certified Tester -    Advanced Level Syllabus Test
Manager (TM). Versão 2012br.
ISTQB. Overview - Foundation Level Extension Syllabus Agile Tester.
Versão 2014br.
KRUG, Steve. Não me faça pensar. Uma abordagem de bom senso
à usabilidade na Web e Mobile. Atualizado. 2ed.  Alta Books, 2015.
MANTIS, http://www.mantisbt.org/bugs/login_page.php Visualização:
06/03/2017
MOLINARI, Leonardo. Testes De Software. PRODUZINDO
SISTEMAS MELHORES E MAIS CONFIAVEIS. 4 ed. Erica 2003.
MYERS, Glenford J. The Art of Software Testing  2 ed. Nova Jérsei:
John Wiley & Sons, 2004. 
RIOS, Emerson; BASTOS, Anderson; CRISTALLI, Ricardo;
MOREIRA, Trayahú. Base de Conhecimento Em Teste de Software - 3
ed. 2012.
RIOS, Emerson; MOREIRA, Trayahú. Teste de Software. 3 ed.
revisada e ampliada. Alta Books, 2013.
RIBEIRO, Camilo. Myers e seus Trinta e Dois anos de Teste de
Software. Publicação: 20/02/2011 http://www.bugbang.com.br/myers-e-
seus-trinta-e-dois-anos-de-teste-de-software/. Visualização: 06/03/2017.
TECHMAN, Você sabe o que é um BUG e como surgiu esta
expressão? Publicação: 2015. http://www.techman.com.br/2015/02/voce-
sabe-o-que-e-um-bug-e-como-surgiu.html. Visualização: 10/03/2017