11-2 - Modelo de Processo Generico de Teste de Software

Centro de Tecnologia da Informação Renato Archer – CTI/MCT

SPB - Modelo de Processo Genérico de Teste de Software 1

Centro de Tecnologia da Informação Renato Archer, CTI

Ministério da Ciência e Tecnologia, MCT

Modelo de Processo

Genérico de Teste de

Software

Autores:

Adalberto Nobiato Crespo: [email protected]

Mario Jino: [email protected]

Miguel Argollo: [email protected]

Paulo M. S. Bueno: [email protected]

Celso P. Barros: [email protected]

Dezembro/2010



Modelo de Processo Genérico de Teste de Software

Apresentação

Este documento apresenta um modelo de processo genérico de teste de software;

apresenta o contexto do teste de software; define os subprocessos fundamentais de um

processo de teste de software e apresenta alguns exemplos de processos de teste de

software.

Este documento é parte integrante da Estrutura Tecnológica de Teste de Software do

Software Público Brasileiro – SPB. Destina-se às comunidades do SPB interessadas na

atividade de teste com o objetivo de aprimorar a qualidade dos produtos de software

disponíveis no Portal do SPB.



Sumário

1 Introdução ........................................................................................................................ 4

2 O Que é Teste de Software .............................................................................................. 4

3 O Que é um Processo ....................................................................................................... 4

4 O Que é um Processo de Teste de Software .................................................................... 5

5 Um Modelo de Processo Genérico de Teste de Software ............................................... 6

5.1 Subprocessos do Processo de Teste de Software .................................................... 7

5.1.1 Planejamento dos Testes ................................................................................. 7

5.1.2 Projeto dos Testes ............................................................................................ 8

5.1.3 Execução e Registro dos Testes ....................................................................... 9

5.1.4 Acompanhamento dos Testes ........................................................................ 10

5.1.5 Finalização dos Testes .................................................................................... 10

6 Caracterização do Processo de Teste ............................................................................. 11

7 Exemplos de Processo de Teste de Software ................................................................. 12

7.1 Teste ao Longo do Processo de Desenvolvimento de Software ............................ 12

7.1.1 Primeiro Exemplo: Processo de Teste Alinhado com o Modelo Cascata ....... 13

7.1.2 Segundo Exemplo: Processo de Teste Alinhado com o Processo Iterativo de

Desenvolvimento ........................................................................................... 20

7.2 Teste de um Software Previamente Desenvolvido ................................................ 23

7.3 Teste de uma Nova Versão de um Software .......................................................... 26



1 Introdução

Sistemas computacionais têm hoje um papel fundamental, afetando de forma significativa os

vários segmentos da sociedade, tais como os setores de energia, transporte, financeiro,

comércio, telefonia, educação, só para citar alguns. O funcionamento inadequado desses

sistemas tem potencial de gerar grandes prejuízos operacionais, financeiros, ou de colocar

em risco vidas humanas; portanto, é natural que as exigências de qualidade e confiabilidade

desses sistemas sejam cada vez maiores. Para que se atinjam altos níveis de qualidade de

produtos que envolvem software, é fundamental o aprimoramento dos processos de

engenharia e de gestão no desenvolvimento de software. Além de uma maior qualidade dos

produtos de software, almeja-se que os projetos sejam bem sucedidos, com menores custos

e respeitando os limites de prazo.

O teste é uma atividade fundamental para avaliar se o software produzido atende aos

requisitos levantados com os usuários, identificar deficiências que possam existir em

produtos de software e, ainda, obter evidências da confiabilidade do software (ou da falta

dela). Portanto, para a obtenção de produtos de software de boa qualidade é de suma

importância a adoção, por parte das organizações desenvolvedoras, de boas práticas de

teste de software. O teste é uma das atividades de verificação e validação e não exclui a

utilização de outras atividades, como a realização de inspeções nos artefatos produzidos ao

longo do desenvolvimento de software.

O teste é a avaliação final da qualidade do produto desenvolvido. O teste de software,

realizado ao longo, no final ou após o desenvolvimento do software, é uma atividade que

requer um processo bem definido que oriente a sua realização.

2 O Que é Teste de Software

Teste de software é o processo de executar o software de uma maneira controlada com o

objetivo de avaliar se ele se comporta conforme especificado.

Tipicamente, o teste de um produto de software tem por objetivo avaliar se ele atende aos

requisitos do usuário; identificar defeitos que possam existir nos produtos de software; e

obter evidências sobre a confiabilidade do software.

3 O Que é um Processo

Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades,

métodos, práticas e transformações, usado para atingir uma meta. Esta meta geralmente

está associada a um ou mais resultados concretos finais, que são os produtos da execução

do processo. Um processo define: o que é feito (produto), quando é feito (passos), por quem



é feito (agentes), as coisas que se utilizam (insumos) e as coisas que se produzem

(resultados).

4 O Que é um Processo de Teste de Software

Um processo de teste de software é um conjunto de passos parcialmente ordenados

constituídos por atividades, métodos e práticas, usados para testar um produto de software.

Numa visão contextual, um processo de teste tem as seguintes partes:

• Entradas: são todas as informações necessárias para a execução do teste do

software, tais como informações do software, especificação de requisitos, etc.;

• Mecanismos e Agentes: são as equipes de teste, as técnicas de teste, os

procedimentos de teste, as ferramentas, etc.;

• Restrições e Condições: cronogramas, custos, confiabilidade requerida, etc.

• Saídas: são os resultados, produtos da execução das atividades, tais como:

software testado, defeitos revelados, nível de confiabilidade atingido, qualidade

desejada, etc.

A Figura 1 ilustra a visão contextual de um processo de teste de software.

Figura 1: Visão Contextual de um Processo de Teste de Software



5 Um Modelo de Processo Genérico de Teste de Software

Um modelo de processo genérico de teste de software é um modelo de processo

abrangente que envolve todas as situações de teste de um software e contém todas as

