Você está na página 1de 7

Caracterizaca o de um Subconjunto de Praticas do

TMMi para Compor um Processo de Teste Enxuto


Kamilla Gomes Camargo , Fabiano Cutigi Ferrari , Sandra Camargo Pinto Ferraz Fabbri
Computing Department Federal University of Sao Carlos Brazil
Email: {kamilla camargo, fabiano, sfabbri}@dc.ufscar.br

ResumoContexto: O teste de software e uma das fases mais


importantes do desenvolvimento. Entretanto, sao comuns os casos
em que essa fase fica comprometida por falta de planejamento
e recursos. Diante desse cenario, a adoca o de um processo
de teste enxuto pode viabilizar a construca o de produtos de
software com nveis de qualidade desejaveis. Objetivo: Embasar
a definica o de um processo generico de teste de software por
meio da identificaca o de um conjunto de atividades fundamentais.
Metodo: Com base nas praticas descritas no TMMi (Test Maturity
Model integration) foi feito um survey com profissionais da a rea

de teste que atuam tanto na academia quanto na industria.


Os
dados obtidos foram analisados quantitativa e qualitativamente.
Resultados: Das 81 praticas do TMMi que estao relacionadas
a` s etapas de um processo de teste, 13 foram consideradas
mandatorias e 29 desejaveis considerando o conjunto total
de respostas obtidas. Entretanto, quando somente as respostas
de especialistas sao consideradas, esse conjunto de praticas e
reduzido para 13 mandatorias e 3 desejaveis. Considerando os
dois grupos, total e apenas especialistas, houve uma sobreposica o
parcial do conjunto de praticas mandatorias. Conclusao: Esses
resultados mostram que ha um consenso sobre um subconjunto
de praticas que podem guiar a definica o de um processo de
teste mais enxuto se comparado a um processo que inclui todas
as praticas do TMMi. Espera-se que tal processo mais enxuto
incentive a pratica mais ampla de atividades de teste no a mbito

da industria
de software.

I. I NTRODUC AO
O uso de modelos de referencia auxilia na elaboraca o de
um processo com qualidade.
Uma survey e uma estrategia de investigaca o que permite
coleta de informaco es quantitativas e qualitativas atraves de
questionarios respondidos por uma amostra representativa da
populaca o que se deseja investigar. Os resultados de um
survey devem ser analisados para obter conclusoes descritivas
e explanatorias [1].
O TMMi e um framework que direciona a criaca o de um
processo de teste de software, e foi criado com base no
CMMi ??, que sugere a implantaca o do processo de forma
incremental de acordo com o nvel de maturidade atingido. O
TMMi e dividido em a rea de processo, que possuem objetivos
especficos, que por sua vez possuem praticas especficas.
Essas praticas sao atividades que o TMMi sugere que sejam
implementadas e executadas em um processo de teste. Esses
objetivos estao relacionados com cada fase de um processo
de testes e tambem com institucionalizaca o do processo. Essa
divisao em praticas pode ser uma tentativa de facilitar a
implementaca o das atividades, porem muitas vezes torna o
modelo complexo e de difcil compreensao. O processo a ser
construdo, com base em algum modelo de referencia, deve
estar de acordo com a realidade da empresa que o adotara.
Nem todas as atividades sugeridas no TMMi sao factveis para
todos os tamanhos de empresas e equipes. Com base nisso,

acredita-se que seja importante ter como base quais praticas


podem comprometer mais a qualidade do processo e consequentemente do produto de teste. Diante disso, foi proposto
um survey para identificar o que deve ser feito essencialmente
num processo de testes segundo os especialistas da a rea.
O TMMi possui 81 praticas relacionadas diretamente com
o processo de teste. Algumas praticas estao relacionadas com
institucionalizaca o do processo e com a parte organizacional
que envolve o teste. Esses dois u ltimos grupos nao fizeram
parte do estudo, pois nao estao diretamente relacionados com
a execuca o dos testes em si.

II. P LANEJAMENTO
A. Objetivo do Survey
Este estudo foi realizado com o proposito de identificar
quais sao as praticas mais importantes do TMMi e que devem
ser realizadas prioritariamente na execuca o de um processo
de testes, segundo o ponto de vista de especialistas em
teste de software. Acredita-se que existam atividades basicas
relacionadas a cada fase de um processo de teste que nao
devem ser deixadas de lado, mesmo que o orcamento, tempo
ou equipe sejam escassos. Um processo generico de testes
deve incluir atividades ou fases de planejamento, projeto
de casos de teste, execuca o e analise, e acompanhamento dos
testes [2, 3].
B. Projeto do Survey
O questionario foi projetado com o apoio da ferramenta
Lime Survey1 , a qual permite organizar as questoes em grupos
e visualiza-los em paginas Web distintas. Para a confecca o
do questionario foi utilizado o agrupamento das praticas do
TMMi feito por Hohn [4]. A autora identifica quais praticas
estao relacionadas com cada uma das cinco fases de um
processo generico de teste mencionadas. O questionario foi
dividido em seis grupos de questoes. O primeiro grupo,
relacionado ao perfil, teve como objetivo tracar o perfil dos
participantes identificando a experiencia e o conhecimento
em modelos de referencia, sendo eles o CMMi, o MPS.Br
e o TMMi. Cada um dos cinco grupos restantes representam
uma das fases de um processo de teste: (A) Planejamento,
(B) Projeto de Casos de Teste, (C) Configuraca o de Dados e
de ambiente, (D) Execuca o e Analise e (E) Monitoramento e
Controle.
Como cada pagina do questionario apresentava um u nico
grupo de questoes, optou-se por incluir no primeiro grupo
algumas instruco es para o preenchimento do questionario e
uma tabela contendo a escala que deveria ser utilizada na
resposta a` s questoes. Essa escala e apresentada na Tabela I.
Esta escala nao forneceu valor neutro com o objetivo de
obrigar o respondente identificar a importancia do item em
questao. Os participantes nao foram informados que o questionario foi construdo com base no TMMi. Foi solicitado ao
participante que respondesse o questionario de acordo com sua
opiniao pessoal, porem, o ambiente no qual ele se insere pode
influenciar suas respostas.
Tabela I

