Usando o MPS.

BR para amadurecimento das equipes de teste de software

Autor: Emerson Rios
Resumo
Os mtodos usados para testar software evoluram medida que os sistemas tornaram-se
maiores, mais complexos e destinados a variados ambientes. Os testes passaram a ser
executados por equipes especializadas e as empresas criaram reas dentro da sua estrutura
organizacional para cumprir esse papel. Passamos a ter projetos e processos de teste, que
como tal so passveis de melhorias. H diversos modelos de maturidade de teste,
entretanto o autor os considera desnecessrios, propondo que seja utilizado o MPS.BR
como modelo de maturidade e explicando como cada processo se aplica em uma unidade de
teste de software.
Introduo
At a dcada de 90, quase todas as empresas ou organizaes que desenvolviam software
tratavam o teste como uma atividade inserida no ciclo de vida do desenvolvimento. Quando
o software terminava a etapa de construo ele passava para a etapa de teste. Os testes eram
executados pelos desenvolvedores e em algumas situaes pelos usurios. Os primeiros
faziam o que atualmente chamamos de teste unitrio e teste de integrao e os segundos
executavam o teste de aceitao. Os desenvolvedores testavam se a aplicao estava
funcionando e os usurios se ela atendia aos seus requisitos. Esse modelo servia
adequadamente, mesmo com ressalvas, desde que os primeiros computadores foram
instalados. O advento da Internet e das aplicaes para ambiente web, tornaram os
softwares complicados e difceis de serem testados. Uma aplicao pode envolver centenas
ou at milhares de componentes, alm de ter que funcionar em diversos ambientes, muitos
deles completamente heterogneos. Os desenvolvedores e os usurios no conseguiam mais
garantir que uma aplicao tinha sido suficientemente testada para ser liberada para a
produo. Alguns defeitos passaram a aparecer quando as aplicaes estavam em produo,
justamente quando a sua correo mais cara. Os custos de manuteno aumentaram e a
qualidade caiu a nveis inferiores ao das dcadas anteriores. O escopo dos problemas
causados pelos defeitos deixou de ser restrito ao ambiente da empresa e envolvia o prprio
negcio da empresa.
Apesar desta realidade ainda permanecer na maioria das empresas at os dias atuais, foi em
1979 que Glenford Myers publicou aquele que atualmente ainda considerado um dos
melhores livros de teste de software existentes no mercado, sob o ttulo de The Art of
Software Testing (publicado por John Wiley and Sons Inc. em edio revisada em 2004).
Este livro continua sendo a bblia de muitos dos testadores do sculo 21. Myers
basicamente lembrava que testar era procurar defeitos e no provar que o software estava
funcionando. Com isso estava quebrando um paradigma que j existia e continuaria a
existir durante muitos anos.
Um artigo publicado na revista Communications of the ACM sob o ttulo The Growth of
Software Testing (Gelperin, D. and B. Hetzel. The Growth of Software Testing. Communications of the ACM 31 (June 1988): 687-95), escrito por David Gelperin e Bill