atividades previstas no teste de um software. Um processo genérico de teste pode ser

instanciado e implantado numa organização desenvolvedora de software de acordo com as

suas necessidades, seus recursos, padrões utilizados, e tipo de software desenvolvido. A

implantação do processo de teste envolve a definição das atividades a serem efetuadas e a

definição dos artefatos a serem criados na realização do teste de um software.

Qualquer que seja o processo de teste existem atividades correlacionadas que podem ser

agregadas em um subconjunto denominado subprocesso. O processo genérico de teste de

software proposto possui os seguintes subprocessos:

• Planejamento do Teste;

• Projeto do Teste;

• Execução e Registro do Teste;

• Acompanhamento do Teste;

• Finalização do Teste.

A Figura 2 mostra um processo genérico de teste com seus respectivos subprocessos.

Figura 2: Um Processo Genérico de Teste de Software e seus Subprocessos.

Escopo Extensão Equipe Abordagem Métricas e Medidas Recursos Ambiente Atividades Cronograma Riscos

Planejamento

Abordagem Ambiente Técnicas Critérios Tipos Métricas e Medidas Procedimentos Base de dados Scripts Casos de teste

Projeto

Execução: Procedimentos Casos de teste

Registro: Incidentes Diário Resumo Medidas

Execução e Registro

Aceitação do produto

Avaliação final: Produto Medidas Equipe Cronograma Oportunidades de melhoria

Registro: Resultados

Finalização

Acompanhamento

Avaliação de incidentes Acompanhamento dos riscos Avaliação do cronograma Avaliação de métricas Tomada de ações corretivas Avaliação de recursos Avaliação de cobertura Revisão e ajuste do planejamento



5.1 Subprocessos do Processo de Teste de Software

Um processo de teste de software pode ser entendido como uma hierarquia de

subprocessos, organizados de tal maneira que cada subprocesso tenha seu próprio modelo

de processo. Cada subprocesso é composto por atividades; tem critérios de início e término

para essas atividades; e as atividades de um subprocesso são organizadas em uma

seqüência lógica. Além disso, cada atividade de um subprocesso gera um conjunto de

informações que podem ser consolidadas num documento e devem ser utilizadas como

subsídios para o acompanhamento do processo de teste. A Figura 3 ilustra a hierarquia dos

subprocessos de um processo de teste de software.

P R O C E S S O D E T E S T E

Execução

Registro

Subprocesso

Atividades

Finalização

Subprocesso

Atividades

Projeto

Subprocesso

Atividades

Planejamento

SubprocessoAtividades

Informações Informações InformaçõesInformações

A C O M P A N H A M E N T O

Figura 3: Hierarquia dos Subprocessos do Processo de Teste de Software.

5.1.1 Planejamento dos Testes

A primeira atividade de planejamento de teste é a iniciação, que consiste em coletar todas

as informações disponíveis para o planejamento do teste.

O produto deste subprocesso é um conjunto de informações denominado Plano de Teste de

Software que descreve o planejamento de todas as atividades envolvidas no teste de um

software. Além das atividades, o Plano de Teste deve conter a abrangência do teste, a

abordagem utilizada no teste, os recursos necessários, o cronograma das atividades de

teste e a definição do ambiente operacional para a execução dos testes.

Um plano de teste é uma forma de agrupar idéias e experiências que possam ser aplicadas

no projeto atual; ele serve como um mecanismo de comunicação com os demais envolvidos

e permite a identificação, comunicação e discussão de problemas e pontos em aberto.



As atividades de planejamento de teste procuram responder às seguintes perguntas:

• O que deve ser testado no software?

• O que pode ficar fora do teste?

• Que abordagem de teste vai ser seguida neste projeto?

• Quais riscos devem ser abordados pelos testes?

• Que equipe vai participar do teste do software?

• Quanto tempo está disponível para o teste do software?

• Como as tarefas de teste do software serão distribuídas neste tempo?

Tipicamente, o Plano de Teste identifica os itens de software a serem testados, o nível em

que os itens devem ser testados, a abordagem utilizada para testar cada um dos itens, as

tarefas envolvidas em cada atividade de teste, as pessoas responsáveis pelas atividades,

os riscos associados ao teste, um cronograma das atividades e as métricas para se medir o

processo de teste .

O Plano de Teste de Software pode conter informações relacionadas a um projeto amplo de

teste do software ou pode conter informações relacionadas a um dos níveis de teste, tais

como: Teste de Unidade, Teste de Integração, Teste de Sistema e Teste de Aceitação.

Um Plano de Teste de Software pode ser um conjunto de informações tão simples e

resumido que caiba em poucas linhas ou seguir um padrão altamente estruturado. O nível

de detalhamento dependerá do formalismo adotado pela organização.

O Guia para Planejar o Teste de Software traz informações sobre as atividades que

devem ser realizadas na fase de planejamento dos testes.

5.1.2 Projeto dos Testes

O produto deste subprocesso é um conjunto de informações denominado Projeto de Teste

de Software, que descreve todas as informações necessárias ao teste de um software.

Os objetivos deste subprocesso são:

• Refinar a abordagem de teste de software definida no planejamento;

• Definir e especificar os casos de teste;

• Revisar os requisitos de ambiente de teste;

• Definir e especificar os procedimentos de teste.

Da mesma forma que um bom projeto de software dará origem a um sistema de software

bem estruturado, que atenda a todas as necessidades de seus usuários e que seja mais

facilmente modificado, um bom projeto de teste dará origem a casos de testes que cubram

adequadamente as funcionalidades do software em teste e que tenham a capacidade de



detectar mais rapidamente a presença de defeitos nas áreas do software que apresentem

maiores riscos.

A atividade de projeto de teste procura responder às seguintes perguntas:

• Quais são as técnicas de teste mais adequadas a serem utilizadas neste projeto?

• Como os casos de teste serão agrupados de forma coerente?

• Como as diversas funcionalidades do software em teste serão cobertas pelo teste?

