CBTM – Change-Based Test Management

Procurando sempre se posicionar estrategicamente no mercado de processadores, a Intel através dos seus relatórios anuais de operação, afirma: "Entre dezembro de 1999 e agosto de 2002 a Intel liberou vinte diferentes versões do processador Intel® Pentium III e Pentium 4, o que corresponde aproximadamente a um novo processador a cada um mês e meio" (Intel 2002). Isso quer dizer que se a densidade de um circuito integrado dobra a cada doze meses, pode-se afirmar que os projetos de software também ficarão maiores e mais complexos.

por Fábio Martinho Campos

Objetivo

O objetivo desse artigo é mostrar o conceito de teste de software do ponto de vista de uma das maiores empresa de TI do mundo, a Intel Corporation.

Introdução

Procurando sempre se posicionar estrategicamente no mercado de processadores, a Intel através dos seus relatórios anuais de operação, afirma: “Entre dezembro de 1999 e agosto de 2002 a Intel liberou vinte diferentes versões do processador Intel® Pentium III e Pentium 4, o que corresponde aproximadamente a um novo processador a cada um mês e meio” (Intel 2002). Isso quer dizer que se a densidade de um circuito integrado dobra a cada doze meses, pode-se afirmar que os projetos de software também ficarão maiores e mais complexos.

Com isso, a mudança natural na indústria de software requer também que as empresas de software, assim como as de hardware, continuem competitivas e lancem produtos mais atualizados e com novas versões, adaptando-se assim ao novo hardware que foi lançado.

Um exemplo clássico seria a Microsoft: ela lança segundo dados de pesquisa, um novo sistema operacional a cada 18-24 meses, sendo uma razão para que demais empresas que dependem da plataforma Windows se adaptem a esta nova versão, fazendo assim mudanças em seus softwares. O caso mais recente que temos é o lançamento do sistema operacional Microsoft Windows Vista. O Windows Vista após ter sido lançado, provocou uma “euforia” na indústria de software! Empresas grandes como Adobe, IBM, DELL, HP e outras tiveram que rapidamente se enquadrar neste novo sistema operacional, para assim não perderem market-share.

Ou seja, todos estão mudando seus respectivos softwares para se alinhar às novas tendências do mercado de hardware.

Atualmente, as mudanças de hardware e acessórios ligados a ele são quase que instantâneas. Um processador ou placa-mãe de última geração que você adquiriu algum tempo atrás, talvez o mês que vem já não seja a melhor opção. Tomo como exemplo os pen-drives: comprei o meu primeiro com 2GB! Passou-se dois meses e foi lançado o de 4GB. Novamente, comprei o de 4GB e passado algum tempo um colega do trabalho comprou um de 8GB. E o que eu fiz? Comprei o meu de 8GB e acabei desistindo depois de comprar o próximo: lançaram o pen-drive de 32GB.

Esta mudança freqüente traz alguns problemas: em um projeto de software, quando o desenvolvedor está produzindo um sistema para certo tipo de hardware, ao finalizar o projeto aquele mesmo hardware já não é o mais atual. Geralmente os desenvolvedores gastam horas e mais horas tentando ao máximo escrever linhas de código-fonte que possam ao máximo usufruir da performance do hardware em questão, já que performance é um dos requisitos mais cobiçados por todos atualmente, especialmente no mundo dos games para computador.

Torna-se ainda um ponto chave o ciclo de vida de desenvolvimento de software, uma vez que quando certo sistema for finalizado digamos pela empresa 1, a empresa 2 já estará produzindo um sistema que utilize melhor um novo hardware, o qual havia sido lançado durante o desenvolvimento do sistema da empresa 1.

Como resolver este problema?

Uma solução seria reduzir o número de ciclos de desenvolvimento de software e fases de validação, segundo Sistowizc e Arell. No entanto, a grande pergunta é como fazer isso! De acordo com os mesmos autores, o refinamento do processo aumenta a qualidade! Para tanto, seriam necessárias auditorias de processo para se achar gaps onde se consome muito tempo, fazendo com o projeto dure muito mais além do necessário.