E SCALA DE IMPORT ANCIA


1- Dispensavel
2- Opcional
3- Desejavel
4- Mandatoria

Atividade dispensavel que nao precisa ser realizada


Atividade que nao necessariamente precisa ser realizada
Atividade que deve ser realizada sempre que possvel
Atividade essencial que deve sempre ser realizada.

Conforme podera ser observado nos resultados e discussoes


apresentados nas proximas seco es, as respostas foram agrupadas conforme um conjunto pre-definido de tres perfis. O
primeiro perfil, aqui denominado Perfil-Especialista, e constitudo por profissionais com mais de tres anos de experiencia
com teste em empresas de software e que ja trabalharam
com algum processo de testes formalmente implantado. Outro
perfil, e constitudo por profissionais que conhecem e utilizam

o MPS.Br, que sera chamado de Perfil-MPS.Br. Por fim,


identificou-se um perfil que e formado por profissionais que
conhecem o TMMi. A esse u ltimo perfil deu-se a denominaca o
Perfil-TMMi. Ressalta-se que esses grupos foram selecionados
pois, em geral, espera-se que o grau de conhecimento tacito,
acerca de processos e de teste de software, seja muito maior
que dos respondentes que nao se encaixam nesses perfis.
Nos resultados sao apresentados os dados demograficos desta
pesquisa.
C. Divulgaca o
O questionario foi disponibilizado no link: http://amon.dc.
ufscar.br/limesurvey/index.php?sid=47762&lang=pt-BR e divulgado por e-mail entre alguns especialistas da academia
e da industria de software, e entre uma comunidade virtual
de testadores, o qual possui mais de 3 mil participantes
cadastrados2 . O questionario tambem foi distribudo entre
algumas empresas de software da cidade de Ribeirao Preto,
no estado de Sao Paulo, pertencentes ao PISO (Polo Industrial
de Software)3 .
D. Forma de Analise dos Dados
Foram obtidas 39 respostas completas e todas foram consideradas na exploraca o dos dados. A amostra obtida e pequena, em relaca o ao numero de convidados a responderem
o questionario. Ainda assim, esse numero permitiu que os
dados fossem analisados por meio de metodos estatsticos,
mas com um nvel de confianca menor que o usado em geral.
Neste survey, as variaveis independentes sao as categorias
experiencia em empresa, possui processo, conhecimento e
utilizaca o do MPS, conhecimento do TMMi e a variavel
dependente e a escala de importancia atribuda a cada questao.
O questionario foi construdo com base no TMMi: cada
pergunta do questionario era um objetivo especfico do TMMi,
o qual possui praticas especficas associadas. Essas praticas
eram as opco es de cada pergunta, nas quais o respondente
atribua uma nota, de 1 a 4 conforme a escala, de acordo com
sua opiniao pessoal em relaca o a` importancia daquela opca o
(pratica) para a realizaca o da pergunta (objetivo especfico).
No TMMi o objetivo especfico e alcancado com a realizaca o
do conjunto de suas praticas relacionadas.
Os dados obtidos foram analisados atraves de um teste
nao-parametrico, por terem nvel de mensuraca o ordinal e
uma distribuica o nao simetrica, pois a maioria das respostas
estavam concentradas em 3 ou 4. O teste escolhido foi o teste
de sinal (do ingles, Sign Test) para uma amostra [5, 6], para
avaliar se a resposta de 50% dos participantes e maior que
um determinado valor. O teste do sinal avalia se a mediana,
calculada para uma determinada questao, e maior que um valor
fixo. Neste caso foram escolhidos dois valores: inicialmente
2,5, que permitiu identificar quais praticas foram consideradas
como desejaveis ou mandatorias, e um segundo valor de
3,5, que permitiu identificar quais das questoes previamente
marcadas como desejaveis ou mandatoria sao efetivamente
mandatorias, pois a mediana dessas questoes seria maior que
o segundo valor fixo. Para todos os casos foi utilizado o nvel
de confianca (p-value) de 0,15 devido ao tamanho da amostra.
Apesar de nao ser um nvel de confianca comum, observa-se
2 http://br.dir.groups.yahoo.com/group/DFTestes

1 http://www.limesurvey.org/

- acessado em 09/04/2012.

3 http://www.piso.org.br/

- acessado em 09/04/2012
- acessado em 09/04/2012.

que para amostras pequenas e em estudos exploratorios alguns pesquisadores [7, 8] utilizam nveis de confianca menos
rigorosos do que os tradicionais nveis de 0,01 ou 0,05.
III. R ESULTADOS
O survey ficou disponvel por 45 dias, perodo no qual
houveram 113 acessos e desses apenas 39 responderam o questionario em sua totalidade. Apos esse perodo o questionario
foi fechado e foram analisadas somente as respostas completas
ao questionario.
A. Caracterizaca o do Nvel de Conhecimento dos Respondentes
A analise inicial das respostas permitiu a identificaca o
de duas respostas discrepantes. A primeira possua todas as
praticas assinaladas com valor 4 (quatro). Na segunda, a escala
foi utilizada de forma invertida, ou seja, atribuiu-se o valor
1 (um) para praticas consideradas mandatorias. Ambas as
respostas foram consideradas outliers para os objetivos deste
estudo, tendo sido removidas do conjunto final.
Apos essa identificaca o das respostas discrepantes, foram
caracterizados os nveis de conhecimento do conjunto final
de 37 respondentes do survey. Ressalta-se que, embora essa
caracterizaca o nao coincida exatamente com os perfis definidos na Seca o II (isto e , Perfil-Especialista, Perfil-MPS.Bre
Perfil-TMMi), ela serviu de base para a quantificaca o de respondentes que se encaixavam dentro de cada um dos tres perfis
definidos anteriormente. A Figura 1 sumariza os resultados
oriundos da caracterizaca o dos nveis de conhecimento. Os
resultados sao descritos a seguir.
Experincia

Processo de Software
6%

11%

24%
Possui
No possui
N/A

46%

43%

Possui
No possui
N/A

71%

Certificao

Tipo de Certificao

16%
Possui
No possui
N/A

MPS.BR
CMMi
48%
52%

a) Experiencia: O primeiro grafico, intitulado Ex


periencia,
mostra que dos 37 profissionais que responderam
o questionario, 46% (ou seja, 17 deles) possuem mais de tres
anos de experiencia com teste de software em empresas e/ou
na academia, enquanto 43% (16 respondentes) possuem de
um a tres anos de experiencia e apenas 11% (4 respondentes)
possui menos de um ano de experiencia.
b) Processo de Software: O grafico intitulado Processo
de Software mostra que 65% dos respondentes (isto e , 24
de um total de 37) trabalham com um processo de teste
implantado, enquanto 22% (8 respondentes) atuam em uma
organizaca o sem processo de teste. Observa-se que 12% (ou
seja, 5 respondentes) nao responderam essa questao.
revela que 22
c) Certificaca o: O grafico Certificacao
respondentes trabalham em uma organizaca o que possui um
certificado de maturidade de processo de software, o que
representa 59% do total de respondentes. Outros 24% (9
respondentes) nao atuam em organizaco es certificadas 16%
(6 respondentes) nao responderam essa questao.
d) Tipo de Certificaca o: Dos 22 respondentes que afirmaram trabalhar em um organizaca o com certificaca o de
maturidade de processo de software, metade deles atua em
organizaco es que possuem certificaca o CMMi em algum nvel,
enquanto a outra metade atua em organizaco es certificadas
pelo modelo MPS.Br. Essas informaco es estao sumarizadas
da Figura 1.
no grafico Tipo de Certificacao
e) TMMi: Por fim, o grafico TMMi mostra que apenas
8% dos respondentes (isto e , apenas 3 deles) ja utilizaram o
TMMi na pratica, enquanto 59% (22 respondentes) afirmam
conhecer o modelo de maturidade de processo de testes e 12%
(12 respondentes) desconhecem o modelo.
Com base nos resultados da caracterizaca o do nvel de conhecimento dos respondentes do questionario, conclui-se que
em geral eles possuem um nvel adequado para os objetivos
tracados por este estudo. Dentre os 37 respondentes, 89%
possuem experiencia com teste de software, 65% trabalham em
uma organizaca o que possui um processo de teste implantado,
59% trabalham em uma organizaca o certificada com CMMi
ou MPS.Br e 67% conhecem o TMMi, com alguns ja tendo
utilizado-o na pratica. O nvel das empresas certificadas em
CMMi sao 2, 3 e 5. Ja o nvel das empresas certificadas
em MPS.Br varia entre E, F e G. Para esses nveis do
MPS.Br a a rea de processo que envolve teste de software
nao esta presente [9]. Para analise dos resultados nao foram
consideradas as certificaco es por nao apresentarem diferencas
significativas, no caso do CMMi e por nao envolver a a rea de
teste, no caso do MPS.Br.

24%

59%

B. Caracterizaca o da Importancia das Praticas do TMMi

TMMi

16%
Conhece na prtica
Conhece, mas no
na prtica
No conhece
24%

59%

Figura 1.

Perfis obtidos na amostra

A descrica o dos resultados e as respectivas analises apresentadas a seguir sao baseadas no grupo total de respondentes e nos tres perfis definidos na Seca o II, sendo eles
Perfil-Especialista, Perfil-MPS.Bre Perfil-TMMi.
Para alguns perfis algumas praticas nao apresentaram
diferenca estatstica significativa, na analise pelo teste de sinal.
O que demonstra que nao houve um consenso claro a respeito
da importancia de determinadas praticas, ou seja, as notas
atribudas estao distribudas de maneira mais uniforme entre
pelo menos 3 e 4.
As praticas que se apresentaram nos resultados da analise
estatstica foram as praticas que possuem maiores diferencas

Figura 2. Diagrama de Venn para os quatro perfis descritos apresentando


as intersecco es dos resultados e praticas que foram identificadas como
mandatorias e desejaveis.

nas respostas, ou seja, que estao mais polarizadas para determinada nota da escala.
1) Todo: Na analise do conjunto todo 42 praticas apresentaram diferenca significativa. Das quais 13 foram classificadas como mandatorias e 29 como desejaveis. A figura 2
mostra quais praticas pertencem a` analise do conjunto todo.
Essas praticas estao enumeradas e podem ser vistas nas
figuras 3, 4, 5, 6, 7. Na fase de planejamento quatro praticas
foram classificadas como mandatorias e coincidem com as
praticas mandatorias da mesma fase de outros perfis. 14
praticas foram classificadas como desejaveis. Algumas praticas
aparecem somente na analise do conjunto todo, como pode
ser visto na figura 2. Na fase de projeto de casos de teste
somente uma pratica apresenta diferenca significativa e foi
classificada como desejavel. Na fase de configuraca o de dados
e de ambiente 5 praticas sao desejaveis e 1 mandatoria. Na
fase de execuca o e analise 4 mandatorias e 2 desejaveis Na
fase de monitoramento e controle 7 desejaveis e 4 mandatorias
As praticas que aparecem somente nos resultados desse
perfil sao desejaveis:

Definir criterios de entrada,


Definir criterios de parada,
Revisar plano de teste,
Desenvolver requisitos (ambiente),
Identificar riscos de produto nao funcionais,
Definir criterios nao funcionais de parada,
Definir criterios de revisao por pares,
Manter rastreabilidade com requisitos nao funcionais,
Analisar dados de revisao por pares,
Monitorar compromissos de teste,
Verificar status em relaca o aos criterios de entrada.

??
2) Perfil-Especialista: Para especialistas 16 praticas tiveram diferenca estatstica significativa, sendo 3 praticas sao
desejaveis e 13 praticas mandatorias, porem, somente algumas
possuem intersecca o com o grupo total, como pode ser visto na
figura 2. Para especialistas Monitorar riscos de produto aparece
como desejavel, o que mostra a importancia dada a` analise
de risco de produto, que foi estabelecida previamente no
planejamento e acompanha a atividade de testes, pois em caso
de mudanca de risco e necessario gerenciar as contingencias
geradas.
3) Perfil-MPS.Br: Para os que conhecem e utilizam o
MPS.Br 27 praticas estao presentes nos resultados, sendo 8

praticas foram classificadas como mandatorias e 19 praticas


desejaveis.
4) Perfil-TMMi: Para quem conhece o TMMi 29 praticas
apresentaram diferenca significativa, sendo 11 mandatorias e
18 desejaveis.
Observando a intersecca o dos quatro grupos foram encontradas 6 praticas mandatorias e 1 desejavel, como pode ser
visto na parte central da figura 2. No resultado tambem foram
consideradas as praticas que estao na intersecca o de pelo
menos dois grupos. Com essa analise e possvel perceber que
o conjunto total de 81 praticas do TMMi pode ser reduzido
para 31 e ainda assim ter as principais atividades de teste
contempladas. Apesar de nao haver praticas especficas da
fase de projeto de casos de teste, essa etapa do processo de
teste e contemplada, pois ha praticas relacionadas a estabelecer
plano de teste que, segundo o padrao IEE [10], contempla a
definica o das classes e condico es de teste, que sao atividades
descritas por praticas especficas da a rea de processo Projeto
e Execuca o de Testee com a criaca o dados de teste especficos
e genericos, esta fase estaria completa, mesmo nao obedecendo
a divisao do TMMi. Isso pode demonstrar uma falha do
TMMi, que divide em muitas praticas atividades que sao
semelhantes. Isso pode confundir quem utiliza o documento
para implementar um processo de teste, ja que quebra em
muitas praticas um mesmo objetivo. Muitas vezes as praticas
sao redundantes o que torna o documento excessivamente
carregado. A seguir e apresentada a discussao por fase do
processo de teste acerca dos resultados obtidos segundo a
analise do todo, dos especialistas, de quem conhece o TMMi
e de quem conhece e utiliza o MPS.

IV. D ISCUSS AO
O resultado da analise estatstica sobre as respostas do
survey indicou quais praticas foram classificadas como mandatorias ou desejaveis com significancia estatstica, utilizando
nvel de confianca de 0,15. Foi construdo um mapa mental, com base no mapa feito por Hohn [4], para melhor
visualizaca o dos resultados em relaca o as praticas do TMMi.
Esse mapa mental e apresentado nas figuras abaixo divido
pelas fase do processo de teste com as praticas selecionadas
marcadas. Com base na analise dos resultados pode-se concluir
o TMMi pode ser reduzido, e portanto existe uma gama menor
de praticas que podem ser utilizadas para implementar um
processo de teste completo, porem mais enxuto.
A. Planejamento e Projeto de Casos de Teste
Planejar o teste de software e uma das fases mais importantes do processo de teste, pois e a fase na qual se
define como sera executado todo o processo para um projeto
especfico e que permite ao gestores acompanhar e mensurar o
resultado da execuca o do processo. Nessa fase deve-se definir
um plano de teste que inclui definico es sobre cronograma,
equipe, identificar o que sera testado, o que nao sera testado
e a abordagem que sera utilizada [10]. No TMMi tambem
estao relacionadas a essa etapa o planejamento de testes nao
funcionais, definica o do ambiente de testes e revisao por
pares. Os objetivos especficos dessa fase incluem realizar
avaliaca o de risco do produto, estabelecer abordagem de teste,
estabelecer estimativas de teste, desenvolver um plano de teste,
obter comprometimento com o plano de testes, desenvolver
requisitos de ambiente de teste, realizar avaliaca o de risco
e estabelecer abordagem para teste nao funcional e ainda

definica o de abordagem de revisao por pares. Nesta fase que


sao mostradas na figura 3, das quais estao destacadas em
negrito as praticas mandatorias e sete desejaveis.

Fase 1
Planejamento

SG 1
Realizar avaliao
de risco do produto

SP 1.1 Definir categorias e parmetros de


risco de produto
SP 1.2 Identificar os riscos do produto
SP 1.3 Analisar riscos do produto

SG 2
Estabelecer uma
abordagem de
teste

SP 2.1 Identificar elementos e


caractersticas a serem testados
SP 2.2 Definir a abordagem de teste
SP 2.3 Definir critrios de entrada
SP 2.4 Definir critrios de parada
SP 2.5 Definir critrios de suspenso e
recomeo

Nvel 2 PA 2.2

SG 3
Estabelecer
estimativas
de teste

Planejamento de Teste

SP 3.1 Estabelecer uma wbs de alto nvel


SP 3.2 Definir ciclo de vida de teste
SP 3.4 Determinar estimativas de
esforo e custo de teste
SP 4.1 Estabelecer o cronograma de teste

SG 4
Desenvolver um
plano de teste

SP 4.2 Planejar a equipe de teste


SP 4.3 Planejar o envolvimento dos
interessados
SP 4.4 Identificar riscos ao projeto de teste
SP 4.5 Estabelecer o plano de teste

SG 5
Obter comprometimento com o plano
de teste

SP 5.1 Revisar o plano de teste


SP 5.2 Conciliar trabalho e nveis de
recursos
SP 5.3 Obter comprometimento com o
plano de teste

Nvel 2 PA 2.5

SG 1
Desenvolver os
requisitos do
ambiente de teste

Ambiente de Teste

SP 1.1 Obter (elicitar) necessidades do


ambiente de teste
SP 1.2 Desenvolver os requisitos do
ambiente de teste
SP 1.3 Analisar os requisitos do
ambiente de teste

SG 1
Realizar avaliao
de riscos no
funcional do produto

SP 1.1 Identificar riscos do produto no


funcionais
SP 1.2 Analisar riscos do produto no
funcionais

Nvel 3 PA 3.4

Teste No Funcional
SG 2
Estabelecer uma
abordagem de teste
no funcional

SP 2.1 Identificar caractersticas no


funcionais a serem testadas
SP 2.2 Definir a abordagem de teste no
funcional
SP 2.3 Definir critrios no funcionais de
parada

Nvel 3 PA 3.5

Reviso por Pares

Figura 3.
Teste

SG 1
Definir uma abordagem
de reviso por pares

SP 1.1 Identificar produtos de trabalho


que devem ser revisados
SP 1.2 Definir critrios para a reviso
por pares

Praticas do TMMi relacionadas a` fase de Projeto de Casos de

