PIQASD001 - Galp · A atividade de teste é critica no sentido de reduzir os riscos de entrega de...

PIQASD001 Metodologia e Procedimentos de Testes Versão 4.1 / 23-01-2017

Metodologia e Procedimentos de Testes

2/33

Controlo de Versões

Versão Autor Data Revisão Data Comentários

4.0 DSI Novembro

2016

Novembro

2016 Versão inicial

4.1 DSI Janeiro 2017 Janeiro 2017 Atualização 6.1.1


3/33

ÍNDICE

1. OBJETIVOS ........................................................................................................... 5

2. ENQUADRAMENTO ............................................................................................... 6

3. V-MODEL .............................................................................................................. 7

4. FASES DE TESTE ................................................................................................... 9

4.1 Detalhe das Fases de Teste ................................................................................ 10

4.1.1 Component Test ........................................................................................... 10

4.1.2 Assembly Test ............................................................................................... 10

4.1.3 Performance Test ......................................................................................... 10

4.1.4 Product Test ................................................................................................. 11

4.1.5 User Acceptance Test ................................................................................... 12

4.1.6 Operational Readiness Test ......................................................................... 12

4.2 Testes Transversais às Fases de Teste ............................................................... 14

4.3 Produtos Resultantes ......................................................................................... 15

4.4 Estratégia de Execução dos Testes .................................................................... 16

4.5 Ferramentas de Apoio aos Testes ...................................................................... 17

4.6 Ambientes ........................................................................................................... 18

4.7 Participação da Equipa de Qualidade e Testes .................................................. 18

4.8 Projetos Entregues pelos Proponentes .............................................................. 20

5. STAGE CONTAINMENT E CRITÉRIOS DE ENTRADA E SAÍDA .............................. 21

5.1 Critérios de Entrada e Saída ............................................................................... 22

5.1.1 Critérios de Saída de Ambientes .................................................................. 23

5.1.2 Critérios de Entrada para certificação ......................................................... 23

5.1.3 Processo de validação de TEC ...................................................................... 24

5.1.4 Critérios de Saída de Certificação ................................................................ 26

5.2 Testes Regressivos ............................................................................................. 26

5.3 Estratégia de Aceitação ...................................................................................... 27

5.4 Gestão de Pedidos de Alteração/ gestão de Defeitos ....................................... 27

6. SUPORTE AOS PROCEDIMENTOS DE QUALIDADE E TESTES EM ÂMBITO DE PROJETO

29

6.1 Gestão de Testes ................................................................................................. 29

6.1.1 Gestão de Defeitos ....................................................................................... 29

6.2 Centralização da informação de testes criada fora do HP ALM ......................... 32


4/33

7. REFERÊNCIAS .................................................................................................... 33


5/33

1. Objetivos

O objetivo deste documento é o de estabelecer a metodologia de testes e os procedimentos de Qualidade e

Teste na Galp os quais devem ser adotados por parte dos diversos intervenientes no processo, em especial

Integradores, equipas de manutenção e equipa de Qualidade e Testes.


6/33

2. Enquadramento

As tarefas de teste são parte integrante do ciclo de vida de desenvolvimento de software e representam uma

forma estruturada de validar que os requisitos e especificações se encontram implementadas e cumprem as

expectativas dos utilizadores, não só a nível funcional, mas também técnico, de operação e de manutenção.

A atividade de teste é critica no sentido de reduzir os riscos de entrega de software. Este documento define a

metodologia de abordagem ao teste, baseado no modelo V-Model e os procedimentos associados.

A aplicação das orientações e procedimentos, em termos latos, é independente do seu âmbito de projeto ou

de manutenção e certificação dos testes ser realizada ou não pela equipa de Projeto, equipa de Manutenção

Aplicacional, equipa de Midrange, equipa de Qualidade e Testes, equipa de Negócio, outras equipas da DSI -

Direção de Sistemas de Informação.


7/33

3. V-Model

O V-Model é um modelo utilizado pela indústria de desenvolvimento de software e representa uma melhor

prática na condução de projetos de implementação de soluções informáticas.

O diagrama seguinte pretende dar uma visão do modelo em questão.

O V-Model exige que cada produto resultante da atividade de desenvolvimento de software seja verificado e

validado permitindo a identificação de problemas o mais cedo possível e assegurar que as especificações

estão completas, corretas e aderentes aos standards definidos.

O teste pretende assegurar que as especificações do sistema se encontram corretamente implementadas e

que a solução vai de encontro aos requisitos de negócio e aos requisitos técnicos. Nesse sentido o diagrama

anterior deve ser lido no sentido de seguir os procedimentos abaixo ilustrados e descritos:

o Validação: Fazer o que está correto

Verifica que o produto resultante satisfaz os requisitos especificados em estados anteriores;

Garante que o produto resultante se encontra de acordo com o âmbito definido, contribui de forma

positiva para os benefícios esperados e não apresenta efeitos secundários indesejáveis;


8/33

É realizado através de uma verificação, simulação ou prototipagem.

o Verificação: Fazer da forma correta

Valida que o produto resultante está implementado de forma correta;

Valida que o resultado esperado e a implementação do processo estão de acordo com os standards

definidos;

É realizado através de verificação e revisão.

o Teste: Os componentes certos implementam a funcionalidade corretamente

Valida se uma especificação se encontra corretamente implementada;

Valida se a resposta a falhas técnicas (adaptador em “baixo”, falha de comunicação de rede, “hot

shutdown”, ligação a aplicações, etc.) se encontra contemplada e tem o tratamento mais adequado;

Valida se o sistema, componente ou funcionalidade tem o comportamento esperado, não

executando operações que não estejam contempladas nos requisitos (teste negativo);

É realizado através da execução do código.

