Métricas de Testes

imagem de luizgustavovieira

Guia para Testes de Software - Mais prático e objetivo

Pessoal, como alguns já sabem, tenho escrito no meu blog sobre formas mais práticas e objetivas de implantar o processo de testes de software, aos poucos vou postando sobre como elaborar uma Estratégia de Testes, Plano de Testes, criar Casos de Testes, etc. e minhas dicas e comentários sobre cada uma dessas atividades. Qualquer contribuição será de grande valia para enriquecer o conteúdo do blog!

 

Segue alguns assuntos já postados:

Elaborando uma Estratégia de Testes:
http://testavo.blogspot.com/2010/05/estrategia-de-testes.html

Elaborando um Plano de Testes:
http://testavo.blogspot.com/2010/05/elaborar-plano-de-testes.html

Exemplo de um Caso de Teste a partir de um Caso de Uso:
http://testavo.blogspot.com/2010/05/exemplo-de-caso-de-teste-criado-part...

Desmistificando Testes de Regressão:
http://testavo.blogspot.com/2010/05/desmistificando-testes-de-regressao....

Entre outros posts interessantes no passado que postei como Testes em Metodologias Ágeis, Técnicas Avançadas de Testes (Tabelas de Decisão, Partição de Equivalência, Tabelas de Decisão, etc.), críticas sobre o CInTeQ 2010, dicas para as provas do ISTQB (CTFL e CTAL), entre outros.

O endereço do meu blog é http://testavo.blogspot.com

Qualquer dúvida estou à disposição. Meu MSN é: luizgustavo@lugati.com.br

 

imagem de robsonagapito

Tom DeMarco: "Como eu estava errado sobre métricas e controle"

Um texto de arrepiar quem segue a metodologia de projetos do PMI, mas sempre é bom a gente ter mente aberta para todas as opiniões.

Abrassss

Robson Agapito

=================================================