Na fase de planejamento o TMMi concentra 29 praticas


das quais, apos a analise, quatro praticas foram classificadas
como mandatorias e sete como desejaveis. Essas praticas
sao mostradas em destaque na figura 3. Como pode ser
observado, nessa fase estao relacionados o planejamento dos
testes funcionais e nao funcionais, do ambiente e da revisao
por pares.
O TMMi divide a avaliaca o de risco em tres praticas:
Definir categorias de riscos, Identificar riscos e Analisar riscos.
Essas praticas em conjunto produzem uma avaliaca o com os

riscos identificados e categorizados. A pratica Analisar Riscos


consiste na distribuica o dos riscos identificados nas categorias
definidas, porem, o fato de somente a pratica identificar
riscos ter sido selecionada por todos os perfis mostra que
esse objetivo foi atingido ja que a identificaca o e seguida
de uma analise para fornecer informaco es a` equipe de teste.
Acredita-se que para os profissionais a pratica identificar
riscos ja contemple a analise. A analise de risco de produto
e essencial, pois e com base nisso que todo o projeto de
teste e guiado. REFERENCIA?? O TMMi separa em uma
pratica diferente a analise de risco do ponto de vista nao
funcional do produto. Essa pratica aparece como desejavel,
o que demonstra consistencia nos resultados, ja que a analise
de risco deve ser feita tanto para caractersticas funcionais
quanto nao funcionais do produto. Identificar elementos e
caractersticas a serem testados tambem foi identificada como
mandatoria por todos os grupos. Essa pratica esta diretamente
relacionada com a pratica Estabelecer plano de teste que
foi marcada como mandatoria pelos grupos TMMi, Todo e
MPS. Somente o grupo de Especialistas nao identificou essa
pratica como mandatoria, segundo a analise estatstica, embora
a mediana seja 4, nesse grupo essa pratica nao apresentou
diferenca significativa. O que mostra que para os especialistas
nao ha um consenso claro a respeito do grau de importancia
dessa pratica. Como ela foi selecionada por outros tres grupos
entende-se que esta pratica seja importante, ja que complementa a pratica de Identificar elementos e caractersticas a
serem testados na criaca o do plano de testes. Segundo a
IEE [10] o plano de teste deve descrever os itens que serao
testados e o que nao sera testado, abordagem a ser utilizada,
classes e condico es de teste identificadas. Definir abordagem
de teste nao funcional tambem foi marcado como desejavel.
Apesar do TMMi colocar em pratica separada, a definica o
de abordagem de teste, seja ele funcional ou nao funcional,
esta contemplada no plano de testes. A pratica estabelecer o
plano de teste consiste em documentar o que foi planejado,
na definica o do TMMi, mas percebe-se que a compreensao e
de que essa pratica define e claro documenta o plano. Esse
resultado mostra que a divisao excessiva em diversas praticas
nao e aceita.
Para estabelecer a abordagem de teste deve-se identificar
elementos e caractersticas a serem testados, definir abordagem
de teste, definir criterios de entrada, definir criterios de parada
e criterios de suspensao e recomeco. Para todos os grupos a
pratica Identificar elementos e caractersticas a serem testados
e mandatoria. Com base nisso fica claro a importancia de
se identificar o que sera testado e que em um processo
enxutoessa pratica prevalece sobre outras relacionadas a`
definica o de abordagem a ser utilizada no teste e complementa
a pratica Estabelecer plano de teste. Definir ciclo de vida de
teste esta diretamente relacionado com estimativas de teste,
pois conhecendo o ciclo de vida do teste pode-se identificar
os esforcos necessarios para cumpri-lo. Essa pratica aparece
desejavel para o todo e para quem utiliza o MPS.Para esse
u ltimo grupo e esperado esse resultado ja que o MPS forca a
criaca o de um ciclo de vida de testes, embora seja somente no
nvel D [9]. Planejar envolvimento dos interessados foi identificado como desejavel por Perfil-Especialistae Perfil-TMMi
Projeto de casos de teste e a etapa seguinte ao planejamento
e tem como entrada o plano de testes que possui definico es
pertinentes a essa etapa: o que sera testado, abordagem de teste
funcional e nao funcional e classes de teste, como mostrado na