O modelo do V-Model procura poupar tempo e esforço durante a fase de desenvolvimento, tendo como

objetivo assegurar uma melhor qualidade do produto final. A adoção deste modelo reduz substancialmente o

número de erros encontrados em fases finais do projeto e em produção.


9/33

4. Fases de Teste

Relativamente ao processo de teste, a figura do V-Model permite-nos identificar as seguintes fases de teste:

o “Component Test” ou Teste Unitário;

o “Assembly Test”;

o “Performance Test”;

o “Product Test”;

o “User Acceptance Test”;

o “Operational Readiness Test”.

O diagrama do V-Model ilustra a forma como as diferentes fases do teste se encontram associadas às

diferentes atividades do ciclo de vida de desenvolvimento de aplicações.

O planeamento das tarefas do teste ocorre durante a execução das atividades de planeamento, análise,

desenho e desenho detalhado da solução (lado esquerdo do diagrama).

A execução das tarefas do teste ocorre na metade direita do diagrama a partir da atividade de construção da

solução e prolonga-se até ao momento em que a aplicação é colocada em ambiente de produção.

As tarefas iniciais de teste (Component Test e Assembly Test) focam-se na confirmação dos requisitos

especificados nas tarefas de Detailed Design and Build e Design.

As seguintes tarefas de teste (Performance Test, Product Test, User Acceptance Test e Operational Readiness

Test) vêm a sua atividade focada na confirmação do cumprimento dos Requisitos (Functional Requirement e

Technical Requirement)

O diagrama seguinte pretende ilustrar o conceito associado a cada fase do teste, permitindo entender que o

grau de cobertura, complexidade e abrangência do teste aumenta ao longo da cadeia ascendente do V-Model.


10/33

4.1 Detalhe das Fases de Teste

4.1.1 Component Test

O componente de granularidade mais baixa numa aplicação de software é o componente (programa ou

módulo).

O teste de componente valida se o código produzido reflete as especificações detalhadas nos documentos de

desenho técnico do mesmo. Uma condição de teste formula um caminho único na execução do código do

componente. O âmbito das condições de teste engloba a exploração de caminhos alternativos de execução,

valores limites, condições de paragem em ciclos, etc. O teste de componente pode ser subdividido nas

seguintes áreas:

o Componentes desenvolvidos à medida;

o Interfaces;

o Configurações;

o Melhorias/Modificações;

o Reporting.

O planeamento do teste é realizado durante a fase inicial de construção do componente.

A execução do teste é realizada na fase final da construção do componente, logo após a sua codificação.

4.1.2 Assembly Test

Assegura que as interações entre os vários módulos programados se encontram a funcionar e produzem o

resultado esperado. Tipicamente pretende-se testar os interfaces entre os componentes de arquitetura

adjacentes no sentido de avaliar que, no seu conjunto e quando trabalham integrados, estes cumprem os

requisitos técnicos e de negócio para os quais foram desenhados.

O Assembly Test deverá começar com um nível de complexidade baixo, testando a integração entre pequenos

conjuntos de 2 a 3 componentes, evoluindo para as situações mais complexas.

Não se pretende validar neste teste as funcionalidades mais complexas da solução, já que essas serão

verificadas no teste de produto.

O planeamento do teste é realizado durante a fase de desenho.

A execução do teste é realizada durante a fase de testes.

4.1.3 Performance Test

Assegura que o sistema está capacitado para operar aos níveis de carga previstos e que os requisitos

identificados (SLAs) são cumpridos.


11/33

Durante a fase de testes de performance e de carga, deverão ser validados os seguintes aspectos:

o Performance do sistema com níveis normais de volume de utilização;

o Performance do sistema com níveis de pico de volume de utilização;

o Performance do sistema com níveis duas vezes superiores ao pico de volume de utilização;

o Identificação do volume a partir do qual se começa a observar degradação do sistema;

o Identificação da natureza da degradação;

Os testes de performance e carga devem ser executados num ambiente representativo do ambiente de

produção onde outros processos podem interferir com a aplicação a ser testada (por exemplo, processos

batch concorrenciais de outras aplicações, processos de limpeza e backups de base de dados, etc.). Desta

forma assegura-se que o teste decorre em circunstâncias o mais semelhante possível com as condições reais

de produção.

Durante os testes de performance e carga deverão ser monitorizados os diversos componentes do sistema,

nomeadamente:

o Capacidade de processamento dos servidores web;

o Capacidade de processamento dos servidores aplicacionais;

o Capacidade de processamento dos servidores de base de dados;

o Tempos médios de resposta da aplicação;

o Largura de banda ocupada pelas transações;

o Tráfego de rede e bottlenecks em elementos ativos de rede (routers, firewalls, switchs).

O planeamento do teste é realizado durante a fase de análise.


4.1.4 Product Test

Os testes de produto procuraram validar que todos os requisitos de negócio são cobertos pelo sistema. O

teste pode ser decomposto em sub testes nos casos em que o sistema é composto pela interação entre

múltiplas aplicações de negócio (por exemplo, Enterprise Integration). Neste cenário, o resultado do teste

final será condicionado ao resultado da soma dos vários testes de produtos que forem realizados

Os testes de produto são decompostos em dois tipos:

o Application – Com o objetivo claro de identificar se os requisitos de negócio estão a ser suportados na

nova solução;


12/33

o Integration – Representando um teste integrado end-to-end, onde os requisitos de negócio são validados

pela resultado da integração dos processos executados através da plataforma integradora.

O planeamento do teste é realizado durante a fase de análise.


4.1.5 User Acceptance Test

Assegura que os utilizadores se encontram, satisfeitos com o produto final e que este cumpre as

especificações e requisitos funcionais/técnicos.

Só após a aprovação deste teste se deverá preparar a solução para entrada em produção. Este teste permite