• Quais passos serão necessários para executar os testes?

O Projeto de Teste de Software contém basicamente o detalhamento da abordagem do

teste definida na fase de planejamento, bem como a definição dos casos de teste e os

procedimentos para a aplicação dos casos de teste. Para cada caso de teste, o projeto de

teste deverá conter o detalhamento dos dados de entrada e os respectivos resultados

esperados. Além disso, o projeto contém os requisitos de ambiente de teste, os requisitos

de procedimentos especiais, as dependências entre casos de teste, e a definição das

métricas de teste.

Um projeto de teste pode ser um conjunto simples de informações, armazenado em

planilhas que contenham os casos de teste e os respectivos passos que devem ser

seguidos nos testes, ou pode ser composto por um conjunto maior de informações.

O Guia para Projetar o Teste de Software traz informações sobre as atividades que

devem ser realizadas nesta fase.

5.1.3 Execução e Registro dos Testes

A execução e registro dos testes é a fase responsável pela aplicação dos testes planejados

e projetados anteriormente; o tempo investido nas atividades anteriores à execução será

compensado nesta atividade. A execução envolve a aplicação de cada caso de teste, de

acordo com o procedimento de teste anteriormente definido no projeto de teste.

Normalmente os testes são realizados em ciclos, de forma que em cada ciclo todos os

casos de testes projetados, ou um conjunto predefinido deles, sejam aplicados. Os testes

devem ser realizados em ambiente distinto do ambiente de desenvolvimento e, durante a

realização de cada ciclo de teste, o ambiente operacional deve permanecer estável.

O registro envolve a identificação e o detalhamento dos incidentes observados durante os

testes. Um incidente de teste é a manifestação de qualquer defeito no software ou uma

anomalia no funcionamento do ambiente operacional.

Incidentes encontrados durante a realização dos testes devem ser relatados em relatórios

ou preferencialmente por meio de ferramentas como Bugzilla, Mantis, etc.

Nesta fase devem ser registrados:



• Detalhes e medidas relevantes relacionados com a execução dos testes;

• Qualquer evento que ocorra durante a execução do teste e que requeira análise;

• Resumo dos resultados das atividades de teste associadas ao Projeto de Teste;

• As avaliações baseadas nos resultados do teste.

O Guia para Executar e Registrar o Teste de Software traz informações sobre as

atividades que devem ser realizadas nesta fase.

5.1.4 Acompanhamento dos Testes

A execução dos testes gera uma quantidade considerável de informações relativas aos

testes realizados. A fase de acompanhamento é responsável por organizar e consolidar

estas informações de forma que seja possível verificar rapidamente a situação do teste e

também a situação do software em teste.

O acompanhamento de teste procura responder às seguintes perguntas:

• Quantos casos de teste já foram executados?

• Quantos incidentes foram detectados e identificados?

• Quantos incidentes continuam em aberto?

• Quantos incidentes continuam em aberto nas áreas de risco identificadas?

• Quais funcionalidades já foram adequadamente cobertas pelos casos de teste

aplicados?

• Que porcentagem do software já foi testada?

• Novos casos de testes são necessários?

O acompanhamento é composto por atividades que são realizadas periodicamente, visando

monitorar e avaliar o andamento do teste. Neste contexto, são avaliados: os incidentes

ocorridos; as medidas coletadas, de acordo com as métricas definidas; as medidas de

cobertura do teste; os fatores de risco associados ao processo de teste e ao produto em

teste; o cronograma das atividades; os recursos utilizados e os custos incorridos. Sempre

que forem identificados desvios significativos em relação ao que foi planejado, ou qualquer

situação não prevista inicialmente, ações corretivas apropriadas devem ser realizadas.

O Guia para Acompanhar o Teste do Software traz informações sobre atividades que

podem ser realizadas nesta fase.

5.1.5 Finalização dos Testes

A finalização dos testes é o subprocesso que trata das atividades de encerramento do teste.

Nesta fase é feita a aceitação formal do produto pelo cliente, caso esta atividade esteja

prevista no Plano de Teste. Além disso, no encerramento do teste consolidam-se todas as



informações sobre: o andamento do teste; os resultados obtidos no teste do produto; o

desempenho da equipe de teste; o processo de teste adotado; as métricas definidas no

processo de teste; os recursos gastos no teste; o tempo gasto na execução das atividades

em relação ao planejado; e as lições aprendidas no teste daquele produto.

Todas essas informações devem ser consolidadas num conjunto denominado Resumo do

Teste e disponibilizadas para gerência. Essas informações podem servir como referências

para futuras tomadas de decisões e/ou melhorias do processo de teste.

O Guia para Finalizar o Teste do Software traz informações sobre atividades que podem

ser realizadas nesta fase.

6 Caracterização do Processo de Teste

Em qualquer desenvolvimento de software a aplicação do teste deve ser realizada segundo

um processo de teste previamente definido. Caracterizar um processo de teste significa

definir os níveis de teste, os tipos de teste, as técnicas e critérios que direcionam a criação

dos casos de teste, e os elementos do teste alinhados ao processo de desenvolvimento do

software. A caracterização do processo de teste é completada pelo detalhamento das

atividades de planejamento do teste, projeto do teste, execução e registro dos resultados do

teste, finalização do teste; e acompanhamento do teste, levando em consideração os

elementos anteriormente especificados.

A caracterização do processo de teste depende da política de teste adotada pela empresa e

deve ser feita de forma cuidadosa obedecendo às reais necessidades de teste e dos

recursos e características da organização. Os seguintes fatores devem ser considerados na

definição de um processo de teste: tipo de software que desenvolve; requisitos do software

em relação à confiabilidade, segurança e desempenho; e disponibilidade de recursos

humanos e financeiros.

Uma empresa pode definir um processo de teste único, a ser aplicado em qualquer produto

de software por ela desenvolvido, ou seja, o seu modelo de processo de teste de software é