figura 4. Porem ao se fazer essas definico es automaticamente


os casos de teste comecam a ser criados. O TMMi divide em
varias praticas diferentes a criaca o de casos de teste funcional
e nao funcional, sugerindo a identificaca o e priorizaca o dos
casos e condico es de teste, mantendo a rastreabilidade horizontal com requisitos. Essa fase apresentou algumas praticas
desejaveis nos grupos TMMi, MPS e Todo, porem no grupo
dos especialisas as atividades relacionadas a essa fase nao tem
um consenso claro a respeito de sua importancia, de forma que
nao apresentou resultados significativos na analise estatstica.
Isso pode demonstrar tambem que muitas vezes casos de teste
nao sao devidamente documentados, embora sejam planejados
e executados.
Fase 2
Projeto de
Casos de Teste
Nvel 2 PA 2.4

Projeto e Execuo
de Teste

Fase 3
Configurao de
Dados e do
Ambiente de Teste
Nvel 2 PA 2.4

Projeto e Execuo
de Teste

Nvel 2 PA 2.5

SP 2.2 Criar dados de teste especficos


SP 2.3 Especificar procedimento de teste
intake (pr-teste)
SP 2.4 Desenvolver cronograma de
execuo do teste

SG 2
Realizar
implementao do
ambiente de teste

