Recentemente chegou às bancas a edição de número 09 da revista MundoDotNet. Essa edição conta com um artigo onde descrevo uma técnica interessante para administração de cenários de testes implementada com sucesso pelo meu colega Paulo Cesar Fernandes aqui na empresa.  A técnica consiste em interceptar a execução de métodos de forma a armazenar objetos construídos durante a execução da aplicação em um banco de dados orientado a objetos. Assim, esses objetos podem ser carregados na memória no momento em que são necessários para o SetUp de testes unitários. Na verdade, o artigo foi um pouco além de descrever a técnica. Grande parte do texto é dedicada a explicar as raízes e as várias formas em que técnicas de teste podem ser utilizadas para aumentar a qualidade do software no contexto de um projeto ágil. Alguns tópicos e trechos do artigo Uma nova visão para as atividades de teste de software:  A relação das atividades de teste com qualidade. Algumas das idéias de Deming que podem ser utilizadas em desenvolvimento de software. A relação de Deming com o estilo de administração japonês que levou ao Movimento Ágil e as técnicas que este movimento trouxe de forma a permitir a redução de inpeções no software. Testes como oportunidades para aumentar a qualidade: Em projetos ágeis, testar significa criar oportunidades para que o produto absorva elementos de qualidade de forma permanente. "Um teste automatizado injeta qualidade dentro do software". Quando testes automatizados podem aumentar a qualidade do processo:  Testes de aceitação automatizados criam as condições para melhoria do processo de desenvolvimento na medida em que estabelecem um instrumento de colaboração e de comunicação entre clientes e desenvolvedores. "o propósito de um teste de aceitação é aumentar a qualidade do processo de comunicação necessário para as atividades de análise e levantamento de requisitos, por meio de especificações executáveis". Quando testes automatizados podem aumentar a qualidade do produto: Aqui a defesa é que o uso de TDD aumenta a qualidade interna do produto na medida em que cria as condições para a evolução sustentável do software. "o propósito do teste unitário é influenciar o design da aplicação, permitindo que ele evolua sem sofrer os danos causados pelo seu processo de degradação". O artigo também oferece um rápido exemplo de como uma ferramenta como o Fitnesse pode criar especificações executáveis fáceis de ler e de produzir. Conforme imagem a seguir:   A abordagem Ágil oferece uma nova perspectiva para endereçar qualidade de software. Acho que esse artigo dará ao leitor uma boa idéia do que isso quer dizer.

Posted by: alisson.vale
Posted on: 6/17/2008 at 9:43 PM
Tags: , ,
Categories: Coding | Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (3) | Post RSSRSS comment feed
 
 
Embora Quality has nothing to do with testing seja um ótimo post que vale a pena dar uma olhada, acho que o título ficaria melhor formulado como Quality has nothing to do with finding defects. Testes são instrumentos de feedback que obtemos do software quando comparamos seus resultados com nossas expectativas. Assim, quando o resultado de um teste é associado com a completude de uma expectativa, ele é sim um importante instrumento de qualidade. O mérito do post está em desmistificar as atividades de teste como sendo as únicas necessárias para garantir a qualidade do software. Na verdade, o que ocorre é que as atividades de teste perdem dramaticamente o poder de agregar valor em termos de qualidade quando são utilizadas como instrumento de inspeção-para-a-localização-de-defeitos. Se uma feature sai do ambiente de desenvolvimento sem funcionamento adequado, será certamente mais apropriado parar e descobrir porquê isso ocorreu do que registrar os problemas em um bug tracking e depois continuar o trabalho de inspeção incansável até que nenhum problema seja mais encontrado. Uma melhor opção é utilizar as atividades de testes como instrumentos para prevenção-de-defeitos. Ao criar, por exemplo, um teste automatizado, não há inspeção. Há a formalização de critérios de aceitação que passarão a conviver eternamente de forma agregada ao produto à partir daquele momento. Assim, somos capazes de introduzir qualidade no produto no mesmo passo em quê o desenvolvemos. A qualidade dos incrementos de software liberados em um projeto Ágil depende muito do efeito conjunto resultante da aplicação de diferentes tipos de técnicas e práticas, cujo intuito central é evitar que defeitos sejam introduzidos no produto. A ação conjunta desses elementos tem o poder de eliminar (muitas vezes por completo) a necessidade de inspeções-para-a-localização-de-defeitos. Testes orientados para inspecionar aquilo que, já no seu início, é produzido sem levar em conta os vários aspectos de qualidade relevantes para desenvolvimento de software, são nocivos na medida em que criam uma cultura em que quem desenvolve não precisa garantir a qualidade daquilo que faz, pois há uma implícita delegação para que isso seja verificado por uma outra pessoa.    No entanto, inspeções não serão sempre ruins. Há as inspeções boas também. Elas ocorrem quando o foco é gerar feedback. Ao inspecionar uma nova funcionalidade, por exemplo,  o foco de quem inspeciona não precisa ser verificação e conferência. O objetivo da boa inspeção é dar feedback, é oferecer um novo ponto de vista de modo a encontrar pontos que poderiam estar melhor resolvidos. O mesmo ocorre quando inspecionamos código, seja passando o código para um colega inspecionar, ou seja fazendo inspeção contínua com pair programming. Em ambos os casos, a procura-por-problemas é elemento secundário, enquanto que feedback é o elemento central. Em resumo, a inspeção ruim procura por defeitos, enquanto que a boa gera feedback.

