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
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) :
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:
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 !!!)
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.
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)
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.
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
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