FERRAMENTAS DE TESTE

MANUAL
Teste:
 O processo de identificação dos bugs em um software (projeto/produto) é conhecido
como "Teste".
 O Engenheiro de Testes tem que verificar (validar) se o software desenvolvido está de
acordo com os requisitos do cliente ou não. Ele é responsável por entregar software de
qualidade para o cliente.

**Nota: A principal responsabilidade do engenheiro de testes é, ele tem que verificar

(validar) se o aplicativo desenvolvido (software) é útil para o usuário final ou não.

Bug: O desvio do requisito é conhecido como bug ou defeito.

Qualidade:A justificativa de todos os requisitos do cliente com facilidade de uso e

segurança é conhecida como qualidade.
 Vamos a um exemplo: Entregue/Lançado

Analista de Negócios Documento necessário Empresa DesenvolvedorProjeto/produto

Me Arquiteto Plano Construtor Construtor Casa

Cliente

Plano
Supervisor

Engenheiro de Testes

Projeto:
Será desenvolvido com base nos requisitos do cliente; Uma vez desenvolvido, será entregue ao
cliente. Com base na necessidade dos clientes, os membros da equipe (usuários finais) irão usá-
lo.
Ex: Spicejet.com, selenium4testing.com, Construindo casa própria com nossas
exigências.
Produto:
Ele será desenvolvido com base nos requisitos da empresa. Uma vez desenvolvido, ele será
lançado no mercado com base nas necessidades do cliente que ele escolherá o produto.
Ex:Aplicativo móvel, calculadora, Facebook, yahoo, MS Office, sistema operacional Mac,
sistema operacional Windows, Gmail etc...
Tipos de teste:

Ferramentas de teste

Teste Funcional Teste Não Funcional

Teste de Carga

Teste manual Teste de automação Teste de desempenho

Selênio, vencer corredor Stress Testing

QTP, RFT, silktest, Água, Watin Soak Testing

Aplicações baseadas na Internet:

Esses aplicativos podem ser acessados em todo o mundo com um número ilimitado de
usuários.

Ex: Gmail, Facebook, selênio 4testing

Aplicações baseadas em intranet:

Esses aplicativos também podem ser acessados em todo o mundo, mas com número limitado
de usuários.

Ex: Aplicativos que são limitados a uma organização específica.

Licitação do projeto:
Funções envolvidas:
1. Analista de Negócios de Marketing (BA)
2. Gerente de Engajamento (EM)

 Analista de Negócios de Marketing (BA):

Marketing BA irá atender o cliente e convencê-lo com a proposta. Uma vez que o cliente esteja
satisfeito com a proposta, o cliente e a empresa aprovarão o projeto.
 Aprovação:

O acordo oficial entre o cliente e a empresa sobre a entrega do projeto é conhecido

como 'sign off'.

Reunião de KickOff:

Assim que o projeto for assinado, a empresa irá para uma reunião de 'kickoff' . É uma
reunião rápida onde toda a alta gerência participará e eles anunciarão o projeto, o
cliente e escolherão o gerente de projeto para o projeto. O gerente de projeto é
responsável pelo SDLC.

 Gerente de Engajamento (EM):

O Engagement Manager é responsável por manter o relacionamento entre o cliente e a

empresa. Ele atua como uma ponte entre o Cliente e a Empresa.

Licitação do projeto
1 Cr
Cliente
Sobre a empresa 1 ano

História

Estimativas
Proposta Aprovação

Tempo & Custo

Reunião de Kick
C1 C2 C3
off

Gerente de Projetos 2cr 1.5 cr 1 cr

2 anos 1,5 anos 1 ano

Hierarquia de projeto ou hierarquia de designação ou hierarquia de função

LLM: Gestão de Baixo Nível

MLM: Gerenciamento de nível médio

HLM: Gestão de Alto Nível

CICLO DE VIDA DE
DESENVOLVIMENTO DE SOFTWARE (SDLC):
Consiste nas fases abaixo,

1. Fase de Requerimento
2. Fase de Análise
3. Fase de projeto
4. Fase de codificação
 5. Fase de testes
6. Fase de entrega e manutenção.

PIN:Nota de iniciação/intimação do projeto:

É um e-mail, será preparado pelo gerente de projeto onde contém a data de início e término do
projeto. O e-mail será enviado ao cliente e à gerência de alto nível.
O PIN indica o início do projeto.

1) Fase de exigência:
Funções:Analista de Negócios
Gerente de Engajamento
Gerente de Projetos

 A BA é responsável por coletar todos os requisitos em um documento modelo de

requisito (RTD).
 Uma vez que todos os requisitos são coletados no modelo de requisitos, em seguida,
eles aprovarão os requisitos,
 O documento assinado é conhecido como SRS (Software/system requirement
specification) ou BRS (Business requirement specification) ou FRS (Functional
requirement specification) ou BDD (Business design document) ouBD (Business
document document).
 Uma vez que o documento SRS é baseline, o BA é responsável porPOC (Proof of
concept).
 Durante a POC a BA é responsável por desenvolver o protótipo e ele será apresentado
ao cliente.

Protótipo: É uma aplicação de amostra áspera e rapidamente desenvolvida; ele não

contém nenhuma das funcionalidades reais. Ele simplesmente descreve como o projeto
vai ser e como ele vai ser exibido. O principal objetivo do protótipo é coletar todos os
requisitos corretamente e entender todos os requisitos corretamente.

 O Engagement Manager é responsável por manter o Rapport ou Relacionamento entre

o cliente e a empresa. Ele também se concentrará nos requisitos extras, custo extra e
tempo extra do projeto.
 O Gerente de Projetos é responsável por monitorar as fases e ajudará tanto o BA quanto
o EM a concluir suas atividades adequadamente.
Nota: O resultado da fase de requisitos é SRS e Prototype

2) Fase de Análise:Analisando os requisitos.

 Funções:Gerenciamento de alto nível
Gestão de nível médio
Gerente de Projetos
BA

 Todas as funções acima serão reunidas para uma reunião e elas executarão as
atividades abaixo
a. Estudo de viabilidade
b. Seleção de tecnologia
c. Plano de recursos
d. Plano H& S
a. Estudo de viabilidade: Factível significa possível ou não. As funções acima
atenderão a todos os requisitos no documento SRS. Os requisitos serão
analisados e eles vão identificar se é possível desenvolver ou não, se é possível
desenvolver então eles vão identificar quanto tempo é necessário para
desenvolver, testar e entregar para o cliente. Se algum requisito não for viável
de desenvolver, eles informarão ao cliente.
b. Seleção de tecnologia: A lista de tecnologias como Java, .net, MSSQL, Oracle,
selenium etc. são necessários para o desenvolvimento do projeto, testes e
entrega ao cliente serão descritos aqui. Com base nas tecnologias, eles
contratarão os recursos.
c. Plano de Recursos:O número de recursos como desenvolvedores, engenheiros
de teste, engenheiros de banco de dados são necessários para o
desenvolvimento e teste do projeto será descrito aqui.
d. Plano de hardware e software:O número de hardwares como desktops, laptops,
celulares, impressoras etc... Com softwares relacionados são necessários para o
projeto será descrito aqui.

 Todos os itens acima serão documentados em documento chamado plano de projeto.

Será enviado ao cliente, para análise.

3) Fase de projeto:
Papéis: Arquiteto/arquiteto chefe
Analista de Negócios (BA)
Gerente de Projetos
  O arquiteto analisará todos os requisitos do documento SRS, enquanto analisa se
quaisquer esclarecimentos são necessários sobre os requisitos, então a BA é
responsável por limpar todos os requisitos não compensados.
 Uma vez que o arquiteto é claro sobre todos os requisitos, em seguida, ele irá dividir os
requisitos em vários módulos e submódulos. O grupo de requisitos relacionados é
conhecido como 'Módulo'.
 Uma vez que todos os módulos são divididos, então ele fornecerá o diagrama
arquitetônico (fluxograma) de todo o projeto com a ajuda de UML (linguagem de
modelagem unificada)
 Todos os itens acima serão documentados em um documento chamado Design
document ou SRS.

4) Fase de codificação:
Funções: Desenvolvimento de equipe
Equipe de testes
BA
Gerente de Projetos

 Uma vez que os módulos são divididos por arquiteto, eles serão atribuídos aos
desenvolvedores, bem como à equipe de testes.
  Os desenvolvedores são responsáveis por desenvolver o código-fonte dos módulos.
Uma vez que o código-fonte esteja estável, eles farão o check-in do código-fonte no
repositório central.
 O líder de desenvolvimento fará checkout do código-fonte para seu sistema local, em
seguida, o líder de desenvolvimento construirá o código-fonte e a compilação será
liberada para a equipe de teste para teste.

Repositório Central:

Repositório significa uma pasta de armazenamento. Repositório Central significa a pasta

que é comumente acessível a todos os recursos na organização. Ele contém todos os
arquivos seguros.
Ex: SVN- Sub Versão
VSS- Fonte visual segura
TFS- Servidor do Team Foundation
CVS- Sistema de Versão Simultânea
Perforce, Github
Check-in:O processo de upload dos arquivos do sistema local para o repositório central é
conhecido como Check-in ou Confirmação.

Confira: O processo de download dos arquivos do repositório central para o sistema local é
conhecido como Check-out.

Build:O processo de conversão do código-fonte em código executável é conhecido como Build.

5) Fase de testes:
Papéis:Engenheiros de Teste
Equipe de desenvolvimento
Analista de Negócios (BA)
Gerente de Projetos

 Uma vez que o documento SRS é alinhado com base (Concluído), ele será enviado para a
equipe de desenvolvimento, bem como para a equipe de teste.
 A equipe de desenvolvimento é responsável por revisar o documento SRS, entendê-lo e
desenvolver a compilação.
 A equipe de testes também é responsável por revisar o documento SRS. Durante a
revisão, se forem identificados requisitos pouco claros (Dúvidas), estes serão atualizados
no documento denominado "Relatório de Revisão (RR)".
 O relatório de revisão será enviado para o líder da equipe, onde ele consolidará (Faça
um documento) todos os relatórios de revisão em um único documento chamado
"Relatório de revisão consolidado (CRR)" e será enviado para o BA.
 BA é responsável por revisar todos os requisitos obscuros e ele fornecerá os
