O Custo da Qualidade de Software

Muito se fala sobre o custo elevado das atividades de teste e dos procedimentos que buscam garantir que um software tenha qualidade. Mas como um software adquire qualidade e quanto custa às organizações para que seus produtos atinjam um nível superior de excelência?

É possível que um software adquira qualidade tanto por uma construção que utilize processos maduros e bem definidos, como pela identificação e resolução dos problemas do software, antes que ele seja entregue aos usuários. Essa qualidade pode ser também atingida com a estabilização  pós-implantação do software, considerando nesse caso, a possibilidade de alguns ciclos desgastantes de ocorrência de falhas, identificação e correção de defeitos, com a liberação de novas versões da aplicação.

A cada uma dessas alternativas, está associado um custo específico. Esses custos, somados, constituem o custo da qualidade. O custo da qualidade é parte do custo total de produção do software, que contempla também os custos de sua construção.

Fonte: QAI - Quality Assurance Institute

Custo de Prevenção – Mais que um custo, é um investimento realizado para se evitar erros e fazer o trabalho certo na primeira tentativa. É um investimento com retorno a médio ou longo prazo e que contempla a criação de métodos e procedimentos, a melhoria de processos, a capacitação dos profissionais, a aquisição de ferramentas e o planejamento da qualidade. Esse custo ocorre antes da criação do produto.

Custo de Avaliação – Esse custo refere-se ao que é gasto em procedimentos de verificação e em testes dos produtos de software para identificação de defeitos, após a sua construção e antes que sejam disponibilizados para uso ou implantados em produção. Contempla tanto produtos intermediários, como documentos de requisitos, modelos de dados ou especificações, como também o produto de software final.

Custo de Falhas – Envolve todos os custos associados a produtos defeituosos, que já foram entregues aos usuários ou disponibilizados em produção e que geraram algum tipo de falha. Esses custos referem-se ao retrabalho para reparação de produtos defeituosos, ou a prejuízos decorrentes das falhas no software. Incluem-se nesta categoria, também os custos associados à manutenção de um Help Desk.

Considerando as categorias de custos que compõem o custo da qualidade, podemos perceber que ao investirmos estrategicamente na prevenção e na detecção de defeitos, os custos de falhas podem ser sensivelmente reduzidos, com reflexo direto sobre o custo da qualidade. Dessa forma, o custo total de produção de um software pode ser também diminuído, acompanhando a redução do custo da qualidade. Ponto para os processos de Garantia da Qualidade e de Testes de Software, que estruturam importantes atividades de prevenção e detecção de defeitos.

Desenvolvedores não gostam de testar!

Quando observamos os perfis psicológicos de desenvolvedores e testadores, percebemos algumas diferenças importantes na maneira de pensar desses profissionais.

Basicamente, os desenvolvedores têm suas energias direcionadas para a conclusão do projeto, sempre buscando executar com sucesso a implementação do software e provar que ele funciona. É uma forma de pensar muito diferente dos testadores, que estão sempre em busca de defeitos, certamente com o objetivo de trazer mais qualidade ao software, mas que pode parecer conflitante com a idéia de entrega do produto final. Até fora do trabalho, os testadores estão sempre procurando defeitos. Qual testador nunca se pegou perseguindo defeitos em placas de trânsito e anúncios pelas ruas ou em embalagens de produtos no supermercado? Esse comportamento faz parte do perfil do testador, que é um crítico por natureza.

Mas voltando aos desenvolvedores, sabemos que os testes podem e devem ser realizados também por  eles. A grande questão é como convencer um desenvolvedor a investir esforço em testar o seu produto. Os testes seriam sempre direcionados a provar que a aplicação funciona ou podemos adotar alguma abordagem que garanta uma certa isenção do desenvolvedor em relação ao produto e mais qualidade para os testes? 

Sabemos que uma boa parte dos defeitos pode ser identificada nos testes em nível unitário e integração, que normalmente ficam à cargo da equipe de desenvolvimento, quando existe na organização uma separação de papéis entre desenvolvedores e testadores. Dessa forma, a capacitação dos desenvolvedores para que realizem mais e melhor os testes sob sua responsabilidade, pode ser um investimento com possibilidades de excelente retorno para os projetos de desenvolvimento. Passar aos desenvolvedores conhecimentos básicos sobre testes pode fazer uma grande diferença na qualidade das aplicações. E nada que exija técnicas elaboradas de teste ou um esforço muito maior do que aquele já investido. Todo desenvolvedor testa, de alguma forma, a sua aplicação. O quanto ele testa é que é o problema. Como o seu foco é provar que a aplicação funciona, normalmente apenas o "caminho feliz" é testado e grande parte do código não é exercitado. 