Posted by: alisson.vale
Posted on: 6/10/2008 at 10:37 PM
Tags: ,
Categories: Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Talvez as questões de garantia de qualidade estejam dentre os assuntos mais misteriosos para aqueles que ainda estão começando a trilhar os primeiros passos em métodos Ágeis. Muito se fala em testes de aceitação, TDD, testes unitários, mas é só isso? Qualidade em projetos ágeis se assegura somente com testes automatizados? A resposta é não. Essas técnicas são importantes, mas há todo um universo conceitual por trás dos projetos ágeis que poderão lhe ajudar a não só explicar como isso se dá, mas também a aplicar pequenas melhorias que podem causar grande repercussão no seu processo.  O primeiro ponto a se entender é que qualidade é um meio não um fim. A idéia é não procurar montar um processo cujo objetivo seja gerar um produto de qualidade. O ideal é fazer com que a própria busca pela qualidade oriente a formação do seu processo. A forma como um projeto ágil lida com qualidade está muito sintonizada com as idéias de Edward Deming e com o modelo de administração e gerenciamento oriental (muito influenciado por ele). O modelo ocidental lida basicamente com o uso de inspeções em massa para assegurar qualidade. O mesmo modelo é utilizado pelos processos tradicionais de desenvolvimento de software. A idéia é mais ou menos a seguinte: Depois que está tudo pronto, vamos testar pra ver se funciona. Talvez por isso a idéia de se criar testes antes de se escrever o software seja considerada tão "excêntrica" por aqueles que ainda não conhecem a abordagem ágil. O modelo mental de se testar só depois que algo é considerado pronto é muito forte. Não foram poucas as vezes que eu ouvi me dizerem: "Mas pra quê eu vou testar agora se ainda não está pronto?" Assim, para entender como se garante qualidade em projetos ágeis, há 5 pontos que acho serem fundamentais: 1. Não depender de inspeções para garantir qualidade: Se você inspeciona seu software com a expectativa de encontrar defeitos, seu processo ainda não tem qualidade. Então, invista em qualidade durante a produção, não depois. Inspeções são ineficientes porque não previnem o problema, apenas o encontram. Em quê ajuda encontrar um erro em uma inspeção? O erro já está lá! Inspeções são necessárias, certamente não vamos conseguir viver sem elas tão cedo. Mas encontrar erros em uma inspeção no final do processo é desperdício. Considere que há duas maneiras de evitá-las ou reduzir a dependência que você tem delas: Inserindo qualidade no produto. Aqui entra a figura dos testes automatizados. Antecipando as inspeções de modo que elas aconteçam antes que um defeito seja inserido no produto. Como? Muitas práticas ágeis já ajudam muito, cada uma da sua forma: Integração Contínua, times multi-disciplinares, shared workspaces,  daily meetings, pair programming, TDD, code e design Inspections e outras. Cada prática dessas traz consigo uma diferente forma de inspeção. Você também pode ajudar fazendo testes durante o processo de produção, não depois. Um exemplo é chamar alguém para testar o que foi feito, antes que o software saia da máquina do desenvolvedor. É o melhor momento para se encontrar um problema.  Se deixarmos pra testar tudo no final de uma iteração, as chances de não entregar nada no final são grandes. 2. Valorize a prevenção, não a detecção. Encontrar um defeito não pode ser algo comum. O processo de prevenção deve ser revisado imediatamente. A equipe não deve ir adiante enquanto houverem defeitos. Há várias formas de se trabalhar com prevenção, uma delas é a automação. Por exemplo, automatizar o deploy e a instalação do seu software é investir em prevenção. Um grande número dos problemas encontrados em ambientes fora da fronteira da equipe estão associados às configurações necessárias para se instalar e rodar o software produzido. Os próprios desenvolvedores devem ser capazes de incorporar os recursos que ele precisa para ser instalado. Assim, é o desenvolvedor que tem que indicar que scripts de banco devem ser rodados e que arquivos de configuração devem receber novas entradas. É comum o uso de uma gerência de configuração para isso. Mas é desnecessário quando há automação. Aqui no nosso projeto, o próprio desenvolvedor que produziu a funcionalidade configura tudo que será preciso ser executado quando da instalação do software. A automação elimina a necessidade de intermediação. Isso aumenta a qualidade porque elimina mais um hands-off do processo. 3. Não confie nas especificações como forma de garantir satisfação dos usuários. Se seu projeto ainda está atrelado à necessidade de se desenvolver para atender uma especificação, saiba que elas não são capazes de contar toda a história. Especificações não são bons instrumentos para descrever como um software deve funcionar. A melhor maneira de aumentar a qualidade que o seu cliente percebe no seu produto é envolvendo-o no processo. Ciclos de feedback geram aprendizado, confiança e ajudam o usuário a encontrar a melhor solução. Seguir uma especificação é separar o problema da solução e direcionar o cliente para apenas descrever o problema, enquanto você fica responsável pela solução. O ideal é que o problema e a solução estejam no mesmo contexto, e que eles sejam trabalhados em conjunto. Se, de alguma forma, o cliente contribuir para a solução, ele não só ficará mais satisfeito, como também se tornará seu cúmplice e o ajudará nos momentos difíceis pelos quais você pode chegar a passar. 4. Qualidade não se controla, se incorpora. Em caso de equipes de projeto, não acredito que bugs aparecem por causa de desenvolvedores ruins (talvez problemas de design ou de performance apareçam por causa de desenvolvedores ruins). Bugs aparecem porque a falta de qualidade do processo permitiu. Assim, medidas de punição ou recompensa, ou qualquer outra abordagem top-down para tentar reduzir bugs não funcionam a longo prazo. É injustificável ficar tentando controlar algo tão precioso - como é o caso da qualidade - quando é possível incorporá-la ao seu dia-a-dia.    5. Treine a aquisição de habilidades, não o uso dos instrumentos. As pessoas são capazes de se tornarem multi-disciplinares. Basta treiná-las para isso. Você vai incorporar qualidade ao seu processo na medida que investe nas pessoas para que elas adquiram novas habilidades. Assim, treine: modelagem, não UML; padrões de arquitetura, não Webservices; design, não novos recursos da IDE; programação pragmática, não novos recursos de linguagem; a especificar testes, não a usar ferramentas de testes; Enquanto que os itens a esquerda geram novas habilidades nas pessoas, os itens a direita podem ser resolvidos com 20 minutos de pesquisa no google.

