Anda di halaman 1dari 5

Ministrio da Sade

Secretaria Executiva
Departamento de Informtica do SUS
Coordenao-Geral de Anlise e Manuteno
METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE

Guia de Preenchimento
Plano de Teste
Todos os exemplos usados nesse guia so fictcios!

NOMENCLATURA PADRO DO DOCUMENTO


A nomenclatura do arquivo padro para este e os demais artefatos da MDS esto
descritos no Controle de Branches e Baseline. Em caso de dvida, entrar em contato com
a UGCS - Unidade de Gerncia de Configurao de Software.

INFORMAES SOBRE O PROJETO


Descrevem as informaes bsicas para identificar o projeto, como sigla e nome do
projeto, dados pessoais dos responsveis: Gestor e Gerente de Projeto.
Ex.:

ZAP Zona de Acordo Possvel


Gestor do Projeto Gerente de Projeto
Joo Carlos da Silva Mariana Cavalcante
Joao.silva@saude.gov.br marianac@saude.gov.br
3315-8569 3315-6632

OBJETIVO DESTE DOCUMENTO


Descreve os objetivos do documento e outras informaes relevantes para o
preenchimento do seu contedo. Este campo estar pr-defino e no precisa ser
preenchido, apenas complementado, caso seja necessrio.
Ex.:

Objetivo deste Documento

Este documento tem como objetivo estabelecer as principais funcionalidades e


fronteiras do sistema descrevendo informaes que delimitam o projeto de
desenvolvimento como um todo.

HISTRICO DE REVISO
Os parmetros de histrico de reviso dos documentos so mantidos pela Unidade de
Gerncia de Configurao de Software.
- O campo Data deve ser preenchido no formato dd/mm/aaaa;
- O campo Demanda corresponde ao meio de solicitao e o nmero gerado pela
solicitao. O Sistema de Demanda Sirius recebe a sigla SR+ nmero da demanda.
- O campo Autor deve conter o nome e 1 sobrenome do autor da reviso;
- No campo Descrio deve est descrito as alteraes feitas no documento;
- O campo Verso dever ser evoludo em toda alterao feita e preenchido de
acordo com os parmetros definidos pela UGCS - Unidade de Gerncia de Configurao
de Software.
Ex.:

Histrico de Reviso
Data Deman Autor Descrio Vers
da o
01/01/201 SR1935 Manuela de Criao do Documento 0.1
6 68 Souza
Guia de Preenchimento
Documento de Negcio

18/01/201 SR1935 Manuela de Homologao do 1.0


6 68 Souza Documento.

Obs.: O redimensionamento das colunas das tabelas poder ser alterado caso haja
necessidade.

1. INTRODUO

1.1 Escopo
Uma breve descrio do escopo deste Plano de Teste; a que Projeto(s) ele est
associado e tudo o mais que seja afetado ou influenciado por este documento. Caso
esteja em outro documento fazer a referncia ao outro documento.

Ex.:
O escopo do Plano de Testes em questo abrange os seguintes requisitos do projeto e poder
sofrer alteraes durante a evoluo do Projeto:

Caso o usurio seja corporativo, o sistema dever realizar


validao no SCPA; essa validao dever ser realizada
atravs do e-mail.
01 Efetuar Login Caso o usurio seja Parlamentar ou Assessor, o
sistema dever realizar a validao na base do prprio
sistema e vincular as emendas aos respectivos
parlamentares
O sistema dever apresentar opes de visualizao de
pendncias, grficos consolidados com as informaes
Visualizar Painel de
02 das emendas e das propostas do parlamentar, agenda
Controle
das emendas e filtros de consulta relacionadas s
emendas do parlamentar autenticado na aplicao
O sistema dever apresentar as emendas e a linha do
tempo das emendas vinculadas ao parlamentar
Visualizar Informaes autenticado na aplicao bem como as informaes das
03
da Emenda propostas cadastradas para cada emenda, tais como: a
situao, linha do tempo, pareceres, habilitao,
empenho e pagamento de cada proposta.
O sistema dever apresentar a opo para que o
04 Indicar Beneficirio parlamentar indique beneficirios para cada emenda
vinculada ele.
O sistema dever apresentar opo para que o ator tenha
05 Conceder Acesso a permisso de conceder ou retirar o acesso de um ou
mais usurios

