Usando o MPS.BR para amadurecimento das equipes de teste de software

Autor: Emerson Rios

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.