É possível ver em várias pesquisas de projetos de software, que os mesmos são os mais caros para serem desenvolvidos gerando custos exponenciais e ainda não possuem toda a qualidade esperada para o usuário final do sistema, sem contar o prazo que quase nunca é cumprido e os riscos incontroláveis sem suas devidas mitigações. Algumas vezes porque o projeto foi mal estimado, alocando-se recursos desnecessários ou no caso, nosso próprio processo de desenvolvimento está desenhando de tal forma que torna o projeto de software muito caro e com prazos intangíveis.

A redefinição e refinamento de processos fazem com que até mesmos as pessoas trabalhem de forma mais efetiva, o que por conseqüência de um bom processo desenhado, aumentará a qualidade do desenvolvimento de software e principalmente no nosso caso, a validação ou teste de software. Ou seja, qualidade não é somente deixar menos defeito no software que são encontrados pelos clientes, mas também a diminuição dos custos de manutenção e suporte por parte da empresa que fornece a solução.

Elaborando uma estratégia de validação eficiente, pode-se liberar o produto para uso mais rapidamente através do refinamento e diminuição dos ciclos de teste, aumentando então a qualidade, diminuindo o time to market e também o número de chamados de no help desk para defeitos encontrados em produção.

Porém, sempre o que vemos são ciclos de desenvolvimento muito longos, fazendo com que o teste de software ainda que exista, tenha a sua janela de atuação muito pequena. Freqüentemente uma prática muito comum em projetos é o uso do tempo de validação por parte do desenvolvimento, e ainda sim a janela de teste sempre continua a mesma, quando na verdade o cronograma deveria mudar, sendo a release da solução adiada(mas nenhum gerente de projeto quer isso!!!). Com isso inúmeros problemas começam a acontecer como geração errada de builds, validação feita em versões desatualizadas, a documentação não existe mais ou está desatualizada, massa de dados não reflete mais as características do sistema, pois há muitas mudanças, etc.

O que significa, então, qualidade e muito tempo gasto? Segundo Sistowizc e Arell qualidade significa liberar o produto com a qualidade atual, superando os riscos(Bach 1997). Muito tempo significa perder uma janela de atuação no mercado. Tudo isso devido às mudanças constantes e indesejadas em projetos de software.

E é exatamente neste ponto que o Gerenciamento de Testes Baseado em Mudanças entra em ação.

O que é Change-Based Test Management?

Ao contrário da equipe de desenvolvimento, a equipe de qualidade/teste de software provê informações para a gerência do projeto como número de bugs encontrados, número de bugs que foram fechados, cobertura dos testes em relação aos requisitos levantados e outros indicadores que vão ajudar o gerente do projeto a tomar uma decisão: liberar ou não o software para a produção.

Portanto, o papel da área de testes ou quality assurance como é chamado por muitas empresas, é de avaliar e certificar a qualidade do produto de forma rápida, a fim de descobrir os defeitos com maior grau de impacto, realizando obviamente, os casos de teste mais importantes primeiramente.

Segundo Sistowizc e Arell, para que o bom desempenho da CBTM seja realizado “o papel do departamento de validação deve avaliar o produto o mais rápido possível”, sendo ainda que não são objetivos da CBTM ganhar dinheiro ou introduzir novos produtos, mas sim corrigir defeitos em um produto existente, não permitindo que o cliente final descubra por si só esses defeitos.

EMPRESAS QUE NÃO INVESTEM EM VALIDAÇÃO, NÃO SOBREVIVEM!!!

Corrigindo esses defeitos antecipadamente faz com que a saúde do projeto em termos de qualidade seja mais eficiente, construindo assim uma confiança na aplicação que está sendo entregue.

CBTM(Change-Based Test Management) ou simplesmente Gerenciamento de Testes Baseado em Mudanças “é um modelo de validação que tem como alvo principal áreas de mudança no software como primeiras áreas a serem testadas”. (Sistowizc e Arell)

Pessoalmente, pude notar uma grande semelhança dessa abordagem com o teste de regressão, onde fazemos todos os testes novamente para garantir que áreas que já estavam previamente funcionando(e que já haviam sido testadas) não foram afetadas pelas novas mudanças introduzidas. Vejo que a diferença básica seja que o teste de regressão é um tipo de teste a ser realizado dentro do próprio CBTM, enquanto que o CBTM em si é um modelo de validação de software baseado em mudanças(principalmente de hardware).