Hetzel, descrevia um processo de evoluo dos testes e lanava um documento que chamou
de Plano de Testes. Esse documento, base de todas as metodologias de teste que usamos
hoje em dia, segundo o artigo citado, deveria ser escrito a partir dos requisitos do sistema e
por si s j ajudava a reduzir a quantidade de defeitos dos sistemas, dando aos testadores os
objetivos a serem alcanados durante a atividade de teste. Isso nos leva a uma concluso
bvia, que reporta existncia do documento Plano de Testes h mais de 20 (vinte) anos,
ainda que a popularizao do seu uso seja mais recente.
Embora desde a dcada de 70, como vimos nos pargrafos anteriores, j existissem
trabalhos mostrando que o teste precisava ser re-estruturado, essa mudana s comeou a
ocorrer de fato no final da dcada de 90. Decidiu-se ento tratar o teste de software no
mais como uma atividade do processo de desenvolvimento, mas sim como um processo
independente. Desta forma o teste passaria a ser executado por uma equipe de especialistas
com o objetivo de diminuir o nmero de defeitos que estavam sendo passados para a
produo. Essa soluo vem sendo gradativamente adotada pelas empresas, com os
resultados esperados, qual seja, softwares com ndices de qualidade melhores. No entanto
essa mudana organizacional inesperada, e ainda no completamente absorvida, trouxe
tambm novos problemas a serem tratados. No adianta apenas testar, mas sim testar bem.
Os custos podem cair na etapa final, mas inicialmente os investimentos so maiores. Se a
rea de teste no estiver bem organizada os defeitos vo continuar a ocorrer num estgio
onde os custos so maiores. Cogitou-se ento em modelos que permitissem rea de teste
de software atingir nveis de maturidade, melhorando, desta forma, os resultados esperados.
A lgica passou a ser a seguinte, alm de implantar a rea de teste de software, que por si
s trar resultados imediatos, ainda vamos criar um processo de melhoria contnua, com
resultados cada vez melhores.
Os modelos de maturidade de teste de software
Ao mesmo tempo em que se comeava a implantar as reas de teste nas empresas, os
especialistas j se preocupavam com os modelos que permitissem a sua melhoria. Data da
dcada de 1990 os primeiros modelos de maturidade de teste. O que interessante, pois
talvez 80% ou mais das empresas que desenvolviam software, ainda no trabalhavam com
equipes especialistas em teste de software. Atualmente existe uma verdadeira sopa de
letrinhas envolvendo esses modelos de maturidade de teste de software conforme listado
adiante:

Testability Suport Model (TSM)

Testing Maturity Model (TMM)
Test Process Improvement (TPI)
Test Organization Maturity (TOMtm)
Testing Assessement Program (TAP)
Testing Improvement Model (TIM)

Alguns desses modelos partiram do CMM e depois foram adaptados ao CMMI, porm
apesar desse pressuposto, possuem atualmente, pouca ou nenhuma ligao com eles. Se
tomarmos como exemplo o TMM, cuja base original o CMM, mas a equivalncia hoje
muito pequena. Ou seja, ficaram a separao por estgios e talvez nada mais.

Nveis do TMM
1

Descrio
Inicial

Fase de definio

Integrao

Gesto e medies

Otimizao, preveno de defeitos e

controle de qualidade
Tabela 1

Por que no usarmos o MPS.BR ou o CMMI

A busca por modelos alternativos surgiu porque os tcnicos entenderam que modelos
pesados como o CMMI no serviam para a rea de teste em razo de o seu tamanho ser
muito menor do que o da rea de desenvolvimento. O MPS.BR surgiu no Brasil para
atender as empresas desenvolvedoras de software com uma estrutura menor. O que vamos
mostrar neste documento que no h necessidade de buscar um modelo alternativo para
testes, pois eles tero um grande problema para se impor no mercado, principalmente
devido a grande quantidade de modelos que foram surgindo no decorrer dos anos. A melhor
soluo usar o prprio modelo adotado pelas reas de desenvolvimento de software.
Quando uma empresa alcana o nvel G, por exemplo, a rea de teste poder atender aos
processos de gerncia de projetos e gerncia de requisitos. Ou seja, a rea de teste tambm
poderia ser credenciada nesse nvel, desde que tambm mostrasse as evidncias de que
estaria usando esses dois processos. Alguma dificuldade poderia surgir nos momentos em
que a rea de teste resolvesse buscar um nvel acima da rea de desenvolvimento, e isso
ser discutido neste documento.
Para facilitar o entendimento vamos analisar cada um dos nveis do MPS.BR e mostrar
como a rea de teste poderia tambm ser implementada no mesmo nvel,
independentemente da rea de desenvolvimento estar ou no nesse nvel. Evidentemente, se
ambas caminharem juntas, o custo da preparao ser muito menor.
Nvel G
O nvel G exige as seguintes reas de processo:
Gerncia de Projetos
Gerncia de Requisitos
Se tratarmos o projeto de teste como um projeto paralelo e integrado ao projeto de
desenvolvimento, no difcil entender que ambos podero se sustentar num processo de
gerncia de projetos, que poderia ser nico para os dois ou poderia ser separado, devido a
algumas sutilezas. A adaptao surgiria em funo da diferena entre os documentos
adotados nos dois projetos, mas isso ainda no assunto para esse artigo.

