Usando o MPS.

BR para amadurecimento das equipes de teste de software

Autor: Emerson Rios
Explicação inicial: Este trabalho foi escrito em novembro de 2007 para ser apresentado
num dos seminários de implementadores de MPS.BR promovido pela Softex. Na ocasião o
trabalho foi classificado como muito bom, mas acharam que não era adequado para um
evento focado em processos de software. Este documento, que passou pela avaliação de
inúmeros técnicos em MPS.BR e CMMI, sem nenhuma restrição séria quanto a sua
proposta, serviu depois de base para o desenvolvimento modelo MPT que está no momento
sendo usado no Brasil.

Resumo
Os métodos usados para testar software evoluíram à 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 são passíveis de melhorias. Há diversos modelos de maturidade de teste,
entretanto o autor os considera desnecessários, 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.

Introdução
Até a década de 90, quase todas as empresas ou organizações que desenvolviam software
tratavam o teste como uma atividade inserida no ciclo de vida do desenvolvimento. Quando
o software terminava a etapa de construção ele passava para a etapa de teste. Os testes eram
executados pelos desenvolvedores e em algumas situações pelos usuários. Os primeiros
faziam o que atualmente chamamos de teste unitário e teste de integração e os segundos
executavam o teste de aceitação. Os desenvolvedores testavam se a aplicação estava
funcionando e os usuários 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 aplicações para ambiente web, tornaram os
softwares complicados e difíceis de serem testados. Uma aplicação pode envolver centenas
ou até milhares de componentes, além de ter que funcionar em diversos ambientes, muitos
deles completamente heterogêneos. Os desenvolvedores e os usuários não conseguiam mais
garantir que uma aplicação tinha sido suficientemente testada para ser liberada para a
produção. Alguns defeitos passaram a aparecer quando as aplicações estavam em produção,
justamente quando a sua correção é mais cara. Os custos de manutenção aumentaram e a
qualidade caiu a níveis inferiores ao das décadas anteriores. O escopo dos problemas
causados pelos defeitos deixou de ser restrito ao ambiente da empresa e envolvia o próprio
negócio 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 título de “The Art of
Software Testing” (publicado por John Wiley and Sons Inc. em edição revisada em 2004).
Este livro continua sendo a bíblia de muitos dos testadores do século 21. Myers
basicamente lembrava que testar era procurar defeitos e não 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 título “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 evolução dos testes e lançava 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 alcançados durante a atividade de teste. Isso nos leva a uma conclusão
óbvia, que reporta à existência do documento Plano de Testes há mais de 20 (vinte) anos,
ainda que a popularização do seu uso seja mais recente.
Embora desde a década de 70, como vimos nos parágrafos anteriores, já existissem
trabalhos mostrando que o teste precisava ser re-estruturado, essa mudança só começou a
ocorrer de fato no final da década de 90. Decidiu-se então tratar o teste de software não
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 número de defeitos que estavam sendo passados para a
produção. Essa solução vem sendo gradativamente adotada pelas empresas, com os
resultados esperados, qual seja, softwares com índices de qualidade melhores. No entanto
essa mudança organizacional inesperada, e ainda não completamente absorvida, trouxe
também novos problemas a serem tratados. Não adianta apenas testar, mas sim testar bem.
Os custos podem cair na etapa final, mas inicialmente os investimentos são maiores. Se a
área de teste não estiver bem organizada os defeitos vão continuar a ocorrer num estágio
onde os custos são maiores. Cogitou-se então em modelos que permitissem à área de teste
de software atingir níveis de maturidade, melhorando, desta forma, os resultados esperados.
A lógica passou a ser a seguinte, além de implantar a área de teste de software, que por si
só trará resultados imediatos, ainda vamos criar um processo de melhoria contínua, com
resultados cada vez melhores.

Os modelos de maturidade de teste de software