Texto retirado do Blog de José Papo (para ser justo, peguei este link do blog do grande Fabricio, o Qualidade Br - http://qualidadebr.wordpress.com/ ) .
http://josepaulopapo.blogspot.com/2009/07/tom-demarco-metricas-controle.html


Tom DeMarco: "Como eu estava errado sobre métricas e controle"

Na revista IEEE Software de julho/agosto de 2009, Tom DeMarco escreveu um artigo excelente de título Software Engineering: An Idea Whose Time Has Come and Gone? . Tom DeMarco ainda é um metodologista e consultor importante, mas era ainda mais famoso antigamente por ter sido um dos pais da metodologia estruturada.


No artigo ele diz que hoje discorda do que escreveu em um de seus livros muito usados na época de título "Controlling Software Projects: Management,Measurement, and Estimation". Não posso deixar de recomendar a leitura do pequeno texto, mas vão aí algumas frases excelentes (traduzi para o português) :

imagem de Zauza

Métricas subjetivas e objetivas em Testes de Software

Nobres colegas, métricas é um assunto polêmico. Falar sobre ele é sempre um desafio, pois depende de quem escuta. Se o cidadão tiver um pensamento contextual, analítico, qualitativo você com certeza deverá readequar sua linha de pensamento para defender o processo ideal de gestão da produtividade na área de QA.

A equipe que trabalha comigo é heterogênea, multidisciplinar e a maior parte é reativa. Existem ferramentas disponíveis para controle e gestão, mas são subutilizadas. O processo é formal, mas flexível em pontos-chave (no meu julgamento).

Hoje fui desafiado a criar um conteúdo para um projeto de métricas na auto-gestão de um colaborador no processo de QA, com as seguintes premissas:

  1. Reverter a subjetividade, em objetividade. Reatividade, em pro-atividade.
  2. Responder rapidamente a uma decisão gerencial de alto escalão.
  3. Utilizar (Contextualizando !!!) padrões e metas de produção.

Tenho muito material sobre o assunto. Mas gostaria de saber a opinião da comunidade sobre o ele: qual a melhor estratégia na criação de métricas para o colaborador utilizá-las a seu favor e a favor da corporação, durante o ciclo de produção ??? (Antecipo agradecimentos pelo feedback !!!)

imagem de fabio_martinho

CBTM – Change-Based Test Management ou Gerenciamento em Teste Baseado em Mudanças

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.

imagem de robsonagapito

Métricas de Testes de Software (EDD e ERD)

Métricas de Testes de Software (EDD e ERD) 

O mercado atual está cada vez mais focado em qualidade, e no mundo da informática não é diferente. E para a qualidade de software ser completamente adequada é muito importante a presença da área de testes em conjunto com outras áreas.

Mas como medir o que está sendo realizado no ciclo de desenvolvimento do produto/sistema para que possamos tomar ações de melhoria no processo como um todo? Para esta medição utilizamos de métricas.

Segundo o Wikipedia:

“A métrica de software é a medida de alguma propriedade do software ou da sua especificação. Utilizado para calcular orçamentos, desempenho...

Uma vez que as medidas quantitativas (mensuráveis) têm-se provado eficientes em vários ramos da ciência, cientistas de computação têm trabalhado arduamente para aplicar métodos similares no desenvolvimento de software.”

Abaixo demonstro dois exemplos de métricas que podem ajudar no aperfeiçoamento da qualidade do ciclo de desenvolvimento.


EDD (Eficácia de Detecção de Defeitos)

imagem de Felipe R. Silva

Metodologia para Gerenciamento de Recursos numa Execução Manual de Testes.

Autor(es): Felipe Silva e Thiego Carvalho
Publicado em: I SBTS
Data de publicação: Novembro/2006

RESUMO
Um dos fatores que levam a ocorrer defeitos escapados por falha humana é a maneira com que os testes são atribuídos para cada testador, por não existir um critério a satisfazer, acontece de determinados testes serem muitas vezes executados pelo mesmo testador, ou o testador não conhecer completamente os testes da sua equipe. Essas sucessivas repetições contribuem ainda para a falta de motivação dos testadores, levando-os a fadiga e limitando-os para as demais responsabilidades, desenvolvendo ainda vícios e abstrações gerados pela repetição da execução. Como forma de diminuir os defeitos escapados e melhorar a qualidade nos resultados obtidos, 4TestMethod é uma metodologia que analisa testes e testadores, resultando na combinação mais produtiva e mais confiável para os resultados reais, diminuindo assim os riscos de defeitos por falha humana. Além disso, esta metodologia se dispõe a distribuir o conhecimento entre o time de testes através da análise de distribuição das atividades e organização física entre os testadores.

Artigo completo anexado.

imagem de Cristiano Caetano

Métricas para acompanhar o progresso dos testes e a qualidade da aplicação

No seu blog, kumar kuldeep, postou um ótimo apanhado de várias métricas úteis para acompanhar o progresso do projeto de teste e a qualidade da aplicação em teste. Vale a pena conferir no seguinte endereço:
http://kuldeepse.wordpress.com/2007/05/29/metrics-used-in-testing/

Cristiano Caetano
www.testanywhere.com.br

imagem de Cristiano Caetano

Métricas de Software: Dez armadilhas que devemos evitar

Noite passada estava revendo uma bibliografia que usei para estudar métricas de software e sem querer encontrei um ótimo artigo que eu já tinha lido há um tempo atrás sobre o assunto. O artigo chamado 'Software Metrics: Ten Traps to Avoid' foi escrito por Karl E. Wiegers é extremamente conciso e foca com detalhes as armadilhas que normalmente caímos durante a implantação de métricas de software. Abaixo, segue a lista enumerada das armadilhas descritas no artigo, no entanto, vale a pena dar uma lida no artigo completo. O artigo está disponível online no seguinte site:
http://www.processimpact.com/articles/mtraps.html
Um resumo dos pontos abordados:
Software Metrics: Ten Traps to Avoid
#1: Lack of Management Commitment
#2: Measuring Too Much, Too Soon
#3: Measuring Too Little, Too Late
#4: Measuring the Wrong Things
#6: Using Metrics Data to Evaluate Individuals
#7: Using Metrics to Motivate, Rather than to Understand
#8: Collecting Data That Is Not Used
#9: Lack of Communication and Training
#10: Misinterpreting Metrics Data

Cristiano Caetano
www.testanywhere.com.br

 

Conteúdo sindicalizado