Embed Size (px)
Citation preview
Curso de Engenharia da Computação
CMM E PROCESSO DE TESTE DE SOFTWARE
Cristiano Pereira Godoy
Itatiba – São Paulo – Brasil
Novembro de 2004
ii
Curso de Engenharia da Computação
CMM E PROCESSO DE TESTE DE SOFTWARE
Cristiano Pereira Godoy
Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do Curso de Engenharia da Computação da Universidade São Francisco, sob a orientação do Prof. Dr. Carlos Eduardo Camara , como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Dr. Carlos Eduardo Camara
Itatiba – São Paulo – Brasil
Novembro de 2004
iii
O presente exemplar da monografia CMM e Processo de Teste de Software contempla as correções sugeridas pela banca examinadora durante a apresentação do Trabalho de Conclusão de Curso. Itatiba/SP, 08 de Dezembro de 2004
Prof Dr Carlos Eduardo Camara - Orientador
iv
CMM e Processo de Teste de Software
Cristiano Pereira Godoy
Monografia defendida e aprovada em 27 de Novembro de 2004 pela Banca
Examinadora assim constituída:
Prof Dr Carlos Eduardo Camara (Orientador)
USF - Universidade São Francisco - Itatiba - SP.
Prof Mestre Sidney Piu de Campos
USF - Universidade São Francisco - Itatiba - SP
Prof Raimundo Cláudio de Vasconcelos
USF - Universidade São Francisco - Itatiba - SP
v
Agradecimentos
Agradeço primeiramente ao Professor Carlos Eduardo Camara, meu orientador, que acreditou
em mim e incentivou-me para a conclusão deste trabalho, face aos inúmeros percalços do
trajeto.
Agradeço também à Analista de Teste do CPqD (Centro de Pesquisas e Desenvolvimento),
hoje atual namorada, companheira de percurso e de discussões profícuas, dentro e fora do
contexto deste trabalho, agraciando-me incontáveis vezes com sua paciência e conhecimento.
Alguns experimentos e vários “entendimentos” não teriam sido possíveis sem a colaboração
de Reginaldo Pereira de Souza e José Rubens Garros Parra, por isso não posso deixar de
agradecê-los também.
Eu agradeço fraternalmente a todos.
vi
Sumário
Lista de Figuras.................................................................................................................. vii
Lista de Tabelas ................................................................................................................ viii
Resumo ................................................................................................................................ ix
1 Introdução ..................................................................................................................... 1
2 CMM (Capability Maturity Model).............................................................................. 2 2.1 Nível 1 – Inicial ........................................................................................................ 4 2.2 Nível 2 – Repetível ................................................................................................... 4 2.3 Nível 3 – Definido .................................................................................................... 5 2.4 Nível 4 – Gerenciado ................................................................................................ 6 2.5 Nível 5 – Otimizado.................................................................................................. 7
3 Conceito de Teste........................................................................................................... 8 3.1 Formas Básicas de um Teste ..................................................................................... 8
3.1.1 Verificação ......................................................................................................... 8 3.1.2 Validação ........................................................................................................... 8
3.2 Métodos Fundamentais de Teste................................................................................ 9 3.3 Estágios dos Testes de Validação .............................................................................. 9
3.3.1 Teste de Unidade .............................................................................................. 10 3.3.2 Teste de Integração........................................................................................... 10 3.3.3 Teste de Usabilidade......................................................................................... 10 3.3.4 Teste Funcional ................................................................................................ 10 3.3.5 Teste de Sistema............................................................................................... 10 3.3.6 Teste de Aceitação............................................................................................ 13
3.4 Processo de Desenvolvimento x Estágios de Teste .................................................. 14
4 Concepção do Processo de Teste - Cmm nivel 3 ......................................................... 15 4.1 Fluxo de Atividades do Processo de Teste ............................................................... 15
4.1.1 Solicitação........................................................................................................ 16 4.1.2 Planejamento .................................................................................................... 17 4.1.3 Projeto.............................................................................................................. 18 4.1.4 Preparação de Ambiente ................................................................................... 19 4.1.5 Execução .......................................................................................................... 20 4.1.6 Avaliação ......................................................................................................... 21
5 Conclusão..................................................................................................................... 23 5.1 Contribuições.......................................................................................................... 23 5.2 Extensões................................................................................................................ 23
6 Referências Bibliográficas........................................................................................... 24
vii
Lista de Figuras
FIGURA 2.1 – NÍVEIS DO MODELO CMM .............................................................................. 3
FIGURA 3.1 – RELAÇÃO ENTRE PROCESSO DE SOFTWARE E TESTE .................................... 14
FIGURA 4.1 – FLUXO GERAL DAS ATIVIDADES DE TESTE .................................................... 16
FIGURA 4.2 – ATIVIDADE DE SOLICITAÇÃO DE TESTE ......................................................... 17
FIGURA 4.3 - ATIVIDADE DE PLANEJAMENTO DE TESTE ..................................................... 18
FIGURA 4.4 - ATIVIDADE DE PROJEÇÃO DE TESTE .............................................................. 19
FIGURA 4.5 – ATIVIDADE DE PREPARAÇÃO DE AMBIENTE DE TESTE .................................. 20
FIGURA 4.6 – ATIVIDADE DE EXECUÇÃO DE TESTE ............................................................. 21
FIGURA 4.7 – ATIVIDADE DE AVALIAÇÃO DE TESTE ........................................................... 22
viii
Lista de Tabelas
TABELA 3-1 – CATEGORIAS DE TESTE DE SISTEMA ............................................................ 13
TABELA 3-2 – CATEGORIAS DE TESTE DE ACEITAÇÃO ....................................................... 13
ix
Resumo
Esta monografia tem como objetivo principal, descrever um Processo de Teste de
Software, utilizando praticas de Nível 3 do modelo de qualidade de software CMU/SEI-CMM
Carnegie Mellon University/ Software Engineering Institute-Capability Maturity Model,
também conhecido como CMM.
Este processo é definido como um fluxo de atividades, onde cada uma possui um
conjunto de entradas e saídas necessárias para a sua realização, tarefas a serem realizadas e
responsabilidades, e tem como objetivo melhorar a qualidade do software produzido.
No entanto, para tal definição é necessário ter o conhecimento do conceito de teste de
software com algumas formas básicas, métodos e estágios do teste, além do conhecimento do
modelo de qualidade de software – CMM.
1
1 INTRODUÇÃO
Nos últimos tempos a preocupação com a qualidade de software está se tornando cada
vez maior em função do grande volume de software produzido atualmente e a exigência cada
vez maior de seus usuários para que produza os resultados esperados sem erros ou falhos.
A qualidade de software e o teste de software são considerados áreas de conhecimento
da Engenharia de Software. Estas áreas têm recebido crescente atenção em função do grande
volume de software que é produzido na atualidade[6].
Em função dos altos custos e da grande quantidade de tempo exigida pelas atividades
de teste, estas atividades muitas vezes são negligenciadas ou reduzidas e, conseqüentemente, é
comum a entrega do software para seu usuário com a presença de defeitos não revelados.
Como parte da preocupação pela melhoria da qualidade do software (tanto do produto
como do processo), muitas metodologias e técnicas têm sido desenvolvidas ao longo dos anos.
O teste de software contribui para a melhoria da qualidade do software produzido na
empresa, sendo considerada uma atividade essencial para ascensão ao nível 3 (três) do
Modelo CMM (Capability Maturity Model), que é um modelo que permite avaliar a
maturidade organizacional de uma empresa de software, tendo como foco o processo de
software[4].
Na seção 2 (dois) será abordado o modelo CMM, um modelo de para medir a
maturidade de uma empresa juntamente com seus níveis.
Na seção 3 (três) será mostrado um pouco de teoria de Teste, como definição de teste,
algumas formas, métodos e estágios de testes.
Na seção 4 (quatro) quatro será apresentado uma concepção de um processo de teste,
com suas atividades, seus critérios de entradas e saídas do inicio ao final do processo.
2
2 CMM (CAPABILITY MATURITY MODEL)
Na década de 90, iniciou-se um movimento de entendimento e solução de problemas
crônicos que afetam a indústria de software, principalmente os relacionados a não
cumprimento de prazos, orçamentos e funcionalidades requeridas em seus produtos. Foi
reconhecido que vários desses problemas estariam baseados no fato da construção de software
estar sendo conduzida por métodos improvisados e de maneira artesanal, muitas vezes, mais
dependente do talento profissional e de esforços heróicos individuais, do que de processos
formais orientados ao gerenciamento e à engenharia de software[4].
O CMM é uma iniciativa do SEI (Software Engineering Institute) para avaliar e
melhorar a capacitação de empresas que produzem software. O projeto CMM foi apoiado pelo
Departamento de Defesa do governo dos Estados Unidos (DOD), que é um grande
consumidor de software e precisava de um modelo formal que permitisse selecionar os seus
fornecedores de software de forma adequada. Embora não seja uma norma emitida por uma
instituição internacional como a ISO ou o IEEE, este modelo tem tido uma grande aceitação
mundial. O CMM é um guia designado a ajudar as organizações de software a selecionar
estratégias de melhoria de processos[3].
O objetivo deste modelo é que o processo de software possa ser repetido, controlado e
medido e estabelecer uma compreensão comum entre clientes e a equipe de desenvolvimento
de software sobre a necessidade dos clientes, o CMM leva a organização em direção a uma
visão integrada onde as necessidades técnicas devem ser mantidas consistentes com as
atividades desenvolvidas e com o planejamento do projeto. Para efetuar este processo, os
requisitos do software devem ser documentados e revistos pelos gerentes de software e grupos
afetados, incluindo representantes dos clientes e da comunidade de usuários.
O modelo auxilia as organizações a implementarem um processo de melhoria
gradativa, baseado em níveis de maturidade. O termo maturidade está associado ao grau de
conhecimento, controle e sistemática de execução de um processo de software atingido por
uma organização[3]. O CMM se divide nos seguintes níveis como mostra a figura 2.1:
3
Figura 2.1 – Níveis do Modelo CMM[4]
Cada nível especifica um conjunto de processos que devem ser estabelecidos para se
atingir a maturidade correspondente ao nível. Adicionalmente, cada nível serve de base para o
estabelecimento dos processos do nível seguinte.
Os cinco níveis do CMM são organizados em áreas chave (KPA). Ao todo, o modelo
possui 18 áreas chave[2]. Cada área chave possui 5 características comuns:
• Compromisso em realizar
• Capacidade de realizar
• Atividades realizadas
• Medição e Análise
• Verificação da Implementação
Cada área chave possui práticas chaves (KP). Ao todo, o modelo possui 316 práticas-
chave.
As áreas chave do processo constituem a primeira divisão sistemática dentro dos
níveis de maturidade de uma organização. Esses grupos de atividades, quando executadas em
conjunto, satisfazem um conjunto de metas relevantes para a melhoria da capacitação do
processo. O CMM considera cada área chave um processo particular[2].
Inicial (1)
processo
disciplinado Repetível (2)
processo
padronizado Definido (3)
processo
previsível Gerenciado (4)
processo em
melhoria contínua Em otimização (5)
pouco
controlado
4
Os níveis de maturidade descrevem os problemas mais predominantes daquele nível.
Uma organização migra de um nível a outro sempre que consegue operacionalizar todas as
áreas-chave específicas de um nível.
2.1 Nível 1 – Inicial
O desenvolvimento normalmente é caótico e dependente de esforços heróicos
individuais. Não existem planos realistas de projeto, estimativas de custos, normas,
procedimentos, padrões, documentação e controle que permitam ao gerente e à administração
sênior conhecerem a situação do projeto, identificarem riscos, problemas e agirem preventiva
ou corretivamente. Desvios não são tratados a tempo ocorrendo problemas freqüentes com
relação a prazos, orçamentos, qualidade ou funcionalidades do produto de software [4].
Visibilidade do processo[1]:
• Estágios das atividades mal definidos;
• Dificuldade de visualizar e gerenciar o progresso e as atividades do projeto;
• Os requisitos fluem no processo de uma forma não controlada e há um “produto”
resultante;
• O cliente somente verifica se os seus requisitos foram atendidos na entrega do
produto.
Áreas-chave de Processo:
• Este nível não possui áreas-chave de processos.
2.2 Nível 2 – Repetível
A organização programa controles básicos de gerenciamento de projetos, incluindo
administração de requisitos, planejamento e acompanhamento do projeto de software.
Adicionalmente, estabelece-se uma área de qualidade (SQA - Software Quality Assurance)
para verificar ativamente a conformidade da aplicação de normas, padrões e procedimentos
na condução de projetos. Aspectos como sub-contratação de terceiros, bem como
gerenciamento de produtos e subprodutos resultantes dos projetos (SCM - Software
Configuration Management), também são considerados no nível 2 do CMM. Ao atingir esse
nível, a organização de software estará em melhores condições de controlar projetos,
5
gerenciar expectativas de clientes, estimar prazos e custos e assegurar a qualidade de seus
produtos finais. [4]
Visibilidade do processo[1]:
• As atividades, medições, pontos e verificação estão definidos;
• Requisitos do cliente e produtos do trabalho são controlados;
• É possível medir qualidade, custo e cronograma;
• O processo de desenvolvimento de software permite o gerenciamento entre pontos de
transição (“milestones”);
• O cliente pode analisar o produto durante o processo de software (“Checkpoints”);
• Existem mecanismos formais para a correção de desvios;
• Os processos pertencem aos projetos e não às pessoas.
Áreas chave de Processo[1]:
RM – Gerência de Requisitos
SPP – Planejamento de Projeto de Software
SPTO – Acompanhamento e Supervisão do projeto de Software
SSM – Gerenciamento de subcontratado de software
SQA – Garantia da qualidade de software
SCM – Gerência da configuração de software
2.3 Nível 3 – Definido
Nesse nível, é estabelecido um processo de desenvolvimento de software, notadamente
baseado em uma metodologia de trabalho com ciclo de vida definido, técnicas e ferramentas
apropriadas. Cria-se o grupo SEPG–Sofware Engeneering Process Group, que será a equipe
de trabalho responsável por estudar e implementar processos cada vez mais otimizados. No
nível 3, temos a implementação de controles qualitativos do processo de software[4].
Visibilidade do processo[1]:
6
• As atividades no processo definido de projeto de software são visíveis;
• Os processos utilizados estão estabelecidos e padronizados em toda a organização;
• Como estão estáveis, os processos podem ser medidos quantitativamente;
• Gerentes e engenheiros entendem suas atividades e responsabilidades no processo;
• Gerenciamento preparado pró-ativamente para possíveis riscos;
• O cliente pode obter status atualizado, rapidamente e corretamente, com detalhe entre
as atividades;
• Os processos pertencem agora à organização e não aos projetos.
Áreas chave de Processo[1]:
OPF – Foco no processo da organização
OPD – Definição do processo da organização
TP – Programa de treinamento
ISM – Gerência Integrada de Software
SPE – Engenharia de Produto de Software
IC – Coordenação entre grupos
PR – Revisões técnicas formais
2.4 Nível 4 – Gerenciado
A organização implementa métricas para medir características específicas dos produtos
de software. São definidas e implementadas maneiras de se coletar, armazenar e analisar
dados que servirão de base para melhorias específicas nos processos e produtos. Os controles
passam a ser também quantitativo com relação à qualidade dos produtos e a eficiência do
processo[4].
Visibilidade do processo[1]:
• Medidas de qualidade e produtividade são coletadas em todos os projetos;
• Gerentes possuem uma base de dados para tomadas de decisões;
• A habilidade de prever resultados é maior e a variabilidade do processo é menor;
7
• O cliente pode estabelecer um entendimento quantitativo da capacidade do processo e
riscos antes do projeto iniciar;
Áreas chave de Processo[1]:
QPM – Gestão quantitativa dos processos
SQM – Gestão da qualidade de software
2.5 Nível 5 – Otimizado
A organização implementa meios automáticos para coletar dados sobre métricas
visando prevenir a ocorrência futura de problemas e ineficiências. Enquanto os dados
coletados no nível 4 possam informar, por exemplo, erros existentes em determinadas porções
do software, os dados coletados no nível 5 servirão para otimizar o processo de
desenvolvimento como um todo. O enfoque IDEAL é proposto pelo SEI para o ciclo de
melhoria do processo de software baseado na iniciação dos esforços de melhoria, diagnóstico
do processo de software, estabelecimento de mecanismos para melhoria do processo, ação
para implementar as melhorias e nivelamento do processo por toda a organização[4].
Visibilidade do processo[1]:
• Melhoria contínua do processo objetivando produtividade e qualidade;
• Gerentes são aptos a estimar e monitorar a eficácia das mudanças;
• Forte relação de parceria com o cliente.
Áreas chave de Processo[1]:
DP – Prevenção de não-conformidades
TCM – Gestão de Mudança Tecnológica
PCM – Gestão de Mudança do Processo
8
3 CONCEITO DE TESTE
Teste é o processo de executar um programa com o objetivo de revelar a presença de
erros e contribui para aumentar a confiança de que o software desempenha as funções
especificadas[7].
3.1 Formas Básicas de um Teste
Existem duas formas de se testar um software, de acordo com o momento do processo de
software em que o teste será realizado que são: Verificação e Validação[6].
3.1.1 Verificação
Trata-se de um processo de avaliação dos documentos e informações coletadas nas
primeiras fases do processo de desenvolvimento do software devendo ser aplicado a todos os
produtos produzidos em cada fase, evitando que os problemas migrem de uma fase para a
outra, ou seja, é o processo de avaliar um software para determinar se o produto de uma dada
fase de desenvolvimento satisfaz às condições impostas no inicio dessa dada fase. Não
envolve em nenhum momento a execução do software no computador. A verificação garante
que o software implementa corretamente uma função específica, ou seja, “O produto esta
sendo desenvolvido de maneira certa?”[6].
3.1.2 Validação
Trata-se de um processo de avaliação de um sistema ou componente durante o seu
processo de desenvolvimento ou no final, tendo o objetivo de comprovar se ele está de acordo
com os requisitos e especificações realizadas e validadas pelas fases iniciais do projeto, ou
seja, é o processo de avaliar um software, durante ou após o processo de desenvolvimento,
para determinar se ele satisfaz aos requisitos especificado. A validação garante que o software
que foi construído é adequado aos requisitos do cliente, ou seja, “O produto certo foi
desenvolvido?”[6].
9
3.2 Métodos Fundamentais de Teste
Existe enfoque diferente para categorizarem-se os teste de software e os conceitos
divergem entre as pessoas. Do ponto de vista de quem testa, da cobertura, dos riscos, de como
os testes estão sendo feitos e dos fornecedores de ferramentas pode-se encontrar diferentes
abordagens, mas basicamente podem-se destacar os três métodos abaixo:
• Método da Caixa Branca - tem por objetivo determinar defeitos na estrutura
interna do produto, através de testes que exercitem suficientemente os
possíveis caminhos de execução. Requer conhecimento e acesso às estruturas
internas do software em desenvolvimento, sendo considerado por alguns
autores como teste estrutural. Os testes feitos pelos programadores nos seus
códigos são normalmente caixas brancas[7].
• Métodos da Caixa Preta - tem por objetivo determinar se os requisitos foram
totais ou parcialmente satisfeitos pelo produto. Não verifica como ocorre o
processamento apenas os resultados produzidos e não requer conhecimento
interno do sistema apenas conhecimento dos requisitos do negócio. É
considerado por alguns autores como teste funcional. Os testes feitos pelos
usuários do sistema são normalmente caixas pretas[4].
• Método da Caixa Cinza - utiliza o método da caixa preta, mas se baseia no
conhecimento do funcionamento do software para a construção dos casos de
teste.Poderia ser exemplificado como um programador testando o seu código
(caixa branca), mas avaliando a funcionalidade (caixa preta) ou vice-versa.
3.3 Estágios dos Testes de Validação
Os métodos ou técnicas de teste (caixa branca, preta e cinza) devem ser utilizados em
conjunto, organizados em estágios (também chamados de fases ou estratégias de teste)
estabelecendo como, em que ordem e quem realizarão cada tarefa.
“Uma estratégia de teste de software integra técnicas de projeto de casos de teste em
uma série bem definida de passos que resultam na construção bem sucedida do software”[4].
Abaixo será descrito cada estágio do processo de Validação.
10
3.3.1 Teste de Unidade
Concentra-se em cada unidade (ou módulo) do software, de acordo com o que é
implementado no código-fonte, podendo ser realizado em paralelo para vários módulos. Uma
unidade pode ser uma classe ou um conjunto de classes correlatas. Os testes de unidade são
geralmente de caixa branca[6].
3.3.2 Teste de Integração
Concentra-se no projeto e na construção da arquitetura do software, identificando os
erros associados às interfaces entre os módulos do software. As unidades que foram testadas
separadamente são testadas de forma integrada. Os testes de integração geralmente misturam
teste de caixa branca e de caixa preta[7].
3.3.3 Teste de Usabilidade
Este teste é aplicado várias vezes no processo de desenvolvimento do software, sendo
responsável pela interação antecipada do usuário com o software em desenvolvimento,
através de desenhos, protótipos ou produtos semi-acabados. Apesar desse tipo de teste ser
iniciado na fase de verificação, é considerado uma atividade de validação, pois requer
interação do usuário final com o produto acabado[7].
3.3.4 Teste Funcional
Tem o objetivo de detectar erros entre as especificações funcionais do software e seu
atual comportamento. Nesta fase, o software já está totalmente produzido, não sendo
necessário o conhecimento das estruturas internas do projeto. São realizados testes de
validação de alto nível, se utilizado o Método da Caixa preta. Esses testes devem ser feitos
por um grupo independente do desenvolvimento para aumentar a eficiência dos testes a serem
aplicados[7].
3.3.5 Teste de Sistema
O software e outros elementos do sistema são testados como um todo, tendo como
meta encontrar erros de comportamento do software em relação aos requisitos e objetivos
originalmente especificados. O planejamento deste teste não é uma tarefa fácil, pois não existe
um método genérico aplicável em qualquer situação. Uma forma para organizar os teste é
relacioná-los em categorias, com objetivos bem definidos e distintos[6]. Os testes de sistemas
podem ser subdivididos em categorias como mostra tabela 3.1.
11
Categorias de Testes de Sistemas
Funcionais Utilizam o método caixa preta e têm como objetivo encontrar erros em relação
às regras de negócio, aos requisitos e às funcionalidades da aplicação.
Estresse Objetivo: Determinar o limite máximo de picos de
carga que o software poderá suportar. Confronta o
sistema com situação anormais de uso.
Condições: Elevação momentânea de parâmetros chave
do software como taxa de erros, volume transações,
número de usuários simultâneos e combinações destes.
Comentários:Trata-se de um tipo de teste fundamental.
Carga
/Volume
Objetivos: Determinar o limite máximo de carga que o
software poderá suportar.
Condições: Ao contrário de teste de carga/estresse, esse
tipo de teste não focaliza situações de pico, mas o
aumento contínuo das condições de carga.
Configuração Objetivos: Determinar configurações de software
hardware, previstas na especificação de requisitos, em
que o software não opera de forma adequada.
Condições: Produto deve ser testado com todos os
softwares e hardwares especificados nos requisitos.
Compatibilidade Objetivos: Determinar as áreas em que o software
apresenta incompatibilidade, especialmente quando se
planeja realizar convenções. Uma situação típica em
que isto ocorre é a mudança de versão de ambiente.
Condições: Deve-se verificar a compatibilidade entre
interfaces de hardware e software de diversas situações.
Segurança Objetivos: Detectar formas de quebra de segurança do
software.
Condições: Validar todas as condições de segurança
definidas nos requisitos.
Não-
Funcionais
Performance Objetivos: Determinar se o desempenho em situações
normais e de pico está consistente com os requisitos de
12
desempenho especificados.
Condições: Medição das taxas de transação e tempos
de resposta típicos e comparação com os valores
especificados.
Comentários: Este depende da especificação dos
atributos de desempenho que são difíceis de estimar.
Dados baseados em versões anteriores ou protótipos são
fundamentais se tais metas são factíveis. Omitir estas
informações é altamente indesejável.
Instabilidade Objetivos: Determinar se os procedimentos de
instalação geram erros.
Condições: Devem-se executar as instruções de
instalações em ambientais simulados (Laboratório de
teste) ou reais, verificando se estas estão claras e
completas, observando os resultados produzidos.
Comentários: Recomenda-se que este seja executado,
por usuários típicos.
Confiabilidade/
Disponibilidade
Objetivos: Determinar as medidas de confiabilidade e
disponibilidade quando o software estiver operando
com cargas típicas.
Condições: Esse tipo de teste geralmente envolve a
operação de software por longos períodos para que se
possa medir o grau de confiabilidade e disponibilidade.
Comentários: Geralmente é obtida a execução de
outros testes de sistema.
Recuperação Objetivos: Determinar o comportamento do software
após ocorrência de um erro ou outras condições
anormais.
Condições: Geralmente são obtidos durante a execução
de outros testes de Sistema.
Comentários: Testar o tempo máximo estabelecido
para recuperação de falhas.
13
Manutenibilidade Objetivos: Identificar situações em que, dada uma
situação de erro do software, informações,
documentações, e facilidades de manutenção não
estejam disponíveis ou suficientes para a equipe de
suporte.
Condições: Devem-se provocar erros mais comuns do
software e analisar a informação fornecida e o
comportamento do sistema.
Tabela 3-1 – Categorias de Teste de Sistema
3.3.6 Teste de Aceitação
Tem por objetivo permitir ao cliente e/ou usuário final executar o software já finalizado. É
aplicado após os testes de usabilidade, funcionalidade e o de sistemas. A tabela 3.2 lista as categorias
de Teste de Aceitação.
Categorias de Testes de Aceitação
Teste Alpha Quando os clientes são convidados a operar o
software em um ambiente simulado no
fornecedor.
Teste Beta É realizado por alguns clientes selecionados em
seu próprio ambiente.
Teste de Progressão São elaborados de acordo com a evolução do
produto. Na medida em que o software ganha
novas funcionalidades, um novo conjunto de
testes deve ser criado. Todos os casos de testes
nascem como testes de progressão e acabam
tornando-se posteriormente testes de regressão
durante o ciclo de vida do produto.
Teste de Regressão Re-execução total ou parcial de testes
previamente executados após uma manutenção
corretiva ou evolutiva.
Tabela 3-2 – Categorias de Teste de Aceitação
14
3.4 Processo de Desenvolvimento x Estágios de Teste
Cada estágio dos testes de validação é aplicado em um determinado momento do
processo de desenvolvimento. Na figura 3.1 apresentamos a relação entre o Processo de
Desenvolvimento e os Estágios dos Testes de Validação.
Figura 3.1 – Relação entre Processo de Software e Teste[7]
O processo de teste inicia com os testes unitários, que visam verificar se cada módulo
ou unidade satisfaz à sua especificação. Após testar separadamente cada módulo, estes são
agrupados para compor os subsistemas, conforme a arquitetura do sistema definida na fase de
projeto, sendo esta a fase de teste de integração; o objetivo destes testes é mais encontrar
falhas de interfaceamento entre os módulos e subsistemas. Os testes de validação visam
determinar se o software satisfaz aos requisitos especificados na fase de Análise/
Especificação de Requisitos e os testes de sistema visam exercitar o sistema como um todo,
incorporando todos os componentes para determinar se o sistema completo satisfaz à sua
especificação.
Engenharia do
Sistema
Especificação de
Requisitos
Projeto
Código
Teste de Sistema
Teste de
Validação
Teste de
Integração
Teste de Unidade
15
4 CONCEPÇÃO DO PROCESSO DE TESTE - CMM NIVEL 3
O Processo de Testes está organizado em atividades, onde cada uma possui um conjunto
de entradas e saídas necessárias para a sua realização, tarefas a serem realizadas e
responsabilidades.
O Processo de Testes diz respeito à organização dos testes para o projeto do sistema,
onde as atividades se iniciam em paralelo ao planejamento do projeto, seguindo um modelo
iterativo e incremental. O Processo de Testes que está sendo definido diz respeito à
organização das atividades de testes de sistemas de software, sendo executados inclusive por
uma equipe de testes independente da equipe de desenvolvimento (Equipe de Teste).
4.1 Fluxo de Atividades do Processo de Teste
Neste item será abordada cada atividade especifica do processo de teste, juntamente
com seus objetivos, tarefas, entradas, saídas e responsáveis. A figura 4.1 mostra o fluxo geral
das atividades do processo.
16
Figura 4.1 – Fluxo Geral das Atividades de Teste
4.1.1 Solicitação
As atividades de testes se iniciam a partir de uma solicitação formal, feita por e-mail,
por exemplo, pela área técnica ou equipe de desenvolvimento do projeto de acordo com a
figura 4.2.
Objetivo: Iniciar demanda para realização dos testes.
Tarefa: Solicitar a necessidade de realização de teste.
Entrada: Solicitação de Teste.
Saída: Inicio das Atividades de Teste.
Responsável: Área Técnica.
Solicitar Teste de Software
Planejar Teste de Software
Projetar Teste de software
Preparar Ambiente de
Teste
Executar Teste de Software
Avaliar Teste de Software
Início do Processo
Fim do Processo
17
Figura 4.2 – Atividade de Solicitação de Teste
4.1.2 Planejamento
A partir da solicitação de testes, é feito um planejamento em conjunto com a área
técnica responsável pelo sistema para atender os objetivos do produto a ser testado ( software,
sistema ou componentes), definir o que vai ser testado (escopo dos testes), quem vai testar,
quando serão realizados os testes, e os recursos necessários. Esta atividade prevê a elaboração
de um documento chamado de Plano de Testes de Software, que terá como insumos alguns
artefatos de especificação de requisitos. A figura 4.3 irá ilustrar o que foi descrito.
Objetivo: Entender os objetivos do produto a ser testado e prever recursos necessários para a
realização dos testes.
Tarefa: Definir os item a serem testados a partir dos requisitos do projeto; Definir os tipos de
testes a serem realizados e a necessidade de utilização de ferramentas de apoio; Definir
condições de completeza dos testes (itens a serem testados e grau de cobertura por item);
Definir condições termino dos testes; Definir recursos necessários para os testes (software,
hardware, pessoas); Definir cronograma das atividades.
Entrada: Requisitos do Projeto, para este processo será adotado que minimamente existam
três documentos de requisitos, que são: Documento de Requisitos Suplementar, Documento
de Caso de Uso e Documento de Requisitos Funcionais.
Saída: Plano de Teste de Software.
Responsável: Equipe de Teste de Software.
Área Técnica
Solicitar Teste de Software
E-mail de Solicitação
18
Figura 4.3 - Atividade de Planejamento de Teste
4.1.3 Projeto
Após o planejamento, a bateria de teste deve ser definida. Para tal os casos de teste e
os procedimentos de teste são definidos, juntamente com a ordem de execução dos mesmos e
são selecionados artefatos de teste de outros projetos que possam ser reaproveitados.
Os casos de teste contêm valores de entrada e valores de saída esperados para cada
instância de teste e as pré-condições necessárias para que o caso de teste possa ser executado.
Os valores de entrada são escolhidos de acordo com critérios que maximizam a cobertura dos
testes. Os casos de teste serão descritos em um documento chamado Especificação de Teste
de Software.
Os procedimentos de teste contem uma seqüência de passos a serem executados para a
realização de um conjunto de testes semelhantes. Cada procedimento de teste corresponde a
um roteiro para: instalação da aplicação a ser testada, instalação de ferramentas de apoio,
realização de um caso de uso (teste funcional), scripts de teste (no caso de utilização de
ferramentas de automação de testes). Os procedimentos de teste serão descritos em um
documento chamado Procedimentos de Teste de Software. A figura 4.4 irá ilustrar o que foi
descrito.
Objetivo: Definir bateria de Teste, estabelecendo os procedimentos de teste, os casos de teste
e a ordem de execução dos mesmos. Define-se “como fazer”.
Tarefa: Definir bateria de testes estabelecendo: os objetivos dos testes e pré-condições
necessárias para que o caso de teste possa ser executados; Especificar os Procedimentos de
teste; Especificar os Casos de teste.
Documento de Requisitos
Suplementar
Documento de Caso de Uso
Documento de Requisito Funcional
Outros Documentos (se aplicável)
Plano de Teste de Software
Equipe de Teste Planejar Teste
19
Entrada: Plano de Teste de Software; Manuais de instalação e de operação do software das
ferramentas de apoio.
Saída: Procedimento de Teste; Especificação de Teste.
Responsável: Equipe de Teste.
Figura 4.4 - Atividade de Projeção de Teste
4.1.4 Preparação de Ambiente
Nessa atividade o ambiente de teste é completamente preparado, o software a ser
testado e as ferramentas de apoio são instalados e configurados. Os componentes utilizados
em testes anteriores podem ser reaproveitados. A figura 4.5 irá ilustrar o que foi descrito.
Objetivo: Preparar o ambiente de teste, tornando disponível todos os recursos necessários.
Tarefa: Configurar o ambiente de Teste no Laboratório; Instalar o software a ser testado e as
ferramentas necessárias.
Entrada: Procedimento de Teste; Manuais do usuário, de instalação e de operação do
software e das ferramentas de apoio.
Saída: Disponibilização da infra-estrutura necessária para a realização dos testes.
Responsável: Equipe de Teste de Software.
Plane de Teste (Atualizado)
Procedimento de Teste
Especificação de Teste
Equipe de Teste Projetar Teste
Manual do Usuário
Manual de Operação
Manuais de Instalação das Ferramentas de Apoio
Plane de Teste
20
Figura 4.5 – Atividade de Preparação de Ambiente de Teste
4.1.5 Execução
Após a disponibilizarão da infra-estrutura necessária para realização dos testes, os
mesmos são executados no ambiente simulado no Laboratório e os resultados são registrados
em um documento chamado de Resultados dos Testes de Software. A figura 4.6 irá ilustra o
que foi descrito.
Objetivo: Executar os teste e registrar os resultados.
Tarefa: Executar os teste no Laboratório; Registrar os resultados.
Entrada: Ambiente de Teste Configurado; Procedimento de Teste; Especificação de Teste;
Scripts de Teste(se aplicável).
Saída: Resultado de Teste.
Responsável: Equipe de Teste Software.
Procedimento de Teste
Ambiente Configurado
Equipe de Teste Preparar Ambiente
de Teste
21
Figura 4.6 – Atividade de Execução de Teste
4.1.6 Avaliação
A partir dos resultados dos testes, é verificado se as condições de completeza e sucesso
dos testes definidas no Plano de Testes de Software estão satisfeitas. O Resultado dos Testes é
verificado e completado. A figura 4.7 irá ilustrar o que foi descrito.
Objetivo: Garantir a satisfação do produto.
Tarefa: Verificar se o produto esta realmente pronto, de acordo com o planejado.
Entrada: Plano de Teste de Software; Resultados de Teste.
Saída: Resultado de Teste Atualizado.
Responsável: Equipe de Teste de Software.
Procedimento de Teste
Especificação de Teste
Scripts de Teste (Se houver)
Resultado de Teste
Equipe de Teste Executar Teste
22
Figura 4.7 – Atividade de Avaliação de Teste
Plano de Teste de Software
Resultado de Teste
Resultado de Teste (Atualizado)
Equipe de Teste Avaliar Teste
23
5 CONCLUSÃO
Nos últimos anos investiu-se muito em ferramentas e metodologia para o processo de
desenvolvimento de software. Apesar dos testes fazerem parte do processo de
desenvolvimento, a utilização de técnicas e ferramentas nessa área ainda é incipiente.
O processo de testes deve ser tratado como mais um processo de software. A adoção
de uma metodologia de testes permite que sejam utilizados indicadores de testes para a
melhoria da qualidade dos softwares desenvolvidos e do processo de desenvolvimento,
reduzindo custos e melhorando a produtividade.
5.1 Contribuições
Resumidamente, as principais contribuições gerais deste estudo são: uma nova visão
de processo de desenvolvimento de software baseado em um nível de maturidade, onde
poucos têm conhecimento, que permite melhores qualidades no desenvolvimento de software,
e também ganhar espaço no mercado de trabalho com uma ampla visão de processo baseado
em CMM.
5.2 Extensões
Este trabalho pode ser continuado na adequação do processo para o nível 4 (quatro) do
modelo CMM,ou seja, daria mais ênfase nas atividades de coleta de métricas, definindo e
implementando maneiras de se coletar, armazenar e analisar os dados que servirão como base
para melhorias no processo e produto. Com isso os controles passariam a ser também
quantitativo com relação à qualidade dos produtos e a eficiência do processo.
24
6 REFERÊNCIAS BIBLIOGRÁFICAS
1. PAULK, Mark C: Capability Maturity Model for Software, version 1.1, Software
Engineering Institute, CMU/SEI-93-TR-24, DTIC number ADA263403, February
1993.
2. WESLEY Addison: The Capability Maturity Model – Guidelines for Improving
the Software Process. The SEI Series in Software Engineering.
3. FURLAN, J. D.: Melhorando a qualidade de software através do CMM.
http://www.sucesusp.org.br/html/menuarti/artigos/artigo_jose_davi_furlan.html
4. ROSA, F. P.. Estagio Supervisionado. Trabalho preparado para a disciplina de
Estagio Supervisionado do Curso de Engenharia de Computação, 2003.
5. PRESSMAN, R. S. – Software Engineering. McGraw-Hill, 4. edição 1997.
6. ROSA A.C.A., C.R.B de Souza, Verificação e Validação: um Overview e Inspeção
de Software.Trabalho preparado para o curso de Mestrado, 1996.
7. MYERS G.J..The Art of Software Testing. John-Wiley & Sons, 1979.
8. Apostila de Especializaçao em Engenharia de Software – Modalidade Extensão
Universitaria: Verificação e Validação – INF307, ,2004. Recuperado em
18/09/2004
9. Capability Maturity Model for Software (SW-CMM), in
http://www.sei.cmu.edu/cmm/.