fixo. Outra empresa pode definir seu processo de teste de acordo com os vários tipos de

produtos de software por ela desenvolvidos, ou seja, o modelo de processo de teste de

software da empresa é configurável.

O processo de teste a ser aplicado em um produto de software específico deve ser definido

de acordo com o modelo de processo de desenvolvimento de software adotado pela

organização. Além disso, o processo de teste pode ser complexo ou simples dependendo

das características da organização, dos recursos disponíveis, e do tipo, tamanho e

complexidade da aplicação. Cada modelo de processo de desenvolvimento de software

define seus produtos correspondentes. Os produtos gerados durante o desenvolvimento do



software serão utilizados para planejar e projetar os testes. Exemplos: a análise de

requisitos produz os requisitos do software que serão utilizados para projetar os casos de

teste de aceitação; o projeto da arquitetura do software produz a arquitetura do programa

que será utilizada para projetar os casos de teste de integração. Em uma perspectiva

ampla, a Figura 4 ilustra os fatores envolvidos na definição de um processo de teste de

software. Os objetivos de negócio da organização fornecem a base para moldar o processo

de teste. Este processo, por sua vez, deve produzir as informações úteis para que os

objetivos do negócio da organização sejam alcançados.

NEGÓCIO

INFORMAÇÃO PROCESSO

DirecionaApoia

Gera

Figura 4: Fatores que Envolvem a Definição de um Processo de Teste de Software.

7 Exemplos de Processo de Teste de Software

7.1 Teste ao Longo do Processo de Desenvolvimento de Software

Deve ser observado que o teste de um software pode ser planejado a partir do momento em

que se consolida a especificação dos requisitos do software. Neste contexto, as atividades

do processo de teste devem estar em conformidade com as outras atividades do processo

de desenvolvimento do software. Ou seja, o processo de teste é dependente do processo

de desenvolvimento do software. Desta forma, as informações geradas pelas outras

atividades do desenvolvimento do software deverão ser utilizadas como entradas para as

atividades do teste do software.

Centro de Tecnologia da Informação Renato Archer

SPB - Modelo de Processo Genérico de Teste de Software

No entanto, cada processo de desenvolvimento de software tem suas caracter

próprias, gera informações específicas e tem

determinada seqüência. A Figura 5

processo de desenvolvimento do software.

devem estar em conformidade com

Nos dois primeiros exemplos de processo de teste

teste estarão alinhadas com o

Figura 5: Processo de Teste Acoplado ao Processo de Desenvolvimento

7.1.1 Primeiro Exemplo

Neste exemplo é apresentado um processo de teste instanciado para um produto sendo

desenvolvido segundo o ciclo de vida

pela sua manutenção e evolução. O teste é realizado por uma equipe especializada e

experiente em teste, distinta da equipe de desenvolvimento. Como o mercado em que o

produto será oferecido é muito exigente, a liberação de u

qualidade necessário foi considerado mais importante do que a economia dos recursos

alocados aos testes.

Por estas características, optou

documentado, de forma que o esforço despendido

teste da versão inicial do

posteriores. O processo apresentado será formal e pesado; outros exemplos explorarão

processos mais informais e leves.

A Figura 6 apresenta o processo de teste e suas atividades, alinhado com o modelo cascata

de desenvolvimento.

Como pode ser observado na

primeira etapa compreende a iniciação,


Modelo de Processo Genérico de Teste de Software

ada processo de desenvolvimento de software tem suas caracter

informações específicas e tem suas atividades executadas

A Figura 5 traz uma ilustração do processo de teste

processo de desenvolvimento do software. Desta forma, exemplos de processos de teste

devem estar em conformidade com o processo de desenvolvimento de software.

primeiros exemplos de processo de teste a serem apresentados, as atividades do

com o processo de desenvolvimento de software.

Processo de Teste Acoplado ao Processo de Desenvolvimento

Exemplo: Processo de Teste Alinhado com o Modelo Cascata


o ciclo de vida modelo cascata pela mesma empresa responsável



produto será oferecido é muito exigente, a liberação de um produto com o nível de


Por estas características, optou-se por um processo de teste sistemático e bem

documentado, de forma que o esforço despendido nas fases de planejamento e projeto do

teste da versão inicial do produto possa ser compensado no teste de suas versões


processos mais informais e leves.

processo de teste e suas atividades, alinhado com o modelo cascata

Como pode ser observado na Figura 6, o fluxo pode ser descomposto em 3 etapas. A

primeira etapa compreende a iniciação, o planejamento, o projeto dos testes de si

13

ada processo de desenvolvimento de software tem suas características

executadas numa

processo de teste acoplado ao

Desta forma, exemplos de processos de teste

olvimento de software.

a serem apresentados, as atividades do

Processo de Teste Acoplado ao Processo de Desenvolvimento do Software.

: Processo de Teste Alinhado com o Modelo


pela mesma empresa responsável



m produto com o nível de


se por um processo de teste sistemático e bem

nas fases de planejamento e projeto do

no teste de suas versões


processo de teste e suas atividades, alinhado com o modelo cascata

, o fluxo pode ser descomposto em 3 etapas. A

projeto dos testes de sistema e



aceitação e a realização dos testes de unidade e integração. A segunda etapa compreende

a realização dos testes de sistema, ao passo que a etapa final abrange a realização dos

testes de aceitação. Atividades de controle e replanejamento estão distribuídas ao longo do

processo no término dos testes de unidade e integração e no término de cada ciclo de

testes de sistema e aceitação, pois se acredita que nestes pontos encontra-se disponível a

quantidade de informação necessária a um eventual replanejamento dos testes.

Neste exemplo foi dada uma ênfase maior na descrição das atividades do que na definição

das condições de início, dados de entrada, condições de término, dados de saída e

métricas. Entretanto, na definição de um processo real, todas estas informações devem

estar determinadas, em um nível de detalhamento adequado.

Os diversos guias de teste elaborado pelo SPB apresentam formas concretas para a

