Testes de Software: Tendencia ou moda?

Um "processo" de revisao e inspecao de testes burocratico tambem nao ajuda muito. Vou contar como funciona na maioria dos projetos aqui da ThoughtWorks, sem tentar julgar muito:

Analista de negocios (BA) descobre um requisito e poe num cartao

Analista de testes (QA) converesa com o BA e descreve no cartao alguns cenarios de teste

Desenvolvedor estima o tempo que vai demorar pra implementar aquele cartao

Desenvolvedor senta com o QA e verifica que os testes que ele bolou sao os que o QA queria

Desenvolvedor apresenta pro BA os testes funcionando depois que a implementacao terminou, fim de papo

Algum tempo depois, caso seja descoberto um bug, o mesmo cartao volta, com novas informacoes, e a sequenciazinha repete

Putz, eu detesto isso de estimar prazo pra desenvolvimento.

Porém, isso vocês fazem com todo requisito?

Estimar um projeto inteiro eh muito mais complicado do que uma tarefa: o tamanho de cada tarefa nos cartoes geralmente nao passa de 3 ou 4 dias (em alguns projetos/casos especificos, chega a duas semanas, no maaaaaaaximo). Entao, nao eh tao chato assim: uma tarefa definida como "itens do carrinho de compras devem ser excluidos quando a quantidade selecionada pelo usuario eh 0" eh muito mais facil de estimar do que algo aberto como "carrinho de compras".

HelloWorld Membro desde: 19/01/2005 16:52:31 Mensagens: 20 Offline

Olá cv,

Só uma dúvida? o único artefato que vc utiliza para controle de cenário, validação com BA e QA, quantidade de teste, classificação de teste, estágio de criação dos casos de testes(NEW, ASSIGN, WORK, CLOSED, ..., por exemplo) é esse cartão?

O máximo de pessoas envolvidas são 3? QA, BA e o desenvolvedor? Como vc comentou que tem que validar com o BA, então são teste de aceitação, homologação, ...., sou seja, mais na visão do cliente.

Outra coisa, sobre questão de estimar, é muito importante porque já tem um estimativa para o planejamento, vc pode acabar antes ou depois, mas fica arquivado e quando for necessário fazer criação dos testes, então já tem um conjunto de métricas e ter firmeza em chegar para o cliente e dizer, eu entrego o que pede em X tempo com essa qualidade de fazer teste de unidade, integração, stress, boundary, ....

James, o cartao eh a unica coisa que fica visivel o tempo todo - claro, todos os artefatos criados por causa dele continuam valendo como material de suporte: o BA escreve alguma documentacaozinha, o desenvolvedor escreve testes unitarios, codigo e mais alguma documentacaozinha, o QA escreve um cenario de testes de stress, ou um teste funcional, ou algo do genero, afinal, depende muito do projeto.

Os estados pelos quais um cartao pode passar sao, apesar de isso fazer pouco sentido analisado isoladamente: novo, estimado, implementado, terminado, este ultimo indicando que a funcionalidade do cartao foi pra producao, e o cliente esta satisfeito por enquanto, o que nao impede que ele mude de ideia, o que faz o estado do cartao mudar de novo.

É uma tendência de toda a grande empresa e todas elas que querem ter a certificação CMM

Grinvon wrote:É uma tendência de toda a grande empresa e todas elas que querem ter a certificação CMM

As 3 letras malditas!

SALVEM-SE DO RICHARDPEDER!
*se esconde debaixo da mesa e assume posicao fetal*

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

Grinvon wrote:É uma tendência de toda a grande empresa e todas elas que querem ter a certificação CMM

Bom... CMM já era né.. a moda agora é cMMI (ou CMI .. não lembro!!! o nome exato) ..

Realmente as empresas adoram CMM... mas isso é discussão para mais de metro!!!

Hoje podemos ver que principalmente Fábricas de Software (eca) são as maiores interessadas no assunto.

Agora uma opiniãozinha pessoal.... CMM por enquanto não avalia nada!!!

Empresas realmente envolvidas com metodologias de desenvolviment ágil como XP por exemplo, repudiam o CMM, pois a burocracia que CCMM gera faria com que a metodologia deixa-se de ser ágil.. ou seja.,.. nada ver CMM com Software Ágil!!

Outro detalhe é:
Na ìndia, onde temos uma renca de empresas CMM5, todos utilizam desenvolvimento no modo cascata,... que é mais fácil de gerenciar, mas que necessita de mais mão de obra. Mas para sorte deles, a mão de obra na índia é baratíssima!

Já no Brasil a mão de obra é mais cara, e para atender a demanda, precisam desenvolver mais rápido com menos mão de obra. Logo utilizam uma metodologia mais ágil, como por exemplo o desenvolvimento expiral e outras metodologias próximas. Essas metodologias são mais dificeis de gerenciar também...

Daí o resultado: A gente não tem nem Cmm 3 direto, e o indianos mandam bala no Cmm 5....

Você acha isso justo???

Quanto eu tiver miinha empresa.. (rsrsrs....

), primeiro me preocuparei com certificações do tipo ISO e outros do tipo... CMM só se essa coisa amadurecer mesmo!!!

Abraços!

HelloWorld Membro desde: 19/01/2005 16:52:31 Mensagens: 20 Offline

Existe realmente uma diferença entre CMM e CMMI.