esclarecimentos, em seguida, o "Relatório de revisão atualizado (URR)" será enviado
para a equipe de testes
 A equipe de testes analisará novamente o documento do SRS com esclarecimentos.
 Uma vez que a equipe de teste é muito clara sobre todos os requisitos, então eles
pegarão o modelo de caso de teste e escreverão os casos de teste para todos os
requisitos.
 Os documentos dos casos de teste serão enviados para o BA. Onde ele irá analisá-lo e
ele fornecerá os comentários se quaisquer novos casos de teste são necessários para ser
adicionado.
 Com base nos comentários da BA, a equipe de testes atualizará os casos de teste.
 Uma vez que os casos de teste são alinhados base (concluídos), ele será enviado ao
cliente para revisão final.
 Depois que a compilação for liberada para a equipe de teste, eles executarão todos os
casos de teste na compilação.
 Durante o teste da compilação, se algum Bug for identificado, ele será relatado
(enviado) para a equipe de desenvolvimento. O desenvolvedor irá corrigi-lo e enviá-lo
de volta para a equipe de teste para teste.
 O Test Engineer testará se o bug foi realmente corrigido ou não e, ao mesmo tempo,
verificará se há outros bugs.
 Se identificado, será reportado ao desenvolvedor.
 O mesmo processo será continuado até que a compilação esteja estável (livre de bugs
ou sem bugs).
 A compilação estável será entregue ao cliente.
 6) Entrega e Manutenção:
Papéis:Engenheiros de Teste
Equipe de desenvolvimento
Analista de Negócios (BA)
Gerente de Projetos
Cliente

Entrega:Quando a compilação estiver estável no ambiente de teste, a equipe de teste (TL)

enviará um e-mail para o gerente de projeto dizendo que a compilação é estável, então o
gerente de projeto entregará a compilação ao cliente.

 O cliente implantará a compilação no ambiente de estágio e executará testes.

 O ambiente de estágiot é o ambiente comum onde a equipe de teste e a equipe do
cliente testarão o aplicativo antes que ele entre no ar. Também é conhecido como
ambiente de pré-produção.
 Quando a compilação estiver estável no ambiente de estágio, o cliente implantará a
compilação no ambiente ao vivo ou de produção.
 Uma vez que a compilação é implantada com sucesso no ambiente de produção/ao
vivo, podemos concluir que o projeto é entregue com sucesso ao cliente.
Manutenção:
«Ao vivo» significa onde o cliente ou os utilizadores finais estão a utilizar a aplicação. A
manutenção será continuada enquanto a aplicação estiver no ar.

ManutençãoFase TAT Corrigindo os bugs,

Cliente
Tempo de resposta CRs
BA/PM/TL
3 Bugs
(Aprimoramento)
3 CRs Companhia

12/24 Horas 3 Bugs – 3 dias

3 CRS – 4 dias

7 dias

 Uma vez que o projeto é entregue com sucesso ao cliente e é implantado com sucesso
no ambiente de produção/ao vivo, a manutenção do projeto será iniciada.
 Durante a manutenção a empresa é responsável por duas atividades.
a) Corrigindo os bugs.
b) Atualizando os aprimoramentos/solicitações de alteração CRs.
 Enquanto o projeto estiver no ar, a manutenção do projeto será continuada.
 De acordo com a aprovação (Acordo) inicialmente a empresa estará fornecendo
manutenção gratuita por até 3 a 5 anos (depende da aprovação do projeto).
 Uma vez concluído o período de manutenção gratuita, o cliente renovará o contrato de
manutenção.
  Sempre que o cliente está enviando algum bug e CRS então, da empresa alguém
(Desenvolvedor, BA, Testador) tem que enviar o e-mail de confirmação para o cliente
dentro do TAT (Tempo de Resposta) acordado conforme o acordo, pode ser 12/24
horas.
 O e-mail contém o número de horas que vamos levar para corrigir e entregar a nova
compilação para o cliente.
 Enquanto o projeto estiver no ar, a manutenção do projeto será continuada

Q. Que tipo de aplicativos você testou?

TIPOS DE APLICAÇÕES:

Existem três tipos de aplicações que podem ser testadas;

1) Aplicações Web
2) Aplicações Desktop
3) Aplicações Mobile

1) APLICAÇÕES WEB:

Esses aplicativos são acessados com a ajuda de algum navegador.

É de dois tipos
a) Aplicativos de arquitetura de 3 camadas.
b) Aplicativos de arquitetura N-Tier.

Ambiente/Sistema:

Todas as aplicações são combinações do ambiente.

O ambiente contém:
1. Camada de apresentação.
2. Camada de negócios.
3. Camada de banco de dados.
AMBIENTE
CAMADA APLICAÇÃO APRESENTAÇÃO/CLIENTE

Solicitar Resposta
SERVIDOR
CAMADA DE NEGÓCIOS

Solicitar Resposta
BANCO DE
DADOS CAMADA DE BANCO DE DADOS

1º. Camada de apresentação:

O Front-end que o usuário final vai acessar é conhecido como camada de

apresentação/cliente.

2. Camada de negócios:

É o servidor o responsável por atender a solicitação. Isso significa que ele pegará
a solicitação do aplicativo, enviará para o banco de dados, pegará a resposta do
banco de dados e a enviará de volta ao aplicativo. Todo o processo é conhecido
como atendimento ao pedido.

Ex: Tomacat, JBoss, Weblogic, WebSphere, IIS

3. Camada do banco de dados:

A camada de banco de dados é responsável por armazenar os dados na forma de

tabelas.
Ex: MS SQL, Meu SQL, ORACLE

a) Aplicativos de arquitetura de 3 camadas:

Em aplicações de arquitetura de 3 camadas, as 3 camadas acima estão disponíveis em três

máquinas diferentes (camadas) que chamaremos de camadas. Por isso, eles são chamados
de aplicativos de arquitetura de 3 camadas.

Ex: PL - Navegador
SErver - Tomacat
 Banco de Dados - Oracle

b) Aplicativos de arquitetura N-Tier:

É o mesmo que como aplicações de arquitetura de 3 camadas com base no número de

usuários (carga), teremos mais número de servidores e bancos de dados.

Com base na solicitação de carga, a lógica de negócios será distribuída entre os servidores e os
DB's. Por isso, vamos chamá-lo de aplicativos de ambiente distribuído.

.PL .PL .PL

Servidor Servidor Servidor

BL

.DB .DB .DB

DBL

2) APLICAÇÕES DESKTOP:

Esses aplicativos podem ser acessados sem qualquer navegador.

Ex: Skype, calculadora, MS Office, vlc player etc.
É de dois tipos:
 1 Nível
 2 camadas

 1 camada:

Essas aplicações são limitadas a um sistema específico (PC). Todas as 3 camadas PL, BL e
DBL estarão disponíveis apenas nesse sistema específico.
Ex: VLC jogador, Calc
 2 camadas:

A camada de apresentação estará disponível em um sistema a camada de negócios e a

camada de banco de dados estará disponível em outro sistema, com a ajuda de
LAN/WANwe pode acessar essas aplicações de vários sistemas. Por isso, vamos chamá-lo de
aplicativos de camada 2, também é conhecido como aplicativos de arquitetura cliente-
servidor.
Ex: Skype

NOTA:Para Aplicações Desktop precisamos instalar o aplicativo no lado do usuário / cliente,

então apenas nós arcane capaz de acessá-lo. Para executar testes para aplicativos de desktop,
precisamos executá-lo tanto no cliente quanto no servidor.

Para aplicativos Web, precisamos testá-los somente no cliente.

(BL)

Servidor + DBL

Aplicaç
ão

LAN WAN LAN

M1 M2 M3
.PL

3) APLICAÇÕES MÓVEIS:
Os aplicativos que podem ser acessados na plataforma mobile são conhecidos como
Aplicativos Móveis.
 Ex: Android, IOS, Blackberry, Windows etc.

São de três tipos

uma. Aplicações Nativas

b) Aplicações Web
c) Aplicações Híbridas

a. Aplicações Nativas:

Esses aplicativos podem ser acessados sem qualquer navegador.

Ex: Viber, funcionalidade de chamada, msg, relógio etc.

b. Aplicações Web:

Esses aplicativos podem ser acessados com a ajuda do navegador no celular.

Ex: selenium4testing.com

c. Aplicações híbridas:

Esses aplicativos podem ser acessados tanto sem navegador quanto com navegadores .
Ex: Gmail / Gmail app, Facebook / Facebook app, Banking Websites / App etc.

NOTA:Aplicativos ForWeb não é necessário instalar o aplicativo no lado do usuário / cliente,

pois somos capazes de acessar com a ajuda do navegador. Para realizar testes para aplicações
web precisamos realizá-lo apenas no cliente.

METODOLOGIAS DE TESTES:

P:Quem é responsável pelos testes. Em que nível o Engg. de Teste. envolverá em testes
São de três tipos

um. Teste de caixa preta

b. Teste de caixa branca
c. Teste de caixa cinza

a. Teste de caixa preta:

Se o recurso estiver realizando testes na parte funcional do aplicativo, ele será tratado
como "testador de caixa preta".
 Parte funcional significa se a aplicação desenvolvida está de acordo com os requisitos do
cliente ou não. Testadores realizarão testes de caixa preta em ambiente de teste e estágio env
(pré-produção env)

b. Teste de caixa branca:

Se o recurso estiver testando a parte estrutural (programação) do aplicativo, ele será

tratado como "testador de caixa branca". Os desenvolvedores são responsáveis pelos testes de
caixa branca no ambiente de desenvolvimento.

c. Teste de caixa cinza:

Se o recurso estiver tendo a experiência em ambos os testes (teste de caixa branca e

teste de caixa preta). Em seguida, ele será tratado como "testador de caixa cinza".

NÍVEIS DE TESTE:
Se um projeto tem que passar da fase de aprovação para a produção ao vivo, ele tem que
passar pelos níveis abaixo de testes.

1) Nível unitário de teste

2) Teste de nível de módulo
3) Nível de integração dos testes
4) UAT(Teste de aceitação do usuário)
5) Teste do sistema

1) Nível de unidade de teste: Unidade significa o menor fluxo ou cenário no aplicativo.

 O desenvolvedor é responsável pelos testes de nível de unidade.
 Ele dividirá o módulo atribuído em várias unidades e desenvolverá o código para
todas as unidades.
 Ele é responsável por verificar se toda e qualquer unidade está funcionando