organização e realização das atividades necessárias à execução de um processo de teste,

e devem ser consultados em paralelo à leitura deste exemplo de processo.

Note que este é simplesmente um exemplo de processo – outros processos que atendam

aos objetivos do projeto também podem ser definidos, sem que sejam necessariamente

melhores ou piores que o processo apresentado.



Figura 6: Processo de Teste e suas Atividades, Alinhado com o Modelo Cascata



(A) Iniciação

Esta atividade tem como objetivo coletar informações relativas ao sistema em teste, tais

como: agentes envolvidos (stakeholders), requisitos funcionais e não funcionais, planos e

processo de desenvolvimento, recursos de teste, etc. Todas as informações necessárias ao

planejamento dos testes devem ser levantadas nesta fase.

Embora a iniciação faça parte do subprocesso Planejamento, esta atividade foi destacada

no exemplo para maior clareza.

(B) Planejamento do Teste

O subprocesso Planejamento tem como objetivo definir, a partir das informações levantadas

na iniciação, a abordagem que será adotada no teste do produto, as atividades necessárias

à realização dos testes, o cronograma e os recursos correspondentes.

Pelas características do produto em teste optou-se pela realização de um planejamento

cuidadoso e abrangente, que procure identificar a maior parte das situações que podem

ocorrer ao longo do processo de teste.

Atividades propostas:

• Definir abordagem e estratégia de teste;

• Definir tarefas de teste;

• Definir cronograma de teste;

• Definir equipe de teste;

• Definir riscos associados ao produto;

• Definir critérios de aprovação do produto em teste;

• Definir em alto nível a forma pela qual os testes de unidade e integração serão

realizados e avaliados, e elaborar check-lists de auxílio à equipe de

desenvolvimento;

• Definir métricas usadas para acompanhar a realização dos testes;

• Definir ambiente de execução dos testes;

• Definir riscos associados ao projeto.

(C) Projeto dos Testes de Sistema e Aceitação

O subprocesso Projeto do Teste tem como objetivo a obtenção dos casos de teste e

procedimentos de teste utilizados na execução dos testes de sistema e de aceitação.

Como os testes projetados deverão ser aproveitados nas próximas versões do produto,

optou-se por uma documentação cuidadosa e detalhada dos casos e procedimentos de

teste. Optou-se também por manter uma associação entre casos de teste e requisitos para

facilitar o trabalho de teste de futuras versões do sistema, onde requisitos originalmente

levantados poderão sofrer modificações.




• Refinar abordagem de teste;

• Acompanhar requisitos levantados junto à equipe de desenvolvimento;

• Identificar cenários de teste a partir dos requisitos;

• Projetar e documentar casos de teste;

• Validar casos de teste com os agentes envolvidos (stakeholders) com o sistema

(incluindo equipe de desenvolvimento);

• Associar casos de teste aos requisitos do sistema;

• Definir e documentar procedimentos de teste;

• Desenvolver a base de dados de teste e eventuais programas para carga de dados;

• Preparar o ambiente de teste (hardware, software e scripts de teste).

(D) Execução dos Testes de Unidade e Integração

Atividade realizada pela equipe de desenvolvimento, seguindo os critérios explicitados no

Plano de Teste.


• Executar teste de unidade;

• Executar teste de integração;

• Registrar evidências da execução dos testes.

(E) Avaliação da Realização dos Testes de Unidade e de Integração

Esta é uma atividade simples, realizada pela equipe de teste, que tem como objetivo

verificar se os testes de unidade e de integração foram realizados conforme definido na fase

de planejamento.

(F) Controle e Replanejamento

Esta atividade tem como objetivo verificar o andamento do projeto, identificando desvios em

relação ao planejado e antecipando potenciais problemas que podem ocorrer.

(G) Preparação para Ciclo de Teste de Sistema

Atividade realizada pela equipe de desenvolvimento.

(H) Avaliação do Produto para o Início de um Ciclo de Teste

Esta é uma atividade que deve ser simples e rápida, e tem como objetivo verificar se a

versão entregue para teste pode ser executada, ou seja, se todos os arquivos que devem

estar presentes na distribuição realmente estão presentes com as versões corretas. Na

literatura esta atividade é conhecida pelo nome smoke test, termo provavelmente herdado

das equipes de hardware, consistindo simplesmente em ligar o equipamento sendo testado:

se não houver fumaça, o teste inicial é considerado um sucesso!




• Instalar software no ambiente de teste;

• Realizar testes iniciais para validar a estabilidade mínima da versão distribuída para

teste (smoke test).

(I) Execução de Ciclo de Teste de Sistema

Pelas características do projeto, todas as informações e artefatos necessários à realização

dos testes devem estar disponíveis neste ponto: ambiente de teste preparado, casos de

teste documentados com valores de entrada e resultados esperados, bases de dados e

scripts necessários para os testes definidas, etc.


• Executar testes projetados, com documentação dos resultados obtidos;

• Registrar incidentes identificados.

(J) Aplicação do Critério de Aprovação do Produto

Ao término da execução de cada ciclo de teste de sistema a equipe de teste deve verificar

se o critério de aprovação do produto, definido na fase de planejamento dos testes, já foi

atingido. Esta verificação é realizada, por exemplo, pela análise da gravidade dos incidentes

reportados.

Atividade proposta:

• Verificar se o produto atingiu o critério de aprovação definido no planejamento dos

testes.

(K) Realização das Mudanças Necessárias

Realização, pela equipe de desenvolvimento, das alterações necessárias à correção dos

incidentes relatados

(L) Controle e Replanejamento

Esta atividade, que ocorre sempre que um ciclo de teste de sistema for encerrado, tem

como objetivo acompanhar o andamento do projeto, identificando desvios em relação ao

planejado e antecipando potenciais problemas que possam ocorrer.

Atividades do Controle e Replanejamento:

• Avaliar incidentes identificados e ainda não resolvidos;