Ambiente de Teste

SP 2.1 Implementar ambiente de teste


SP 2.2 Criar dados de teste genricos
SP 2.3 Especificar procedimento de teste
intake (pr-teste) para o ambiente
de teste
SP 2.4 Realizar o teste intake (pr-teste)
do ambiente de teste

Nvel 3 PA 3.4

SP 1.1 Identificar e priorizar condies


de teste
SG 1
Realizar anlise e
projeto de teste
usando tcnicas
de projeto de teste

SP 2.1 Desenvolver e priorizar os


procedimentos de teste
SG 2
Executar
implementao de
teste

SG 4
Executar
implementao de
teste no funcional

Teste No Funcional

SP 4.1 Desenvolver e priorizar os procedimentos do teste no funcional


SP 4.2 Criar dados de teste especfico

SP 1.2 Identificar e priorizar casos de teste


SP 1.3 Identificar dados de teste
especficos necessrios

Figura 5. Praticas do TMMi relacionadas a` fase de Configuraca o de Dados


e de Ambiente de Teste

SP 1.4 Manter rastreabilidade horizontal


com requisitos
SP 3.1 Identificar e priorizar condies de
testeno funcional

Nvel 3 PA 3.4

Teste No Funcional

SG 3
Realizar anlise e
projeto de teste
no funcional

SP 3.2 Identificar e priorizar casos de teste


SP 3.3 Identificar dados de teste
especficos necessrios
SP 3.4 Manter rastreabilidade horizontal
com requisitos no funcionais

Figura 4.
Teste

Praticas do TMMi relacionadas a` fase de Projeto de Casos de