conforme o esperado ou não.

2) Teste de nível de módulo:

 A partir do teste de nível de módulo, tanto a equipe de teste quanto a equipe de
desenvolvimento são responsáveis.
 O desenvolvedor combinará todas as unidades relacionadas para formar um
módulo.
  Uma vez que o módulo é desenvolvido, o desenvolvedor é responsável pelos
testes de caixa branca no ambiente de desenvolvimento.
 Uma vez que o módulo é liberado para a equipe de testes, eles são responsáveis
pelos testes de caixa preta no ambiente de teste.

3) Teste de nível de integração:

 O processo de combinação de todos os módulos desenvolvidos é conhecido
como integração.
 Verificar se o fluxo de dados está navegando de um módulo para outro é
conhecido como teste de nível de integração.
 Tanto a equipe de desenvolvimento quanto a equipe de testes são responsáveis
pelos testes de nível de integração.
Ex: Crie uma conta no Gmail, verifique se você está conseguindo fazer login no
aplicativo com a conta criada. Em seguida, componha o e-mail e envie-o,
verifique se ele está devidamente entregue ou não.
 Enquanto a integração, se algum módulo obrigatório estiver faltando, o Lead de
desenvolvimento substituirá o módulo obrigatório por algum código fictício
conhecido como stub ou driver.

D1 D2 D3 D4 D5
+ + + + +
Credenciais Login Compor Enviar Logout

Stub/Motorista:Ambos nada mais são do que um código fictício, não contém

nenhuma funcionalidade.

 Se o líder de desenvolvimento estiver usando a abordagem de cima para baixo

para integrar os módulos, enquanto a integração se algum módulo obrigatório
estiver faltando, ele será substituído pelo Stub.
  Se o líder de desenvolvimento estiver usando a abordagem de baixo para cima
para integrar os módulos, enquanto a integração estiver faltando algum módulo
obrigatório, ele substituirá por Driver.

4) Teste de aceitação do usuário:

 É conhecido como teste de aceitação do usuário/cliente. Uma vez que a
compilação é estável no ambiente de teste, então vamos planejar para entregar
a compilação para o cliente. Antes de entregar a compilação ao cliente, o cliente
enviará casos de teste de aceitação do usuário para a equipe de teste para
execução.
 A equipe de teste executará todos os casos de teste de UA no ambiente de teste;
Se todos forem aprovados, o gerente de projeto entregará a compilação ao
cliente.
 O cliente novamente executará todos os casos de teste de UA no ambiente do
cliente (ambiente de estágio). Se todos forem passados, o cliente implantará a
compilação no ambiente Live ou Production.
 O UAT é de dois tipos:

um.Teste Alpha
b. Teste Beta UAT

Teste alfa Teste beta (UATCS)

(UATCs) Ambiente de testeAmbiente de estágio

um. Teste alfa:A execução de todos os casos de teste de UA em um ambiente de teste

pela equipe de teste é conhecida como 'teste Alpha'.

b. Teste Beta:A execução de todos os casos de teste de UA no ambiente de estágio do

cliente pela equipe do cliente ou pela equipe de teste é conhecida como 'teste beta'.

Uma vez que o teste Beta é aprovado, em seguida, o cliente irá para o ambiente ao vivo.

Ambiente de teste Cliente

Construir (UATCS) passar

Desenvolvimento da Começar
equipe de teste Entregar

UATCS

5) Teste do sistema:
 Também é conhecido como teste não funcional. Uma vez que o aplicativo é
estável, então podemos ir para testes não funcionais.
 Nos testes não funcionais será identificado o desempenho (tempo de resposta)
da aplicação.
 O tempo entre a solicitação e a resposta é conhecido como tempo de resposta.
Ele será identificado com a ajuda de vários tipos de testes não funcionais, como
teste de carga, teste de desempenho, teste de estresse, teste de ponto de
ruptura.
MODELOS DE DESENVOLVIMENTO DE SOFTWARE:
Q. Qual processo você usou para desenvolver seu projeto

Os modelos são os seguintes.

1) Modelo em cascata
2) Modelo espiral
3) Modelo em V
4) Modelo de Peixe
5) Processo ágil

1) Modelo Cascata:
Foi o processo ou modelo inicial introduzido para o desenvolvimento de software
(processo antigo). A execução sequencial de todas as fases em SDLC é conhecida como
modelo de queda d'água. Uma vez concluída a fase, a alta administração analisará essa
fase.

NOTA: Como cascatas de um nível para outro, da mesma forma as fases do SDLC
serão implementadas.

Vantagens:

 É muito fácil implementar o projeto porque é Execução Sequencial.

Desvantagens:
  O risco não pode ser identificado na fase inicial do ciclo de vida, pelo que não
pode ser evitado.
 É um processo demorado, bem como um processo dispendioso.
 Não podemos aceitar a mudança de requisitos no meio do projeto. Se ainda
precisar ser aceito, aceitaremos a mudança de requisito na forma de solicitações
de mudança de CRs. As solicitações de alteração são feitas ao final do projeto e
os CRs cobrados pela empresa.

mês

2) Modelo Espiral:

 O modelo espiral é uma combinação de modelo em cascata e protótipo.

  Em vez de recolher todos os requisitos uma vez, o BA recolhe poucos requisitos; Ele
será analisado e projetado com a ajuda do protótipo. Em seguida, será dado ao
desenvolvimento.
 Assim que o desenvolvedor desenvolver a compilação, ela será liberada para a
equipe de testes. O mesmo processo será continuado para todos os requisitos.
 Uma vez que todos os requisitos são concluídos e a compilação é estável, então a
compilação será entregue ao cliente.

Vantagens:

 Podemos economizar tempo e custo, pois estamos executando todas as fases em

paralelo.
 O risco pode ser identificado na fase inicial do SDLC e pode ser prevenido na fase
inicial do ciclo de vida.
 A mudança de requisito pode ser aceita no meio do processo.

Desvantagens:

 Está tendo o enorme risco de entrega, por causa dos prazos agressivos (menos
tempo).
 Não é possível aceitar alteração de requisito no estágio final do projeto para evitar
risco de entrega.

3) Modelo V (Modelo de Verificação e Validação):

 Validação:

Também é conhecido como "QC" (Controle de qualidade). A equipe de testes é

responsável pela validação. A equipe de testes verificará se o software desenvolvido
está de acordo com a exigência do cliente ou não.

Os engenheiros de teste são validadores.

Verificação:

Def1: Verifique se todo e qualquer documento de resultado de fase está de acordo com
as diretrizes da empresa e do cliente ou não.

Def2:Verifique se toda e qualquer função na organização está funcionando de acordo com o

Empresas e clientes orientam linhas ou não. A verificação também é conhecida como
QA (Quality Assurance).

O grupo de gestão de projectos/processos (PMG) ou o grupo de auditoria são responsáveis pela

verificação.

 A partir do modelo V, até mesmo a equipe de testes participará da coleta de

requisitos.
 A BA é responsável por coletar os requisitos, paralelamente a equipe de testes
estará analisando todos os requisitos para verificar se é possível testar ou não.
 Uma vez que o SRS é baseline, a equipe de validação é responsável pelo plano de
teste
 Com base nas fases de análise e projeto, a equipe de validação está preparando o
plano de teste do sistema e o plano de projeto.
 Uma vez que o código é desenvolvido, eles liberarão a compilação para a equipe de
teste, onde executarão todos os níveis de teste. Uma vez que a compilação é estável
ele será entregue ao cliente.

Vantagens:
  As atividades de teste são iniciadas a partir da fase de exigência para que possamos
garantir a qualidade.
 Para cada fase, a equipe de verificação e a equipe de validação verificarão as fases
para que possamos garantir a qualidade.
 O risco pode ser identificado na fase inicial, porque temos uma atividade de
testagem paralela, para que possa ser prevenida.
 Podemos aceitar a mudança de requisito no meio da fase.

Desvantagens:

 É um processo demorado e caro, mas podemos garantir a qualidade.

4) Modelo de peixe:

 É o mesmo que o modelo em v.

 No modelo fish teremos várias equipes de Verificação do cliente e da empresa para
verificar o processo e proporcionar mais qualidade e segurança.
 É mais caro que o modelo v.
 Proporciona mais segurança e é aplicado em projetos de segurança de alto nível
como NASA, Força Aérea, Marinha, Exército etc.
Nota: A equipe de validação analisará os resultados dos casos de teste de unidade
quando a compilação estiver em desenvolvimento
5) Processo ágil:

 É ter vários submodelos como adaptativo, Scrum, modelo iterativo etc... O modelo
que vamos usar é o modelo scrum.
 É um modelo iterativo e incremental. O modelo Scrum está tendo as atividades
abaixo.
a. Scrum mestre
b. Histórias de usuários
c. Scrum meeting/scrum calls/DSM
d. Plano de sprint
e. Reunião da Sprint
f. Atrasos

a. Scrum master:

O scrum master é quem vai liderar o projeto. O gerente de projeto ou o cliente atuará
como um scrum master. O Scrum Master é responsável por reuniões scrum e sprint.

b. Histórias de usuários:
Os requisitos serão capturados na forma de fluxos usados pelo usuário final (maneiras
usadas pelo usuário final). Por isso, vamos chamá-lo de User stories. BA é responsável
por recolher

c. Reunião Scrum:

 No dia a dia, todos os membros da equipe participarão de uma rápida reunião

onde descreverão quais atividades foram realizadas ontem e quais tarefas estão
planejadas para realizar hoje e se há desafios.
 Todos os membros da equipe, incluindo o scrum master e o cliente, devem
descrever.
 O principal objetivo do scrum meeting é acompanhar os recursos e também
manter a transparência.

d. Plano de sprint:

 Sprint é período de tempo fixo pode ser uma semana / duas semanas / três
semanas etc. Será decidido pelo scrum master.
 O plano Sprint é, para colecionar histórias de usuários, analisar, desenvolver,
testar e entregar ao cliente.
 Durante o sprint, se não conseguirmos completar qualquer um dos requisitos, o
sprint não será estendido. E os requisitos pendentes devem ser levados para o
próximo sprint. Sprint é um período de tempo fixo

e. Reunião Sprint:

Assim que a sprint for concluída, o próximo plano de sprint será decidido na reunião de
sprint. Eles discutirão, se o sprint atual é entregue com sucesso ou não, se há algum
desafio enfrentado.