• Avaliar medidas coletadas;

• Avaliar cobertura dos testes (% dos requisitos validados pelos testes);

• Avaliar andamento do cronograma dos testes;

• Redefinir e renegociar cronograma e recursos alocados aos testes, se necessário;



• Projetar novos casos de teste, se necessário;

• Acompanhar riscos do projeto.

(M) Preparação para Ciclo de Teste de Aceitação


(N) Avaliação do Produto para o Início de um Ciclo de Teste de Aceitação

Esta é uma atividade que deve ser simples e rápida, e tem como objetivo verificar se a

versão entregue para teste pode ser executada, ou seja, se todos os arquivos que devem

estar presentes na distribuição realmente estão presentes com as versões corretas.

Atividades propostas

• Instalar software no ambiente de teste;

• Realizar testes iniciais para validar a estabilidade mínima da versão distribuída para

teste (smoke test);

• Negociar com os envolvidos (stakeholders) datas previstas para a realização dos

testes de aceitação.

(O) Execução de Ciclo de Teste de Aceitação

• Executar testes de aceitação projetados, com documentação dos resultados

obtidos;

• Registrar incidentes identificados.

(P) Realização das Mudanças Necessárias


incidentes relatados.

(Q) Aplicação do Critério de Aceitação do Produto

Tarefa proposta:

• Verificar se o produto atingiu o critério de aceitação definido no planejamento dos

testes.

(R) Controle e Replanejamento

Caso o sistema não seja aprovado ao término do 1o ciclo dos testes de aceitação,

realização das seguintes tarefas:

• Avaliação dos incidentes identificados e ainda não resolvidos;

• Avaliação das medidas coletadas;

• Avaliação da cobertura dos testes (% dos requisitos validados pelos testes);

• Avaliação do andamento do cronograma dos testes;



• Redefinição e renegociação do cronograma e recursos necessários aos testes, se

necessário;

• Projeto de novos casos de teste, se necessário;

• Acompanhamento dos riscos do projeto.

(S) Finalização

Este subprocesso tem como objetivo encerrar formalmente o teste realizado.



• Avaliar desempenho da equipe;

• Avaliar recursos estimados e utilizados;

• Identificar oportunidades de melhoria;

• Comunicar formalmente o término do teste.

7.1.2 Segundo Exemplo: Processo de Teste Alinhado com o Processo Iterativo de Desenvolvimento


desenvolvido por um processo iterativo por uma empresa que não é responsável por sua

manutenção e evolução. O produto desenvolvido é novo e complexo, e nem a empresa

desenvolvedora nem a empresa que contratou o desenvolvimento estão em condições de

definir completamente seus requisitos antes do início do desenvolvimento, razão pela qual o

processo incremental foi o escolhido. Desta forma, os requisitos devem ser refinados ao

longo do desenvolvimento, na medida em que uma melhor compreensão das necessidades

for obtida. A equipe de desenvolvimento adota um processo leve, voltado mais para a

produção de versões executáveis necessárias para a validação dos requisitos e

necessidades dos usuários do sistema, com pouca documentação. A equipe de

desenvolvimento tem experiência e emprega a automação dos testes de unidade ao longo

do desenvolvimento.

A qualidade do produto é considerada crítica, pois ele será distribuído por vários escritórios

espalhados pelo país ao ficar pronto.

O teste é realizado por uma equipe de teste especializada e experiente em teste, distinta da

equipe de desenvolvimento. As duas equipes já trabalharam juntas em outro projeto

iterativo, e seus membros estão acostumados a cooperar e trocar informações. Como o

prazo para a conclusão e entrega do produto é considerado suficiente, mas com pouca

folga, optou-se por um processo de teste simples, que produz pouca documentação.

Particularmente, nos sub-processos de planejamento e projeto devem ser realizadas

somente as atividades consideradas essenciais, de forma a sobrar o máximo de tempo



possível para as tarefas de execução dos testes e remoção dos eventuais defeitos. A Figura

7 apresenta o processo de teste e suas atividades.

Figura 7: Processo de Teste e suas Atividades, Alinhado com o Processo iterativo

(A) Iniciação

Esta atividade tem como objetivo juntar as informações relativas ao sistema testado, tais

como os envolvidos (stakeholders), a versão inicial da arquitetura do aplicativo, os principais

requisitos funcionais e não funcionais já definidos bem como o plano de incrementos

proposto (quais funcionalidades estão previstas por iteração). Como as equipes de

desenvolvimento e teste já trabalharam juntas, seus processos de trabalho são conhecidos.


O principal objetivo do subprocesso de planejamento é definir a abordagem adotada no

teste do produto, baseada principalmente na distribuição das funcionalidades entre os

diversos incrementos propostos.




• Definir riscos associados ao produto e ao projeto de teste;

• Definir prazos de teste de acordo com a distribuição das funcionalidades entre os

diversos incrementos propostos;

• Definir a abordagem do teste;

• Definir ambiente de execução dos testes;

• Detalhar as tarefas e cronograma dos testes do 1º incremento.

(C) Projeto do Teste

O subprocesso projeto do teste tem como objetivo a elaboração dos casos de teste

necessários em cada iteração.

Este subprocesso é repetido antes do início de cada iteração do desenvolvimento, e tem

como principal objetivo identificar os principais cenários de teste para as funcionalidades da

iteração e definir os casos de teste para as funcionalidades que apresentem maior risco.

Como a equipe de teste acompanha o trabalho de detalhamento de requisitos, os

procedimentos de teste não são documentados, bastando somente a documentação dos

casos de uso. A partir da 2ª iteração este subprocesso deve verificar quais testes

realizados nas iterações anteriores precisam ser repetidos como teste de regressão.


• Acompanhar requisitos levantados junto à equipe de desenvolvimento;

• Identificar cenários de teste a partir dos requisitos;

• Projetar e documentar os casos de teste;

• Validar os casos de teste com os envolvidos com o sistema (stakeholders).

