Plano de Teste
De BISAWiki
(Criou página com 'Arquivo:mpt1.PNG<br><br><br><br><br><br> Arquivo:responsavel.PNG<br><br> =1. OBJETIVO= O objetivo desse Guia é especificar como serão desenvolvidas as atividades de ...') |
|||
| (6 edições intermediárias não estão sendo exibidas.) | |||
| Linha 1: | Linha 1: | ||
[[Arquivo:mpt1.PNG]]<br><br><br><br><br><br> | [[Arquivo:mpt1.PNG]]<br><br><br><br><br><br> | ||
| - | + | ||
=1. OBJETIVO= | =1. OBJETIVO= | ||
| - | O objetivo desse Guia é especificar como serão desenvolvidas as atividades de teste na Bisa, abordando técnicas a serem utilizadas durante a sua execução, reunindo todas as informações necessárias para | + | O objetivo desse Guia é especificar como serão desenvolvidas as atividades de teste na Bisa, abordando técnicas a serem utilizadas durante a sua execução, reunindo todas as informações necessárias para planejamento e controle de teste referente a uma iteração específica. |
=2. CONCEITOS BÁSICOS= | =2. CONCEITOS BÁSICOS= | ||
| - | 2.1 Tipos de testes | + | ===2.1 Tipos de testes=== |
| - | Existem vários tipos de teste. Este Guia abordará apenas o tipos utilizados pela Bisa. Seguimos duas técnicas de teste, Caixa Branca e Caixa Preta, | + | Existem vários tipos de teste. Este Guia abordará apenas o tipos utilizados pela Bisa. Seguimos duas técnicas de teste, Caixa Branca e Caixa Preta, distribuídos em quatro níveis (Teste de Unidade, de Integração, de Sistema e de Aceitação). Veremos na figura abaixo e melhor detalhado no link: <http://www.portalbisa.com.br/wiki/index.php/Fluxograma_representando_o_processo_de_desenvolvimento_de_Testes_na_Bisa> |
[[Arquivo:Diagrama_Estágios_de_teste.png]] | [[Arquivo:Diagrama_Estágios_de_teste.png]] | ||
| + | |||
| + | |||
| + | ===2.2 Itens a serem testados=== | ||
| + | O acompanhamento de testes de todas as CRs será feito através da planilha: http://boletoswebbisa.com.br/processo/Sprint%20Delphi | ||
| + | |||
| + | ===2.3 Critérios de Entrada=== | ||
| + | Podemos iniciar os testes quando o ambiente de teste estiver pronto e configurado e as versões beta liberadas para o teste. | ||
| + | |||
| + | ===2.3 Critérios de Saída=== | ||
| + | Podemos encerrar os testes quando todos os testes planejados forem executados e todos os problemas encontrados e reportados segundo o padrão. | ||
| + | |||
| + | ===2.4 Critérios de Suspensão=== | ||
| + | Os testes devem ser suspensos quando o ambiente se mostrar instável ou os problemas encontrados em uma requisição afetem outras requisições impedindo que os testes sejam executados. O teste também será suspenso caso haja qualquer tipo de falha inesperada no ambiente de teste. | ||
| + | |||
| + | =3. O PROCESSO DE TESTE NA BISA= | ||
| + | ===3.1 Processo=== | ||
| + | 1. Análise do escopo<br> | ||
| + | 2. Execução do teste<br> | ||
| + | 3. Aceitação<br> | ||
| + | 4. Implantação do Sistema<br> | ||
| + | |||
| + | ===3.2 Fluxo de teste=== | ||
| + | Abaixo é apresentada uma figura representando o processo de execução de teste da BisaWeb. | ||
| + | |||
| + | [[Arquivo:Testar_Build.png]] | ||
| + | |||
| + | |||
| + | =4. PADRÕES DE DOCUMENTAÇÃO= | ||
| + | |||
| + | ===4.1 Criação da suite campos necessários:=== | ||
| + | <b>Campo <Nome da suite de Teste></b> | ||
| + | * Na suite de teste principal deve-se colocar o nome da rotina do sistema, ao qual deseja-se fazer relação a requisição que vai ser criado o caso de teste. | ||
| + | * Na suite secundaria deve-se ser colocado o nome do módulo ao qual a requisição pertence. | ||
| + | <b>Detalhes</b>: Uma breve descrição sobre a suite que está se criando, por exemplo se a suite for referente a rotina deve-se explicar a rotina, se for referente ao modulo deve-se explicar o modulo | ||
| + | ===4.2 Palavras chaves disponíveis:=== | ||
| + | |||
| + | * Quando for criada a suite principal deve-se criar pelo menos uma palavra chave associada a cada caso de teste. | ||
| + | * Quando for criado o módulo deve-se criar uma palavra chave referente ao modulo. | ||
| + | |||
| + | ===4.3 Na criação dos casos de teste é necessário preencher os seguintes campos:=== | ||
| + | |||
| + | <b>Campo <Título do Caso de Teste></b> | ||
| + | * Neste campo deve conter o número do mantis e a descrição | ||
| + | <b>Campo <Objetivo do Teste></b> | ||
| + | * Descrever o objetivo do teste de forma clara para que o testador saiba o que esta testando e verifique se o resultado está de acordo com o esperado. | ||
| + | <b>Campo <Pré-Condição></b> | ||
| + | * Preencher com os dados necessários para a execução do CT | ||
| + | <b>Campo < Pós-Condição></b> | ||
| + | * Campo opcional. | ||
| + | <b>Campo <Tipo de Execução></b> | ||
| + | * Deve-se escolher entre as opções Manual ou automatizado: | ||
| + | <b>Opção Manual -</b> teste executado através dos casos de teste.<br> | ||
| + | <b>Opção Automatizado -</b> irá utilizar uma ferramenta para teste automatizados onde são criados scripts de teste.<br><br> | ||
| + | <b>Campo <Prioridade do Teste></b> | ||
| + | * Deve-se escolher uma das opções: alto, médio ou baixo. | ||
| + | <b>Campo <Palavras chaves></b> | ||
| + | * Outras palavras chaves devem ser identificadas para apoio no reuso. | ||
| + | |||
| + | =5. DEFINIÇÕES PARA O RESULTADO DA EXECUÇÃO DO CASO DE TESTE= | ||
| + | |||
| + | * <b>Bloqueado:</b> O caso de teste será bloqueado quando o mesmo estiver desatualizado ou quando um passo não estiver bem descrito impossibilitando seguir para o passo seguinte. | ||
| + | * <b>Passou:</b> Um caso de teste estará aprovado quando todos os passos forem executados sem falhas e sem bloqueios | ||
| + | * <b>Falhou:</b> É dado como falha quando o resultado esperado de um passo está diferente do resultado da aplicação. | ||
| + | |||
| + | |||
| + | |||
| + | =6. REPORTANDO BUGS= | ||
| + | O erro deverá ser reportado ao desenvolvedor através do Mantis. O status do mantis é alterado para atribuído, devolvendo o mantis para o programador responsável pela requisição. | ||
| + | ===6.1 Campos obrigatórios do mantis -=== | ||
| + | <b>Campo <Adicionar Anotação></b> nesse campo é descrito passo a passo como reproduzir o erro e qual o real resultado esperado da aplicação.<br> | ||
| + | <b>Campo <Carregar Arquivo></b> Nesse campo são adicionadas imagens com o passo a passo reproduzindo o erro. | ||
| + | |||
| + | --[[Usuário:AnaPaula|AnaPaula]] 12h13min de 15 de janeiro de 2013 (BRST) | ||
Edição atual tal como 19h57min de 14 de fevereiro de 2013
Tabela de conteúdo |
1. OBJETIVO
O objetivo desse Guia é especificar como serão desenvolvidas as atividades de teste na Bisa, abordando técnicas a serem utilizadas durante a sua execução, reunindo todas as informações necessárias para planejamento e controle de teste referente a uma iteração específica.
2. CONCEITOS BÁSICOS
2.1 Tipos de testes
Existem vários tipos de teste. Este Guia abordará apenas o tipos utilizados pela Bisa. Seguimos duas técnicas de teste, Caixa Branca e Caixa Preta, distribuídos em quatro níveis (Teste de Unidade, de Integração, de Sistema e de Aceitação). Veremos na figura abaixo e melhor detalhado no link: <http://www.portalbisa.com.br/wiki/index.php/Fluxograma_representando_o_processo_de_desenvolvimento_de_Testes_na_Bisa>
2.2 Itens a serem testados
O acompanhamento de testes de todas as CRs será feito através da planilha: http://boletoswebbisa.com.br/processo/Sprint%20Delphi
2.3 Critérios de Entrada
Podemos iniciar os testes quando o ambiente de teste estiver pronto e configurado e as versões beta liberadas para o teste.
2.3 Critérios de Saída
Podemos encerrar os testes quando todos os testes planejados forem executados e todos os problemas encontrados e reportados segundo o padrão.
2.4 Critérios de Suspensão
Os testes devem ser suspensos quando o ambiente se mostrar instável ou os problemas encontrados em uma requisição afetem outras requisições impedindo que os testes sejam executados. O teste também será suspenso caso haja qualquer tipo de falha inesperada no ambiente de teste.
3. O PROCESSO DE TESTE NA BISA
3.1 Processo
1. Análise do escopo
2. Execução do teste
3. Aceitação
4. Implantação do Sistema
3.2 Fluxo de teste
Abaixo é apresentada uma figura representando o processo de execução de teste da BisaWeb.
4. PADRÕES DE DOCUMENTAÇÃO
4.1 Criação da suite campos necessários:
Campo <Nome da suite de Teste>
- Na suite de teste principal deve-se colocar o nome da rotina do sistema, ao qual deseja-se fazer relação a requisição que vai ser criado o caso de teste.
- Na suite secundaria deve-se ser colocado o nome do módulo ao qual a requisição pertence.
Detalhes: Uma breve descrição sobre a suite que está se criando, por exemplo se a suite for referente a rotina deve-se explicar a rotina, se for referente ao modulo deve-se explicar o modulo
4.2 Palavras chaves disponíveis:
- Quando for criada a suite principal deve-se criar pelo menos uma palavra chave associada a cada caso de teste.
- Quando for criado o módulo deve-se criar uma palavra chave referente ao modulo.
4.3 Na criação dos casos de teste é necessário preencher os seguintes campos:
Campo <Título do Caso de Teste>
- Neste campo deve conter o número do mantis e a descrição
Campo <Objetivo do Teste>
- Descrever o objetivo do teste de forma clara para que o testador saiba o que esta testando e verifique se o resultado está de acordo com o esperado.
Campo <Pré-Condição>
- Preencher com os dados necessários para a execução do CT
Campo < Pós-Condição>
- Campo opcional.
Campo <Tipo de Execução>
- Deve-se escolher entre as opções Manual ou automatizado:
Opção Manual - teste executado através dos casos de teste.
Opção Automatizado - irá utilizar uma ferramenta para teste automatizados onde são criados scripts de teste.
Campo <Prioridade do Teste>
- Deve-se escolher uma das opções: alto, médio ou baixo.
Campo <Palavras chaves>
- Outras palavras chaves devem ser identificadas para apoio no reuso.
5. DEFINIÇÕES PARA O RESULTADO DA EXECUÇÃO DO CASO DE TESTE
- Bloqueado: O caso de teste será bloqueado quando o mesmo estiver desatualizado ou quando um passo não estiver bem descrito impossibilitando seguir para o passo seguinte.
- Passou: Um caso de teste estará aprovado quando todos os passos forem executados sem falhas e sem bloqueios
- Falhou: É dado como falha quando o resultado esperado de um passo está diferente do resultado da aplicação.
6. REPORTANDO BUGS
O erro deverá ser reportado ao desenvolvedor através do Mantis. O status do mantis é alterado para atribuído, devolvendo o mantis para o programador responsável pela requisição.
6.1 Campos obrigatórios do mantis -
Campo <Adicionar Anotação> nesse campo é descrito passo a passo como reproduzir o erro e qual o real resultado esperado da aplicação.
Campo <Carregar Arquivo> Nesse campo são adicionadas imagens com o passo a passo reproduzindo o erro.
--AnaPaula 12h13min de 15 de janeiro de 2013 (BRST)