B. Configuraca o de Dados e de Ambiente de Teste


O ambiente de teste e importante que seja diferente do ambiente de desenvolvimento e que seja semelhante ao ambiente
de produca o. Antes de iniciar os testes e importante deixar
preparado o ambiente. REFERENCIA?? A implementaca o do
ambiente de teste e configuraca o dos dados a serem utilizados
e contemplado no TMMi com praticas relacionadas a criaca o
de dados especficos e genericos, especificaca o de procedimento de pre-teste para o produto e para o ambiente e desenvolvimento de procedimentos de teste nao funcional, alem
da implementaca o em si do ambiente de teste. Como mostra
a figura 5 Essa u ltima pratica foi a u nica classificada como
mandatoria por todos os grupos. As outras seis praticas foram
classificadas como desejaveis pelo todo, TMMi e MPS. Para
o grupo de especialistas a u nica pratica que apresentou um
consenso claro acerca de sua importancia foi a implementaca o
em si do ambiente de teste.
C. Execuca o e Analise
Apos a criaca o dos dados de teste, e do ambiente pronto
para ser utilizado pela equipe de testes, o proximo passo e
realizar a execuca o dos testes planejados. A equipe que foi
alocada executa os casos de teste e como resultado apresenta
uma lista dos defeitos encontrados registrados em relatorio. A
analise visa assegurar que o objetivo do teste foi alcancado
e comunicar os resultados aos interessados [3]. Nesta fase
o TMMi concentra 13 praticas, que estao relacionadas com
execuca o, gerenciamento de incidentes, execuca o do teste nao
funcional e revisao por pares. O resultado da analise do toto
mostra que 4 praticas foram classificadas como mandatorias

e uma foi classificada como desejavel, como mostrado na


figura 6. As praticas classificadas como mandatorias sao
consistentes entre si, ja que tratam da execuca o de casos de
teste (funcional e nao funcional) e do relato dos incidentes
encontrados em ambas execuco es. A pratica classificada como
desejavel foi Testadores revisam documentos da base de teste,
que esta relacionada com a revisao por pares. Sabe-se que
realizar revisao por pares pode ajudar a encontrar falhas
em documentos que comprometem o desenvolvimento do
software.
Fase 4
Execuo e
Avaliao do
teste

SP 3.1 Realizar teste intake (pr-teste)


SG 3
Realizar execuo
de teste

SP 3.3 Relatar incidentes de teste


SP 3.4 Escrever log de teste

Nvel 2 PA 2.4

Projeto e Execuo
de Teste

SP 3.2 Executar casos de teste

SG 4
Gerenciar incidentes
de teste para
encerramento

SP 4.1 Decidir sobre incidentes com o


grupo de controle de configurao
SP 4.2 Executar aes apropriadas para
corrigir os incidentes de teste
SP 4.3 Acompanhar o status dos
incidentes de teste

Nvel 3 PA 3.4

SG 5
Realizar execuo
de teste no funcional

SP 5.1 Executar casos de teste no


funcional
SP 5.2 Relatar incidentes de teste

Teste No Funcional

SP 5.3 Escrever log de teste

Nvel 3 PA 3.5

Reviso por Pares

SG 2
Realizar revises
por pares

SP 2.1 Conduzir revises por pares


SP 2.2 Testadores revisam os
documentos da base de teste
SP 2.3 Analisar dados de reviso por pares

Figura 6.