(D) Execução dos Testes de cada Iteração

Este subprocesso se inicia com a re-execução dos testes selecionados da iteração anterior.

Caso não haja ocorrência de falhas, executam-se os testes previstos para a iteração atual,

sendo priorizadas as funcionalidades que apresentam maiores riscos. A equipe de teste

pode propor novos cenários de teste, caso perceba que determinadas áreas do aplicativo

apresentem um maior número de problemas do que o esperado. Problemas encontrados

são inicialmente discutidos com a equipe de desenvolvimento e, se necessário, com

representantes dos usuários, e posteriormente documentados no sistema de

acompanhamento de incidentes.

A proximidade entre as equipes de desenvolvimento e de teste permite que os componentes

da iteração possam ser testados tão logo estejam implementados, o que permite um

considerável ganho de tempo, fator importante no projeto.



Esta fase é considerada terminada quando todos os cenários de teste previstos são

executados sem a ocorrência de incidentes graves.

(E) Replanejamento para Próxima Iteração

Esta é uma atividade rápida, composta principalmente pela revisão do planejamento

anteriormente realizado.

(F) Finalização

Este subprocesso tem como objetivo encerrar formalmente o teste. Atividades propostas:

• Analisar medidas finais do projeto;

• Comunicar formalmente o término do teste.

7.2 Teste de um Software Previamente Desenvolvido

Neste exemplo é apresentado um processo de teste que visa a realização do teste final de

um produto de software já desenvolvido. Neste caso, as atividades de análise de requisitos,

projeto e implementação do software já foram concluídas. Não são estabelecidas premissas

sobre as atividades de teste já realizadas. Isto é, o teste pode ter sido feito de forma

informal, sem aplicação de técnicas e sem registros que o evidenciem; o teste pode ter sido

feito de forma mais cuidadosa e sistemática; ou mesmo nenhuma atividade de teste pode

ter sido realizada.

Qualquer que seja a situação, o processo de teste visa a:

• Avaliar de forma sistemática o software identificando os defeitos existentes;

• Criar registros que evidenciem um teste sistemático e seu nível de rigor.

Diferentemente dos anteriores, em que um processo de teste completo deve ser executado

ao longo do desenvolvimento do software, tem-se o objetivo específico de criar um bom

conjunto de casos de teste de sistema; executá-los; e criar registros destas atividades.

Portanto, os testes de unidade e de integração não são tratados. É importante destacar que,

quando não se realizam testes de unidade e de integração, pode existir um número maior

de defeitos no software. Além disto, a identificação do defeito e a correção do software

tendem a ser mais trabalhosas neste caso do que quando todos os níveis de teste são

aplicados.

A equipe que realiza o teste não é necessariamente formada por integrantes da equipe que

desenvolveu o software e que, eventualmente realizou testes iniciais. No entanto, membros

da equipe de desenvolvimento podem ser uma importante fonte de informações para o

teste.

Dado o objetivo deste processo de teste, são enfatizados os subprocessos de: projeto,

execução e registro do teste. As atividades destes subprocessos são definidas a fim de



permitir um bom nível de agilidade do teste, mas ao mesmo tempo, visando propiciar o

controle necessário das atividades de teste e a utilização de técnicas e tipos adequados de

teste, conforme o nível de confiabilidade requerida do produto. Além disso, esses

subprocessos podem ser executados de forma colaborativa, de maneira que partes do

software sejam alocadas a responsáveis distintos.

Algum esforço de planejamento é necessário, mas provavelmente é menor do que o

realizado nos exemplos anteriores, nos quais os diferentes níveis e ciclos de teste

demandam um maior rigor no tratamento de aspectos gerenciais.

A Figura 8 apresenta uma visão geral do processo de teste.

P R O C E S S O D E T E S T E

(A) Planejamento do Teste

(B) Projeto do Teste

(C) Execução e Registro dos Testes

(D) Acompanhamento do Teste

(E) Finalização do Teste

Critério de Aceitação Atingido?

Sim

Não

Figura 8: Processo de Teste para um Software já Desenvolvido



(A) Planejamento do Teste

O planejamento do teste deve ser executado logo que se identifique a necessidade de

realizar atividades de teste, seja com o objetivo principal de identificar defeitos e aprimorar o

produto de software ou com o objetivo de criar evidências do teste. O objetivo geral do

planejamento é definir os principais aspectos do teste: abordagem, técnicas, tipos, riscos,

equipe e ambiente de teste.


• Coletar informações úteis ao teste;

• Definir riscos associados ao produto;

• Definir abordagem e estratégia de teste;

• Definir equipe de teste;

• Definir tarefas de teste;

• Definir cronograma de teste;

• Definir critério de aprovação do produto;

• Definir as métricas usadas;

• Definir ambiente de execução dos testes.

(B) Projeto do Teste

O projeto do teste de sistema inicia-se tipicamente após a realização do planejamento.

Neste subprocesso a equipe alocada para o teste elabora, com base em informações

coletadas do software, os casos de teste a serem executados e os procedimentos

necessários para a execução. O objetivo do teste de sistema é avaliar se o software satisfaz

os requisitos funcionais e não funcionais estabelecidos. É importante, portanto, utilizar

técnicas adequadas para projetar casos de teste que permitam esta avaliação. Como há

interesse em coletar evidências do teste, os casos de teste (dados de entrada e resultado

esperado) serão documentados.


• Refinar abordagem de teste;

• Projetar e documentar casos de teste;

• Definir e documentar procedimentos de teste;

• Desenvolver a base de dados de teste e programas de carga de dados;

• Preparar o ambiente de teste.

(C) Execução e Registro do Teste

Este subprocesso envolve as atividades necessárias para a execução dos casos de teste

projetados, seguindo os procedimentos de teste estabelecidos. Durante a execução dos

testes é feito o registro de informações relevantes para: apoiar o gerenciamento do

processo; evidenciar a realização do teste; e controlar os incidentes observados.