O CMM foi o primeiro a surgi e justamente é voltado para software. Só que ele cresceu tanto que está abrangendo outras áreas fora software, como projetos de sistemas embarcados, por exemplo, o alarme de uma casa, o terminal de venda de um supermercado e até mesmo o projeto de um celular . Com isso alem da preocupação do software, tem o projeto do hardware, e com o passar do tempo, é necessário integrar o hardware com o software e aí que acontece os maiores paus.
Existe uma metodologia, chamada co-design que estuda isso, em como fazer um projeto de hardware em paralelo ao software e haver uma "integração perfeita".
A utilização do RUP é voltado para grandes projetos, por exemplo, a índia ser responsável por um componente, o Brasil por desenvolver outro componente, China responsável pelo hardware onde vai rodar o software, então eu acho que o RUP é burocrático, mas acredito que é um "mal necessário" para que um grande projeto não vá para o lixo.
Concordo que precisar ser mais ágil, tanto que cada empresa instancia o RUP na melhor forma possível, porque se fosse utilizar todas as atividades do RUP, seria somente preencher documento, quem trouxe o café para o desenvolvedor, quanto tempo levou isso, ...
Eu acho que RUP e XP são dois processos que podem se complementar. O RUP organizando e o XP colocando a mão na massa.
Até mesmo o CMMI tem no último estágio como sendo o de otimização do processo, ou seja, onde poderia tem um gargalo e poderia eliminar uma atividade e ser suprida por outra atividade. Então mesmo em processo com muita burocracia tem a preocupação do tempo.
Mas éeeeeeeeeee muito difícil conseguir isso, no Brasil somente tem a TATA como CMMI nível 5, e isso porque vieram todos importados de lá.
Concordo que quem sabe, não precisa mostrar papel com certificado Java, CMMI, de teste. Mas infelizmente, as grandes empresas então começando a exigir dos parceiros esses certificados para ganhar licitações e projetos.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Tem também uma iniciativa chamada SPICE que tem a haver também com a ISO 15.000 e alguma coisa que eu não me lembro.

Qual é a vantagem ?
Compare o CMM com a microsoft$ e SPICE com o linux.

Gente, comecem um novo topico se for pra discutir ___ (eu nao vou usar as letras malditas). Vamos voltar ao assunto, por favor. Essa thread ja ta bem grandinha

Ok, apra voltar ao assunto...

cv wrote:Vou contar como funciona na maioria dos projetos aqui da ThoughtWorks, sem tentar julgar muito:

Vou listar o fluxo em algumas empresas verdadeiramente grandes que conheço para se fazer uma comparação (e esculhambarmos elas

)

1 - Cliente pede algo
2 - Alguem eh mandado pra covnersar com o cara, faz n workshops, isso pdoe durar 2 meses facil facil
3 - O lider tecnico do projeto recebe um catalogo de requisitos enorme e impresso ou PDF (pra vc ver a "imutabilidade" da coisa)
4 - lider de qa escreve um escopo de teste em alto nivel
5 - Lider prepara um documento conceitual e um sobre a arquitetura, vao para o cliente
5 - apos aprovado, conceito eh dividio em componentes, cada um ehe specificado por uma pessoa ou mais (geralmente pessoas diferentes que nao vao implementar estes componentes, mas outros)
6 - qa começa a especificar testes dos componentes
7 - começa a implementação do sistema, em paralelo dos testes (esse paralelo eh sempre mentiroso)
8 - tudo eh reescrito um milhao de vezes, os documentos nao sao atualizados ate alguem chorar
9 - produto entregue

Alguém por acaso falou de CMM/CMMI aqui?!

Falando sério....cv, este cenário de testes da sua empresa é legal...

CMMI é dificil conseguir mesmo...algumas empresas que já tem CMM estão migrando para o CMMI....CMM já era! A TATA é a única CMMI nível 5 do Brasil...inclusive a certificada está aqui em Brasilia, mais precisamente no Brasilia Shopping...

....e para quem acha que certificar é só copiar e colar, estão enganados...institucionalizar é muito mais do que dar treinamentos e workshops...é colocar na veia do cidadão processos de um nível de maturidade 5...facil pra quem jah ouviu um dia falar de CMM, quase impossível para quem nem sabe o que é isso!

ate mais...

This message was edited 3 times. Last update was at 21/03/2005 21:06:59

pcalcado, acho que agente foi co-worker e não sabia...

cv wrote:As 3 letras malditas! SALVEM-SE DO RICHARDPEDER!
*se esconde debaixo da mesa e assume posicao fetal*

Esse cv tem umas colocações muito engraçadas... to rindo aqui sozinho... lol

HelloWorld Membro desde: 19/01/2005 16:52:31 Mensagens: 20 Offline

Concordo com Richardpeder,

No processo de CMMI, o mais difícil é a conscientização das pessoas que é necessário seguir umas regrinhas simples

.

Acho que mais fácil para o pessoa de teste aceita melhor a implantação do CMMI na empresa do que os programadores.

Por falar em programador e testador, um problema que eu vejo, é que o programador acha que o testador está para derrubar o trabalho dele. Quando na verdade está querendo melhor o produto. Não se olha o erro do programador, mas sim, a qualidade do produto.
Uma analogia que eu faço é que o programador faz o diamante bruto e o testador, ajuda o programador, a lapidar esse diamante, tornando-o mais brilhante e apresentável.

Um abraço.

Notícias, artigos e o maior fórum brasileiro sobre Java