aos utilizadores finais terem a possibilidade de conduzir uma última revisão à solução antes desta entrar em

produção.

Os testes de aceitação devem ser planeados em conjunto com os utilizadores finais da solução. Desta forma

assegura-se que os utilizadores alvo da aplicação se reveem nas condições de teste e participam ativamente

na sua concretização.

O planeamento deste teste é realizado durante a fase de planeamento e análise do projeto, em consonância

com a definição de requisitos da aplicação.

A execução do teste é realizada durante a fase de teste.

4.1.6 Operational Readiness Test

Tem como objetivo testar o ambiente de execução no sentido de garantir que este cumpre os requisitos

técnicos necessários para a implementação da solução. É composto por três componentes: Testes de

Operação, Teste de Deployment e Teste de Verificação do Deployment.

4.1.6.1 Teste de Operação

Verifica que as funcionalidades, arquitetura e procedimentos se encontram definidos e implementados, de

modo a permitir às equipas de suporte à produção executar, manter e dar suporte ao sistema em produção,

de acordo com a prática definida ou com o nível de serviço acordado.

Os testes de operação compreendem tipicamente a cobertura das seguintes situações:

o Disponibilidade do sistema e monitorização de eventos nos servidores, rede, aplicações e interfaces;

o Funcionalidades e arquitetura de recuperação para o servidor, rede, aplicações ou falha nos interfaces;

o Falha nos discos e nos sistemas de mirroring;

o Capacidade de Switch over (servidores, bases de dados, rede, etc.);

o Funcionalidades de backup e restore;

o Sistema de recuperação do desastre e medidas a tomar;


13/33

o Funcionalidades de administração do sistema;

o Mecanismos de Segurança;

o Funcionalidades de job scheduling;

o Ferramentas de gestão e monitorização;

o Funcionalidades de arquivo;

o Sistemas de Gestão de Configurações.

Deverão ser desenhadas condições de teste e elaborados scripts de teste no sentido de assegurar que do

ponto de vista operacional, a aplicação cumpre com os requisitos e normas definidas.

4.1.6.2 Teste de Deployment

Durante este teste são validados os seguintes aspetos:

o Verificação de que todos os componentes necessários à solução se encontram identificados e podem ser

corretamente instalados no ambiente de produção, no momento definido;

o Verificação de que as rotinas de instalação, cutover e conversão funcionam como apropriado;

o Verificação de que as rotinas de instalação podem ser executadas dentro dos tempos previstos para o

deployment da solução;

o Verificação de que as rotinas de instalação podem ser executadas mais de uma vez, no sentido de

demonstrar a sua capacidade de reutilização;

o Verificar se é possível a realização de um rollback de instalação no caso de no processo de instalação ser

necessário repor a imagem anterior.

Os scripts de teste para o deployment tipicamente devem conter a informação suficiente para que possam ser

usados como instruções para o deployment. Os scripts devem ainda:

o Fazer referencia a checklists de instalação;

o Lista cada passo do processo de instalação;

o Especificar cada componente para instalação.


14/33

4.1.6.3 Teste de Verificação de Deployment

Este teste verifica que o sistema se encontra corretamente instalado e configurado no ambiente de produção,

capacitado para fornecer os serviços desenhados e possa ser corretamente monitorizado.

A verificação da instalação pode ser realizada recorrendo aos scripts (ou a um sub-set dos scripts) de teste de

produto, integração e operação e/ou recorrendo a condições especificas. Verificações comuns a realizar são:

o O sistema operativo está instalado com a versão correta e em operação como esperado;

o Bases de dados encontram-se instaladas com a versão correta e operam como esperado;

o O código aplicacional está instalado com as versões corretas e opera como esperado;

o Os interfaces encontram-se instalados e operam como esperado;

o Ferramentas de operação estão instaladas e executam como esperado;

o A conectividade entre os diferentes componentes da solução funciona como esperado;

o Foram executados os processos de conversão de dados na totalidade;

o As aplicações funcionam de forma correta e cumprem os requisitos de negócio identificados.

Para cada deployment aplicacional devem ser verificados os pontos descritos. No caso de uma aplicação de

integração via EAI, deverão ser executados estes processos para todas as aplicações. Uma vez completada a

sequência então a aplicação pode considerar-se em produção.

O planeamento das atividades de teste deve ser realizado antes da fase de deployment do projeto, com a

devida preparação prévia e execução de testes antes do deployment para produção. O processo utilizado para

o deployment nos ambientes de testes, pré produção e produção deve ser o mesmo, pelo que esse processo

será sistematicamente testado ao longo das fases de teste.

4.2 Testes Transversais às Fases de Teste

Apesar de se testar se as funcionalidades novas/alteradas funcionam, é necessário testar as restantes

funcionalidades para garantir que continuam a funcionar como esperado. Os testes regressivos (ou de

regressão) são os testes que cobrem esta necessidade.

Testes Regressivos – têm por objetivo garantir que todas as funcionalidades, que não foram alvo direto de

alterações, continuam a funcionam com sucesso. Os testes regressivos são descritos em maior detalhe na

seção 5.2 como parte integrante do Stage Containment.

Tendo em conta as fases de teste descritas na seção anterior e os respetivos testes diretamente associados,

os testes regressivos podem ser executados de forma transversal às fases definidas, em especial em

Performance Test, Product Test e User Acceptance Test.


15/33

4.3 Produtos Resultantes

Para cada fase do teste, é necessário criar um plano de testes. Cada tipo de teste necessita de um plano,

sendo que o produto resultante base é idêntico para cada uma das fases, variando o grau de complexidade e

detalhe a aplicar em cada tipo de teste.

Assim deverá ser criado um plano de teste, por cada fase de teste, que inclua a seguinte documentação:

o Abordagem ao Teste – Cada fase de teste deverá ter especificado uma abordagem à forma como deve

ser implementada. Este documento deverá conter a seguinte informação:

Dar a conhecer o overview do teste que se pretende realizar;

Especificar os critérios de entrada e saída para a fase de teste;

Especificar como vai ser implementado o controlo do teste (issue management, reporting);

Identificar os recursos envolvidos no processo de teste;

Estabelecer as datas chave e principais produtos resultantes;

Definir as métricas do teste a serem usadas nos critérios de entrada e saída da fase de teste e como

forma de validar a aceitação dos mesmos;

Especificar o ambiente de teste;

Especificar as ferramentas de teste a utilizar;

Inventariar assunções, riscos e pontos em aberto.

o Cenários de Teste - Cada teste deverá ter definido (alto-nível) os cenários funcionais e técnicos que irão

ser testados. Cada cenário de teste pode ser subdividido em sub-cenários até a um nível de detalhe em

que é possível identificar condições de teste e resultados esperados. Como resultado um cenário de teste

é descrito como um conjunto de condições de teste e resultados esperados.

o Condições de Teste e Resultados Esperados – As condições de teste definem os testes a serem

executados e devem sempre encontrar-se relacionadas com os requisitos que querem demonstrar:

Condições de teste de produto para testar requisitos funcionais e de negócio;

Condições de teste de assembly para validar o desenho;

Condições de teste de componente para validar o desenho detalhado.

Uma condição de teste tipicamente tem as seguintes propriedades:

Nome e descrição;

Resultado Esperado;


16/33

Referência ao requisito ou fonte do desenho;

Adicionalmente pode ou não conter os dados necessários para a execução do teste

o Script de Teste – Detalha os passos exatos que é necessário percorrer para concluir o teste de uma

determinada condição:

Tipicamente existe um script de teste para cada ciclo de teste;

Os scripts de teste podem incluir os dados que são necessários utilizar para a execução de cada

passo do script;

Cada passo do script de teste tem uma condição de teste associada que pode ser mapeada no

requisito de negócio que lhe deu origem.

o Registo de erros – Os erros identificados durante a execução dos testes, devem seguir o ciclo de vida

definido na seção “6.1.1.1 Ciclo de Vida dos Defeitos” e devem conter informação como a seguinte:

Descrição do erro;

Teste em que o erro ocorreu;

Severidade do erro;

Estado do tratamento do erro;

Equipa responsável pela sua correção;

Data de ocorrência;

Ações a efetuar para a sua correção;

Data de resolução da anomalia por parte da equipa de projeto.

Os templates a utilizar para garantir o cumprimento dos documentos anteriormente referidos de suporte aos

testes são:

o PIQAST001 – Plano de Abordagem ao Teste [1], o qual identifica a abordagem ao teste;

o PIQAST003 – Caderno de Testes [2], o qual identifica os cenários de teste, scripts de teste, condições de

teste e resultados esperados e ainda o registo e controlo de erros.

4.4 Estratégia de Execução dos Testes

Como forma de otimizar a utilização de recursos (e tempo) na execução dos testes, é necessário organizar os

ciclos de testes tendo em conta os tipos de testes que têm que ser executados. Para cada projeto, a

estratégia será definida em detalhe no plano de abordagem ao teste (PIQAST001[1]).


17/33

Por exemplo, os testes efetuados pela equipa de Qualidade e Testes, durante a fase de “Product Test”, terão

por base os tipos de teste Funcional e de Regressão. Sendo a participação da equipa alargada a outros tipos

de teste a estratégia de execução terá que ser adaptada ás circunstâncias específicas de cada projeto.

Tendo em conta que os 2 tipos de teste base, funcional e de regressão, se complementam na sequência de

testes a ser executada, serão utilizados 2 tipos de ciclos de testes:

o Ciclo Funcional – Onde serão executados os casos de testes funcionais desenhados de acordo com a

informação da documentação funcional.

o Ciclo de Regressão – Após a finalização do Ciclo Funcional, quando o software atinge o ponto de

estabilidade ao nível das funcionalidades alteradas/adicionadas, são executados os testes de regressão.

Estes testes são efetuados em ambiente controlado, de forma a validar que as restantes funcionalidades

que não estão diretamente relacionadas com os desenvolvimentos continuam a funcionar corretamente.

Adicionalmente, consoante os tipos de testes que sejam necessários executar, podem ser adicionados ciclos

adicionais de teste ou utilizar um dos ciclos base já existente.

Ao nível dos casos de teste, a prioridade deve ser definida com base na criticidade do requisito mais crítico

que lhe esteja associado.

4.5 Ferramentas de Apoio aos Testes

Para a condução dos vários tipos de teste identificados, a Galp utiliza um conjunto de ativos, alguns dos quais

permitem modelizar os passos descritos e automatizar a execução dos testes e/ou consolidar, para fins de

reporting e suporte à decisão os resultados dos mesmos.

No entanto, em determinadas situações a Galp poderá optar, tendo por base a criticidade/relevância das

soluções, adotar medidas excecionais no que respeita à utilização de ferramentas adicionais de suporte a

Qualidade e Testes.


18/33

4.6 Ambientes

Ambientes que devem ser disponibilizados por cada uma das fases:

Fases de Teste Ambiente

Component Test (Teste Unitário) DEV

Assembly Test DEV

Load & Perfomance Test QUA

Product Test Testes de Sistema: QUA

Testes Integrados: QUA

Testes de Regressão: PREPROD

User Acceptance Test QUA

Operational Readiness Test PROD

4.7 Participação da Equipa de Qualidade e Testes

A Galp prevê três níveis distintos de participação da equipa de Qualidade e Tests nos projetos de IT, a saber:

Nível 1 No nível 1 a equipa de Qualidade e Testes não participa em atividades de projeto

Nível 2 No nível 2 a equipa de Qualidade e Testes participa a nível de validação metodológica,

validando a estratégia e planos de testes elaborados pelos integradores

Nível 3

No nível 3 a equipa de Qualidade e Testes tem participação a nível metodológico e executa

testes de certificação da solução e de regressão. Opcionalmente pode também executar

testes de aceitação (UAT)

A definição do nível de participação da equipa de Qualidade e Testes é da responsabilidade da Galp, sendo

que, por norma, a mesma é definida durante a fase de consulta ao mercado. Caso tal não ocorra, a

participação será definida na fase inicial do projeto.

Tendencialmente a participação da equipa de Qualidade e Testes deverá ser do nível 2 ou 3.


19/33

Apresenta-se abaixo diagrama com os critérios alto nível de participação do integrador versus equipa de

Qualidade e Testes dependendo do nível de participação desta última definida ao nível do projeto.

A tabela seguintes identifica a intervenção que a equipa de Qualidade e Testes poderá ter nas diferentes

fases, mais detalhadamente:

Equipa Qualidade e Testes

Fases de Teste Testes Efetuados

Teste Unitário ou Component Test NA

Assembly Test NA

Load & Perfomance Test Testes de Carga

Testes de Performance

Product Test Testes Funcionais

Testes Não Funcionais

Testes de Segurança

Testes Negativos

Testes de Regressão

Testes Estáticos

User Acceptance Test Suporte aos testes de aceitação

Operational Readiness Test NA


20/33

4.8 Projetos Entregues pelos Proponentes

Para todos os projetos entregues pelos proponentes, independentemente de serem alvo de testes de

certificação ou não pela equipa de Qualidade e Testes, é da sua inteira responsabilidade a execução dos

seguintes testes:

Projetos entregues pelos proponentes

Fases de Teste Testes Efetuados

Component Test (Teste Unitário) Testes Unitários

Assembly Test Testes de Integração

Load & Perfomance Test Testes de Carga

Testes de Performance

Product Test Testes Funcionais

Testes Não Funcionais

Testes de Segurança

Testes Negativos

Testes de Regressão1

Testes Estáticos

Testes técnicos

Suporte à equipa de Qualidade e Testes, quando está é envolvida,

na realização de teste de:

Certificação;

Regressão.

User Acceptance Test Gestão e suporte aos testes de aceitação

Operational Readiness Test1 Suporte às equipas envolvidas 1Conforme descrito no documento de “Caderno de Encargos”.

A execução dos testes prossupõe a entrega dos documentos descritos no ponto “4.3 Produtos resultantes”.


21/33

5. Stage Containment e critérios de entrada e saída

O objetivo do stage containment é o de identificar os problemas no sistema durante o desenvolvimento antes

de passar para a fase seguinte. Este procedimento promove a qualidade do produto final, já que a deteção e

correção de erros numa fase inicial do processo de desenvolvimento é menos onerosa do que nas fases

seguintes.

Sem a implementação desta regra, um determinado desenvolvimento pode conduzir à situação ilustrada na

figura seguinte.

Este exemplo demonstra como a deteção de problemas numa fase avançada do desenvolvimento tem

impacto direto no plano de projeto e aumento dos custos do mesmo. Ao definir uma abordagem de Stage

Containment, pode-se minimizar o risco descrito e ajudar na implementação de ações corretivas ao processo

que conduziu à criação dos erros.

A figura seguinte ilustra o modelo desejado de implementação.

Para o concretizar é necessário estabelecer determinados procedimentos base no processo de teste que nos

irão dar a indicação sobre a possibilidade de transitar para a fase seguinte, sem risco de incorrer em desvios

e problemas de não conformidade da aplicação a ser desenvolvida no final do projeto.


22/33

Assim a transição entre fases deverá ser realizar recorrendo à implementação das seguintes praticas:

o Definição de critérios de entrada e de saída de testes/ambiente;

o Técnicas de verificação;

o Técnicas de validação.

5.1 Critérios de Entrada e Saída

Os critérios de entrada e saída não são mais do que um conjunto de condições que devem ser satisfeitas

antes de entrar ou sair de uma determinada fase/ambiente. Os critérios identificam o que é necessário para

poder suportar uma determinada fase – critério de entrada – e o que é necessário para poder determinar a

sua saída – critério de saída.

Os critérios de entrada e saída são definidos para cada ambiente de forma a assegurar que os produtos

resultantes apresentam a qualidade esperada no momento de passagem para a fase/ambiente seguinte.

Os critérios de entrada de uma fase/ambiente, tipicamente asseguram que os critérios de saída da

fase/ambiente anterior são cumpridos.

Alguns critérios de saída podem satisfazer critérios de entrada não da fase/ambiente seguinte mas de uma

outra mais à frente. Tipicamente os critérios de saída de cada fase/ambiente acabam por adicionar mais uma

condição de que a anterior.

Por exemplo, os critérios de entrada na fase/ambiente de execução do teste de produto podem incluir que os

critérios de saída do teste de componente de assembly tenham sido cumpridos. Uma condição adicional pode

estabelecer a necessidade do ambiente de execução para os testes de produto está concluído e todos os

critérios de saída da fase de preparação do teste de produto estão cumpridos.

O V-Model especifica que as atividades de uma determinada fase/ambiente sejam completadas antes de

prosseguir para a fase seguinte. É crítico que os critérios de saída de uma fase sejam cumpridos antes de dar

entrada na fase seguinte. Estes critérios deverão ser definidos no documento de abordagem ao teste.


23/33

5.1.1 Critérios de Saída de Ambientes

Toda a informação que vai para logging deve atender as condições atualmente definidas no Spotfire -