Ao mesmo tempo em que se começava a implantar as áreas de teste nas empresas, os
especialistas já se preocupavam com os modelos que permitissem a sua melhoria. Data da
década de 1990 os primeiros modelos de maturidade de teste. O que é interessante, pois
talvez 80% ou mais das empresas que desenvolviam software, ainda não 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, porém
apesar desse pressuposto, possuem atualmente, pouca ou nenhuma ligação com eles. Se
tomarmos como exemplo o TMM, cuja base original é o CMM, mas a equivalência é hoje
muito pequena. Ou seja, ficaram a separação por estágios e talvez nada mais.

Níveis do TMM Descrição

1 Inicial

2 Fase de definição

3 Integração

4 Gestão e medições

5 Otimização, prevenção de defeitos e

controle de qualidade

Tabela 1

Por que não usarmos o MPS.BR ou o CMMI

A busca por modelos alternativos surgiu porque os técnicos entenderam que modelos
pesados como o CMMI não serviam para a área de teste em razão 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 não há necessidade de buscar um modelo alternativo para
testes, pois eles terão um grande problema para se impor no mercado, principalmente
devido a grande quantidade de modelos que foram surgindo no decorrer dos anos. A melhor
solução é usar o próprio modelo adotado pelas áreas de desenvolvimento de software.
Quando uma empresa alcança o nível G, por exemplo, a área de teste poderá atender aos
processos de gerência de projetos e gerência de requisitos. Ou seja, a área de teste também
poderia ser credenciada nesse nível, desde que também mostrasse as evidências de que
estaria usando esses dois processos. Alguma dificuldade poderia surgir nos momentos em
que a área de teste resolvesse buscar um nível acima da área de desenvolvimento, e isso
será discutido neste documento.

Para facilitar o entendimento vamos analisar cada um dos níveis do MPS.BR e mostrar
como a área de teste poderia também ser implementada no mesmo nível,
independentemente da área de desenvolvimento estar ou não nesse nível. Evidentemente, se
ambas caminharem juntas, o custo da preparação será muito menor.

Nível G

O nível G exige as seguintes áreas de processo:

  Gerência de Projetos
 Gerência de Requisitos
Se tratarmos o projeto de teste como um projeto paralelo e integrado ao projeto de
desenvolvimento, não é difícil entender que ambos poderão se sustentar num processo de
gerência de projetos, que poderia ser único para os dois ou poderia ser separado, devido a
algumas sutilezas. A adaptação surgiria em função da diferença entre os documentos
adotados nos dois projetos, mas isso ainda não é assunto para esse artigo.

Os mesmos requisitos que servem para desenvolver o software também servem para criar
os artefatos de teste, inclusive com uma ressalva, pois muitas empresas ainda produzem
requisitos de teste a partir dos requisitos do usuário. Devemos aceitar que a área de teste
precisa de uma gerência de requisitos.

Nível F

O nível F exige as seguintes áreas de processo:

 Aquisição
 Gerência de Configuração
 Gerência de Qualidade
 Medição

A área de processo de Aquisição com toda certeza pode ser usada pela área de teste pois os
seus projetos envolvem aquisições, principalmente na parte de automação específica. De
qualquer forma essa também não é uma área obrigatória.

Cada projeto de teste de software produz inúmeros artefatos, tais como Planos de Teste,
Procedimentos de Teste, Casos de Teste e diversos Relatórios de Teste. Nunca é demais
lembrar que os casos de teste podem chegar aos milhares num único projeto, e, além disso,
devem ser passíveis de reastreabilidade a partir do requisito. Não temos nenhuma dúvida
que a gerência de configuração deve contemplar a área de teste.

Usando o próprio manual de implementação do MPS.BR encontramos a seguinte

afirmativa:
“O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e
a execução dos processos estejam em conformidade com os planos e recursos
predefinidos.”

Não existe uma distinção sobre quem está cumprindo os processos mas sim se os processos
estão sendo cumpridos, o que nos leva a concluir que essa área também atende aos projetos
de teste de software.

Um processo como o de teste de software, que produz importantes indicadores de

qualidade, não poderia deixar de contemplar a área de medição. Para citarmos o exemplo
mais óbvio, temos o número de defeitos encontrados num projeto de teste de software, que
pode ser categorizado de diversas formas, tornando-se um indicador crítico no processo de
tomada de decisões.
Nivel E