• Executar testes projetados e documentar os resultados obtidos;

• Registrar o progresso do teste;

• Documentar os incidentes identificados.

(D) Acompanhamento do Teste

As atividades deste subprocesso são executadas periodicamente conforme definido no

planejamento. Normalmente, após a execução de um conjunto de casos de teste, deve-se

avaliar se o critério de aprovação do produto (definido na fase de planejamento) foi atingido.

Pode-se decidir então pela necessidade de projetar e executar casos de teste adicionais.

Neste subprocesso encontram-se também atividades para avaliação do andamento do teste

e para a revisão do planejamento, caso necessário.


• Aplicar o critério de aprovação do produto;

• Avaliar incidentes identificados;


• Avaliar cobertura dos testes;

• Avaliar o cronograma de teste;

• Acompanhar riscos;

• Tomar ações corretivas.

(E) Finalização do Teste

Tem como objetivo encerrar as atividades de teste, realizar avaliações finais e publicar as

informações de teste.


• Avaliar produto final e registrar informações;

• Avaliar processo de teste e registrar informações;

• Relatar e publicar as informações do teste.

7.3 Teste de uma Nova Versão de um Software

No primeiro exemplo é apresentado um processo de teste instanciado para um produto

desenvolvido através do ciclo de vida cascata pela mesma empresa responsável pela sua

manutenção e evolução. A responsabilidade pelos testes é de uma equipe especializada e


produto é oferecido é muito exigente, um produto com boa qualidade é considerado mais

importante do que a economia dos recursos alocados aos testes.

A ênfase do primeiro exemplo é em sua aplicação no desenvolvimento inicial do produto.

Entretanto, o mesmo processo de teste, apresentado na Figura 6, é utilizado para a



realização dos testes de suas novas versões, que incorporam correções de erros

encontrados após as diversas liberações do produto, alterações provenientes por mudanças

nos requisitos e incorporação de novos requisitos.

(A) Iniciação

A atividade de iniciação do teste de uma nova versão do produto é significativamente mais

simples do que a do teste do produto original, uma vez que todas as informações

levantadas inicialmente são mantidas atualizadas. Desta forma, para o teste de uma nova

versão, esta atividade deve se concentrar no levantamento das alterações realizadas e nos

recursos alocados ao teste.


O planejamento pode ser realizado pela revisão do plano de teste original, com a

modificação dos pontos relacionados às alterações realizadas no produto. Um novo

cronograma deve ser elaborado. A análise de riscos pode necessitar ser refeita, devido

tanto à esperada estabilidade das funcionalidades não alteradas no produto como aos

riscos associados às novas funcionalidades e alterações na estrutura do software.

(C) Projeto dos Testes de Sistema e de Aceitação

Os testes anteriormente projetados são revistos para verificar quais casos de teste foram

impactados pelas alterações da nova versão e, dessa forma, precisam ser alterados. O

esforço de elaboração e manutenção da rastreabilidade entre os requisitos e os casos de

teste é compensado neste ponto.

Para as novas funcionalidades, a partir dos requisitos, novos cenários de teste são

identificados, novos casos e procedimentos de teste são projetados e documentados.

(D) Execução dos Testes de Unidade e de Integração

Atividade realizada pela equipe de desenvolvimento, seguindo os critérios explicitados no

Plano de Teste. As novas unidades desenvolvidas para esta versão bem com as unidades

alteradas devem ser testadas conforme previsto no Plano de Teste.

(E) Avaliação da Realização dos Testes de Unidade e Integração

Esta é uma atividade simples, realizada pela equipe de teste, que tem como objetivo

verificar se os testes de unidade e integração foram realizados conforme definido na fase de

planejamento.

(F) Controle e Replanejamento

Esta atividade verifica o andamento do projeto e identifica desvios em relação ao planejado,

antecipando potenciais problemas que possam ocorrer.



Espera-se que no teste de uma nova versão de um produto de software a necessidade de

replanejamento neste ponto seja menor do que no teste do produto original.

(G) Preparação para Ciclo de Teste de Sistema


(H) Avaliação do Produto para o Início de Ciclo de Teste

Esta é uma atividade simples e rápida, e tem como objetivo verificar se a versão entregue

para teste pode ser executada.

(I) Execução de Ciclo de Teste de Sistema

Pelas características do projeto, todas as informações e artefatos necessários à realização

dos testes devem estar disponíveis.

A estratégia de teste de uma nova versão do produto pode focar a estabilidade desta

versão: no ciclo inicial são realizados os testes de regressão juntamente com os novos

testes projetados; ciclos intermediários enfocam os testes das novas funcionalidades; e no

ciclo final são re-executados todos os testes.

Alternativamente, a estratégia também pode focar na rapidez dos testes, de modo que nos

ciclos iniciais são realizados somente os testes das novas funcionalidades, ficando os testes

de regressão reservados para os ciclos finais.

(J) Aplicação do Critério de Aprovação do Produto

Ao término da execução de cada ciclo de teste de sistema a equipe de teste deve verificar

se o critério de aprovação do produto, definido na fase de planejamento dos testes, foi

atingido. Esta verificação é realizada, por exemplo, pela análise da gravidade dos incidentes

relatados.

(K) Realização das Mudanças Necessárias


incidentes relatados.

(L) Controle e Replanejamento

Esta atividade, que ocorre sempre que um ciclo dos testes de sistema for encerrado, verifica

o andamento do projeto, identificando desvios em relação ao planejado e antecipando

potenciais problemas que podem ocorrer.

Ciclo de teste de aceitação

Espera-se que os testes de aceitação, descritos na terceira etapa na Figura 6, sejam

realizados de forma semelhante tanto no caso do desenvolvimento de um novo produto

quanto no caso da liberação de uma nova versão deste produto.

11-2 - Modelo de Processo Generico de Teste de Software

Documents

Transcript of 11-2 - Modelo de Processo Generico de Teste de Software