Análise de Riscos e o Teste de Software

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.

O Profissional do Teste x Comprometimento

É 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.

As Métricas e o 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?

Gestão de Defeitos no Teste de Software

Gestão de Defeitos no Teste de Software é o tema do nosso novo artigo.

Ele está na Edição 94 da Revista Java Magazine, que está disponível online. Temos o maior prazer de apresentá-lo. Segue um trechinho:

De que se trata o artigo:
Neste artigo veremos os conceitos, melhores práticas, ferramentas, vantagens do gerenciamento de defeitos e como ele é fundamental no processo de teste de software.

Em que situação o tema é útil:
O processo de desenvolvimento de software cria produtos com defeitos. Na maioria das vezes, os defeitos são considerados riscos para a imagem da empresa e o negócio. Por isso, apenas descobri-los não é suficiente. É fundamental adotar o gerenciamento de defeitos no processo de teste para que os riscos sejam minimizados, controlados, evidenciados e o seu impacto não seja grande.

Resumo DevMan:
A gestão de defeitos é essencial para lidar com os problemas encontrados durante todo o ciclo de desenvolvimento de software. Neste artigo, são apresentados conceitos e ferramentas que propiciam um melhor gerenciamento das atividades de Teste, garantindo mais qualidade ao processo de desenvolvimento como um todo.

Há quem diga que encontrar defeitos é a finalidade exclusiva do Teste de Software, mas não é bem assim. O grande objetivo do Teste é garantir qualidade ao sistema, o que não quer dizer que o mesmo vai ser entregue ao cliente sem nenhum problema. Garantir qualidade significa minimizar os riscos e deixar o produto final com o menor número de erros possível. Risco é a probabilidade de insucesso, em função de algum acontecimento eventual, incerto, cuja ocorrência não depende exclusivamente da vontade dos interessados. Para evitar os defeitos, diminuir os riscos torna-se fundamental. Afinal, quanto menor o risco, menor a probabilidade de encontrar bugs. Essa afirmação deve ser aplicada tanto para o projeto de desenvolvimento de software, como para o de Teste.

Seria perfeito se os defeitos não existissem, e os bugs jamais impedissem o bom funcionamento de um software. No entanto, enquanto não chegamos a essa situação ideal, gerenciar os defeitos produzidos torna-se essencial.

Mudanças no processo de desenvolvimento de software ocorrem a todo o momento, por inúmeras razões, como restrições de tempo e custo, novas possibilidades de negócios e alteração nas necessidades de clientes. Em função disso, saber identificar a importância dos defeitos é fundamental para entender o impacto que eles causarão no sistema e nos negócios da empresa.

Por isso, é importante que a gestão de defeitos seja realizada, pois a mesma possibilita uma visão geral e consequentemente um melhor acompanhamento do andamento do projeto, através da verificação dos bugs registrados.

Neste contexto, a qualidade do sistema pode ser medida a partir dos bugs encontrados durante todo o seu ciclo de vida, desde a fase de projeto, até ser colocado efetivamente em produção. E para que os bugs sejam gerenciados com sucesso, é necessário que a gestão de defeitos seja utilizada de maneira simples, tornando-se de fundamental importância dentro de um processo de Teste de Software.

Leia na íntegra o artigo, através do link: Gestão de Defeitos no Teste de Software – Revista Java Magazine 94

As Especialistas: 1 Ano!!!

Oi Pessoal,

Estamos em festa, afinal, nesse mês completamos: 1 Ano de Blog! Conversando a respeito, fizemos uma retrospectiva desse período e gostaríamos de compartilhar com vocês…

O COMEÇO

Durante o MBA, nos nossos bate-papos informais sempre surgiam assuntos a respeito da nossa profissão, dos caminhos que seguiríamos na área de Teste, o que faríamos para nos qualificarmos cada vez mais, estudarmos, obtermos informações e divulgarmos sobre a nossa experiência.

Num desses bate-papos, estava presente o Thiago Moreira (profissional do desenvolvimento de software e entusiasta da área) que nos ouvia com a sua paciência habitual. Falávamos sobre a nossa idéia inicial de montarmos um grupo de pessoas do Teste para estudarmos e trocarmos experiências.

Foi quando ele deu a sua opinião sugerindo a criação de um Blog que tratasse exclusivamente assuntos relacionados ao Teste de Software, pois segundo o mesmo, existia uma carência de informações a respeito da nossa área. Ouvimos atentamente a sua brilhante idéia e resolvemos colocá-la em prática.