PIARQT012[5] em termos de condições de aceitação, nas transições de:

o DSVQualidade Isolada

o Qualidade IsoladaQualidade Consolidado

o Qualidade Consolidado Prod

5.1.2 Critérios de Entrada para certificação

Antes da equipa de Qualidade e Testes iniciar a fase de certificação, o proponente deverá validar o

cumprimento do Test Entry Criteria (TEC), de forma a garantir que estão reunidas as condições mínimas para

dar início aos testes de certificação.

O TEC é composto por um conjunto de condições mínimas (pré-requisitos) para que o processo de testes

possa ser iniciado, a saber:

5.1.2.1 Desenho Funcional e Desenho Técnico

o Requisitos Funcionais (PAF002[4]);

o Desenho Funcional (PAF003);

o Documentação Técnica (PIGENT011);

o Desenho e Arquitetura (PIGENT012);

o Check List do Projeto (PIARQT011);

o Mapeamento de Dados (PIGENT016);

o Modelo de Entidades (PIARQT313).

5.1.2.2 Evidências dos Testes Executados

o Testes Unitários/Integrados/Performance/Carga/etc. (PIQAST003 [2]).

o Spotfire - PIARQT012, quando haja componente de integração (para este caso em particular o envio do

relatório pode ser substituído pela indicação do perfil spotfire e período dos testes)


24/33

5.1.2.3 Ambiente de Testes

o Software a ser testado disponibilizado para ambiente de testes;

o Dados de teste para execução dos testes;

o Aplicações necessárias.

5.1.2.4 Preview Funcional

o Demonstração das funcionalidades do projeto implementadas.

5.1.3 Processo de validação de TEC

O processo de validação do Test Entry Criteria (TEC) culmina na apresentação do Preview Funcional, onde as

funcionalidades requisitadas são apresentadas com o objetivo de se aceitar a aplicação para teste de

certificação. Para tal, é necessário seguir um processo que garanta as condições necessárias para que, no dia

do Preview Funcional, sejam cumpridos todos os critérios de aceitação.

5.1.3.1 Agendamento e Validação de Pré-requisitos para Preview Funcional

Responsabilidade: Gestão de Projeto

Descrição: A gestão de projeto deve agendar a data da reunião de preview funcional de acordo com a

disponibilidade dos diferentes stakeholders. Deve igualmente agendar a data para a entrega da agenda do

preview funcional pela equipa de projeto para a equipa de testes de certificação (pelo menos 3 dias antes da

reunião de preview funcional).

Para além do agendamento, é da responsabilidade da Gestão de Projeto a validação dos pré-requisitos

(requisitos funcionais, requisitos técnicos, testes unitários e ambiente de testes, etc.) de forma a verificar se

estão reunidas as condições para se avançar para o preview funcional.

5.1.3.2 Detalhar as Funcionalidades a Apresentar no Preview Funcional

Responsabilidade: Integrador

Descrição: Detalhar agenda do TEC (PIQAST004[3]) com as funcionalidades a serem apresentadas no

preview funcional. Estas funcionalidades devem incluir os processos diretamente associados às alterações e

quando necessário alguns processos críticos de negócio. O objetivo não é testar exaustivamente a aplicação,

mas apenas demonstrar que as funcionalidades novas/alteradas estão a funcionar e que os processos críticos

de negócio não foram afetados.

O detalhe das funcionalidades deve conter a informação da funcionalidade a ser apresentada, as condições de

execução que estão a ser exercitadas e o resultado esperado da execução.

A composição desta agenda deve ter por base principal o PAF002[4] e PIQAST003[2] devidamente

preenchidos com a identificação da criticidade dos requisitos/casos de teste.

A agenda deve ser enviada para validação para a Equipa de Qualidade e Testes com uma antecedência

mínima de 3 dias antes da data planeada para a apresentação do Preview Funcional.


25/33

5.1.3.3 Validar Agenda TEC

Responsabilidade: Qualidade e Testes

Descrição: Validação da composição da agenda do TEC. A agenda deve conter situações funcionais que

exercitem as funcionalidades novas/alteradas, assim como, os processos críticos de negócio relacionados com

as funcionalidades desenvolvidas. Em caso de necessidade, deve ser pedido a alteração da agenda de forma

a alterar/adicionar funcionalidades a serem demonstradas. É necessário efetuar esta validação

atempadamente para que no dia do Preview Funcional estejam reunidas todas as condições necessárias,

como por exemplo, a existência de dados para testes.

5.1.3.4 Preview Funcional - Apresentação Test Entry Criteria (TEC)

Responsabilidade Apresentação: Gestão de Projeto e Equipa de Projeto

Responsabilidade Aprovação: Qualidade e Testes

Stakeholders presentes: Gestão de Projeto, Equipa de Projeto, Qualidade e Testes, outras áreas da DSI

consoante o projeto em causa.

Descrição: Após o deployment do software no respetivo ambiente de testes e das respetivas validações de

desenvolvimento, o Gestor de Projeto deve confirmar a data da apresentação de TEC previamente definida no

plano de projeto.

Ter em atenção que existem 2 tipos de validações:

1. Lista de Critérios de TEC previamente definidos no plano de projeto (Pré-requisitos para Preview

Funcional)

Os critérios de TEC previamente definidos no plano de projeto funcionam como pré-requisitos, sendo

que devem ser cumpridos para que se possa fazer o deployment e marcação da apresentação do

Preview Funcional.

2. Preview Técnico das funcionalidades mais críticas detalhadas na Agenda do TEC

As funcionalidades detalhadas na Agenda do TEC são apresentadas e validadas durante a apresentação

do Preview Funcional.


26/33

Consoante o resultado das validações dos vários critérios, a equipa de Qualidade e Testes deve assinalar a