O nível E exige as seguintes áreas de processo:

 Gerência de Projetos
 Avaliação e Melhoria do Processo Organizacional
 Definição do Processo Organizacional
 Gerência de Recursos Humanos
 Gerência de Reutilização

A área de processo de gerência de projetos já foi discutida no nível G e mesmo no seu

estágio elevado continua sendo importante para os projetos de teste de software. Não vemos
grande distinção entre um projeto de desenvolvimento de software e um projeto de teste de
software, que não aquela relacionada com o tamanho e com os artefatos produzidos. Os
ciclos de vida são semelhantes e devem estar integrados.

As áreas de processo de Avaliação e Melhoria do Processo Organizacional e Definição do

Processo Organizacional tratam de processos e não vemos nenhum problema na sua
implementação na área de testes.

Vamos usar a definição encontrada no próprio manual de implementação do MPS.BR:

“O propósito do processo Gerência de Recursos Humanos é prover a organização e os
projetos com os recursos humanos necessários e manter suas competências consistentes
com as necessidades do negócio.”
Não temos mais nada a acrescentar para justificar a sua existência no apoio aos projetos de
teste de software.

Sabemos que um ativo reutilizável é qualquer artefato relacionado a software que esteja
preparado ou empacotado para ser reutilizado pelos processos da organização. A definição
é bastante abrangente para cobrir também os artefatos criados pelos projetos de teste de
software. Um bom exemplo para isso é a possibilidade de criarmos um banco de Caso de Teste
(Validação de CPF, Campos Obrigatórios, Validação de data e etc..) para reutilização em outro
projeto.

Nivel D

O nível D exige as seguintes áreas de processo:

 Desenvolvimento de Requisitos
 Integração de Produto
 Projeto e Construção do Produto
 Validação
 Verificação

Este talvez seja o nível mais difícil de ser entendido pela área de teste de software, pois
possui algumas sutilezas que iremos discutir adiante. Não há dúvida que a área de
Desenvolvimento de Requisitos é importante também para os projetos de teste de software.
A elicitação dos requisitos de teste, aqueles que serão usados na elaboração dos testes, é um
trabalho que com toda certeza vai envolver a gerência e o desenvolvimento dos requisitos.
Por outro lado, convém 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
caracterização mais específica dos requisitos deverá ser utilizada.

A área de processo de Integração de Produto está muito ligada ao processo de teste de

software. Na maioria das vezes, o teste é necessário para que a integração seja bem
sucedida. O mesmo ocorre com Validação e Verificação. Essas áreas se confundem com a
própria área de testes.. A justificativa dessas áreas é a existência da própria área de teste de
software. A integração do produto está garantida pela realização dos testes de integração.
Os níveis de teste são caracterizados pelos seguintes testes: unitário, integração, sistema e
aceitação. Desde que existam evidências que a equipe de teste executou testes de
integração, a área de processo Integração de Produto se justifica. É importante frisar que os
testes de sistema representam numa escala mais detalhada os testes unitários e de
integração. Além disso, podemos citar as interdependências dos Casos de Teste, e a sua
necessidade de integração para a criação das Suítes de execução.

A área de Projeto e Construção do Produto está diretamente ligada ao desenvolvimento e

implementação de soluções 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, execução, finalização. Dentro do projeto são 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 poderão
envolver a escolha de ferramentas de automação e, conseqüentemente, a elaboração de um
sub-projeto específico para a sua aquisição, se for o caso. Em suma, baseado nos requisitos
é necessário escolher uma solução adequada para aquele projeto de teste específico. Para
facilitar o entendimento precisamos considerar que o produto da área de teste é o Serviço
de Teste.

As áreas de processo Validação e Verificação são aquelas dentro do contexto do próprio