Mesmo sem exigir profundos conhecimentos em testes, podemos ampliar significativamente a quantidade de testes executados, se no planejamento dos testes unitários e de integração for acordado um determinado nível de cobertura sobre o código, compatível com a criticidade da aplicação e com os riscos do projeto. Dessa forma, o desenvolvedor deverá perseguir essa cobertura do código em seus testes, sem necessariamente ter que modificar muita coisa na sua forma de testar. É claro que para que isso seja possível, será necessária a utilização de ferramentas apropriadas para avaliar o atingimento da cobertura esperada. Os testes nos níveis a cargo do desenvolvedor precisam ser apoiados por ferramental específico, de tal forma que o desenvolvedor possa direcionar sua atenção prioritariamente para o desenvolvimento e os testes ocorram de uma maneira natural para ele e com o menor esforço possível. A automação criteriosa dos testes e o direcionamento à cobertura do código podem evitar que grande parte dos defeitos seja identificada apenas em níveis posteriores de testes ou mesmo em produção, quando os custos de correção são muito maiores.

O mais importante de tudo isso é conseguir que o desenvolvedor teste o seu código com uma profundidade adequada, sem ser obrigado a realizar atividades que sejam conflitantes com o seu perfil. Com o apoio de ferramentas para avaliação da cobertura de código na execução dos testes,  o teste será encarado como um aliado pelos desenvolvedores, e a qualidade  final do software será a grande beneficiada.

Impressões sobre o CInTeQ 2010

Antes de qualquer comentário sobre o evento, gostaria de parabenizar a organização do CInTeQ 2010, pela iniciativa de trazer para o Brasil grandes nomes do teste de software, como Rex Black (foto ao lado), Eric van Veenendaal e Dorothy Graham. Iniciativas como esta são visionárias e permitem que os profissionais brasileiros mantenham-se atualizados em relação ao que acontece na área de testes e qualidade de software em todo o mundo. É importante ressaltar que algumas palestras nacionais também enriqueceram muito o evento, demonstrando que temos em nosso país profissionais extremamente capazes.

Gostei muito do congresso e as palestras que mais me chamaram a atenção foram:

• Teste de Segurança em Aplicações WEB - Palestrante: Eduardo Habib
• Lidando com os Desafios do Teste para as Metodologias Ágeis - Palestrante: Rex Black
• A Importância da Especialização dos Papéis em uma Fábrica de Testes - Palestrante: Emílio Castro
• Qualidade e Produtividade em Sistemas de Software: Um Desafio Brasileiro - Palestrante: Mauro Spínola
• Melhoria do teste com TMMi - Melhoria do processo para o presente e futuro - Palestrante: Erik van Veenendaal
• Ilusões Cognitivas no Desenvolvimento e Teste - Palestrante: Dorothy Graham

Outro aspecto importante desse tipo de evento, além das palestras com conteúdo de muita qualidade, é a oportunidade de contatos com diversos profissionais da área, que muitas vezes conhecemos apenas por listas de discussão ou através de seus blogs e artigos publicados. Um bom exemplo disso é o Fabrício Ferrari, que tive a oportunidade  de conhecer pessoalmente durante o evento. Pude perceber o entusiasmo e a dedicação do Fabrício em cobrir o evento e compartilhar com a comunidade tudo o que vimos nesses dois dias de congresso. O QualidadeBR, blog do Fabrício, traz uma cobertura bem completa e detalhada de todas as palestras. Não deixem de visitar esse excelente conteúdo!

Para quem não pôde participar neste ano, fica a dica: ao final do evento foi anunciado o CInTeQ 2011, que ocorrerá nos dias 28 e 29 de março do próximo ano. Programem-se desde já!

CInTeQ 2010

Acontecerá em São Paulo, nos dias 22 e 23 de março o CINTEQ 2010, um evento internacional sobre teste de software, promovido pelo BSTQB. Participaremos do evento, juntamente com outros profissionais do Banco do Brasil, que atuam na área. 

Seguem abaixo informações sobre o evento, que contará com a participação de vários nomes do teste nacional e internacional.