respetiva validação com sucesso ou não no documento de Agenda do TEC:

o Se o TEC for aceite a execução de testes pode ter início;

o Se o TEC não for aceite então considera-se que o desenvolvimento não está entregue e será necessário

continuar com o desenvolvimento da aplicação para que quando este termine se possa efetuar um novo

TEC;

5.1.3.5 Criação de Relatório TEC

Responsabilidade: Qualidade e Testes

O Relatório de TEC, terá por base a agenda do TEC (PIQAST004[3]) com as respetivas validações e resultado

da aprovação pela equipa de Qualidade e Testes.

5.1.4 Critérios de Saída de Certificação

Os critérios de saída definem objetivamente as condições que têm que ser cumpridas para que se possa

considerar que os testes de certificação estão finalizados com sucesso.

Os critérios de saída têm por base/defeito 2 vetores:

o O nível de sucesso da execução de testes;

o Defeitos em aberto e por resolver.

Tabela com os critérios para cada uma das métricas:

Métrica Critério

Taxa de sucesso das execuções prioritárias = 100%

Número de defeitos em aberto de severidade elevada = 0

Taxa de sucesso das execuções prioridade baixa ≥ 95%

Taxa de defeitos em aberto de severidade baixa < 5%

Estes critérios são utilizados para determinar se a execução de testes pode ser declarada completa.

5.2 Testes Regressivos

Os testes regressivos asseguram que quando alterações são introduzidas a um sistema, estas não afetam

inadvertidamente outras funcionalidades existentes. O teste regressivo deve ser utilizado ao longo do

processo de testes sempre que uma alteração ocorre.

Devem ser desenhados procedimentos de teste que asseguram a validação e reteste dos componentes

alterados e de outras áreas afetadas pela alteração, ainda que estas não tenham especificamente sofrido

intervenção direta.


27/33

Por exemplo, a introdução de uma nova release de software base pode originar a necessidade de voltar a

testar a área do sistema afetada por essa alteração. O âmbito do teste regressivo deve ser estabelecido no

início e devem ser alocados recursos para o teste (programadores e utilizadores).

Como melhor prática, deve existir um plano de teste detalhado para as situações de teste regressivo e deve

ser construído de modo a poder ser reutilizado de cada vez que a necessidade de teste regressivo surgir.

O uso de ferramentas automatizadas de teste pode ajudar a reduzir o esforço necessário à sua concretização.

A definição e execução de testes regressivos no âmbito de um projeto é por norma, não da responsabilidade

do projeto, mas da Galp, nomeadamente quando assignado à equipa de Qualidade e Testes.

5.3 Estratégia de Aceitação

A estratégia de aceitação assegura que o calendário de execução do teste e o esforço associado ao mesmo se

encontra alinhado. No momento de planear a execução do teste é fácil esquecer o facto de que, os erros

encontrados durante a execução do teste irão necessitar de ser corrigidos e testados regressivamente,

aumentando desta forma o esforço inicialmente previsto.

Uma melhor prática relativa planeamento da fase de testes é o de contabilizar a necessidade de poder ser

necessário executar 3 passagens de execução de testes. Esta estratégia assume que cada ciclo de teste é

executado em média 3 vezes em cada fase do teste. Os objetivos de cada passagem são os seguintes:

o Passagem 1 – Executar o ciclo de teste, identificando o maior número de defeitos possível e assegurando

que estes são registados e atribuídos à equipa de projeto para correção. Não é necessário completar o

ciclo, quando defeitos graves forem detetados (que impeçam a progressão do teste);

o Passagem 2 – Re-executar o ciclo de teste por inteiro, dando especial atenção aos problemas detetados

durante a passagem 1 e determinar se a correção dos mesmos originou outros defeitos;

o Passagem 3 – Re-executar o ciclo de teste por inteiro, dando especial atenção aos problemas detetados

durante a passagem 2. Nesta passagem não deverão ser detetados novos defeitos, se o forem deverá

ser considerada uma 4ª passagem.

Esta estratégia assegura que todos os defeitos são resolvidos e testados. Também assegura que as correções

introduzidas não afetam inadvertidamente outras áreas do sistema.

A qualidade do código pode ser medida após cada passagem por comparação das métricas com os critérios

de saída. Por exemplo, um critério de saída pode ser uma percentagem de condições provadas. Se no final

estivermos abaixo do valor então será necessário proceder a correções.

5.4 Gestão de Pedidos de Alteração/ gestão de Defeitos

A gestão de pedidos de alteração tem como missão realizar o acompanhamento dos testes, registar as

ocorrências, resolver o defeito e proceder ao teste regressivo.

Este processo envolve o registo, a revisão, prioritização dos defeitos, assignação dos pedidos aos

programadores e assignação das tarefas de teste aos utilizadores.


28/33

Na metodologia adotada pela Galp Energia, nesta vertente da Quality Assurance, o template definido para se

garantir este registo é o PIQAST003[2].


29/33

6. Suporte aos Procedimentos de Qualidade e Testes em âmbito de projeto

6.1 Gestão de Testes

O desenho dos casos de teste, a execução dos mesmos e a gestão de defeitos serão suportados numa

ferramenta de gestão de testes - HP ALM ou pelo template Galp PIQAST003[2].

6.1.1 Gestão de Defeitos

6.1.1.1 Ciclo de Vida dos Defeitos

No diagrama abaixo, está refletido o ciclo de vida dos defeitos em vigor na Galp Energia.

Participam no ciclo de vida dos defeitos os seguintes intervenientes, a equipa de Qualidade e Testes (Q&T) e

o projeto (DEV).


30/33

6.1.1.2 Descrição dos estados dos defeitos

Na tabela seguinte encontram-se as descrições dos diferentes estados dos defeitos.