objetivo da área de teste. Verificação cobre os testes unitários, de integração e de sistemas.
Validação cobre os testes de aceitação. Neste último caso é importante evidenciar que a
equipe de testes participa também dos testes de aceitação. Lembramos também que o teste
de sistema repete também o teste de integração executado com um nível de detalhes maior.
Além disso temos o contexto das inspeções e revisões que são feitas pela equipe de teste de
software nos seus próprios artefatos ou nos artefatos criados pela equipe de
desenvolvimento.

Nivel C

O nível C exige as seguintes áreas de processo:

 Gerência de Reutilização
 Análise de Decisão e Resolução
  Desenvolvimento para Reutilização
 Gerência de Riscos
Os processos de Gerência de Reutilização e Desenvolvimento para Reutilização são áreas
correlatas e não temos nenhuma dúvida quanto à sua importância para a área de teste de
software. O mesmo podemos dizer da Gerência de Riscos, visto que estamos tratando o
teste de software como um projeto e todo projeto precisa de uma análise de riscos.
A área de Análise de Decisão e Resolução com toda certeza também é necessária para um
projeto de teste de software. Testar software é uma atividade que envolve tomada de
decisões e conseqüentemente a avaliação de alternativas. Por exemplo, qual a ferramenta
mais adequada para a execução 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 são decisões que requerem avaliar alternativas de solução.

Nivel B
O nível B exige as seguintes áreas de processo:
 Gerência de Projetos (evolução)

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 nível A exige as seguintes áreas de processo:

 Análise de Causa de Problemas e Resolução

A área de processo Análise de Causa de Problemas e Resolução se fundamenta na

identificação da causa de variações de desempenho do processo com o intuito de serem
tomadas ações que diminuam a sua ocorrência no futuro. Como estamos tratando do
processo de teste de software este é o contexto da melhoria de desempenho e não vimos
nenhuma restrição quanto a sua aplicação nesse processo.

Conclusões

De todas as áreas de processo avaliadas e estudadas apenas três delas poderiam gerar algum
tipo de discussão quanto a sua aplicabilidade à área de teste de software que são as
seguintes:
 Integração de Produto
 Validação
 Verificação

Todas as outras áreas são perfeitamente aplicáveis 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 Gerência de
Riscos, Garantia da Qualidade ou Gerência de Configuração. Em resumo podemos, de
forma genérica, afirmar que quando consideramos o Teste de Software como um projeto
que está baseado num processo, fica fácil entender que a maior parte das áreas de processo
é perfeitamente aplicada a área em questão.
A área de processo Integração do Produto é coberta pelos testes de sistema e pelos testes de
integração. O que conhecemos como Procedimento de Teste ou Roteiro de Teste representa
a execução de um conjunto de Casos de Teste de forma integrada para verificar um
requisito ou uma funcionalidade ou um cenário de teste. No caso das áreas de processo
Validação e Verificação temos uma coincidência com a própria atividade fim da área de
teste. O que falta caracterizar são quais tipos de teste ficariam dentro de cada uma das
áreas, dentro dos inúmeros que são executados pela área de teste. Sabemos que teste de
aceitação é caracterizado como da área de processo Validação. Os testes unitários, testes de
integração e testes de sistema estão dentro da área de processo Verificação, assim como
inspeções e revisões técnicas. De qualquer forma buscar essas evidências vai fazer parte de
um trabalho mais completo que nos propomos a publicar oportunamente. Não vamos
discutir agora o que seriam, por exemplo, as evidências diretas ou indiretas.
A conclusão 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 evidências mostram que, de uma forma genérica, a aplicação do
MPS.BR numa área de teste de software produzirá resultados semelhantes àqueles que
encontramos durante a sua aplicação 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 posição de vanguarda no mundo, já que não existe nenhum
modelo semelhante. Existem sim modelos específicos para teste de software, e o que
estamos propondo é o compartilhamento do mesmo modelo. Uma parceria da ALATS –
Associação Latino Americana de Teste de Software com a Softex ou outra instituição 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
evidências, o que esperamos levar adiante durante o próximo ano. Inicialmente deverá ser
publicada o nível 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. Análise 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 Implementação.
Brasília. 2007.