2. ESTGIO DE TESTES
Este item para identificar os estgios de testes a serem executados no nvel do
teste em questo.
So exemplos de estgios de testes:
Teste Unitrio: estgio mais baixo da escala de testes e so aplicados nos menores
componentes de cdigo criados, visando garantir que estes atendam as especificaes,
em termos de caractersticas e funcionalidade. Os testes devero ser realizados pelos
Desenvolvedores.
Teste de Integrao: so realizados para verificar basicamente se as unidades
testadas de forma individual executam corretamente quando colocadas juntas, isto ,
quando integradas. Os testes so realizados pelo Analista Homologador.
Teste de Sistema: so realizados pelo Analista Homologador, visando a execuo do
sistema, dentro de um ambiente operacional controlado, para validar a exatido e
perfeio na execuo de suas funes.

Metodologia de Desenvolvimento de Software Verso 1.0 Pg. 2 de 5


Guia de Preenchimento
Documento de Negcio

Teste de Aceitao ou Homologao: so os testes finais de execuo do sistema,


realizados pelos usurios, visando verificar se a soluo atende aos objetivos do negcio
e a seus requisitos, no que diz respeito funcionalidade e usabilidade, antes da utilizao
no ambiente de produo. Para a realizao deste tipo de teste, sugere-se a participao
do Analista Homologador.

Ex.:

Definem o momento do ciclo de vida do software em que so realizados testes por pessoas
diferentes daquelas que o programaram. Entretanto, considerando a diviso das tarefas de teste
em quatro nveis relacionados ao escopo do software, esto previstos para o projeto SISPRO os
seguintes estgios de teste:
Teste de Integrao: so realizados para verificar basicamente se as unidades
testadas de forma individual executam corretamente quando colocadas juntas, isto
, quando integradas. Os testes so realizados pelo Analista de Testes.
Teste de Sistema: so realizados pelo Analista de Testes, visando a execuo do
sistema, dentro de um ambiente operacional controlado, para validar a exatido e
perfeio na execuo de suas funes.

3. TIPOS DE TESTE
Neste item devem ser selecionados somente os tipos de testes a serem aplicados no
projeto. Os tipos de teste podem ser:
Acessibilidade: verifica se a interface do usurio fornece o acesso apropriado
s funes do sistema e a navegao adequada. Alm disso, estes testes
garantem que os objetos dentro da interface do usurio funcionem de acordo
com os padres definidos pelo cliente.
Carga: verifica o comportamento do sistema frente variao de carga de
trabalho diferente e grande quantidade de dados no sistema para determinar
se os limites que podem causar a falha do software so alcanados.
Ciclo de negcio: verifica se o ciclo do caso de uso est de acordo,
percorrendo todas as funcionalidades desde a entrada do dado at sua sada.
Configurao: verifica se o software est apto a rodar em diferentes verses
ou configuraes de ambientes (hardware e software), como, por exemplo, em
diferentes browsers.
Controle de Segurana e Acesso: avalia o aplicativo quanto s restries
de acesso em duas principais reas de segurana: segurana em nvel de
aplicao e em nvel de sistema.
Disponibilidade: avaliam a capacidade do software em continuar operando
mesmo quando algum elemento (software ou hardware) fica inoperante ou
para de funcionar.
Estresse: verifica o comportamento do sistema durante condies limite ou
fora da tolerncia esperada.
Falha e Recuperao: assegura que o sistema pode, com sucesso, recuperar
os dados aps uma falha no funcionamento do hardware, do software ou de
rede, quando existir perda dos dados ou da integridade dos mesmos.
Funcional: grupos de testes que avaliam se o que foi especificado foi
implementado.
Instalao: verifica que o sistema instalado em outra mquina, que no
tenha sido utilizada anteriormente, funcione corretamente,
Integridade de dados: devem ser executados os mtodos de acesso base
de dados da interface do usurio, de forma que seja possvel observar e
registrar o comportamento funcional incorreto ou a corrupo de dados.
Performance: mede e avalia o tempo de resposta de cada transao dos
requisitos sensveis ao tempo.

Metodologia de Desenvolvimento de Software Verso 1.0 Pg. 3 de 5


Guia de Preenchimento
Documento de Negcio

Usabilidade: verificam o nvel de facilidade de uso do software pelos


usurios.
Fumaa: verifica a capacidade do sistema de resistir a situaes no
previstas nos requisitos e especificaes.
Regresso: verifica a ocorrncia de novos defeitos aps a resoluo de
defeitos.

Ex.:

Seguem abaixo os tipos de testes a serem aplicados ao projeto SEOFC Emendas


