Como testar quando a documentação é precária?

A importância da documentação para a realização de testes é sempre tema de muita discussão.

Quando falamos de projetos de desenvolvimento de software onde seguimos uma esteira rápida de produção ou quando a complexidade da solução é considerada baixa, normalmente a documentação é bastante simplificada e em muitos casos até desprezada. O fato é que a produção de documentação nesses projetos é normalmente vista pela maioria dos envolvidos no processo de desenvolvimento como perda de tempo e burocracia inútil.  

Isso pode trazer muitos problemas para as equipes de testes, que têm seu trabalho dificultado pela falta de insumos. Entretanto, essa dificuldade não deve ser motivo para que os testes sejam deixados de lado ou para que seja dispensada a participação de equipes de testes independentes. Mesmo com pouca documentação, é possível que essas equipes realizem testes importantes em nível de sistema, complementando a visão dos desenvolvedores sobre a qualidade da solução.

Outro ponto importante, é que pouca documentação certamente é melhor que nenhuma! E em muitos casos, pode ser até melhor termos uma documentação simplificada, mas que agregue real valor ao produto, do que uma ampla documentação, que não possa ser mantida atualizada e que não seja confiável, ou ainda, que não seja mais utilizada após a sua produção, representando um custo desnecessário para o projeto. Mesmo quando temos apenas uma definição simplificada do escopo da solução a ser construída, podemos estruturar nossos testes funcionais de tal forma que seja garantida a rastreabilidade em relação aos requisitos definidos. Isso é importante tanto para a organização dos casos de teste, como também para a avaliação da cobertura obtida na execução dos testes, sejam estes previamente projetados ou realizados de forma exploratória.

Mas como executar os testes se não temos uma documentação suficiente para compreendermos o comportamento esperado do sistema?  Não existe milagre! Quanto menos documentação estiver disponível, maior deverá ser a interação entre os envolvidos no projeto. O problema é que os desenvolvedores também sofrem pressões por uma entrega rápida e não têm muito tempo e nem disposição para explicar o funcionamento do sistema aos testadores. Mas será que isso é mesmo um problema?

Ao tratarmos a importância dos testes de aceitação em nosso último post, ressaltamos que a aproximação entre a equipe de testes e o cliente pode ser muito útil para a construção de roteiros de aceitação e maior detalhamento dos requisitos. Esta certamente é uma estratégia muito útil também quando nos defrontamos com um cenário de documentação escassa nos projetos, pois o cliente pode fornecer à equipe de testes informações preciosas sobre o funcionamento do sistema, desonerando os desenvolvedores desta tarefa. Na verdade, isso pode representar um importante benefício para o projeto, pois não teremos a contaminação dos testes de sistema pela visão do desenvolvimento, além de podermos identificar inconsistências entre as necessidades apresentadas pelo cliente e os requisitos especificados e utilizados para a construção do software. Ao aproximar-se do cliente, a equipe de testes obtém informações que lhe auxiliarão tanto no entendimento de detalhes importantes do sistema como na especificação dos testes, mesmo sem a utilização de uma documentação formal.

Assim, acreditamos ser possível contornarmos uma eventual precariedade da documentação em um projeto de desenvolvimento de software, com uma comunicação mais efetiva entre as equipes de testes e o cliente, permitindo a realização de testes com um bom nível de detalhamento, sem prejuízo ao relacionamento entre testadores e desenvolvedores e à celeridade na entrega das soluções.

A importância dos Testes de Aceitação

Quando falamos em testes de aceitação, normalmente nos lembramos da execução dos testes, quando o cliente ainda encontra alguns defeitos, mas que principalmente serve para a aprovação da solução entregue.

Certamente, a execução dos testes de aceitação é muito útil para que o cliente adquira confiança na qualidade do software, para mensurar a efetividade dos testes executados nos níveis anteriores ou para identificar alguns defeitos residuais. Mas uma grande contribuição que os testes de aceitação trazem para a qualidade da aplicação não está relacionada à execução dos testes, mas ao seu planejamento e projeto.

Ainda nas fases iniciais do desenvolvimento do software, quando seus requisitos estão sendo especificados com a participação do cliente, os testes de aceitação são também planejados e projetados. Esta atividade permite a construção de casos de teste, que mais tarde orientarão a execução dos testes de aceitação. Mas permite também a validação da definição dos requisitos pelo cliente, quando ele fundamenta e aprova o planejamento dos testes e os casos de teste projetados para a aceitação. Dessa forma, podemos evitar que determinados problemas na especificação dos requisitos passem para fases seguintes do desenvolvimento, o que pode comprometer a qualidade do software em construção e gerar retrabalho para o projeto. Além disso, é possível aproximar a visão das necessidades apresentadas pelo cliente dos requisitos efetivamente documentados, estabelecendo-se um acordo sobre os critérios de aceitação a serem observados na entrega da solução.

Portanto, com o apoio dos testes de aceitação, a qualidade do software pode ser beneficiada, tanto pela execução como pelo planejamento e projeto dos testes, que contribuem para a melhoria da especificação dos requisitos.

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á!