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.