Número de empresas certificadas no CMMI pelo mundo

Fala galera!

Estava preparando uma postagem para vocês sobre o CMMI e acabei por encontrar o último relatório do SEI a respeito das empresas certificadas pelo mundo, através dos seus níveis de maturidade.

Listei na imagem abaixo apenas os países que possuem mais de 100 empresas certificadas entre os níveis 2 e 5 do CMMI.

Percebam que o Brasil possui mais do que a metade (55%) de suas empresas certificadas no nível 2, que na teoria é o primeiro nível a ser certificado pelo SEI, enquanto não possui nenhuma empresa nível 4 e apenas 6% de suas empresas (7 ao todo) no nível 5.

Numa comparação rápida com a líder do nível 5, o Brasil possui 3,7 vezes menos empresas certificadas do que a India, mas ao comparar a diferença entre as empresas certificadas no nível 5, o número é muito maior: Uma diferença de mais de 15 vezes!

Por que essa discrepância? Por que o CMMI ainda é pouco difundido no Brasil? Tentarei trazer algumas respostas em uma próxima postagem!

Abraços.

Fonte: CMMI® for SCAMPI Class A Appraisal Results - 2011 Mid-Year Update 

Caso de Teste "Tripa"

Fala galera!

Fui apresentado na semana passada ao termo Caso de Teste "Tripa", algo que nunca havia ouvido falar e que também não possui qualquer referência no Google.

Um colega que trabalha em uma grande empresa voltada para a qualidade me explicou brevemente o conceito deste termo, que parece ter sido criado na própria empresa.

O Caso de Teste "Tripa" pode ser definido como uma má prática adotada por alguns Analistas de Teste, que se utilizam apenas das informações retiradas da Especificação e acabam por tornar o Caso de Teste longo, difícil de ser executado e reutilizado e nada gerenciável.

O Caso de Teste "Tripa" costuma envolver mais do que um sistema ou módulo em sua especificação, além de possuir mais do que 30 passos, o que torna a sua execução maçante, pois é extremamente detalhado, sendo que até mesmo o filhinho de 3 anos do analista consegue executá-lo (existem gestores que exigem tal prática).

Cabe a nós, Analistas de Teste, mostrarmos que esta famigerada técnica não está com nada, já que iremos perder muito tempo detalhando um caso de teste e quando tivermos que alterá-lo no futuro, será um Deus Nos Acuda!

Abraços!

Uma boa Especificação de Requisitos já é meio caminho andado para um projeto com qualidade!

A lógica é bem simples:

Requisitos mal elicitados, excessivas mudanças de escopo e um template mal feito geram uma especificação de requisitos ruim. Com uma especificação de requisitos ruim, o desenvolvimento será feito cheio de buracos e nas "coxas". Com a especificação de requisitos ruim, a equipe de teste irá desenhar casos de teste ruins e que não cobrem todos os requisitos. Ou seja, um efeito dominó, se o trabalho não começar bem feito desde o começo, a equipe de teste não terá como fazer milagre. Esse efeito dominó irá gerar projetos com centenas e até milhares de bugs, diversos ciclos/sprints e um mau humor do cliente na entrega final.

Uma especificação de requisitos bem elaborada, orientada a casos de usos ou exemplos já é um bom começo para mudar tal lógica!

E para você, esta receita é válida?

Abraços!

Obs: A tal "especificação de requisitos" citada por mim é a famosa especificação funcional, também conhecida como detalhamento técnico de requisitos, entre outras denominações!