Os mesmos requisitos que servem para desenvolver o software tambm servem para criar
os artefatos de teste, inclusive com uma ressalva, pois muitas empresas ainda produzem
requisitos de teste a partir dos requisitos do usurio. Devemos aceitar que a rea de teste
precisa de uma gerncia de requisitos.
Nvel F
O nvel F exige as seguintes reas de processo:
Aquisio
Gerncia de Configurao
Gerncia de Qualidade
Medio
A rea de processo de Aquisio com toda certeza pode ser usada pela rea de teste pois os
seus projetos envolvem aquisies, principalmente na parte de automao especfica. De
qualquer forma essa tambm no uma rea obrigatria.
Cada projeto de teste de software produz inmeros artefatos, tais como Planos de Teste,
Procedimentos de Teste, Casos de Teste e diversos Relatrios de Teste. Nunca demais
lembrar que os casos de teste podem chegar aos milhares num nico projeto, e, alm disso,
devem ser passveis de reastreabilidade a partir do requisito. No temos nenhuma dvida
que a gerncia de configurao deve contemplar a rea de teste.
Usando o prprio manual de implementao do MPS.BR encontramos a seguinte
afirmativa:
O propsito do processo Garantia da Qualidade assegurar que os produtos de trabalho e
a execuo dos processos estejam em conformidade com os planos e recursos
predefinidos.
No existe uma distino sobre quem est cumprindo os processos mas sim se os processos
esto sendo cumpridos, o que nos leva a concluir que essa rea tambm atende aos projetos
de teste de software.
Um processo como o de teste de software, que produz importantes indicadores de
qualidade, no poderia deixar de contemplar a rea de medio. Para citarmos o exemplo
mais bvio, temos o nmero de defeitos encontrados num projeto de teste de software, que
pode ser categorizado de diversas formas, tornando-se um indicador crtico no processo de
tomada de decises.
Nivel E
O nvel E exige as seguintes reas de processo:
Gerncia de Projetos
Avaliao e Melhoria do Processo Organizacional
Definio do Processo Organizacional

 Gerncia de Recursos Humanos

Gerncia de Reutilizao
A rea de processo de gerncia de projetos j foi discutida no nvel G e mesmo no seu
estgio elevado continua sendo importante para os projetos de teste de software. No vemos
grande distino entre um projeto de desenvolvimento de software e um projeto de teste de
software, que no aquela relacionada com o tamanho e com os artefatos produzidos. Os
ciclos de vida so semelhantes e devem estar integrados.
As reas de processo de Avaliao e Melhoria do Processo Organizacional e Definio do
Processo Organizacional tratam de processos e no vemos nenhum problema na sua
implementao na rea de testes.
Vamos usar a definio encontrada no prprio manual de implementao do MPS.BR:
O propsito do processo Gerncia de Recursos Humanos prover a organizao e os
projetos com os recursos humanos necessrios e manter suas competncias consistentes
com as necessidades do negcio.
No temos mais nada a acrescentar para justificar a sua existncia no apoio aos projetos de
teste de software.
Sabemos que um ativo reutilizvel qualquer artefato relacionado a software que esteja
preparado ou empacotado para ser reutilizado pelos processos da organizao. A definio
bastante abrangente para cobrir tambm os artefatos criados pelos projetos de teste de
software. Um bom exemplo para isso a possibilidade de criarmos um banco de Caso de Teste
(Validao de CPF, Campos Obrigatrios, Validao de data e etc..) para reutilizao em outro
projeto.

Nivel D
O nvel D exige as seguintes reas de processo:
Desenvolvimento de Requisitos
Integrao de Produto
Projeto e Construo do Produto
Validao
Verificao
Este talvez seja o nvel mais difcil de ser entendido pela rea de teste de software, pois
possui algumas sutilezas que iremos discutir adiante. No h dvida que a rea de
Desenvolvimento de Requisitos importante tambm para os projetos de teste de software.
A elicitao dos requisitos de teste, aqueles que sero usados na elaborao dos testes, um
trabalho que com toda certeza vai envolver a gerncia e o desenvolvimento dos requisitos.
Por outro lado, convm lembrar que a mesma rea de processo poder suportar os projetos
de desenvolvimento e os projetos de teste de software, e que, muitas vezes, uma
caracterizao mais especfica dos requisitos dever ser utilizada.