Posted by: alisson.vale
Posted on: 10/4/2007 at 1:35 AM
Tags: , ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Documentação em projetos ágeis sempre foi um assunto muito polêmico. Há ainda muita gente que a considera um mal necessário. Talvez não seja muito difícil definir uma boa estratégia de documentação se houver um pouco de bom senso e criatividade. Como disse Scott Ambler, um projeto ágil persegue dois objetivos. (a) Objetivo primário: Entregar software funcionando (b) Objetivo secundário: Dar sustentabilidade para o próximo esforço. Documentação tem haver com o objetivo secundário. O fato de ser secundário não o faz ser menos importante. O fato é que cada documento que uma equipe deve gerar tem um custo, e esse custo tem que ser muito bem dimensionado com relação ao benefício que ele causa. Um dos principais problemas da documentação é ela não estar atualizada. Uma boa abordagem para incentivar sua atualização é mantê-la o mais integrada possível com os outros artefatos que o desenvolvedor ou a área de qualidade trabalham no seu dia-a-dia. Assim será fácil e prazeroso mantê-la atualizada. Um exemplo disso pode ser observado na figura 1 (É melhor clicar na imagem para vê-la melhor). Ela representa um documento executável.   Figura 1: Exemplo de um documento executável Na verdade, trata-se de um documento para execução de testes web com o Selenium, mas ele tem algo mais dentro dele. Há comandos que não são interpretados pelo Selenium, mas por um outro tipo de parser que pode ser utilizado para transformar o documento em um outro artefato; fazendo-o servir para diferentes propósitos, como por exemplo, uma especificação funcional, um caso de uso ou até um manual de usuário. No exemplo da Figura 1, pode-se notar na coluna parâmetro I, que há comandos que serão executados para a criação automatizada de um manual ou de uma especificação (spec) ou de ambas (manual, spec). Diferentes outputs podem ser gerados dependendo de onde o documento será visualizado: pdfs, documentos words, ou ainda podem ser diretamente publicados em portais ou wikis. Veja, na Figura 2, qual seria o resultado desse documento publicado no mediawiki.   Figura 2: Visão do documento executável já transformado em uma página wiki Repare também que o documento pode ser diretamente mapeado com o sistema de issue tracking. No caso desse exemplo, por meio de uma integração do Mantis com o MediaWiki. O documento pode comportar também links para outros issues relacionados, bem como outros documentos executáveis. Trata-se de uma forma bem interessante de manter os documentos vivos, fazendo parte efetiva do processo de desenvolvimento. 

Posted by: alisson.vale
Posted on: 9/20/2007 at 11:14 PM
Tags: ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (3) | Post RSSRSS comment feed