f. Atrasos:

Durante o plano de sprint, se alguma história de usuário não puder ser realizada, elas
serão tomadas como Backlogs. Essas pendências devem ser concluídas no próximo
sprint.

É de dois tipos,

(i) Pendências do produto

(ii) Lista de pendências da Sprint
 Carteira de produtos: Os Requisitos (histórias de usuários) que vamos coletar,
desenvolver, testar e entregar ao cliente como parte do plano de sprint são
conhecidos como backlogs de produtos.
Sprint Backlog: Os Requisitos que não forem concluídos como parte do plano de
sprint serão tratados como sprint backlog.

Vantagens:

 Cada sprint será testado várias vezes pela equipe de testes e pelo cliente, para que
possamos garantir a qualidade.
 Todas as fases em SDLC são realizadas em paralelo y para que possamos economizar
tempo e custo.
 A alteração de requisito pode ser aceita em qualquer etapa do projeto (mesmo após a
entrega do sprint).
 O risco pode ser identificado na fase inicial e pode ser prevenido
 Podemos manter a transparência do projeto.
 O cliente também participará de reuniões scrum, para que possamos obter as
informações muito rapidamente.
 Todo e qualquer sprint é entregue ao cliente para que não tenhamos risco de entrega.
 Podemos conquistar a satisfação do cliente entregando todos os sprints para o cliente.
 Sprint também é conhecido como iterativo. Seu modelo iterativo e incremental
Desvantagens:

Manter todas as informações relacionadas ao sprint é uma tarefa muito desafiadora, mas
podemos superar com a ajuda de ferramentas de gerenciamento de testes como Scrum wise,
Quality Center, JIRA e link de teste etc.

Tipos de teste funcional (ou) Tipos de teste de caixa preta :

1) Teste de fumaça:

 Uma vez que a compilação é desenvolvida e implantada em qualquer ambiente, então o

teste inicial será realizado, que é conhecido como teste de fumaça. Inicialmente, a
equipe de desenvolvimento implantará a compilação no ambiente de desenvolvimento
e executará o teste de fumaça. Eles verificarão se cada módulo relacionado ao campo
está navegando corretamente em suas páginas ou não e verificarão a funcionalidade
principal do aplicativo. O objetivo do teste de fumaça é verificar se a construção está
pronta para novos testes ou não. O desenvolvedor se concentrará em testes de caixa
branca
 Se todos esses campos estiverem navegando corretamente para as páginas
relacionadas, eles concluirão que o teste de fumaça foi aprovado.

2) Teste de sanidade:
 Depois que a compilação for implantada no ambiente de teste, a equipe de teste
executará o teste de fumaça no ambiente de teste. É conhecido como teste de
sanidade.
 No teste de sanidade, a equipe de testes realizará pelo menos uma rodada da
funcionalidade de fluxo principal e verificará se está funcionando corretamente ou não.
 Se o teste de sanidade for aprovado, a equipe de teste executará todos os casos de
teste, se falhar, rejeitará a compilação para a equipe de desenvolvimento.

Ex para Fluxo principal: Crie uma conta no Gmail e faça login nessa conta e escreva um
e-mail e envie para um e-mail válido e verifique se ele está entregue corretamente ou
não.

Nota:Uma vez que o teste de sanidade é realizado, a equipe de teste (líder de teste) tem que
enviar um e-mail com os resultados do teste de sanidade para a equipe de desenvolvimento.
 3) Teste pré-SRN:SRN - Notas de versão do software

 Ele contém o status de compilação como, número de módulos disponíveis na

compilação para teste.
 Número de módulos em desenvolvimento.
 Número de stubs e drivers estão disponíveis na compilação.
 Número de bugs que são corrigidos e disponíveis na compilação.
 Número de bugs que estão em desenvolvimento
 Diretrizes de implantação, etc.

 Antes de liberar o documento SRN junto com a compilação para a equipe de teste, a
equipe de teste executará o teste de fumaça no ambiente de desenvolvimento,
conhecido como Teste Pré-SRN
 Também é conhecido como Teste de aceitação de compilação (BAT) ou teste de
verificação de compilação (BVT).

Nota: Depois que a compilação for liberada para a equipe de teste, os engg's de teste
analisarão o documento SRN para saber o status da compilação (o que a compilação contém).
Em seguida, o teste realizará o teste de sanidade.

2. A ordem é inicialmente a equipe de Dev realizará testes de fumaça, em seguida, a equipe de

testes realizará testes de Pré-SRN no Dev Env. Se ambos forem aprovados, a equipe de
desenvolvimento liberará a compilação para a equipe de teste, em seguida, o teste executará o
teste de sanidade
 4) Teste de GUI/UI:
Teste de interface gráfica com o usuário. As cinco atividades abaixo serão testadas em GUI.

 Verifique a ortografia de todos os campos.

 Verifique a fonte de todos os campos onde deve manter a consistência.
 Verifique a cor e os alinhamentos de todos os campos que devem manter a
consistência.
 Verifique a aparência geral da página

5) Teste de regressão:

A execução de testes em funcionalidades já testadas nas compilações iterativas e incrementais

é conhecida como 'Teste de Regressão'.

Será realizada de duas formas:

 Sempre que algum bug for identificado, ele será reportado ao desenvolvedor, o
desenvolvedor irá corrigi-lo, em seguida, ele irá liberar o bug corrigido na forma de nova
compilação (Build2) para a equipe de testes. O engenheiro de teste irá testar novamente,
para verificar se o bug está realmente corrigido ou não.
 Os casos de teste que são passados na compilação antiga serão executados novamente
na nova compilação e verificarão se eles estão funcionando da mesma forma que a
compilação anterior ou não.
 Testar funcionalidades já testadas é testar regressão. Testar as novas funcionalidades não é
o teste de regressão. Ele está em execução de caso de teste.

Nota:Se alguma atualização de código estiver lá, esse novo código pode afetar o código
existente, então estamos executando o teste de regressão.

6) Reteste:

 Executar testes nas mesmas funcionalidades repetidamente com vários conjuntos de

dados de teste diferentes na mesma compilação é conhecido como 'Reteste'.
 A execução dos casos de teste com falha nas compilações iterativas e incrementais
também é conhecida como "Reteste".

Dados de teste:Os dados que a equipe de teste está usando para testar são conhecidos
como "Dados de teste".

Ex: 1. Teste a funcionalidade de login do Gmail com vários conjuntos de diferentes

credenciais.

2. Teste a pesquisa unidirecional do spicejet com os vários conjuntos de

diferentes origens e diferentes passageiros.

P: Qual é a diferença entre Teste de Regressão e Reteste

P: Qual é a diferença entre o Teste de Regressão e o Teste de Nível de Integração

7) Teste de ponta a ponta:

O engenheiro de teste precisa identificar todos os cenários usados pelo usuário final do
aplicativo e verificar se os cenários de ponta a ponta estão funcionando corretamente ou não

Ao realizar testes de ponta a ponta, podemos alcançar testes de nível de integração

Ex: O cenário de ponta a ponta para o Gmail.

 8) Testes de compatibilidade:

 Testar se o aplicativo está funcionando da mesma forma que o esperado em todos os

ambientes de destino ou não é conhecido como 'teste de compatibilidade'. Ambiente é
combinação de SO, Browser, Server, DB etc.
 O teste de compatibilidade é de dois tipos: "teste entre navegadores" e "teste entre
plataformas".
 Teste se o aplicativo web está funcionando como esperado em todos os navegadores de
destino como firefox, safari, google chrome, IE etc. é conhecido como "teste entre
navegadores".
 Teste se o aplicativo de desktop está funcionando como esperado em diferentes
plataformas ou sistemas operacionais como windows, LINUX, MAC, Solaris etc. é
conhecido como "teste multiplataforma".

Ex para testes entre navegadores: Teste se o spicejet está funcionando nos ambientes abaixo
ou não.

Windows – Internet explorer, Firefox, Google chrome, Safari, Opera

Linux - Internet explorer, Firefox, Google chrome, Safari, Opera

MAC - Firefox, Google chrome, Safari, Opera

Ex para testes entre plataformas:Teste se o skype está funcionando nas plataformas ou

ambientes abaixo
 Windows
Linux
MAC e Celular

Nota: Sempre que estamos realizando testes de compatibilidade, precisamos nos

concentrar mais na GUI do aplicativo

9) Testes de usabilidade:

 Usabilidade significa facilidade de uso. O engenheiro de teste tem que fornecer

usabilidade ao aplicativo para a satisfação do usuário final.
 Depende da aplicação que temos para fornecer a usabilidade.

Ex: Para o aplicativo bancário (seguro) temos que fornecer mais segurança, enquanto para sites
sociais (Face book, twitter), precisamos fornecer mais facilidade de uso.

10) Testes Adhoc:

 Adhoc significa à nossa maneira.

 Teste adhoc significa testar a aplicação à sua maneira, Depois de entender todos os
requisitos e pelo menos uma rodada de testes manuais é concluída na aplicação
 O principal objetivo do teste adhoc é fornecer usabilidade ao aplicativo.
 11) Testes exploratórios:

 Exploratório significa identificar o novo requisito / novo recurso. Uma vez que a
compilação é estável, os especialistas do domínio testarão o aplicativo de acordo com
seu conhecimento de domínio, enquanto testam eles explorarão se os requisitos
existentes são suficientes, se não eles fornecerão os novos requisitos.
 O principal objetivo dos testes exploratórios é fornecer usabilidade e segurança ao
aplicativo.

12) Teste de macacos/teste de gorila:

 Uma vez que o aplicativo é estável, então podemos ir para o teste de macaco.
 Executar testes no aplicativo fazendo algumas ações anormais é conhecido como teste
de macaco/gorila.
 Ações anormais significa clicar continuamente em algum campo por um longo período
de tempo e verificar se o aplicativo está travando ou não.
 Teste o aplicativo com dados inválidos, como tags HTML (<html>) e verifique se o
aplicativo está travando ou não.
Nota: O objetivo do teste de macaco é verificar se o aplicativo está travando ou não
(Meios obterá servidor não encontrado exceção)

13) Testes estáticos:

 Testar o aplicativo sem executar nenhuma ação é conhecido como teste estático.

Ex:1. Teste de GUI

2. Validações:- verificar a disponibilidade dos campos na página vem sob teste
estático.

