Upload
luciano-silva
View
164
Download
61
Embed Size (px)
Citation preview
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 2
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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 3
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 4
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 5
é 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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 6
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 7
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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 8
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 9
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:
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 10
• 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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 11
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 12
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,
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
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
Neste exemplo é apresentado um processo de teste instanciado para um produto sendo
o ciclo de vida modelo cascata pela mesma empresa responsável
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 um produto com o nível de
qualidade necessário foi considerado mais importante do que a economia dos recursos
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
posteriores. O processo apresentado será formal e pesado; outros exemplos explorarão
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
Neste exemplo é apresentado um processo de teste instanciado para um produto sendo
pela mesma empresa responsável
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
m produto com o nível de
qualidade necessário foi considerado mais importante do que a economia dos recursos
se por um processo de teste sistemático e bem
nas fases de planejamento e projeto do
no teste de suas versões
posteriores. O processo apresentado será formal e pesado; outros exemplos explorarão
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 14
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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 15
Figura 6: Processo de Teste e suas Atividades, Alinhado com o Modelo Cascata
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 16
(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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 17
Atividades propostas:
• 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.
Atividades propostas:
• 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!
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 18
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).
(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.
Atividades propostas:
• 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;
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 19
• Projetar novos casos de teste, se necessário;
• Acompanhar riscos do projeto.
(M) Preparação para Ciclo de Teste de Aceitação
Atividade realizada pela equipe de desenvolvimento.
(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
Realização, pela equipe de desenvolvimento, das alterações necessárias à correção dos
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;
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 20
• 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.
Atividades propostas:
• Avaliar medidas coletadas;
• 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
Neste exemplo é apresentado um processo de teste instanciado para um produto sendo
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 21
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.
(B) Planejamento do Teste
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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 22
Atividades propostas:
• 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.
Atividades propostas:
• 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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 23
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 24
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 25
(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.
Atividades propostas:
• 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.
Atividades propostas:
• 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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 26
Atividades propostas:
• 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.
Atividades propostas:
• Aplicar o critério de aprovação do produto;
• Avaliar incidentes identificados;
• Avaliar medidas coletadas;
• 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.
Atividades propostas:
• 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
experiente em teste, distinta da equipe de desenvolvimento. Como o mercado em que o
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
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 27
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.
(B) Planejamento do 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.
Centro de Tecnologia da Informação Renato Archer – CTI/MCT
SPB - Modelo de Processo Genérico de Teste de Software 28
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
Atividade realizada pela equipe de desenvolvimento.
(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
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 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.