Praticas do TMMi relacionadas a` fase de Execuca o e Analise

D. Monitoramento e Controle
Durante todo o processo de teste e importante acompanhar o
andamento do projeto sempre observando o que foi planejado,
o que e esperado e a qualidade do que esta sendo feito. Pode-se
observar na figura 7 que essa fase possui 21 praticas, das
quais quatro foram classificadas como mandatorias e quatro

como desejaveis. As praticas mandatorias estao relacionadas


ao acompanhamento dos defeitos encontrados na fase de
execuca o, a tomada de aca o corretiva para sanar esses defeitos
e ao gerenciamento dessa aca o corretiva, para acompanhar
que o defeito foi realmente solucionado. Essas praticas foram
classificadas como mandatorias por todos os grupos. Relatar
incidentes do ambiente de teste aparece como mandatoria para
o todo e para Perfil-Especialista. As praticas classificadas
como desejaveis estao relacionadas ao acompanhamento da
execuca o em relaca o ao que foi planejado e ao que e esperado.
Vale ressaltar que monitorar os riscos do projeto esta entre
essas praticas desejaveis apesar de a identificaca o desses
riscos de projeto nao aparecer em nenhum dos resultados
diretamente. Porem, segundo a norma IEEE829 IEE [10] o
plano de teste deve conter os riscos que podem impactar no
sucesso do projeto. Como as praticas de monitoramento estao
relacionadas ao acompanhamento de todo o projeto, fica claro
que essa identificaca o de riscos de projeto esta implcita.
SP 1.1 Monitorar parmetros do
planejamento de teste

Fase 5
Monitoramento
e Controle

SG 1
Monitorar progresso
do teste em relao
ao plano

SP 1.2 Monitorar recursos do ambiente de


teste disponibilizados e os utilizados
em relao ao plano
SP 1.3 Monitorar compromissos de teste
SP 1.4 Monitorar riscos do projeto de teste
SP 1.5 Monitorar envolvimento dos
interessados
SP 1.6 Conduzir revises do progresso
de teste
SP 1.7 Conduzir revises em marcos do
progresso do teste
SP 2.1 Verificar em relao aos critrios
de entrada

Nvel 2 PA 2.3

Monitoramento e
Controle de Teste

SG 2
Monitorar a
qualidade do produto
em relao ao
plano e expectativas

SP 2.2 Monitorar defeitos


SP 2.3 Monitorar riscos do produto
SP 2.4 Monitorar critrios de parada
SP 2.5 Monitorar critrios de suspenso e
recomeo
SP 2.6 Conduzir revises de qualidade
do produto
SP 2.7 Conduzir revises de marcos da
qualidade do produto

SG 3
Gerenciar aes
corretivas para
encerramento

SP 3.1 Analisar problemas


SP 3.2 Tomar ao corretiva
SP 3.3 Gerenciar ao corretiva

Nvel 2 PA 2.5

Ambiente de Teste

SG 3
Gerenciar e controlar
os ambientes de teste

SP 3.1 Realizar o gerenciamento


dos sistemas
SP 3.2 Realizar o gerenciamento dos
dados de teste
SP 3.3 Coordenar a disponibilidade e o
uso dos ambientes de teste
SP 3.4 Relatar e gerenciar incidentes do
ambiente de teste

Figura 7. Praticas do TMMi relacionadas a` fase de Monitoramento e controle

As praticas em destaque nas figuras 3, 4, 5, 6 e 7 mostram


que ha 31 praticas que foram identificadas como mandatorias
ou desejaveis, com significancia estatstica. Portanto o TMMi
pode ser reduzido em 31 praticas que cumprem todas as
etapas de um processo de teste generico. Isso nao significa

que as outas 50 praticas sao descartaveis, apenas que, para


empresas de pequeno porte, que queriam se utilizar desse
framework para criar um processo de teste ela nao necessita
obrigatoriamente utilizar todas as praticas e objetivos. Eles
podem ser agrupados de forma concisa e ainda assim ter um
processo completo contemplando todas as fases.
V. C ONCLUSIONS AND F UTURE W ORK
Conclusion...
R EFER E NCIAS
[1] C. Wohlin, Experimentation in software engineering: an introduction. Springer, 2000.
[2] A. N. Crespo, M. Jino, M. Argollo, P. M. S. Bueno, and
C. P. Barros, Modelo de processo generico de teste de software. portal do software publico brasileiro 5cqualibr, Online, 2010, http://www.softwarepublico.gov.br/5cqualibr/xowiki/
Teste-item13 - acessado em 27/03/2012.
[3] A. M. J. Hass, Testing processes, in IEEE International
Conference on Software Testing Verification and Validation
Workshop, 2008. ICSTW 08. IEEE, Apr. 2008, pp. 321327.
[4] E. N. Hohn, Kitest: Um arcabouco de conhecimento e melhoria
de processo de teste, Ph.D. dissertation, Instituto de Ciencias
Matematicas e de Computaca o, Universidade de Sao Paulo, Sao
Carlos, SP - Brazil, Jun. 2011.
[5] W. J. Dixon and A. M. Mood, The statistical sign test,
Journal of the American Statistical Association, vol. 41, no.
236, pp. 557566, Dec. 1946, ArticleType: research-article /
Full publication date: Dec., 1946 / Copyright1946 American
Statistical Association. [Online]. Available: http://www.jstor.
org/stable/2280577
[6] E. Whitley and J. Ball, Statistics review 6: Nonparametric
methods, Critical Care, vol. 6, no. 6, p. 509, Sep. 2002.
[7] J. Miller, Statistical significance testinga panacea for software
technology experiments? Journal of Systems and Software,
vol. 73, no. 2, pp. 183192, 2004.
[8] V. Basili and R. Reiter, A controlled experiment quantitatively
comparing software development approaches, IEEE Transactions on Software Engineering, vol. SE-7, no. 3, pp. 299320,
May 1981.
[9] Softex, Melhoria de Processo do Software Brasileiro - Guia
Geral, Associaca o para promoca o da excelencia do software
brasileiro, 2011.
[10] IEEE standard glossary of software engineering terminology,
IEEE Std 610.12-1990, p. 1, 1990.