14) Testes dinâmicos:

 Testar o aplicativo executando alguma ação é conhecida como teste dinâmico.

Ex: Testes de regressão, retestes, testes Adhoc etc...

 15) Teste de autenticação:

 Autenticação significa verificar se as credenciais/dados protegidos estão disponíveis

no banco de dados ou não.
 Teste de autenticação significa testar o aplicativo com vários conjuntos de dados
válidos e inválidos, para dados válidos ele deve exibir a página inicial, enquanto para
dados inválidos, ele deve exibir a mensagem de autenticação adequada (mensagem
de erro).

Ex: Teste a funcionalidade de login do HMS com vários conjuntos de credenciais válidas e
inválidas. Ele tem que autenticar o aplicativo corretamente.

16) Teste direto de URL:

 Faça login em uma página segura e pegue a URL da página protegida e acesse essa
URL em um novo navegador. Onde ele não deve ser acessível se estiver acessível,
então o aplicativo não é seguro.

Ex: Faça login no Gmail.com, copie a URL da página inicial. Abra no novo navegador e acesse a
URL diretamente, onde ela não deve estar acessível.

17) Teste de vazamento de firewall:

 Faça login no aplicativo como um nível de usuário e tente acessar os dados além da
limitação de sua função. Se estiver acessível, então concluímos que o aplicativo não
está funcionando conforme a função (está tendo o vazamento do firewall).

Ex: Faça login no aplicativo HMS como Jr. Doutor e tente acessar os dados do Sr.
Médico, onde não deve ser acessível

18) Teste de banco de dados:

  Testar se os dados estão sendo inseridos corretamente no banco de dados de todas
as tabelas ou não é conhecido como teste de banco de dados. Com a ajuda de
consultas SQL, podemos realizar testes de banco de dados.

Ex: Sempre que estivermos criando o cadastro permanente no HMS, todos os dados
do paciente serão armazenados no banco de dados do HMS, como engenheiro de
testes temos que fazer o login no banco de dados e verificar se os dados estão
inseridos corretamente em todas as tabelas ou não.

Teste de Implantação/Teste de Instalação: A equipe de implantação ou líder

de Teste implantará a compilação em vários ambientes como desenvolvimento,
teste, estágio1, estágio2, produção etc e verificará se está sendo implantado
corretamente ou não

P: Assim que a compilação for lançada, como você testará a compilação

R: Inicialmente vamos realizar testes de sanidade, se for aprovado, então executaremos

todos os casos de teste, em seguida, executaremos todos os tipos de testes funcionais como
abaixo. Ao realizar todos os testes abaixo, podemos garantir a qualidade para a aplicação
Tipos de teste funcional – Fluxo de execução do teste de função na compilação, uma vez
liberado para a equipe de teste

Nota: Para qualquer aplicação todos os testes acima serão realizados para garantir, se a
aplicação está cumprindo os requisitos do cliente, qualidade e sua utilidade para o
usuário final ou não.

2. Se for um aplicativo de desktop top Direct URL Testing e cross browser testing não é
possível executar.

Modelo de relatório de revisão:

Revise o documento SRS do jato de especiarias e forneça o relatório de revisão no modelo
abaixo.

Comentários de Requisito de ID de Requisito por Comentários de TE

Descrição
7. Adulto, criança e bebê gota 1. Qual a diferença entre

Downs devem estar disponíveis. Criança, adulto e bebê

2. O que valoriza os campos adulto, infantil,

infantil?

19) Testes de globalização:

São dois tipos

um. Teste de localização.

b. Testes de internacionalização.

um. Teste de localização:

 Teste a aplicação em todas as línguas locais que são seletivas para o

nosso país como hindi, bengali, telugu, etc. é conhecido como teste de
localização.
 Ele suporta no máximo 10 idiomas para integração única. Por isso, vamos
chamá-lo de teste 'L10N'.

Ex:1. Teste Google.co.in em todas as línguas locais como hindi, bengali, telugu
etc...

2. Teste o caixa eletrônico em idiomas locais como hindi, telugu e inglês.

b. Testes de internacionalização:

 Teste o aplicativo em todos os idiomas internacionais como japonês,

chinês e espanhol etc.is conhecido como teste de internacionalização. Ele
suporta no máximo 18 idiomas para uma única integração. Por isso,
vamos chamá-lo de teste 'I18N'.

Ex: Teste Gmail.com em todos os idiomas internacionais como, japonês,

espanhol e chinês etc ...

CICLO DE VIDA DE TESTE DE SOFTWARE:

Ele contém as seguintes fases:

1) Plano de teste de software.

2) Projeto de teste de software.
 3) Execução de Testes.
4) Análise dos resultados.
5) Relatórios & BLC.
6) Entrega e manutenção.
7) Relatório de resumo de teste/ Relatório de construção post-mortem.

1. Plano de teste de software:

 Plano é um documento estratégico que descreve como executar uma tarefa de forma
eficaz e eficiente.
 O plano de teste de software também é um documento estratégico que descreve como
realizar testes de forma eficaz e eficiente. O plano de teste será preparado pelo líder do
teste; Uma vez preparado, ele será enviado para a equipe de testes para revisão.
 Com base no plano de teste, somos responsáveis por realizar testes.
 Ele contém abaixo atividades ou índice.

Índice do plano de teste

1. Objectivo

1.1 Âmbito dos ensaios

2. Documentos de referência

3. Itens de teste

3.1 Recursos a serem testados

3.2 Recursos não a serem testados

4. Estratégia de teste

4.1 Tipos de teste

4.1.1 Tipos de ensaios funcionais

5. Ambiente de teste

6. Critérios de aprovação/reprovação no teste

7. Análise de defeitos e fechamento

8. Resultados do teste
9. Testes de automação

10. Riscos e contingências

11. Requisitos de hardware e software

12. Plano de recursos

13. Relatório de resumo do teste/ Construir relatório post-mortem.

1. Objectivo:

O objetivo principal do plano de teste será descrito aqui. Ele contém escopo de testes.

1.1 Âmbito dos ensaios:

Que tipos de testes a equipe de teste é responsável por testar no aplicativo é conhecido
como escopo de teste.

Ex: A equipe de testes é responsável pelos testes manuais e automação do projeto.

2. Documentos de referência:

A lista de documentos que o líder de teste usou para preparar o plano de teste será descrita
aqui.

O líder de teste usará documentos SRS para preparar o plano de teste.

3. Itens de teste:

3.1 Características a serem testadas:

A lista de funcionalidades ou módulos pelos quais a equipe é responsável, será descrita

aqui e também a lista de testes que a equipe de testes está realizando nos módulos será
descrita aqui.

Ex: A equipe de testes é responsável por reservar um voo, reservar um hotel e gerenciar
minha reserva.

Para os módulos acima eles são responsáveis por testes manuais e automação.

3.2 Recursos não a serem testados:

A lista de módulos e testes pelos quais a equipe de testes não é responsável será
descrita aqui.
 Ex: A equipe de testes não é responsável pelos módulos de pagamento e também não é
responsável por testes de desempenho, testes de carga, testes de estresse.

4. Estratégia de teste:

Estratégia significa a lista de passos que vamos tomar para realizar o plano.

 A estratégia de teste significa a lista de tipos de teste funcionais. O que a equipe de

testes vai levar para realizar o teste é conhecido como estratégia de teste.
 Vamos realizar todos os tipos de testes funcionais como regressão, retestes, etc... sobre
o pedido
 Em suma, planejar significa o que fazer. Estratégia significa como alcançar o plano.

5. Ambiente de teste:

Ambiente significa que o sistema que vamos usar para implantar a compilação e testar o
aplicativo é conhecido como ambiente de teste.

Ex:Tipo de máquina: Windows server enterprise

OS : Windows
Processador: Intel Xeon CPU
Memória: 4GB/2.13 GHZ
Disco rígido: 150GB
Base de dados : Microsoft SQL Server 2008 standard edition
Servidor Web: IIS 7.0
Cliente : Microsoft internet explorer, Firefox, Google chrome

6. Aprovação/critérios:

Se algum caso de teste estiver se desviando do resultado esperado, ele será tratado
como falha ou bug.

Todo bug está tendo os critérios ou tipo de bug.

É de cinco tipos:

um. Bloqueador
b. Muito Alto
c. Alto
d. Média
e. Baixo

7. fechamento da análise do defeito:

No momento da entrega da compilação, se algum bug/defeito estiver disponível, ele será
analisado pela equipe de testes com o gerente do projeto. Se algum bug não for necessário ser
corrigido, ele será fechado.

8. Resultados do teste:

A lista de módulos que vamos entregar ao cliente conhecida como entregáveis.

Todos os módulos serão divididos em várias fases e também o lead estará fornecendo o prazo
previsto (data de entrega).

Fase Dead Lines (Data de

Não Módulos Entrega)

1. BookaFlight
2. GerenciarMinha Reserva
1 3. Situação PNR 30 de junho

2 4. Horários dos voos 31 julho

5. Benefício Corporativo

3 6. Spice conectar 30 de setembro

9. Testes de automação:
O número de módulos que a equipe de testes vai automatizar será descrito aqui e também a
ferramenta de automação e a estratégia que os engenheiros de teste seguirão serão descritas
aqui.

10. Riscos e contingências:

A lista de riscos que a equipe enfrentará durante a execução do projeto e também com a
solução relacionada será descrita aqui.

Riscos Contingências
Déficit de recursos Manter recursos de buffer

Mudanças contínuas de requisitos Analise os requisitos

Monitorar revisões por

Falta de revisão por pares pares

11. Requisitos de hardware e software:

O número de máquinas como laptops, celulares, impressoras etc... necessário para o teste com
software relacionado será descrito aqui.

12. Plano de Recursos:

Os números de recursos necessários para testes manuais, testes de automação, testes de banco
de dados serão descritos aqui.

13. Relatório de resumo do teste/Relatório post mortem de construção:

Uma vez concluído o teste, o líder de teste deve preparar o relatório de resumo do teste, ele
contém o resumo do teste.

2) Projeto de Teste de Software:

O processo de escrever os casos de teste no modelo de caso de teste depois de entender todos
os requisitos é conhecido como 'design de teste de software'.
  Cada organização terá seu próprio modelo baseado nesse modelo; O engenheiro de
teste é responsável por escrever os casos de teste.
 Estamos tendo os modelos abaixo para escrever os casos de teste. Contém CoverSheet,