Usando o conceito do CBTM permitirá aos profissionais de teste escolher de forma mais adequada quais áreas devem ser testadas primeiro e tomar decisões mais rapidamente no que se refere a cada ciclo de teste. Isso porque a tendência dos testes é aumentar a cada novo ciclo, pois à medida que defeitos vão sendo encontrados, mais casos de teste precisam ser criados para cobrir este defeito em um próximo ciclo de testes. Com isso Sistowizc e Arell afirmam que com o crescimento dos casos de teste, o processo de teste de regressão torna-se longo e redundante. Adicionalmente, por exemplo, uma função foi validade anteriormente acredita-se que há uma grande probabilidade que esta mesma função ainda funcione em uma nova versão.

O que queremos dizer aqui é que: pode-se eliminar o teste de regressão quase que na sua totalidade, focando apenas os testes em partes do código-fonte (funções) que foram afetadas(conceito do CBTM). Isso diminuiria quase que pela metade o tempo de entrega de uma nova versão de um software. No entanto sabemos que somos de certa forma, dependentes do teste de regressão, pois certamente precisaremos garantir o bom funcionamento do software na sua totalidade e não somente naquele módulo. Como então resolver este problema de não eliminar o teste de regressão e ainda sim estar confiante que uma mudança não parou alguma parte do sistema que estava funcionando?

Particularmente gosto da estratégia de se criar uma Matriz de Requisitos, ou seja, saber quais requisitos estão diretamente ligados com regras de negócios, logicamente com outros requisitos, com classes/objetos/funções(componentes/módulos de código-fonte) e obviamente requisitos relacionados com os casos de teste. Com isso pode-se eliminar os módulos os quais a mudança não está diretamente relacionada, pois é possível fazer uma análise visual através de softwares que tem a função Matriz de Rastreabilidade. Certamente, adotando esta abordagem o tempo do teste de regressão será muito menor visto que serão apenas executados os testes relacionados à mudança em si, e não o sistema por completo. Um exemplo para esta abordagem seria a matriz abaixo:

TRAMA - Ferramenta de Auxílio ao Trabalho com Matrizes de Rastreabilidade

Pensando também na estratégia de relacionar a quantidade e esforço de teste a ser feito com as mudanças feitas no código-fonte, o modelo CBTM classifica como atividades essenciais em termos de mudanças:

- Monitorar as mudanças no código-fonte;

- Garantir a cobertura do código-fonte.

Sistowizc e Arell citam duas maneiras para se atingir um padrão de qualidade:

          - Aumentar o tempo de validação;

          - Aumentar a eficácia.

Aumentar o tempo de validação nem sempre é uma boa opção, a menos que uma boa negociação seja feita com o cliente, pois com esta abordagem, a entrega do produto poderá ser postergada e o cronograma do projeto mudado.

Resta-nos então a eficácia! Isso quer dizer que o tempo para se executar um teste geralmente não muda. Então, se você precisa executar estes mesmos teste em um curto espaço de tempo(menor ainda que o ciclo anterior), o número de testes deverá ser reduzido para que se possa entregar no tempo desejado.

No entanto, sabemos que reduzir(cortar) cenários/casos de teste pode ser uma abordagem perigosa, pois muitos testes importantes podem ser eliminados o que causará respectivamente em uma baixa qualidade do produto final sendo que os testes eliminados poderiam, no caso, pegar algum tipo de defeito. Porém, segundo Sistowizc e Arell, em um ciclo CBTM a qualidade será aumentada através de 5 fatores:

: Conforme Sistowizc e Arell, “procure por uma “feature” ou funcionalidade que você não esteja testando. Se um defeito ocorre nesta área, seu esforço de validação não descobrirá defeitos até a entrega do produto”.

: Testes redundantes quando executados podem consumir muito tempo, deixando muitas vezes partes do sistema que deveriam ser testadas para outra fase ou ciclo. A eliminação de desse tipo de teste visa a agilidade e performance, além de economizar tempo no projeto.

Alguns tipos de Código Delta citados pelo CBTM são:

- Segment Delta;

- Function Delta;

- File Level Delta.