Parlamentares:
Funcional: grupos de testes que avaliam se o que foi especificado foi implementado.
Regresso: verifica a ocorrncia de novos defeitos aps a resoluo de defeitos.
Ciclo de negcio: verifica se o ciclo do caso de uso est de acordo, percorrendo todas as
funcionalidades desde a entrada do dado at sua sada.
Acessibilidade: verifica se a interface do usurio fornece o acesso apropriado s funes
do sistema e a navegao adequada. Alm disso, estes testes garantem que os objetos
dentro da interface do usurio funcionem de acordo com os padres definidos pelo cliente.
Disponibilidade: avaliam a capacidade do software em continuar operando mesmo
quando algum elemento (software ou hardware) fica inoperante ou para de funcionar.

4. RECURSOS TCNICOS

4.1 Recursos Humanos


Especificar os recursos humanos necessrios para a execuo dos testes. Caso essa
informao esteja descrita em outro artefato do projeto, como por exemplo o Plano do
Projeto, deve-se referenciar a informao em questo para o documento Plano do Projeto.
Caso esteja em outro documento fazer a referncia ao outro documento.
Ex.:
Os recursos humanos necessrios para a execuo dos testes:
Analista de Testes / Testador

4.2 Recursos Computacionais


Especificar os recursos humanos necessrios para a execuo dos testes. Caso essa
informao esteja descrita em outro artefato do projeto, como por exemplo o Plano do
Projeto, deve-se referenciar a informao em questo para o documento Plano do Projeto.
Caso esteja em outro documento fazer a referncia ao outro documento. Especificar os
recursos computacionais necessrios para a execuo dos testes sejam eles de hardware
ou software. Caso essa informao esteja descrita em outro artefato do projeto, como por
exemplo, o Plano de GCS, deve-se referenciar a informao em questo para o
documento Plano de GCS. No caso de software, deve ser especificada a quantidade de
licenas necessrias para dimensionamento e atendimento ao projeto. Mencionar
tambm as ferramentas para automao caso seja necessrio.
Caso exista detalhamento do ambiente de homologao ou teste no documento de
arquitetura de software o mesmo pode ser referenciado evitando redundncia na
informao.

Ex.:
Os recursos computacionais necessrios esto disponveis no Diretriz_Arquitetural Ministrio
da Sade e Documento-Arquitetura-FNS-MS-ORACLE_BPM e podero sofrer alteraes durante a
evoluo do projeto.

Metodologia de Desenvolvimento de Software Verso 1.0 Pg. 4 de 5


Guia de Preenchimento
Documento de Negcio

5. RISCOS E RESTRIES
Listar quaisquer riscos, restries ou contingncias que possam afetar o projeto,
desenvolvimento ou implementao do teste. Caso esteja em outro documento fazer a
referncia ao outro documento.

Ex.:

Os riscos, restries ou contingncias que possam afetar o projeto, desenvolvimento ou


implementao do teste, esto descritos abaixo:

Compartilhamento de colaboradores com outros projetos


Falta de documentao atualizada
Indisponibilidade e nvel dos requisitos
Indisponibilidade de ambiente de teste de homologao
Solicitao de demandas extras durante a elaborao e execuo dos testes
Complexidade para se testar determinada funcionalidade
Dados para insero na base de dados
Prazos curtos

6. RISCOS E RESTRIES
Especificar os produtos que sero gerados durante a realizao dos testes.
Ex.:
Roteiro de Testes: Artefato gerado para os requisitos funcionais tomando como base a
especificao de caso de uso, interface de caso de uso, regras de negcio e lista de
mensagens. Cada caso de uso ter um roteiro de testes associado e ser gerado
automaticamente pela ferramenta TestLink.
Planilha de Resultado de Teste: Artefato gerado durante a execuo dos ciclos de teste.
Este artefato produzido um para cada roteiro de testes.

7. REFERNCIAS
Listar as referncias utilizadas neste documento. Para apresentao das referncias,
pode-se utilizar a norma aprovada pela ABNT (Associao Brasileira de Normas Tcnicas)
relativa apresentao de referncias bibliogrficas, identificada como NBR 6023:2000
Referncias Bibliogrficas.

Ex.:

# Documento Verso
SEOFC_PPR_Emendas_Parlamenta 0.1
01
res
02 Lista de Caso de Uso 0.1
Diretriz_Arquitetural Ministrio da 1.0
03
Sade
Documento-Arquitetura-FNS-MS- 1.0
04
ORACLE_BPM

Metodologia de Desenvolvimento de Software Verso 1.0 Pg. 5 de 5