casos de teste, Testdata, matriz de rastreabilidade e relatório de teste

Exigir - Teste prioridad TC Teste Pré- Teste Real Esperad Resulta Comentári
Tipos de Ações e ID cenário produção Tipos Resulta o do os
do Resultad
ID o

Folha de rosto:

Nome do módulo :

N.º total de casos de teste:

Nº de casos de teste P1 :

Nº de casos de teste P2 :

Nº de casos de teste P3 :

Nº de casos de teste P4 :

ID do requisito: O número de requisito para o qual estamos escrevendo os casos de teste será
descrito aqui.

Tipos de teste: O tipo de caso de teste é conhecido como tipo de teste. É de cinco tipos.

 GUI
 Validação
 Caso de teste positivo (ou) Caso de teste positivo funcional.
 Caso de teste negativo (ou) Caso de teste funcional negativo
 Caso de teste de banco de dados

Caso de teste positivo: Testar o aplicativo com todos os dados válidos é conhecido
como caso de teste positivo.

Caso de teste negativo: Testar o aplicativo com pelo menos um dado inválido é
conhecido como caso de teste negativo.

Prioridade: Ele descreve a importância do caso de teste. Está abaixo os tipos: P1, P2, P3 e P4.
 P1: Se o caso de teste estiver descrevendo a funcionalidade principal do
aplicativo/módulo, ele será tratado como P1.

A funcionalidade principal significa que, se o caso de teste falhar, não podemos

continuar o teste, de modo que a prioridade é 'P1'.

P2: Se o caso de teste estiver descrevendo a funcionalidade de nível de campo, a

prioridade será 'p2'.

Caso de teste em nível de campo significa que, se falhar, podemos continuar o

teste, mas é importante estar lá no aplicativo de acordo com o requisito do cliente.

P3: Todos os casos de teste de GUI estão sob prioridade P3.

P4:O engenheiro de teste está tendo a opção de dar a sugestão ao aplicativo. Essas
sugestões serão capturadas na forma de casos de teste e, em seguida, a prioridade é
'P4'.

ID do caso de teste: O número de série do caso de teste será descrito aqui.

Cenário de teste:Cenário significa um fluxo ou a maneira usada pelo usuário final. O requisito
será dividido em todos os fluxos ou cenários usados pelo usuário final e esses serão descritos
aqui. O engg de teste tem que identificar os fluxos máximos possíveis (Scenrios) para o requisito
ou história do usuário

Pré-condição:A condição necessária para testar o cenário será descrita aqui.

Etapas do teste:A lista de etapas necessárias para executar o cenário será descrita aqui. Com
base nas etapas de teste, o engg de teste será executado no aplicativo ou compilação

Resultado esperado:No momento em que escrevo os casos de teste, não teremos o aplicativo
conosco. Então, vamos esperar o resultado para o cenário. Esse resultado esperado será
atualizado na coluna de resultados esperados.

Resultado real:Ele será atualizado no momento da execução dos casos de teste. O engenheiro
de teste observará o comportamento real do aplicativo para o cenário e ele será atualizado
aqui.

Resultado:Uma vez que a execução do teste é concluída o engenheiro de teste irá comparar o
resultado real com o resultado esperado, se ambos estiverem correspondendo, então ele
atualizará o resultado como aprovação, se não ele irá atualizá-lo como falha.

Comentários:O BA ou cliente fornecerá os comentários aqui.

Consulte o documento de TCs de login do Gmail

Técnicas de projeto de teste:

Para realizar testes de forma eficaz e eficiente, precisamos seguir as técnicas de projeto
de teste abaixo.

1. Análise de valor de contorno (BVA)

2. Partição de classe de equivalência (ECP)

3. Adivinhação de erros

1. Análise de valor de contorno (BVA):

Sempre que temos a exigência de testar a faixa como 1 a 100 ou 1 a 1000 ou 1 a 1 falta
ou 1 falta a 2 faltas, então não é possível realizar o teste exaustivo (teste completo).
Então, precisamos aplicar a técnica BVA.

 Divida o intervalo em vários limites, como min-1, min, min+1, middle, max-1,
max e max+1.
 Para realizar o teste positivo, teste o campo com min, min+1, middle, max-1 e
max. Onde deve aceitar. (Seu caso de teste +ve)
 Para realizar o teste negativo, teste o campo com min-1 e max+1. Onde não deve
aceitar. (Seu caso de teste -ve)
 Se ele está funcionando de acordo com o acima, então podemos concluir que ele
está aceitando apenas o intervalo.
+Cenário de teste Ve: verifique o campo com os limites como min, min+1, middle, max-1 e
max

-Ve Cenário de teste: Verifique o campo com os limites como min-1 e max+1

2. Partição de classe de equivalência (ECP):

Sempre que tivermos o requisito especial como verificar se o campo (nome de usuário
ou senha) está aceitando os caracteres como a a z, A a Z, 0 a 9 e #%@$&*. Ao mesmo
tempo, o campo não deve aceitar os caracteres especiais como <>-+/\.

 Neste cenário não é possível realizar o teste exaustivo com todos os

personagens. Então precisamos seguir a técnica da ECP.
 Divida igualmente os dados de teste em duas classes.
um. Dados de teste válidos classe b. Classe de dados de teste inválida
 Prepare os dados de teste com todas as maneiras possíveis.
 Para realizar o teste positivo, testa o campo com dados de teste válidos. Onde
tem que aceitar. (Seu caso de teste +ve)
 Para executar o teste negativo, teste o campo com dados de teste inválidos.
Onde não deve aceitar. (Seu caso de teste -Ve)
 Se ele está funcionando como esperado no acima, podemos concluir que ele está
funcionando de acordo com o requisito.
 3) Erro de adivinhação:

Sempre que algum bug for identificado pelo engenheiro de teste, ele deve ser reportado ao
desenvolvedor, onde ele irá corrigi-lo e enviá-lo de volta para a equipe de teste. O engenheiro
de teste verificará se o bug foi realmente corrigido ou não. Ao mesmo tempo, ele tem que
adivinhar os erros ou bugs nas funcionalidades relacionadas. Ele tem que realizar os testes nas
funcionalidades relacionadas também. É conhecido como "Adivinhação de erro".

Ex: Na página PR a mensagem de alerta não está sendo exibida, ela foi corrigida pelo
desenvolvedor e testada pelo testador. Onde a mensagem de alerta está funcionando
corretamente na página PR. Agora o teste engg.. tem que ir as funcionalidades relacionadas,
como conselho de admissão e admissão, em seguida, olhar (adivinhar) para o tipo semelhante
de bug.

Matriz de Rastreabilidade:

É rastrear se o engenheiro de teste cobriu todos os casos de teste para todos os requisitos ou
não.
 Com base na matriz de rastreabilidade, o lead ou o cliente acompanhará se o engenheiro de
teste cobriu todos os casos de teste ou não.

Nº de ID do caso
Req ID CTs de teste Comentários
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 1 6
7 1 7
8&9 5 8 a 12 anos
A exigência não é
Ainda não clara. Aguardando
10 implementado comentários da BA

4) Execução de Testes:

 O processo de execução dos casos de teste no ambiente de teste de compilação é

conhecido como execução de teste. Sempre que a compilação é liberada para a equipe
de teste, o engenheiro de teste precisa revisar o documento SRN para saber o status da
compilação.
 Com base no documento SRN, o líder de teste implantará a compilação e a equipe de
teste executará o teste de sanidade.
 Uma vez que o teste de sanidade é concluído, os resultados do teste de sanidade são
enviados para o desenvolvedor.
 Se o teste de sanidade for aprovado, a equipe de teste continuará a executar os casos
de teste, se o teste de sanidade falhar, a equipe de teste rejeitará a compilação de volta
para a equipe de desenvolvimento.
 Ao executar os casos de teste, o engenheiro de teste observará o comportamento real
do aplicativo para o cenário e ele será atualizado no campo de resultado real. O mesmo
será mantido para todos os casos de teste.

5) Análise dos resultados:

 Ao executar os casos de teste, o engenheiro de teste atualizará o campo de resultado

real, em seguida, ele comparará o resultado real com o resultado esperado, se ambos
estiverem correspondendo, ele fornecerá o resultado como aprovação, caso contrário,
ele atualizará como falha.
  Para o passe vamos dar a cor verde, enquanto para o fail vamos fornecer a cor
vermelha. Execução de testes e análise de resultados, ambos são processos paralelos.

Nota: Uma vez concluída a execução dos casos de teste, somos responsáveis por executar
todos os tipos de testes funcionais no aplicativo para identificar os bugs.

* Quantos casos de teste podemos escrever em um dia?

Tudo depende de todos os requisitos e engenheiro de teste, mas uma média podemos escrever
cerca de 40-50 casos de teste em um dia. Isso significa que estamos levando aproximadamente
8-10 minutos para um caso de teste analisar o requisito e preparar o caso de teste no modelo
de caso de teste com os dados de teste.

* Quantos casos de teste podemos executar em um dia?

Também depende dos casos de teste e do aplicativo, mas em média podemos executar de 50
a 60 casos de teste em um dia porque para revisar o caso de teste e executá-lo no aplicativo.

Estamos levando cerca de 5-8 minutos para executar um caso de teste em média.

6) Relatórios:

 O processo de reportar/enviar os bugs (casos de teste com falha) para o desenvolvedor

é conhecido como Reporting.
 São dois tipos.

1. Relatando os bugs usando arquivos XL.

2. Relatar os bugs usando ferramentas de relatório.

1. Relate os bugs usando o arquivo XL:

Era o processo antigo que usávamos para ter o modelo abaixo para atualizar o bug e enviá-lo
para o desenvolvedor.

Bug Título do Estado Severida Prior Descriç Captura Constr Report Comentários
ID bug/ de idad ão do de tela uir ado atribuídos
Resumo e bug Versão Por
Para
1.

ID do Bug:

O número de série do bug será descrito aqui.

Título do bug/Resumo:

O resultado real do bug será descrito aqui.

Estado:

Com base no bug, os engenheiros de teste, bem como o desenvolvedor, são responsáveis por
dar o status. Está abaixo dos tipos.

 Novo:
Sempre que o engenheiro de teste identificar algum bug. Inicialmente, o status do bug
é Novo. O novo bug será reportado ao desenvolvedor.
 Abrir:
O desenvolvedor irá verificar se o novo bug é realmente um bug ou não. Se sim, então
atualizaremos o status de novo para aberto.
 Corrigido/Verificado:
O desenvolvedor levará algum tempo para corrigir o bug aberto, uma vez que ele é
corrigido, ele atualizará o status de aberto para corrigido. O bug corrigido será enviado
para o engenheiro de teste.
 Fechado:
O engenheiro de teste verificará se o bug corrigido está realmente funcionando como
esperado ou não. Se estiver funcionando, atualizaremos o status de fixo para fechado. O
estado fechado é o fim do Bug.
 Reaberto:
O bug corrigido será testado pelo engenheiro de teste; Se não estiver funcionando como
esperado, ele atualizará o status de Corrigido para Reaberto e o bug de reabertura será
enviado de volta ao desenvolvedor.
 O desenvolvedor irá verificar se é realmente um bug ou não, se sim ele abre, corrija o
bug e o envie de volta para a equipe de testes.
 Rejeitado/Não é um bug/Hold/Differed:
Quando o engenheiro de teste identificar qualquer bug, ele será reportado ao
desenvolvedor com novo status. Se o desenvolvedor não estiver aceitando um bug, ele
atualizará um status de novo para Rejeitado/Não é um bug e ele será enviado de volta
para a equipe de testes.

Severidade:

Ele descreve a gravidade com que o bug afetou o aplicativo nos testes. Severidade significa
gravidade do inseto. Está abaixo dos tipos.

 Bloqueador:
Se o bug está bloqueando todo o teste do módulo, então a gravidade ou tipo de um bug
é Blocker.
 Muito alto:
Se o bug está bloqueando parcialmente o teste do módulo, então a gravidade do bug é
muito alta.
 Alto:
Se o bug estiver bloqueando apenas o cenário específico do módulo, a gravidade é alta.
 Média:
A gravidade de todos os bugs da GUI é média.
 Baixo:
O engenheiro de testes está tendo a opção de dar a sugestão também. Assim, a
sugestão será relatada na forma de bug, onde a gravidade é baixa.

Prioridade:

Priority descreve em que ordem o bug deve ser corrigido pelo desenvolvedor. Com base na
gravidade, o engenheiro de teste dará prioridade ao bug conforme abaixo:

Severidade Prioridade
 Bloqueador/Urgente/ P1
crítico
P2
Muito alto
P3
Alto
P4
Média
Pág. 5
Baixo

Descrição:

As etapas detalhadas para produzir/obter o bug serão descritas aqui. Com base nas etapas o
desenvolvedor irá verificar se é realmente um bug ou não.

Captura de tela:

O engenheiro de teste irá capturar a captura de tela do bug e ele será carregado no modelo de
bug. É para provar que o bug relatado é válido e também para entender sobre o bug.

Versão de compilação:

O número de compilação no qual o engenheiro de teste identificou o bug será descrito aqui.

Relatado por:

O engenheiro de teste que identificou o bug descreverá aqui.

Atribua a:O nome do desenvolvedor ou o nome do líder do desenvolvedor, que vai corrigir o
bug, será descrito aqui.

Comentários:

Tanto os engenheiros de teste, quanto o desenvolvedor podem fazer as perguntas na forma de

comentários.

Nota:O relatório de arquivo XL consumirá muito tempo, então nosso plano é usar as
ferramentas de relatório.
Ex:

Título do
BUG Bug / Estad Severid Priorid
Fases ID Resumo o ade ade Descrição do Bug Captura de tela

O aplicativo
não está 1. Abra Spicejet.com
exibindo os 2. Clique no botão
dois de opção de ida e volta 3. O
seletores de Bloquead aplicativo não está exibindo os dois
Eu 1 data Novo or P1 seletores de data D:\Nagesh\SPicejet_Lo
O nome do
Spicejet está
sendo 1. Abra Spicejet.com
exibido 2. Observe o logotipo
como da Spicejet 3. Sua exibição como jato
II 2 spacejet Novo Média P4 espacial D:\Nagesh\SPicejet_Lo
O botão de
opção
unidirecional
não está 1. Abra Spicejet.com
sendo Muito 2. O botão de opção unidirecional
III 3 exibido Novo Alto P2 não está disponível Caminho
A caixa de
seleção
Estudante 1. Abra Spicejet.com
não está 2. A caixa de seleção Estudante não
Eu 4 disponível Novo Alto P3 está disponível Caminho
Cheange a
cor da
página inicial
do jato de
especiarias
II 5 para azul Novo Baixo Pág. 5 1. Abra Spicejet.com Caminho
O link do
clube
Spicejet não
está
navegando 1. Abra Spicejet.com
para a 2. Clique no link
página do 3 do Spiceje Connect. O link do
clube Bloquead Spiceje Connect não está navegando
III 6 Spicejet Novo or P1 para a página MySpicetrip Caminho
 1. Abra
http://selenium4testing.com/hms
2. Faça login no aplicativo
O aplicativo 3. Clique em Pesquisar Registro
não é 4. O aplicativo não está mantendo a
Eu 7 mantidoGUI Novo Média P4 GUI Spicejet_GUI.png

A GUI da
lista de 1. Abra
trabalho de http://selenium4testing.com/hms
admissão 2. Faça login no hms com
não está user1/user1
sendo 3. Clique em ADT
mantida 4. Clique em Lista de trabalho
corretament de admissão 5. Observe a GUI, sua
II 8 e Novo Média pág. 4 manutenção não é correta D:\Nagesh\hms_ADW

O campo
Adulto não 1. Abra http://spicejet.com
está sendo 2. Observe todos os campos
exibido na Bloquead 3. A lista suspensa Adulto não está
III 9 página Novo or P1 disponível D:\Nagesh\Spicejet\Sp

O aplicativo
não está 1. Abra http://spicejet.com
exibindo 2. Clique no campo
Hyderabad e Muito 3 SairDe. O aplicativo não está
Eu 1 Bangalore Novo Alto P2 exibindo Hyderabad e Bangalore D:\Nagesh\Spicejet\Sp
P: qual é a diferença entre gravidade e prioridade

P: qual é a diferença entre Prioridade em casos de teste e Prioridade em modelo de bug

Não.Se o desenvolvedor não está aceitando seu bug, então como você provará que o seu é
bug válido?

Um: Com base na descrição do bug, documento SRS, captura de tela vamos tentar
provar que o bug é válido se não estiver aceitando, então eu vou pegar o log do sever para
provar que o bug é válido, se ainda não aceitar e então eu vou enviá-lo para um BA, gerente
de projeto e finalmente cliente.

Não. Explicar o cenário onde o bug está tendo alta gravidade com baixa prioridade e baixa
segurança com alta prioridade?

A:Prioridade de gravidade

Bloqueador - P1

Alta segurança Muito alta - P2 Alta prioridade

Alta - P3

Médio - P4
 Baixa segurança Baixa - P5 Baixa prioridade

Temos dois bugs: um é Blocker outro é médio. O bloqueador terá alta prioridade e
médio terá baixa prioridade.

Com base na gravidade do teste engg.. dará prioridade. Com base na prioridade que a
equipe de desenvolvimento é responsável por corrigir

Mas o líder de desenvolvimento está tendo a opção de mudar a prioridade, depende

da situação.

 Os bugs relacionados à entrega da fase atual serão convertidos em alta prioridade,

independentemente da gravidade.
 Os bugs que não fazem parte da entrega atual serão convertidos em baixa
prioridade, independentemente da gravidade.

Id do Bug de Fase Título do Bug/Prioridade de Gravidade do Status do Resumo

I. 1. Spice jetname está exibindo New Medium P4---P1

Como jato espacial

2. 2. Spice jet connect link não é New Blocker P1----P4

Navegando na página de conexão do spice jet

Relatório de teste/relatório de status de compilação:

Uma vez que a execução do caso de teste é concluída na compilação, o engenheiro

de teste é responsável por enviar um relatório de teste para o líder, bem como para o
cliente. Abaixo do formato
Relatório de status de compilação/relatório de teste

Relatório de Status de Compilação / Relatório de Teste

Nome do Engg de teste:
Construir Não 1
Credenciais de login
Navegador FF, IE GoogleChrome
 Teste Matrics
Número total de casos de teste 200
Nº de casos de teste
executados 150
N.º de casos de teste pendentes 50
Nº de casos de teste aprovados 100
Nenhum dos casos de teste
falhar 50
Nº de casos de teste ignorados 10
Nº de Bugs Relatados 3

Métricas de teste:

Métrica significa medição da tarefa. Métricas de teste significa a medição do teste.

Pendente:

Se o desenvolvedor não tiver fornecido nenhuma funcionalidade, esses casos de teste não
poderão ser executados. Está pendente.

Ignorada:

O desenvolvedor deu a funcionalidade, mas não podemos testar as funcionalidades,

porque as funcionalidades dependentes falharam.

Ex: se o login falhar, não poderemos executar a composição.

Compor casos de teste está sob ignorado.

 O relatório será continuado até que a compilação seja estável, o que significa que a
maioria dos casos de teste são aprovados e nenhum bug bloqueador está disponível na
ferramenta de relatório.
 A compilação estável será entregue ao cliente.

P: Explique-me a estrutura de relatórios em sua organização

Relate os bugs usando ferramentas de relatório:

 Qualquer ferramenta de relatório que tenha dois tipos de usuários: um é usuário

administrador e outro é usuário final.
 Usuário administrador: O usuário administrador é responsável por criar o projeto, criar
usuários como engenheiros de teste, desenvolvedores... etc. Ele atribuirá o usuário ao
projeto
  Usuário final: Ele é responsável por usar (reportar) ou receber os bugs ex: engenheiros
de teste, desenvolvedores... etc.

Ex: QC, JIRA, Bugzilla, Redmine, Gerenciador de testes etc...

BugZilla:

 Acesse o Bugzilla usando selenium4testing.com

 Em seguida, clique em Bugzilla.
 Faça login no Bugzilla como engenheiro de testes (jan30selenium@gmail.com& senha :
selenium)
 Usando o Bugzilla podemos realizar atividades abaixo.
um. Relatando um bug.
b. Procure os bugs.
c. Podemos levar o relatório.
d. Preferência.

Introdução ao Bugzilla
O que é o Bugzilla?
O Bugzilla é um sistema de rastreamento de problemas/bugs de código aberto que
permite que os desenvolvedores efetivamente acompanhem os problemas pendentes com
seu produto. Ele é escrito em Perl e usa banco de dados MYSQL.