É lógico, que surgiram as dúvidas, as inseguranças e as opiniões divergentes. Afinal, somos duas pessoas bem diferentes! Mas o interessante é que essas diferenças, somaram, agregaram valor a nossa parceria. As nossas experiências profissionais eram muito semelhantes e possuíamos um objetivo profissional único o que nos incentivou criarmos verdadeiramente o blog e mantê-lo.

OS DESAFIOS

Decidimos então colocar o blog no ar assim que terminássemos o MBA. Apresentamos o nosso trabalho de conclusão de curso e nos sentimos ainda mais confiantes para escrevermos sobre os conhecimentos adquiridos. Além disso, pensamos que teríamos mais tempo para nos dedicarmos ao blog. Mas não foi bem assim…

Com o blog no ar, vieram os desafios: escolher os temas, estudarmos sobre os mesmos e escrever, ou seja, mantê-lo “vivo”. Além disso, cumprir com a missão de divulgar e disseminar o Teste, nos atualizarmos e nos aprofundarmos cada vez mais nesse mundo novo, promissor e fascinante do Teste de Software.

As recompensas compensavam as dificuldades, tivemos bons feedbacks de muitas pessoas que estavam seguindo o nosso blog, acompanhando o nosso trabalho. Os profissionais estavam gostando do que a gente falava. Ficamos mega felizes com a boa receptividade. Percebemos então, que o esforço estava valendo à pena!

AS BOAS SURPRESAS

Através do nosso Blog, tivemos a surpresa de sermos convidadas para escrevermos artigos para a revista Java Magazine. Ficamos muito felizes com o convite e pensamos, “bora para mais desafios!”. Porém, não imaginávamos o trabalho que nos esperava. E o nosso maior desafio foi tentar conciliar todas as nossas responsabilidades!

Esse desafio existe até hoje, mas como sempre, o resultado compensa o nosso esforço, pois com os artigos para a revista continuamos cumprindo com o nosso objetivo de divulgar e disseminar o Teste (esse é o nosso lema!), porém, agora para um público bem maior.

O mais interessante é que estamos tendo a oportunidade de divulgarmos não só para o público de profissionais da área de Teste, mas também para os do desenvolvimento (público da revista), quem sabe eles não são contaminados pelo “vírus” do Teste?!

OS RESULTADOS

Os números são bem estimulantes. Até hoje, o nosso blog foi acessado por aproximadamente 10.000 visitantes. Além disso, os nossos artigos foram acessados através do site da revista por mais de 3.500 pessoas, sem contar com os assinantes da revista impressa. Para nós, esse número representa uma vitória.

Constantemente recebemos um pedido de ajuda, uma sugestão, um comentário, e claro, existem também as críticas.

Ah! As “críticas”. Há quem reclame que demoramos na resposta de um e-mail, que diz que não respondemos em tempo hábil no gtalk. Quem critica algo que deduz que escrevemos (antes de ler na íntegra do que se trata). Tem também aqueles super literais, que acreditam que tem que levar a ferro e fogo o que falamos, ao invés de tentar adaptar à realidade de onde trabalha… Mas essa parte “negativa”, não tá pesando muito na balança não, viu…

Ao longo desse ano, recebemos muitos feedbacks. E ficamos verdadeiramente felizes com cada um deles. Dos negativos, tentamos abstrair o que precisávamos melhorar. Dos positivos, tentamos entender como continuar fazendo algo bacana. Para ilustrar, um comentário recente enviado no grupo de discussão DFTestes (recomendamos!), representa o nosso sentimento de missão cumprida.

“Li o artigo e foi o maior ajuda que já tive em Teste de Software. Digo isso porque o material de estudo pra esse assunto é sempre vago e de início nunca se sabe por onde começar ou como começar o processo de teste dentro de um projeto…” (Lorena Caldas, se referindo a um dos nossos artigos na Java Magazine, `Adotando Checklists no Teste de Software`)

É exatamente por isso, que continuamos, mesmo com tantos desafios!

O FUTURO

Temos muitos novos projetos para a nossa parceria profissional e continuar mantendo o nosso Blog é um deles. Estamos conseguindo alcançar o objetivo que nos propusemos, e vamos continuar mantendo a nossa missão.

Gostaríamos de agradecer ao Thiago Moreira nosso mentor, aos nossos “consultores” Camilo Ribeiro, Fabricio Ferrari e Elias Nogueira, que tanto nos apoiaram no nosso começo. Queremos agradecer também às pessoas que nos seguem e torcem pela gente e a todos os profissionais da área de Teste que buscam o mesmo objetivo que o nosso.

Somos apaixonadas pelo que fazemos e acreditamos que estamos no caminho certo!

Abraço turma,
Vivian Lagares e Renata Eliza.

Anterior