domingo, 13 de fevereiro de 2011

Especialização é o melhor caminho?

Essa pergunta é frequente em várias áreas de atuação, principalmente quando o assunto é a busca por maiores níveis de produtividade e qualidade diferenciada em relação à concorrência.
Quando pensamos no processo de desenvolvimento de software essa questão torna-se ainda mais intrigante, pois trabalhamos com atividades nem sempre muito exatas; talvez quase nunca! Desenvolver um software e também testá-lo com excelência, geralmente requer muita imaginação, intuição e outras aptidões, que em cenários de grande especialização podem ficar prejudicadas.

Nesse contexto, uma especialização elevada na execução das atividades pode comprometer os resultados, mais do que alavancá-los pela maior produtividade e qualidade supostamente decorrente dessa especialização. Mas por que isso ocorre, se em tese, teríamos profissionais mais capacitados e com perfil mais adequado a cada área de atuação?


De fato, a especialização pode trazer um conhecimento específico e um foco no resultado que deveria ter como consequência a excelência e maior produtividade na execução de um processo produtivo. O problema é que não somos máquinas em uma esteira de produção, integradas através de interfaces cuidadosamente projetadas e ajustadas. Isso ocorre em uma montadora de automóveis, por exemplo, onde robôs executam atividades repetitivas e sem a necessidade de "pensar diferente".  Nesse caso, produtividade e exatidão são palavras de ordem!

Entretanto, os profissionais de tecnologia são únicos e repletos do pensar diferente, como só os seres humanos conseguem ser. E isso é muito bom! Mas será então impossível falarmos de especialização em nossa área? 

Acredito, sinceramente, que podemos trabalhar de forma especializada ao longo do processo de desenvolvimento de software, mas também que devemos ter um cuidado extremo com as interfaces entre as diversas áreas de especialização intervenientes em nossos projetos. Quando pensamos em especializar nossas equipes, temos que cuidar para que os processos da organização garantam uma integração efetiva entre elas, pois sem isso estamos mais expostos a conflitos e desacordos, por não se ter uma visão clara e recíproca das necessidades e problemas de cada área envolvida, o que pode comprometer significativamente as chances de sucesso dos projetos.

Assim, para uma organização que deseja implementar a especialização em suas áreas produtivas, faz-se necessária a existência de processos em constante evolução e melhoria, ajustáveis a novas situações trazidas pelos projetos. Além disso, a atuação correta e tempestiva dos níveis gerenciais e lideranças da organização é fundamental, no sentido de viabilizar um ambiente propício à motivação, capacitação e integração das equipes especialistas. 

 E talvez aí esteja o maior problema e não na especialização!

domingo, 12 de setembro de 2010

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.

terça-feira, 22 de junho de 2010

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.

domingo, 30 de maio de 2010

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.


segunda-feira, 12 de abril de 2010

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.