O Bugzilla é uma ferramenta de rastreamento de defeitos, no entanto, pode ser

usado como uma ferramenta de gerenciamento de testes, como tal, pode ser facilmente
vinculado a outras ferramentas de gerenciamento de casos de teste, como Quality Center,
Testlink, etc.

Este rastreador de bugs aberto permite que os usuários permaneçam conectados

com seus clientes ou funcionários, para se comunicar sobre problemas de forma eficaz
em toda a cadeia de gerenciamento de dados.

As principais características do Bugzilla incluem:

 Recursos avançados de pesquisa

 Notificações por e-mail
 Modificar/arquivar Bugs por e-mail
 Controle de tempo
 Segurança forte
 Personalização

Como fazer login no Bugzilla?

Passo 1)Para criar uma conta no Bugzilla ou para fazer login na conta existente, vá para
Nova Conta ou Login opção no menu principal.

Passo 2)Agora, insira seus dados pessoais para fazer login no Bugzilla

1. ID do usuário: jan30selenium@gmail.com
2. Senha: selenium
3. E depois clique em "Entrar"
Passo 3)Você está logado com sucesso no sistema Bugzilla

Criando um relatório de bug no Bugzilla

Passo 1)Para criar um novo bug no Bugzilla, visite a página inicial do Bugzilla e clique
na guia NOVO no menu principal
Clique no link Novo e o aplicativo abre a próxima janela como abaixo.

Passo 2)Na próxima janela

Clique no nome do projeto como HMS e, em seguida, o aplicativo abre uma nova janela
com as seguintes opções:

1. Insira o produto
2. Inserir componente
3. Fornecer descrição do componente
4. Selecione a versão,
5. Selecione a gravidade
6. Selecione Hardware
7. Selecione OS
8. Inserir Resumo
9. Digite a descrição
10. Anexar anexo
11. Enviar

NOTA: Os campos acima irão variar de acordo com a sua personalização do Bugzilla

Digite todos os campos necessários para o seu bug como abaixo,

Se você tiver algum anexo em relação ao seu bug de relatório, você pode anexá-lo clicando no botão
"Adicionar um anexo" e clicando no botão Confirmar no final da página para relatar seu bug.

Passo 4) Bug é criado ID# 208 é atribuído ao nosso Bug. Você também pode adicionar informações adicionais
ao bug atribuído, como URL, palavras-chave, quadro branco, tags, etc. Esta informação extra é útil para dar
mais detalhes sobre o Bug que você criou.

1. Caixa de texto grande

2. URL
3. Quadro branco
4. Keywords
5. Tags
6. Depende
7. Blocos
8. Anexos
Passo 5)Na mesma janela, se você rolar mais para baixo. Você pode selecionar a data limite e também o status
do bug. Deadline no Bugzilla geralmente dá o prazo para resolver o bug em determinado período de
tempo.
Criar relatórios gráficos

Os relatórios gráficos são uma maneira de visualizar o estado atual do banco de dados de bugs. Você pode
executar relatórios por meio de uma tabela HTML ou baseada em gráfico de linhas/pizza/barras. A ideia por
trás do relatório gráfico no Bugzilla é definir um conjunto de bugs usando a interface de pesquisa padrão e, em
seguida, escolher algum aspecto desse conjunto para plotar nos eixos horizontal e vertical. Você também pode
obter um relatório 3-dimensional escolhendo a opção de "Várias páginas".

Os relatórios são úteis de muitas maneiras, por exemplo, se você quiser saber qual componente tem o maior
número de bugs ruins relatados contra ele. Para representar isso no gráfico, você pode selecionar a gravidade
no eixo X e o componente no eixo Y e, em seguida, clicar em gerar relatório. Ele vai gerar um relatório com
informações cruciais.

1. Clique nos relatórios na parte superior da janela da seguinte forma

2. Clique em Relatórios gráficos

A página de relatórios gráficos será exibida como abaixo,

Selecione Eixo Vertical como Severidade e Eixo Horizontal como Prioridade ou o que quiser, você pode
selecioná-lo e obterá o relatório gráfico correspondente.

 Gere um relatório com recursos avançados, inserindo mais detalhes sobre o bug conforme abaixo
O gráfico abaixo mostra a representação do gráfico de barras para a gravidade dos Bugs no componente
"Widget Gears". No gráfico abaixo, o bug ou bloqueadores mais graves em componentes são 88, enquanto
bugs com gravidade normal estão no topo com número 667.

Função Procurar

Passo 1)Para localizar seu bug, usamos a função de navegação, clique no botão Pesquisar no menu principal.
O relatório será continuado até que a compilação seja estável. Uma vez estável, ele será
entregue ao cliente, em seguida, Refer fase de entrega e manutenção

Depois que a compilação for entregue com êxito ao cliente, o líder de teste
preparará o relatório de resumo do teste e ele será atualizado no plano de teste e o plano de
teste será enviado ao cliente no momento da entrega da compilação.

RELATÓRIO DE RESUMO DE TESTE / RELATÓRIO DE BUILD POST MARTUM

 No de Builds lançados pela Dev Team - 50

 Nº de Builds aceitos pela equipe de testes - 25
 Nº de compilações rejeitadas pela equipe de testes - 25
 Nº de casos de teste preparados pela equipe de teste - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 Nº de bugs identificados - 400

o Bloqueador - 100
o Muito Alto - 150
o Alta - 100
o Médio - 40
o Baixo - 10
 Nº de bugs identificados pelo cliente- 100
o Bloqueador - 10
o Muito Alto - 50
o Alta - 10
o Médio - 10
o Baixa - 20
 Histórias de Sucesso
 Desafios

Q : Quais são os critérios de entrada(início) de teste e critérios de saída(fim) de teste

R: O plano de teste e o documento SRS são os critérios de entrada do teste.

Não há fim para os testes. Ele será continuado enquanto a construção estiver no ar. Mas as
atividades de teste serão alteradas após a compilação entregue ao cliente. Durante a
manutenção, não vamos realizar todos os tipos de testes funcionais. Vamos realizar o teste de
regressão.

Terminologia
Peer significa o companheiro de equipe com igual
designação. Todos os pares participarão de uma
reunião e discutirão sobre o projeto para obter
clareza sobre todos os módulos. O objetivo da
revisão por pares é obter conhecimento funcional
Revisão por pares em todos os módulos por cada engg.
Enquanto a revisão por pares, o par sênior
Relatório de Revisão por preparará o documento sobre revisão por pares é
Pares conhecido como relatório de revisão por pares
Se a mesma revisão por pares for conduzida na
frente do líder ou gerente de projeto, então é
conhecido como Passo a passo. O lead ou PM
observará se os membros da equipe estão
Percorrer entendendo o projeto corretamente ou não
Enquanto Percorrer o lead irá preparar o
documento em Passo a passo é conhecido como
Relatório passo a passo Passo através do relatório
A combinação de vários casos de teste é conhecida
Conjunto de testes como conjunto de testes
A combinação do conjunto de testes e do ambiente
Bancada de Teste de teste é conhecida como Test Bed
Relatório de status diário.
No dia a dia, precisamos enviar nosso status de
DSR trabalho para o lead em um modelo
Ata da reunião.
Sempre que participarmos de uma reunião, a
discussão da reunião será levada em uma nota
aproximada. Mais tarde, ele será atualizado em um
e-mail e o e-mail será enviado para todos os
membros da equipe. O objetivo do MOM é manter a
transparência sobre a reunião entre os membros da
MAMÃE equipe
O processo de verificar se a empresa segue as
Inspeção diretrizes ou não. Vistoria será feita sem intimação
É também o processo de verificar se a empresa
segue as diretrizes ou não. Auditoria será realizada
Auditoria com prévia intimação
Estável significa que não são necessárias mais
atualizações.
Compilação estável significa que a maioria dos
casos de teste são aprovados e nenhum bug de
Estábulo bloqueador identificado na compilação
AUT Aplicação em teste
 Quando a compilação for rejeitada, o
desenvolvedor analisará a falha. Se ele está
lançando a mesma compilação para a equipe de
testes novamente sem adicionar novas
funcionalidades é conhecido como PatchBuild.
Se o desenvolvedor está lançando a compilação
com algumas novas funcionalidades é conhecido
Compilação do patch como nova compilação
Disponibilize-o para os usuários visados. Depois
que o documento Testcases ou SRS estiver
alinhado na base, ele será verificado no repositório
central para usuários de destino. É conhecido como
Publicar publicar
Falhas relacionadas ao projeto são conhecidas
como defeito. Ex: Defeitos da
GUI Falhas funcionais relacionadas são bugs (erro
do programador).
Ex: Todos os bugs
funcionais Erro: Exceções no script é conhecido
Bug/Defeito/Erro como erro
Caso de uso é uma lista de etapas, normalmente
definindo interações entre uma função (conhecida
como "ator") e um sistema, para atingir um objetivo.
O ator pode ser um engenheiro de teste ou usuário
final Os requisitos serão convertidos em lista de
Casos de uso etapas pelo BA
Relatórios de Não Conformidade ou Solicitação de
Alteração de Não Conformidade. O requisito que
NCR está em discussão
Ações corretivas são implementadas em resposta a
reclamações
de clientes Ações preventivas são implementadas
CAPA em resposta à identificação de fontes potenciais
Em engenharia de software, o gerenciamento de
configuração de software (SCM ou SWCM) é a
tarefa de rastrear e controlar alterações no
software. As práticas de SCM incluem o controle de
SCM revisão e o estabelecimento de linhas de base.
SDN Nota de entrega de software
Cedendo. Afastando-se da tarefa O não de dias
que você escorregou da tarefa
Derrapagem
Produto defeituoso O produto com defeitos
Idade do defeito (em tempo) é a diferença de tempo
entre a data em que um defeito é relatado e a data
atual (se o defeito ainda estiver aberto) ou a data
em que o defeito foi corrigido (se o defeito já estiver
Idade do defeito corrigido).
Defeito latente Defeito oculto
O Gerenciamento de Portfólio de Produtos é o
gerenciamento centralizado dos processos,
métodos e tecnologias utilizados pelos gerentes de
PPM projeto
PPR Relatórios de Revisão de Desempenho do
 Programa
MRM Gestão de Recursos de Marketing