Estado Owner Estado

Anterior

Estado

Seguinte Descrição

New Tester N/A Open Estado inicial do defect quando é criado em HP ALM.

Open Tester New In Analyses

Após criado o defect será validado pelo Tester, passando

de seguida para o estado ‘Open’. Neste estado ficará na

fila do Proponente.

In Analyses Proponente Open

Reject

Duplicate

In

Resolution

O Proponente inicia a análise ao defect, passa o estado

do mesmo para ‘in analyses’.

Reopen Proponente In

Validation In Analyses

Após o Proponente colocar um defect em ‘reject ’ ou

‘peding retest’, o Tester valida o mesmo. Se o

resultado não for o pretendido coloca o estado do

defect a ‘Reopen’, ficando novamente na fila do

Proponente.

Reject Proponente Open/

Reopen

In

Validation

Caso o Proponente não considere a situação reportada

como sendo um defect, deverá colocar a mesma no

estado ‘Reject’.

Duplicate Proponente Open/

Reopen

In

Validation

O Proponente deverá atribuir este estado sempre que

considere que o defect já foi reportado anteriormente.

In Resolution Proponente Open/

Reopen Fixed

Após análise do Proponente, e se verificarem que a

situação reportada se trata efetivamente de um

defect, o estado do mesmo deverá ser alterado para

‘In Resolution’. Ficará durante o período em que a

correção se encontra em curso.

Fixed Proponente In

Resolution

Waiting for

Instalation

Após resolução do defect reportado, o mesmo deverá

ser colocado no estado ‘Fixed’ até ser planeado para

ser instalado em ambiente de testes.

Waiting for

Instalation Proponente Fixed

Pending

Retest

Quando a correcção ao defect reportado está planeada

para ser instalada em ambiente de testes na próxima

janela de instalação de software.

Pending Retest Proponente Waiting for

Instalation

In

Validation

Solução instalada em ambiente de testes. O Defect

pode ser retestado.


31/33

Estado Owner Estado Anterior

Estado Seguinte

Descrição

In Validation Tester

Reject;

Duplicate;

Pending

Retest

Reopen;

Closed

Podem acontecer uma de duas situações:

o Quando um defect é rejeitado pelo Proponente, o

tester deverá analisar o motivo de rejeição e concluir

acerca deste podendo fechar o defect ou reabri-lo

explicando devidamente a situação.

o Após a correção de um defect ser instalada em

ambiente de testes, o Tester irá proceder á validação

da correção disponibilizada colocando para isso o

defect neste estado.

Closed Tester In

Validation N/A

Pode acontecer uma de duas situações:

o O tester valida uma rejeição e concorda com a

mesma procedendo ao fecho do defect.

o O tester valida com sucesso uma correção

disponibilizada pelo Proponente e fecha o defect.

6.1.1.3 Classificação prioridade e severidade dos Defeitos

Em baixo seguem-se os níveis que foram determinados para classificação dos Defeitos relativamente á

Prioridade:

Nível Descrição Detalhe

1 Low

Oportunidade de melhoria ou sugestão de alteração que não tem impacto nos

resultados esperados.

Não existe qualquer bloqueio nas atividades de teste.

2 Medium

Pequenas incorreções, como erros ortográficos, desalinhamento de campos ou campo

mal formatado num relatório não oficial.

Não existe impacto no calendário de testes (excluindo quando estes são os únicos

defeitos que faltam tratar para o fecho dos testes).

3 High

O defeito está a bloquear parcialmente as funcionalidades do sistema.

Conseguem-se executar um conjunto alargado de casos de teste, no entanto existe

impacto nas atividades e no calendário de testes.

4 Very-High

O defeito está a bloquear grande parte das funcionalidades do sistema.

Apenas se conseguem executar um conjunto pequeno de casos de teste, causando

impacto severo nas atividades e no calendário de testes.

5 Urgent O defeito está a bloquear totalmente a utilização de sistema.

A execução de testes encontra-se totalmente bloqueada.


32/33

Em baixo seguem-se os níveis que foram determinados para classificação dos Defeitos relativamente á

Severidade:

Nível Descrição Detalhe

1 Cosmetic Não afeta qualquer funcionalidade. Não necessita de workaround.

Apenas problemas cosméticos/ sugestões de melhoria.

2 Minor Afeta a utilização de uma funcionalidade menor da aplicação. Existe workaround.

3 Moderate Afeta a utilização de uma funcionalidade importante da aplicação. Existe workaround.

4 Major Afeta a utilização de uma funcionalidade crítica da aplicação. Existe workaround.

5 Critical Bloqueia completamente a utilização de uma funcionalidade crítica da aplicação. Não existe

workaround.

6.2 Centralização da informação de testes criada fora do HP ALM

Com o objetivo de centralizar toda a informação de requisitos e de testes, aquando da utilização do

PAF002[4] e do PIQAST003[2] estes não poderão ser alterados sem a autorização da equipa de Arquitetura e

Standards /equipa de Qualidade e Testes já que se pretende garantir a capacidade de carregamento do

mesmo, via scripts já definidos, na ferramenta HP ALM, nas vertentes de:

o Casos de teste;

o Defeitos;

o Requisitos.


33/33

7. Referências

[1] – PIQAST001 – Plano de Abordagem ao Teste.doc

[2] – PIQAST003 – Caderno de Testes.xls

[3] – PIQAST004 – Agenda do TEC.xls

[4] – PAF002 – Especificação de Requisitos.xls

[5] – PIARQT012 – Métricas de Projeto - Integração

PIQASD001 - Galp · A atividade de teste é critica no sentido de reduzir os riscos de entrega de...

Documents

Transcript of PIQASD001 - Galp · A atividade de teste é critica no sentido de reduzir os riscos de entrega de...