"O CInTeQ é um Congresso Internacional que apresenta assuntos relevantes sobre Teste e Qualidade de Software.

Ele vem preencher uma lacuna nos eventos nacionais, trazendo as mais importantes celebridades no assunto Teste de Software em âmbito mundial para o Brasil.

O Congresso vem em parceria com o encontro geral dos representantes mundiais do ISTQB organização que reúne mais de 40 países este ano na cidade do Rio de Janeiro. Por ser um evento fechado o BSTQB (representante brasileiro da organização) se mobilizou para trazer alguns destes representantes para realizar palestras e treinamentos para um evento que toda a comunidade tenha a oportunidade de falar e trocar informações com estes gurus da área.

Sendo realizado em São Paulo o CInTeQ pretende trazer um número elevado de participantes de todo o território nacional, já que possui toda a infra-estrutura de hotéis e transporte para os profissionais que desejem participar deste evento único no país."

Fonte: CINTEQ 2010.

Maiores informações: http://www.cinteq.org.br/

Gerenciamento do Tempo em Projetos de Teste

Quando falamos sobre o gerenciamento do tempo em nosso último post, destacamos que algumas atividades podem nos ajudar a obter um maior controle sobre o tempo. Sob a visão de gerenciamento de projetos, essas atividades estão relacionadas principalmente à área de conhecimento de Gerenciamento do Tempo. Mas podemos perceber uma forte relação também com outras áreas, como  Gerenciamento de Custos, Riscos, Escopo, Qualidade e Integração.

Um dos primeiros e principais insumos para o gerenciamento do tempo dos projetos é o seu escopo,  que pode ser representado pela  Declaração de Escopo do Projeto, pela Estrutura Analítica do Projeto (EAP) e pelo Dicionário da EAP. Além do escopo, o Plano de Gerenciamento do Projeto também é um importante insumo para que o líder do projeto possa identificar as atividades que devem ser executadas.

Notem que quando falamos do projeto de teste, temos um escopo que é definido principalmente pelos requisitos do software, os quais serão validados através dos testes. Esses requisitos normalmente são entregues em pacotes, o que nos permite organizar as atividades de teste seguindo essa previsão de entregas. Mas atividades adicionais podem ser necessárias para cumprirmos os objetivos dos testes,  mesmo não sendo atividades de teste propriamente ditas e devem ser consideradas para um efetivo gerenciamento do tempo. Um bom exemplo disso, seriam atividades relacionadas à capacitação da equipe ou à aquisição e implantação de alguma ferramenta necessária à realização dos testes.

Definidas as atividades necessárias ao cumprimento dos objetivos do projeto de testes, precisamos organizá-las no tempo, estabelecendo uma sequência lógica de execução. Para esta organização, além das técnicas de sequenciamento previstas na literatura para todos os tipos de projetos, nos projetos de teste devemos observar também a relevância e os riscos associados aos requisitos, para estabelecermos aquilo que merece maior atenção. Isso pode afetar as relações de precedência entre as atividades. Em seguida, deve ser identificado o que será necessário prover para que cada atividade possa ser realizada, incluindo pessoas, equipamentos e ferramentas. O quanto de cada recurso, quando será utilizado e por quanto tempo, são também definições que ocorrem nesse momento e impactam fortemente os custos do projeto.

Todas essas definições são pré-requisitos para o desenvolvimento do cronograma de testes, que é um processo iterativo. Mas elas podem também ser afetadas pelo cronograma, o que pode exigir revisões sobre as estimativas de recursos e prazos já estabelecidos. É importante observarmos que o cronograma evolui  ao longo do projeto de teste, sensibilizado por mudanças no plano do projeto e em seu cronograma ou por ações decorrentes do gerenciamento de riscos associados ao projeto e seu escopo.

Gerenciar o tempo de projetos e principalmente de um projeto de testes, exige um acompanhamento cuidadoso do andamento das atividades, das mudanças ocorridas e da evolução dos riscos e do escopo do projeto. Em muitas ocasiões pode ser necessário sacrificar determinadas atividades para que os prazos do projeto sejam cumpridos. Nestas situações, é importante termos total controle sobre o cronograma e sobre o escopo dos testes. Isso nos permitirá reportar com propriedade aos intervenientes do projeto, o que está sendo sacrificado e quais os prejuízos à qualidade dos testes, informações preciosas para a tomada de decisão.