A rea de processo de Integrao de Produto est muito ligada ao processo de teste de

software. Na maioria das vezes, o teste necessrio para que a integrao seja bem
sucedida. O mesmo ocorre com Validao e Verificao. Essas reas se confundem com a
prpria rea de testes.. A justificativa dessas reas a existncia da prpria rea de teste de
software. A integrao do produto est garantida pela realizao dos testes de integrao.
Os nveis de teste so caracterizados pelos seguintes testes: unitrio, integrao, sistema e
aceitao. Desde que existam evidncias que a equipe de teste executou testes de
integrao, a rea de processo Integrao de Produto se justifica. importante frisar que os
testes de sistema representam numa escala mais detalhada os testes unitrios e de
integrao. Alm disso, podemos citar as interdependncias dos Casos de Teste, e a sua
necessidade de integrao para a criao das Sutes de execuo.
A rea de Projeto e Construo do Produto est diretamente ligada ao desenvolvimento e
implementao de solues para atender aos requisitos. Tanto o processo de
desenvolvimento quanto o processo de teste de software usam os mesmos requisitos. O
ciclo de vida do projeto de teste de software envolve as seguintes etapas: planejamento,
projeto, execuo, finalizao. Dentro do projeto so elaborados os procedimentos de teste
e os casos de teste. No caso de projetos de teste de software, existem alguns tipos de teste
que precisam ter um tratamento especial. Por exemplo, os testes de performance podero
envolver a escolha de ferramentas de automao e, conseqentemente, a elaborao de um
sub-projeto especfico para a sua aquisio, se for o caso. Em suma, baseado nos requisitos
necessrio escolher uma soluo adequada para aquele projeto de teste especfico. Para
facilitar o entendimento precisamos considerar que o produto da rea de teste o Servio
de Teste.
As reas de processo Validao e Verificao so aquelas dentro do contexto do prprio
objetivo da rea de teste. Verificao cobre os testes unitrios, de integrao e de sistemas.
Validao cobre os testes de aceitao. Neste ltimo caso importante evidenciar que a
equipe de testes participa tambm dos testes de aceitao. Lembramos tambm que o teste
de sistema repete tambm o teste de integrao executado com um nvel de detalhes maior.
Alm disso temos o contexto das inspees e revises que so feitas pela equipe de teste de
software nos seus prprios artefatos ou nos artefatos criados pela equipe de
desenvolvimento.
Nivel C
O nvel C exige as seguintes reas de processo:
Gerncia de Reutilizao
Anlise de Deciso e Resoluo
Desenvolvimento para Reutilizao
Gerncia de Riscos
Os processos de Gerncia de Reutilizao e Desenvolvimento para Reutilizao so reas
correlatas e no temos nenhuma dvida quanto sua importncia para a rea de teste de
software. O mesmo podemos dizer da Gerncia de Riscos, visto que estamos tratando o
teste de software como um projeto e todo projeto precisa de uma anlise de riscos.