Sendo ainda que cada tipo de Código Delta fornece diferentes funcionalidades e permite que decisões sejam tomadas baseadas nessas funcionalidades de cada Código Delta.

- Code Coverage(Cobertura de Código): Cobertura de Código é uma medida das áreas do código-fonte que mostra quais linhas/partes do código foram executadas ou não dentro de um determinado teste. A cobertura de código pode ser algumas vezes enganosa, pois atingir a cobertura de 100% do código-fonte não quer dizer que não existem defeitos. Cobertura de teste e cobertura de código são dois conceitos diferentes: cobertura de teste usualmente se refere ao número de testes escritos para um requisito especifico sendo que por outro lado é mais especifico, pois se refere a “porcentagem de uma área atual do código que um determinado teste é executado”.

Alguns tipos de Cobertura de Código citados pelo CBTM são:

          - Line Coverage ou Statement Coverage;

- Decision Coverage(ou como chamado pelo ISTQB, Branch Coverage);

- Condition Coverage;

- Multiple Condition Coverage;

- Hundred-percent Condition Coverage;

- Hundred-percent Multiple Condition Coverage;

- Condition/Decision(C/D) Coverage;

- Path Coverage.

O CBTM define que para que um teste ocorra, três elementos são necessários: uma suíte de testes, um produto de software e uma interface entre os dois. A real ideologia, então, por de trás do CBTM é unir o Code Delta e o Code Coverage movendo os testes de caixa-preta(Black Box) para caixa-branca(White ou Glass-box).

Cabe aqui fazermos uma análise:

- No próprio livro os autores declaram de forma explícita que os testes de caixa-preta são executados sem o conhecimento interno das operações do produto e que este não é um método efetivo de teste porque funcionalidades escondidas podem não ser testadas. Afirma também que o teste de caixa-preta permite ao criador do teste assumir muitas coisas sobre o código, e estas premissas podem levar a erros. Além disso, no capitulo 2 do livro Change-Based Test Management - Improving the Software Validation Process, página 13, a seguinte declaração é feita(traduzido e revisado para não gerar dúvidas): “Com o teste de caixa-preta, você teste o produto contra os requisitos e você está somente interessado se o teste passa ou falha”.

Além disso, na página 14 do mesmo capítulo diz que “Incorporando e analisando cobertura de código, você pode converter teste de caixa-preta em teste de caixa-branca. Teste de caixa-branca implica em um melhor entendimento dos componentes internos do produto. No teste de caixa-branca, você está interessado em como o produto funciona e não meramente se o produto passou um teste. Baseando-se em taxas de ‘passou/falhou’ pode ser perigoso porque são (números) enganosos. Um cliente não se importa se seu produto passou 900 testes ou 90 testes. Testes acham defeitos, e defeitos são o que o cliente vê. Se você rodou 900 testes e 890 deles passaram, então você rodou 890 testes a mais que o necessário. Um cliente não se importa que sua taxa de testes que passaram foi de 98.89%; o cliente apenas se importa sobre os defeitos que você encontrou (...). o problema com o teste de caixa-preta é que um teste que passou não garante você de exatidão. Teste de caixa-branca dá para você muito mais confiança na exatidão do produto (...) porque permite você ver o funcionamento interno do produto. (...)”. (Sistowizc e Arell, 2003)

O CBTM praticamente ignora o teste de caixa-preta, sendo seu foco nos testes de caixa-branca, ou seja, no código-fonte. Será mesmo que em algum momento os testes de caixa-preta não fazem mais efeito? Como e onde as afirmações acima foram baseadas para tal conclusão? Será que ambos os testes de caixa-branca e preta não se complementam ou por outro lado os testes de caixa-preta acabam sendo redundantes? Uma discussão entre os profissionais da área seria muito interessante para avaliarmos diferentes pontos de vista.

Considerações Finais:

Foi a minha intenção neste artigo mostrar outra abordagem para gerenciamento de projetos de teste, proposta pela Intel Corporation. Vale a pena lembrar que em nenhum ponto concordei/discordei com a metodologia imposta pelo CBTM. Além claro, de contribuir para a comunidade de Qualidade e Teste de Software com mais conhecimento e atualização/capacitação pessoal de cada profissional.

