12 Mar 2012
AsEspecialistasPublicado em Java Magazine, Processo de Teste Tags: Artefatos, Ciclo de Vida, Melhores Práticas, Papéis, Responsabilidades
A edição 101 da revista Java Magazine trás o nosso mais recente artigo publicado: “Processo de Teste de Software”
Escrever esse artigo teve um sabor todo especial, pois engloba praticamente tudo que já escrevemos e vivenciamos até hoje. Além, claro, de muitas outras coisas que pretendemos compartilhar.
Mas afinal, qual o objetivo de um Processo de Teste?
Um Processo de Teste de Software tem como objetivo estruturar as etapas, as atividades, os artefatos, os papéis e as responsabilidades do teste, permitindo organização e controle de todo o ciclo do teste, minimizando os riscos e agregando qualidade ao software.
De que se trata o artigo:
Explicar como utilização de um Processo de Teste pode melhorar a efetividade dos testes, controlando as atividades e consequentemente garantindo mais credibilidade e qualidade ao software.
Em que situação o tema é útil:
Para evitar que o teste seja uma mera etapa do ciclo de desenvolvimento, a implantação de um processo relacionado a este garante um maior controle das atividades de teste e, consequentemente, mais qualidade ao software.
Nesse artigo apresentamos o Processo de Teste de Software com as suas principais etapas e respectivos artefatos gerados. Abordamos também os papéis e as responsabilidades de cada membro da equipe envolvida. Por fim, citamos algumas boas práticas que podem contribuir para obter sucesso na utilização de um Processo de Teste. Para melhor visualização, o artigo publicado conta com a seguinte estrutura:
Ciclo de Vida do Processo de Teste: destacamos uma série de etapas dependentes, consideradas como o esqueleto do Processo de Teste, que visam estruturar as atividades definindo como os testes serão conduzidos no projeto. Apresentamos então, as principais etapas do ciclo, juntamente com as suas respectivas responsabilidades dentro do Processo de Teste.
Artefatos: apresentamos os documentos produzidos após a execução de cada etapa do ciclo de vida do processo. O objetivo é registrar e acompanhar a evolução do projeto, inclusive verificar se os resultados obtidos estão de acordo com o que foi especificado.
Papéis: abordamos os principais papéis envolvidos no processo, que têm a função de organizar a responsabilidade de execução de cada atividade, além de definir quem irá gerar os artefatos do teste, levando em consideração as habilidades exigidas por cada um.
Responsabilidades: citamos as atribuições de cada componente da equipe.
Melhores Práticas: selecionamos algumas boas práticas já carimbadas no mercado de teste, que podem ser úteis em diferentes realidades de projeto.
Acesse a íntegra do artigo, através do link: Processo de Teste de Software – Revista Java Magazine 101.
16 Fev 2012
AsEspecialistasPublicado em Comportamento, Profissão Tags: Emprego, Mudança, Recomeço
Por inúmeras vezes ao longo das nossas distintas carreiras na área de Teste de Software, nos deparamos com uma dúvida bem comum nas rodinhas de conversa com colegas da área. E hoje, olhando sob nova perspectiva para essa situação, resolvemos parar, discutir e compartilhar a nossa visão sobre o assunto:
- Será que não está na hora de buscar uma nova oportunidade no mercado de Teste?
Porém, antes de agir no calor da emoção e partir efetivamente para uma busca, é interessante que estejam claros os motivos que estão te levando a isso. Senão, você pode simplesmente acabar trocando seis por meia dúzia.
Como a decisão tomada pode não ter volta, listamos”10 motivos para recomeçar no Teste de Software” para que você possa avaliar, intensificar ou desistir na busca por novos ares:
01) O seu trabalho está sendo reconhecido?
Está evoluindo no trabalho que realiza, geralmente fazendo mais do que te pedem. É detalhista, investigador, perfeccionista, questionador, criativo, organizado, pró-ativo, comprometido, está sempre disposto a aprender e ir além do que foi definido. Porém, ninguém reconhece o seu esforço, não existe incentivo e ninguém nota o seu potencial.
02) Você está sendo valorizado?
Remuneração baixa é um fator extremamente desmotivante, principalmente quando é realizada a famosa comparação com o “mercado lá fora”. Ou pior, quando você percebe que colegas de equipe com as mesmas qualificações, funções e cargos estão ganhando mais. A partir daí você começa a perceber que o seu salário está muito aquém do trabalho que realiza.
03) As regras da empresa condizem com a sua vontade profissional?
Se não concorda com as regras seguidas pela empresa, com os métodos de trabalho aplicados, ou se as políticas são muito diferentes daquilo que espera… Pode ser que uma adaptação a um universo tão diferente não seja possível, ou demande mais tempo que a sua disposição para se enquadrar. Essa situação poderá impactar diretamente numa possível evolução na carreira, caso permaneça.
04) Esse trabalho está te agregando conhecimento?
Se o trabalho que vem realizando é exatamente igual há um longo período, ou se já não existem práticas, técnicas, metodologias, normas ou padrões para aprender há tempos, é sinal de que possivelmente nenhum conhecimento está sendo agregado. Será que vale a pena ter 10 anos de tempo na carteira, sendo que a experiência parou de evoluir?
05) Existe uma possibilidade real de crescimento?
Se a empresa possui um plano de carreira com regras claras para que você alcance os seus objetivos, e você sabe exatamente o que precisa fazer para alavancar a sua carreira, ótimo. Mas se não existe um plano de carreira definido, pode ser que independente do diferencial do seu trabalho, ganhar uma promoção não seja tão simples.
06) Você tem liberdade de expressão?
Tenta expor sua opinião, mas ninguém te ouve. É comprometido, interessado, antenado. Procura trazer para a empresa novidades, tendências ou boas idéias, e nada acontece.
07) Os benefícios da empresa são um diferencial?
Os benefícios oferecidos pela empresa podem ser um fator chave para a retenção de talentos. Algumas oferecem benefícios que podem agregar em média 30% ao salário oferecido. Por outro lado, existem empresas que insistem em manter basicamente os benefícios exigidos pelas leis trabalhistas ou decisões dos sindicatos. Essa avaliação deve ser feita cuidadosamente, colocando cada item na ponta do lápis para que a mudança, ou não, de emprego traga exatamente o que busca.
08) O ambiente é agradável?
Quando o ambiente de trabalho não é agradável, dificilmente você conseguirá sentir prazer nas atividades que realiza. Se não existe companheirismo, comprometimento e simpatia na equipe, a qualidade do seu trabalho acabará sendo influenciada.
09) Acabou a sua motivação?
A motivação, ou a falta dela, é um fator determinante para a sua carreira. Se não consegue achar nenhum bom motivo para ir para o trabalho, se nenhum desafio vindo da sua empresa consegue te encorajar, se antes mesmo de começar o expediente você já está pensando na hora de ir embora, significa que a sua motivação acabou.
10) Está mesmo disposto a recomeçar?
Pare, pense e responda: está mesmo disposto a começar do zero novamente? Na nova empresa você terá que mostrar a que veio. Terá que cativar os pares e os líderes. Lidar com colegas, que dependendo da sua forma de contratação, poderão se sentir injustiçados. Aprender, se adaptar e não se acomodar são premissas fundamentais no recomeço.
Além dos itens citados, lembre-se que outros fatores também podem ser observados na sua análise, como por exemplo:
- Insegurança;
- Comodismo;
- Distância;
- Pressão;
- Carga Horária.
Se no resultado da sua avaliação dos 10 motivos para recomeçar, percebeu que a sua realidade se enquadra negativamente em boa parte dos itens citados, o primeiro passo você já deu, já sabe o que está buscando.
Mas atente-se, porque trocar de emprego não vai fazer com que a motivação volte. Não vai ser a solução para os seus problemas. A maioria das vezes o problema está em nós mesmos. Se não conseguir identificar o que está ocorrendo, deve buscar ajuda de um profissional. Um coaching, por exemplo, pode te ajudar a conduzir ao caminho correto.
Então, se você tem certeza de que recomeçar é a melhor solução, é chegada a hora de dar up no seu currículo e partir para busca. Se prepare. Faça uma análise também do que mais gosta e mais se destaca, e não se esqueça de verificar quais são os pontos fracos que precisa trabalhar.
Mas e os riscos?
Ah, os riscos existem mesmo. E se não avaliar os motivos que estão te levando a buscar um novo emprego, poderá descobrir na prática que a mudança não era a solução para a sua insatisfação.
A questão é que ao se deparar com vários motivos para recomeçar no Teste de Software, você tem duas opções: cruzar os braços ou dar a volta por cima. Se optar por ficar de braços cruzados, você irá simplesmente deixar a vida te levar e só alimentará a sua insatisfação. Se optar por dar a volta por cima, você tomará as rédeas da sua vida profissional em busca de uma oportunidade melhor.
Ok. Independente da área de atuação, os motivos são universais e caem como uma luva para varias outras profissões. Mas e então, o que diferencia esse recomeço sob a perspectiva do Teste de Software?
É sabido que nos últimos anos o Teste tem crescido gradativamente e aos poucos vem ganhando espaço e destaque. Diante desse cenário, o profissional que se sente inconformado, insatisfeito, desmotivado, tende a executar as atividades sem nenhuma disposição. Isso provavelmente impactará na qualidade final do software e poderá manchar a imagem do seu trabalho dentro e fora da empresa.
Se vive essa situação, você não deve ficar parado. Então, aprimore a sua capacitação técnica, e busque os seus objetivos, satisfação, valorização, reconhecimento, busque um lugar melhor no mercado.
Mas será que não vale a pena arriscar? Se der errado, você recomeça de novo.
10 Nov 2011
AsEspecialistasPublicado em Java Magazine Tags: Riscos
Publicado na Edição 97 da revista Java Magazine o nosso mais recente artigo: Análise de Riscos e o Teste de Software.
O artigo já está disponível online, e mais uma vez temos a maior satisfação de compartilhar um trechinho:
Verificamos com a revista e infelizmente não podemos disponibilizá-lo na íntegra. Mas vamos tentar explicar um pouquinho sobre o seu conteúdo.
O risco não é uma certeza de ocorrência de um problema. Um risco é uma probabilidade de que um problema ocorra, é uma perda em potencial para a organização. Em função disso, é mais econômico para a empresa investir em mecanismos que evitem a sua ocorrência.
A análise de riscos pode focar os testes nos pontos mais relevantes do software, além de priorizar a melhor utilização dos recursos técnicos e humanos disponíveis, otimizando todo o Processo de Teste. Apesar disso, a análise de risco voltada para o teste de software segue basicamente as mesmas regras e metodologias utilizadas em projetos de software em geral, o que a diferencia é o acréscimo de características próprias, focando os testes nos pontos mais relevantes, e priorizando a melhor utilização dos recursos disponíveis.
Para demonstrar essas características, ao longo do artigo apresentamos:
- Conceito
- Teste Baseado em Riscos
- Riscos Relativos ao Teste de Software
- Riscos do Processo de Teste
- Riscos Baseados nas Características de Qualidade
- Vantagens
De que se trata o artigo:
Neste artigo veremos como uma análise de risco específica para o teste pode garantir mais qualidade e mudar os custos de um projeto de desenvolvimento de software.
Em que situação o tema é útil:
Um risco não é uma certeza de ocorrência, é uma probabilidade, e deve ser tratado preventivamente para que um problema não ocorra. Tratá-lo diretamente no Teste de Software implica na identificação dos possíveis fatores de riscos pertinentes aos requisitos do software. Dessa forma o foco dos testes vai para as funcionalidades que podem gerar maiores perdas, fazendo com que os testes sejam mais eficazes e eficientes.
Resumo:
As organizações vêm apresentando uma constante preocupação com a qualidade de seus sistemas. Nesse cenário, o Teste de Software exerce um importante papel assegurando que os requisitos satisfaçam as necessidades do cliente, porém, demandando quase 2/4 do valor estimado para o projeto. Para minimizar alguns desses problemas, a Análise de Riscos surge para reduzir os custos e garantir mais qualidade ao software, priorizando os testes nos pontos mais relevantes.
28 Out 2011
AsEspecialistasPublicado em Comportamento, Profissão Tags: comprometimento, Diferencial, Links da Área, Novo no Teste, profissionais
É muito comum um profissional recém chegado na área de Teste de Software perguntar: Sou novo no Teste, por onde começo?
Muito é explicado sobre o que fazer tecnicamente, mas por que não explicar também um pouco sobre como (não) se comportar?
São muitas as características que um profissional do Teste de Software deve ter, e algumas delas são simplesmente fundamentais para o desempenho de um bom trabalho, por exemplo: detalhista, investigador, perfeccionista, questionador, criativo, organizado, pró-ativo, estar sempre disposto a aprender… Mas outro fator tão importante quanto, não pode deixar de ser citado: o profissional do teste deve ser comprometido.
Segundo Tom Coelho, consultor da Infinity Consulting, o comprometimento pode ser definido como algo que remete ao cumprimento de um pacto firmado. Significa honrar a palavra empenhada.
Para o Teste de Software, o comprometimento com a área requer antes de tudo um comprometimento com o seu próprio trabalho. Para isso, o primeiro passo é compreender que independente do tamanho da sua equipe, você faz parte de um time. E por causa disso, frequentemente o seu trabalho poderá ser generalizado como “o trabalho do Teste”, mesmo sendo apenas um dentre tantos outros colegas. Desse modo, se você errar, é o Teste que vacilou. Se você se expressar mal, é o Teste que não sabe se comunicar. Se você é desligado, desinteressado, faz as suas próprias regras e deixa o time em segundo plano, é o Teste é descomprometido.
Trabalhar sob pressão é um fator que anda sempre lado a lado com o Teste de Software. Seguindo uma linha de raciocínio baseada na metodologia tradicional de desenvolvimento (ainda dominante no mercado): se a turma dos Requisitos atrasa no levantamento, consequentemente a turma do Desenvolvimento entregará em cima da hora o projeto para equipe de Teste. Aí, como clientes/contratos não costumam ter muita flexibilidade (e paciência) para a morosidade na entrega, a turma do Teste paga o pato e tem que se virar, fazendo em uma semana o que deveria ser feito em três.
Se o time está repleto de profissionais sem comprometimento, o que será da qualidade desse software?
“Teste x Prazo” é um caso sério, a parte, mas “Teste x Comprometimento” é fundamental para realizar um trabalho digno do reconhecimento que nossa área busca. E esse reconhecimento só virá com muito esforço, execução precisa de toda a parte técnica, e claro, comprometimento. Caso contrário, possivelmente, todo o esforço virá por água abaixo caso se torne habitual para o profissional do Teste passar por situações do tipo:
• Faltar e justificar somente no dia seguinte, alegando que o celular estava descarregado.
• Chegar diariamente atrasado, mas desconsiderar esse atraso ao sair no fim do dia como se tivesse sido pontual.
• Tomar café durante 40 minutos pela manhã, e outros 40 minutos pela tarde.
• Sair no meio da manhã para ir resolver uma questão particular, e voltar 1 hora depois como se tivesse ido tomar uma água.
Alguns profissionais não percebem a urgência e importância de algumas tarefas específicas. Por falta de comprometimento (ou até mesmo por falta de maturidade), e não conseguem compreender nem o que a empresa espera dele e nem mesmo em qual “velocidade” a ativdade deve ser executada. Podemos ainda citar outros exemplos:
• Não entregar uma tarefa na data combinada sem avisar com antecedência;
• Ir embora sem terminar o que precisa ser entregue, porque simplesmente o horário de trabalho terminou;
• Não cumprir com uma ordem determinada, porque não concorda e nem ao menos questiona com argumentos lógicos e propondo novas idéias.
É percebido claramente os profissionais que são comprometidos através do seu comportamento perante determinadas situações. Algumas vezes percebemos que se não existe empenho, se não houver dedicação, o “resto” da equipe será julgado negativamente, e terá todo trabalho desmerecido por causa de uma pequena parte do time.
A idéia não é fazer com que cada membro do time seja perfeito, não é que precisemos ser “os que andam 100% na linha”. Sem literalidade, quem nunca se atrasou? Quem nunca precisou marcar um médico no meio do dia porque não tinha outro horário disponível? Quem nunca…
Não é uma questão de atirar a primeira pedra, mesmo porque muitos de nós erramos mesmo. Mas tudo tem que ser colocado na balança, ter bom senso.
Ok, há quem diga que errar é humano. Mas a função do Teste não é exatamente corrigir as falhas? Por que não começar aprimorando o lado comportamental? Evitando assim que situações como essas sejam recorrentes e se tornarem comuns no nosso dia a dia.
Se você está chegando agora (ou se já é um veterano), vista a camisa do Teste de Software de verdade, é uma área muito interessante, promissora e vem ganhando cada vez mais mercado. Faça o possível para agregar mais valor ao seu time, tenha em mente que ao cuidar dos testes de um projeto, você estará assumindo uma grande responsabilidade. Esteja ciente também de que o seu trabalho pode fazer toda a diferença. Busque o reconhecimento do seu trabalho. Sinta o quanto é gratificante escutar frases do tipo:
• “Aqui não sobrevivemos mais sem Teste”,
• “O Teste aqui é fundamental “,
• “Esse pessoal do Teste é empenhado”,
• “O pessoal do Teste conhece muito”…
Além de um possível sucesso do trabalho do time, esse esforço trará mais conhecimento, mais experiência e mais visibilidade para o seu trabalho.
A partir daí o Teste (e você) ganhará mais espaço, conquistará mais pessoas, e será demonstrada a nossa devida importância, possibilitando a busca de uma valorização justa para o seu trabalho. É claro que tudo isso não acontecerá do dia pra noite, só virá à medida que realizar um bom trabalho, frisando mais uma vez: através da junção da “técnica” com o “comportamento” comportamental.
São as “atitudes dos profissionais comprometidos e que acreditam no Teste, capazes de demonstrar através de números a sua importância, é que mudam a visão das empresas sobre qualificação e formação dos testers”. Definiu exatamente o nosso pensamento o comentário do Thiago Moreira em um dos nossos posts aqui no blog.
Comprometimento é uma questão “universal”, mas sob a perspectiva do Teste de Software é fundamental. Essa é uma área relativamente nova, que ainda precisa brigar muito pelo seu espaço. Se você quer mais por você, pela área, seja comprometido. Seja um profissional diferenciado no mercado.
17 Ago 2011
AsEspecialistasPublicado em Estimativas, Gestão de Defeitos, Métricas Tags: Estimar Testes, Mensurar, Métricas do Teste
Nas edições 92 e 94 da Revista Java Magazine, publicamos (respectivamente) os artigos “Estimativa x Teste de Software” e “Gestão de Defeitos no Teste de Software“.
Nesses artigos, falamos da importância de utilizar uma estimativa específica para o Teste dentro do ciclo de desenvolvimento de software para evitar que o mesmo seja colocado em segundo plano. Apresentamos também, conceitos, melhores práticas, vantagens e ferramentas que propiciam um melhor gerenciamento dos defeitos no Teste.
Atualmente o Teste de Software vem ganhando cada vez mais espaço no cenário dos projetos de software, porém, quando ocorre um atraso em alguma das fases do ciclo de desenvolvimento, o Teste acaba prejudicado, tornando-se assim uma atividade secundária e comprometendo a qualidade final do produto.
Uma maneira de contornar essa situação é criando uma estimativa específica para a fase de Teste dentro do ciclo de vida do desenvolvimento de software. O grande objetivo dessa estimativa voltada para o Teste é garantir mais qualidade em um tempo hábil, conforme planejado para o projeto como um todo.
Com o segundo artigo, apresentamos a Gestão de Defeitos, que também é uma outra maneira de contornar essa situação, pois possibilita uma visão geral e consequentemente um melhor acompanhamento do andamento do projeto, através da verificação dos bugs registrados.
Mas a questão é, depois de estimar e gerenciar os defeitos, como mensurar as atividades?
O objetivo desse nosso post é apresentar como as Métricas de Teste podem complementar as Estimativas e o Gerenciamento dos Defeitos, agregando ainda mais qualidade ao Processo de Teste de Software.
Afinal, o que são métricas de teste de software?
Uma métrica é um indicador de qualidade. Através da sua utilização, questões relacionadas ao software poderão ser respondidas. É uma excelente forma de verificar se os objetivos traçados para o processo de testes estão sendo alcançados, desde os pequenos projetos até mesmo nos casos em que o projeto é extenso e complexo. Através das métricas de teste, é possível traduzir a visão do negócio.
Dica: ao escolher uma métrica, três fatores devem ser priorizados: a simplicidade, a facilidade na coleta e a relevância que terá dentro do seu processo de teste.
Outro ponto importante na utilização de uma métrica é que deve estar claro para a equipe envolvida que as métricas não são uma ameaça. O propósito delas não é necessariamente avaliar cada integrante. Muito pelo contrário, de uma maneira simples, o objetivo de uma métrica de teste é coletar dados para analisar e propor melhorias.
Ao definir uma métrica, esteja certo de que as informações obtidas sejam consistentes, compreensíveis e claras. Não basta utilizá-las, é crucial que a análise das mesmas seja bem realizada. O foco deve se voltar sempre para trazer melhorias no processo, priorizar as ações preventivas, corretivas, e claro, agregar qualidade ao software.
A aplicação de uma métrica é realizada através da análise dos dados coletados, fazendo o levantamento das possíveis recomendações de mudanças para melhoria, comunicando os resultados aos interessados e por fim definindo as ações a serem tomadas.
Alguns exemplos práticos
As métricas utilizadas pela equipe de Teste visam adicionar mais qualidade ao produto final. Afinal, muitos são os relatórios gerados a partir da utilização de uma métrica. Esses dados são importantes para a avaliação da qualidade do software. Através deles é possível analisar a confiabilidade, a estabilidade e o desempenho do software. Algumas métricas podem ser coletadas de forma simples, sem alterar efetivamente o dia a dia de trabalho dos testadores, por exemplo:
- Base histórica: existe um registro histórico contendo informações detalhadas de projetos passados? Através desses dados é possível mensurar, para os próximos projetos a complexidade, a qualidade da especificação de requisitos e a experiência da equipe?
- Número de Ocorrências: das issues encontradas quantas são melhoria, quantas são efetivamente um erro e quantas não passam de sugestão?
- Gravidade dos Defeitos: qual a importância do bug encontrado? Ou melhor, qual o impacto pode sofrer o negócio em relação ao bug encontrado? É trivial, média ou obstáculo?
- Tempo Médio para Encontrar um Defeito: quais foram os esforços necessários para encontrar o bug?
- Efetividade de Caso de Teste: os casos de teste estão encontrando defeitos efetivamente?
- Número de Casos de Teste: qual a quantidade de casos de teste criados, executados, passaram, falharam e foram bloqueados? Qual o tempo de execução da baseline?
E quais as vantagens?
As vantagens de se utilizar uma métrica, no seu processo de Teste de Software são consideráveis:
- Apoio ao Gerenciamento: possibilita ao gerente visualizar o status atual dos testes e priorizar as atividades, na tentativa de reduzir os riscos e ultrapassar os prazos definidos para os mesmos.
- Analisar Defeitos: verificar que tipo de issues estão sendo encontrados nos testes.
- Analisar cobertura dos Testes: analisar qual a amplitude dos testes planejados.
- Avaliar o andamento dos testes: avaliar quais requisitos já foram testados.
- Identificar Riscos: é possível identificar área de risco que necessita de mais testes.
- Viabilizar a tomada de decisão: possibilita identificar quais ações devem ser tomadas na fase de teste.
- Avaliar produtividade do processo: avaliar se o processo está sendo seguido e se o mesmo está gerando o resultado esperado.
- Reduzir frustrações e pressões de cronograma: a medida que os problemas vão sendo identificados e as ações estão sendo tomadas para a solução dos mesmos, as previsões dos prazos de execução das tarefas vão fluindo com pouca ou sem nenhuma interferência. Reduzindo atrasos no cronograma.
E quem utilizará as métricas de teste?
Definir quem fará uso dos dados coletados pelas métricas de teste é tão importante quanto implantá-las. O stakeholder deverá ter em mente exatamente o que busca, para fazer uma leitura correta de tantos dados abstraídos do projeto. É possível buscar questões como:
- Quais os componentes que possuem defeitos que estão bloqueando o andamento dos testes?
- Como estão priorizadas as correções dos defeitos encontrados?
- Onde estão sendo encontrados mais defeitos?
- Qual a cobertura dos testes realizados até agora?
Será que no meu trabalho isso vai funcionar?
Tente visualizar a sua realidade, e analise a viabilidade da implantação de uma métrica.
a) Pense duas vezes antes de tentar implantar uma métrica, se:
- A sua equipe acredita que agilidade é tudo, e descrever mais detalhadamente um bug, por exemplo, vai só demandar mais tempo.
- Para a sua equipe apenas entender o problema de forma objetiva e sem “frescuras”, já é o suficiente.
- Sua equipe, antes mesmo de tentar utilizar uma métrica, se recusa a preencher corretamente os dados necessários para levantamento das métricas, por acreditar que isso apenas torna o trabalho mais burocrático.
b) Por outro lado, por que não funcionaria, caso:
- As informações coletadas realmente serão analisadas, buscando a melhoria do processo.
- A equipe está engajada, e disposta a preencher coerentemente os dados necessários para o levantamento da métrica
Enfim, depois de analisar se vale a pena utilizar, surgiria um novo dilema: Qual métrica utilizar? Existem diversas métricas que podem ser utilizadas, mas na realidade, a escolha dependerá da experiência da equipe envolvida, bem como da necessidade e do tamanho do projeto. Não existe nenhuma restrição quanto à utilização de mais de uma métrica em um mesmo projeto. Às vezes, a junção de algumas delas pode agregar ainda mais qualidade ao produto. Inclusive, é muito interessante que diferentes métricas sejam comparadas visando fornecer um parecer confiável dos testes.
E aí, acha interessante experimentar?
Anterior