A rea de Anlise de Deciso e Resoluo com toda certeza tambm necessria para um
projeto de teste de software. Testar software uma atividade que envolve tomada de
decises e conseqentemente a avaliao de alternativas. Por exemplo, qual a ferramenta
mais adequada para a execuo de um determinado tipo de teste? O teste pode ser feito
manualmente ou melhor automatiz-lo? Qual o melhor ambiente para aquele tipo de
teste? Tudo isso so decises que requerem avaliar alternativas de soluo.
Nivel B
O nvel B exige as seguintes reas de processo:
Gerncia de Projetos (evoluo)
Como j falamos anteriormente estamos tratando de um projeto de teste de software,
paralelo e aderente ao projeto de desenvolvimento do software.
Nivel A
O nvel A exige as seguintes reas de processo:
Anlise de Causa de Problemas e Resoluo
A rea de processo Anlise de Causa de Problemas e Resoluo se fundamenta na
identificao da causa de variaes de desempenho do processo com o intuito de serem
tomadas aes que diminuam a sua ocorrncia no futuro. Como estamos tratando do
processo de teste de software este o contexto da melhoria de desempenho e no vimos
nenhuma restrio quanto a sua aplicao nesse processo.
Concluses
De todas as reas de processo avaliadas e estudadas apenas trs delas poderiam gerar algum
tipo de discusso quanto a sua aplicabilidade rea de teste de software que so as
seguintes:
Integrao de Produto
Validao
Verificao
Todas as outras reas so perfeitamente aplicveis quando consideramos um projeto de
teste de software conduzido por uma equipe independente de teste de software. Neste
artigo mostramos que algumas reas poderiam ser compartilhadas pelos dois processos
(desenvolvimento e teste) ou projetos, como foi o caso, por exemplo, de Gerncia de
Riscos, Garantia da Qualidade ou Gerncia de Configurao. Em resumo podemos, de
forma genrica, afirmar que quando consideramos o Teste de Software como um projeto
que est baseado num processo, fica fcil entender que a maior parte das reas de processo
perfeitamente aplicada a rea em questo.
A rea de processo Integrao do Produto coberta pelos testes de sistema e pelos testes de
integrao. O que conhecemos como Procedimento de Teste ou Roteiro de Teste representa
a execuo de um conjunto de Casos de Teste de forma integrada para verificar um

requisito ou uma funcionalidade ou um cenrio de teste. No caso das reas de processo

Validao e Verificao temos uma coincidncia com a prpria atividade fim da rea de
teste. O que falta caracterizar so quais tipos de teste ficariam dentro de cada uma das
reas, dentro dos inmeros que so executados pela rea de teste. Sabemos que teste de
aceitao caracterizado como da rea de processo Validao. Os testes unitrios, testes de
integrao e testes de sistema esto dentro da rea de processo Verificao, assim como
inspees e revises tcnicas. De qualquer forma buscar essas evidncias vai fazer parte de
um trabalho mais completo que nos propomos a publicar oportunamente. No vamos
discutir agora o que seriam, por exemplo, as evidncias diretas ou indiretas.
A concluso deste trabalho que reas de teste de software, a exemplo das reas de
desenvolvimento, podem evoluir de acordo com um modelo de maturidade do tipo do
MPS.BR. As primeiras evidncias mostram que, de uma forma genrica, a aplicao do
MPS.BR numa rea de teste de software produzir resultados semelhantes queles que
encontramos durante a sua aplicao em reas de desenvolvimento. O passo seguinte desse
trabalho ser definir um modelo de maturidade de teste de software inteiramente baseado
no MPS.BR. Isso nos trar uma posio de vanguarda no mundo, j que no existe nenhum
modelo semelhante. Existem sim modelos especficos para teste de software, e o que
estamos propondo o compartilhamento do mesmo modelo. Uma parceria da ALATS
Associao Latino Americana de Teste de Software com a Softex ou outra instituio seria
um importante passo para definir esse modelo, que inicialmente estamos denominando
MPT.BR. A continuidade desse trabalho ser definir os atributos, resultados esperados e
evidncias, o que esperamos levar adiante durante o prximo ano. Inicialmente dever ser
publicada o nvel G do MPT.BR

Bibliografia:
Rios, E. & Moreira T. Teste de Software. Rio de Janeiro, AltaBooks, 2006.
Institute of Electrical and Electronics Engineers, IEEE Std 829, Standard for Software
Testing Documentation, Nova Iorque, IEEE Computer Society, 1998.
Rios, E. Anlise de Riscos em Projetos de Teste de Software, Rio de Janeiro, AltaBooks,
2005.
Pol M, Teunissem R, Veenendaal E. Van. Software Testing: A guide to the TMap
Approach. Boston, Addison Wesley, 2002.
Softex. MPS.BR Melhoria de Processo do Software Brasileiro Guia de Implementao.
Braslia. 2007.