Pessoalmente, creio que a metodologia é bastante estruturada em termos de como gerenciar as mudanças que ocorrem durante o projeto em termos de código-fonte, mas é “radical” ao mencionar que não é necessário o uso do teste de caixa-preta e que ainda os mesmos deveriam ser migrados/convertidos em teste de caixa-branca.

Outro ponto a ser ponderado é a apresentação dessa metodologia de validação. Podemos sim absorver o que há de melhor nela e criar/elaborar um framework totalmente customizado as nossas necessidades atuais, agregando como mais uma atividade a ser realizada, ou seja, a monitoração de mudanças a partir do código-fonte.

Espero ter contribuído mais uma vez e estou aberto para questionamentos e creio que um bate-papo sobre o assunto poderá iniciado para comparar diferentes opiniões e pontos de vista. Sendo assim, vamos tentar responder as seguintes perguntas:

1. O que você achou da metodologia de validação da Intel, o CBTM?

2. Quais pontos você concorda ou discorda desse tipo de abordagem para gerenciamento de testes baseado em mudanças?

3. Você adotaria este modelo? Se sim, na sua totalidade ou apenas partes que você julgou como praticáveis?

4. No seu entendimento, o modelo consegue realmente garantir a qualidade do software somente pelo fato de se monitorar mudanças no código-fonte?

5. Testes de caixa-branca e preta se complementam ou cada um deve ser exclusivamente usado no projeto?

6. Nos seus projetos passados e/ou atuais, o projeto faz o uso de alguma ferramenta de cobertura do código-fonte?Se sim, qual?

7. Como são monitoradas as mudanças do seu projeto em termos de requisitos, arquitetura e principalmente código-fonte?

Resumo:

- A validação é parte de qualquer ciclo de vida de desenvolvimento e reduzir o tempo desse ciclo faz com que versões do software sejam entregues com mais freqüência;

- O objetivo do CBTM é aumentar a eficácia da validação;

- A validação não envolve somente o código-fonte do produto, mas também o processo usado pra criar o produto;

- O objetivo de qualquer metodologia de validação é achar defeitos o mais cedo possível no ciclo de vida de desenvolvimento de software;

- Não importa quão cuidadoso seja o desenvolvedor, sempre haverá defeitos em código-fonte e geralmente muito mais do que o próprio desenvolvedor pode esperar;

- CBTM é a união de Cobertura de Código e Código Deltas;

- Uma das metas/objetivos do CBTM é mover(migrar/transformar) os testes de caixa-preta em testes de caixa-branca;

- CBTM foca um grande esforço em atividades de monitoração de mudanças de código-fonte;

Referências:

Livro: Change-Based Test Management - Improving the Software Validation Process, by Jon Sistowicz and Ray Arell

Apresentação em PPT sobre CBTM: http://www.saqa.org/presentations/Spin.ppt

Sites:

- HTTP://www.microsoft.com

- HTTP://www.intel.com

Matriz de Rastreabilidade:

- No link abaixo é mostrado o uso do software IBM Rational RequisitePro.

Link

- Apresentação da ferramenta CONTROLA para a criação de Matriz de Rastreabilidade.

http://imasters.uol.com.br/artigo/3480?cn=3480&cc=264

- TRAMA: Ferramenta de Auxílio ao Trabalho com Matrizes de Rastreabilidade

http://code.google.com/p/trama/

- Informações complementares sobre Matriz de Rastreabilidade:

          http://blog.e-lm.com/?p=6

http://en.wikipedia.org/wiki/Traceability_matrix

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=6051

Conceitos (Segundo ISTQB - GLOSSÁRIO PADRÃO DE TERMOS UTILIZADOS EM TESTE DE SOFTWARE -  Versão 1.3br 01 de Julho de 2007):

- Cobertura de código: Método de análise que determina quais parte de um determinado software foram executadas (cobertas) por uma suíte de teste e quais não, por exemplo, cobertura das sentenças, cobertura da decisão e cobertura da condição

- Medição: Processo que designa um número ou categoria a uma entidade a fim de descrever determinado atributo de tal entidade. [ISO 14598]

- Medida: Número ou categoria designada a um atributo de uma entidade por meio de medição. [ISO 14598]

- Métrica: Escala e método utilizados para medição. [ISO 14598]