Pular para o conteúdo principal

A terceira camisa: os exemplos estão virando fashion


Um olhar diferente sobre 3 formas de expressar o comportamento esperado de um sistema:
requisitos, testes e exemplos. Temperadas por uma metáfora esportiva.


Neste feriado, li uma matéria na revista Veja sobre as terceiras camisas dos clubes de futebol, que chamou minha atenção.
Os clubes de futebol sempre tiveram uma camisa oficial. Sempre houve também a camisa reserva, tradicionalmente usada quando o time não tem mando de campo e o padrão da camisa é parecido com o do rival. Mas, de um tempo para cá, a estrela é uma terceira camisa alternativa, utilizada para comemorar algum fato relevante: o centenário do clube, a obtenção de um título, a contratação de um craque ou, no fim das contas, para alavancar as vendas dos itens oficiais do clube. Camisas corinthianas listradas com roxo, torcedores da Lusa com uma cruz metaleira, cruzeirenses em degradé: campeões de vendas nas lojas esportivas.
Assim, algo ao qual que a maioria não dava muita importância (a existência de uma terceira camisa) virou um item fashion. De repente, descobriu-se que servia para alavancar a imagem e as finanças do clube, e passou a ser algo pensado, e se começou a descobrir o que funciona e o que não funciona: como deve ser o design, em que ocasiões o time deveria usar, quando lançar a nova camisa.
Afinal, eu não sou tão interessado assim em futebol ou em marketing esportivo, e o assunto deste blog deveria ser desenvolvimento de software. Acontece que tenho o vício de procurar metáforas para poder usar em sala de aula, e percebi uma analogia com a evolução na forma em que especificamos funcionalidade em sistemas de informação. Requisitos, testes e exemplos são formas diferentes de descrever o comportamento dos sistemas, e podemos associá-los a cada modelo de camisa.
Requisitos
Os requisitos são a camisa oficial. A partir do trabalho de Ivar Jacobson, como formalizar esses requisitos mereceu muita discussão: falava-se em desenvolvimento baseado em casos de uso. A notação de diagramas de casos de uso, desde o início, fez parte das notações de modelagem da UML. Quando foi proposto o processo unificado, diagramas e documentos de caso de uso passaram a fazer parte do conjunto de artefatos sugeridos (ou melhor, prescritos). Discussões intermináveis sobre minúcias dessas notações passaram a fazer parte de quem se interessava por metodologia.
Assim como os esquimôs têm muitos nomes para a neve, por conta da importância que esta tem para eles, passaram a ser utilizados muitos nomes para as atividades referentes a requisitos: levantamento, análise, elicitação, gerenciamento, especificação. Foram elaborados corpos de conhecimento e provas de certificação. Foram escritos livros inteiros e criados cargos específicos para lidar com requisitos: primeiro, o analista de requisitos e, depois, o analista de negócios. Cursos sobre a disciplina de requisitos são ministrados regularmente.
No caso dos esquimôs, podemos imaginar motivos pelos quais seria importante identificar diferentes tipos de neve. Numa viagem de trenô pela tundra, identificar sutis diferenças pode ajudar a evitar uma avalanche ou o mergulho nas águas geladas do Ártico: é questão de vida ou morte.
A sofisticação no tratamento dos requisitos poderia ser motivada pela percepção de perigos equivalentes ? Há três décadas, Barry Boehm alertava para o fato de que, no modelo vigente à época, errar nos requisitos tinha um impacto proporcionalmente muito maior, em termos de custo, nas etapas posteriores do ciclo de vida no software.
A mensagem passou a ser: não erre, seja muito cuidadoso com os requisitos, porque depois as consequencias serão desastrosas. Muitos interpretaram isso como perseguir um santo graal de requisitos completos, formalizados, detalhados e assinados com sangue no início do projeto. Hoje, sabemos que a cura foi pior que a doença, mas isso é assunto para outro post.
Testes
A camisa reserva é representada pelos testes, já que estes também são uma alternativa para a descrição do comportamento. Até pouco tempo atrás, não se dava importância real ao teste de software. Por quê ? Na verdade, já fiz antes essa pergunta: testar seria uma arte perdida ? As pessoas sabiam que o funcionamento de um sistema precisaria ser verificado de maneira adequada, mas as pressões de curto prazo sempre faziam com que o esforço de testes fosse empurrado com a barriga.
Na primeira década do século XXI, alguns fatores conspiraram para que o interesse em teste de software aumentasse. Um deles é a crescente penetração dos sistemas de informação no dia a dia das pessoas: os sistemas se tornam ao mesmo tempo mais críticos e mais complexos. O resultado das empresas depende cada vez mais do software que suporta suas operações, e o impacto direto dos defeitos no software passa a ser cobrado pelos seus usuários e percebido pelos tomadores de decisão.
Outro fator relevante foram as metodologias ágeis de desenvolvimento, que acordaram muitos profissionais de TI para a necessidade de testes, e passaram a utilizar testes automatizados como uma forma de especificação do comportamento dos sistemas. Note-se que esta visão invade a praia dos requisitos, e que contraria uma premissa tradicional da disciplina de testes: distinção entre requisitos e testes. Na visão tradicional, os artefatos de requisitos são uma das fontes para criar artefatos de teste, e se discute como derivar estes a partir daqueles.
Nesse processo, novas técnicas e ferramentas foram desenvolvidas, novas práticas e formas de gestão do esforço de testes surgiram. O papel dos profissionais de teste está sofrendo mudanças radicais e modelos estão sendo propostos para entender a disciplina de testes neste novo contexto.
Assim como na disciplina de requisitos, existe todo um ecossistema em torno de testes: associações profissionais, cursos, programas de certificação, modelos, empresas dedicadas exclusivamente a testes e cargos específicos. Testes têm um status emergente na sociedade.
Exemplos
A terceira camisa são os exemplos. De fato, são o patinho feio, a forma menos estudada de descrever o comportamento de um sistema. No entanto, são a forma intuitiva de captura regras de negócio junto a um especialista de domínio: as pessoas conseguem raciocinar melhor a partir de exemplos concretos. Os modelos abstratos, desde um ponto de vista cognitivo, são inferidos a partir de conjuntos suficientemente abrangentes de casos concretos. Agora, começa a haver um interesse em formular melhor práticas relacionadas a exemplos.
No entanto, muitas das propostas em metodologia de sistemas foram focadas em abstração. Apenas para citar um caso, uma das premissas dos documentos de casos de uso era a de serem uma especificação do comportamento do sistema, do ponto de vista do usuário: em muitas organizações, no entanto, eles foram sequestrados pelos técnicos e transformados em especificações formais em uma linguagem para iniciados, procurando abranger todos os caminhos alternativos, validações de domínio, exceções, regras de negócio e passos atrelados a uma certa implementação. Códigos como RN077, UC045 e A12 estão espalhados em um texto com dezenas (ou até centenas) de páginas.
Será que, nesse caso, não se seguiu a trilha errada ? Um especialista de domínio teria condições de entender esse formato ? Para efeito de compreensão da funcionalidade, isso funciona melhor que um conjunto consistente de exemplos concretos ?
Os exemplos começaram a ser estudados a partir do surgimento de ferramentas que usavam esse modelo de conjuntos de exemplos como forma de especificação de comportamento. A primeira destas ferramentas que adquiriu um uso amplo foi o FIT (framework for integration testing): os exemplos são expressos em formato de tabela, que é interpretada através de um adaptador (fixture), que aciona o sistema sendo desenvolvido usando como parâmetros os dados da tabela. Estes exemplos são chamados de testes de aceitação automatizados (talvez teste não seria a melhor forma de descrever: falo disso mais adiante). O FIT evoluiu para incorporar um front-end Wiki, chamado FitNesse, que torna o formato ainda mais próximo de um especialista de domínio.
A ideia é que o próprio especialista do domínio, ou um analista de negócios, ou um analista de testes seja responsável por essa especificação em forma de exemplo. No mínimo, o exemplo deve estar em um formato que todos consigam entender, e que não fique restrito a um perfil técnico.
Por quê prefiro chamar de exemplos e não de testes: a diferenciação é sutil. Se enfatizamos o aspecto do exemplo, não nos preocupamos tanto com classes de equivalência, cobertura e casos interessantes do ponto de vista de detecção de defeitos. Na qualidade de exemplo, o foco é na comunicação, no formato acessível. De fato, muito do que normalmente chamamos de testes no contexto de práticas ágeis poderia ser melhor descrito como exemplos.
As técnicas de TDD (desenvolvimento guiado pelos testes) e, por extensão, ATDD (desenvolvimento guiado pelos testes de aceitação) talvez seriam melhor entendidas se trocarmos "testes" por "exemplos". Brian Marick, justamente, propõe trocar a sigla TDD por XDD (eXample driven development). O objetivo principal é guiar o desenvolvimento, e para tal o papel de detecção de defeitos não é seu principal objetivo: o nome "testes" parece sugerir o contrário.
O BDD (desenvolvimento guiado pelo comportamento) utiliza este modelo de especificação baseada em exemplos, adicionando alguns formalismos e ferramentas. Mas o seu uso é suficientemente interessante para garantir livros inteiros apenas tratando do assunto. Fico devendo um post específico, podem cobrar.
A utilização de exemplos em geral, ATDD e BDD, têm provocado bastante barulho nos últimos tempos.
Exemplos agora estão virando fashion.
Eu ia discutir também a convergência entre esses três aspectos da especificação de comportamento em artefatos comuns, e seu efeito sobre a comunicação entre os envolvidos, mas essa elaboração fica para a próxima entrega. Até.

Comentários

Muito bom o artigo Jorge!

Gostaria de lembrar que tanto as camisas dos times de futebol, quanto os requisitos, testes e exemplos, são formas de comunicar algo a alguém.

E hoje em dia, os times estão utilizando essa camisa, visando os torcedores, se não me engano, alguns times até fazem pesquisas na internet. Ou seja, é uma camisa voltada mais para os torcedores, assim como os exemplos, são voltados para os clientes.

É importante dizer, que a existência dos três são importantes, embora os exemplos, costumem ser mais importante em projetos que temos os clientes atuando mais próximos da equipe de desenvolvimento.

Postagens mais visitadas deste blog

JavaMail: Enviando mensagem HTML com anexos

Introdução Depois do post "JavaMail: Enviando e-mail com Java" , que apresentava como enviar um e-mail com Java, resolvi complementar a assunto apresentando como enviar uma mensagem formatada, em HTML , e também como realizar o envio de anexos. Bibliotecas Além da biblioteca JavaMail, veja mais no post anterior , é necessário incluir o JavaBeans Activation Framework (JAF), apenas se a versão utilizada for anterior ao JSE 6.0 , que já tem o JAF incluso. O JAF está disponível em http://www.oracle.com/technetwork/java/javase/downloads/index-135046.html , e neste download encontramos, alguns exemplos na pasta demo , documentação, incluindo javadocs, na pasta docs e a biblioteca activation.jar , que deve ser acrescentada no classpath da aplicação para versões anteriores ao JSE 6.0. Exemplo Primeiramente devemos realizar a configuração da javax.mail.Session e da javax.mail.internet.MimeMessage , estes passos podem ser vistos no post anterior . Agora vamos montar um

O que é Lógica de programação?

Este é o segundo de uma série de posts voltados aos leitores do blog que estão dando início à carreira de desenvolvimento de software. O assunto de hoje é a lógica de programação. Para ler antes: Entendendo como funciona a programação de computadores: linguagens de programação, lógica, banco de dados A lógica de programação é um pré-requisito para quem quer se tornar um desenvolvedor de software, independente da linguagem de programação que se pretende utilizar. Mas o que é de fato a Lógica de Programação e como saber se eu tenho esse pré-requisito? A lógica de programação nada mais é do que a organização coerente das instruções do programa para que seu objetivo seja alcançado. Para criar essa organização, instruções simples do programa, como mudar o valor de uma variável ou desenhar uma imagem na tela do computador, são interconectadas a estruturas lógicas que guiam o fluxo da execução do programa. Isso é muito próximo ao que usamos em nosso cotidiano para realizar atividad

Devo fazer um curso ou ler um livro?

Acredito que todos os instrutores ou professores, independentemente da área, escola ou centro de treinamento, já devam ter recebido essa pergunta alguma vez na vida: devo fazer um curso ou ler um livro? Para responder a essa pergunta, precisamos avaliar os prós e contras de cada opção. Trabalho com treinamento há algum tempo e, hoje, recebi essa pergunta de um aluno. Não adianta responder a ou b sem argumentar, demonstrando as opções conforme a situação do aluno. O conteúdo, a forma de transmissão e a capacidade de assimilação do indivíduo são chaves para haver benefício maior de aprendizado. Tanto em um bom curso quanto em um bom livro, o conteúdo é a premissa básica . Por conteúdo entendemos: se está organizado; se respeita pré-requisitos; se promove o aprendizado guiado e incremental; se aborda de forma satisfatória os principais pontos; se tem bom balanço entre teoria, exemplos e prática (favorecendo exemplos e prática); se tem como premissa a acessibilidade possível (e cabível) pa

Lançamento do JDK 7 no TDC2011 em São Paulo

O The Developer's Conference foi realmente um grande momento para toda comunidade de desenvolvedores, um encontro de comunidades de TI onde foi possível interagir com pessoas incríveis das comunidades .NET, PHP, Python, Cloud, Games e tantas outras. Com mais de 200 palestrantes e 25 coordenadores é difícil até citar nomes sem ser injusta. Neste post gostaria de falar um pouco sobre um acontecimento muito especial para a comunidade Java, o Lançamento mundial do JDK 7! A história toda começou há muito tempo atrás, num relacionamento construído ao longo de vários anos de atuação dos membros do SouJava, participando do JavaOne, das JSRs e muito networking. Mas, durante o último JustJava conversamos com Roger Brinkley e Bruno Souza, e tivemos a felicidade de ter o TDC2011 exatamente no dia planejado para o Lançamento Mundial do JDK7. O grande mérito foi do SouJava e do amigo Bruno Souza (JavaMan). Com a participação formal no Executive Committeé do JCP estamos ficando cada vez ma

Literais da Linguagem Java

Na última semana, tive uma conversa com um profissional Java iniciante que me apresentou dúvidas sobre o uso de valores hexadecimal na linguagem, inicialmente entendi que ele precisava da representação textual de um valor hexadecimal, então apresentei um método da classe wrapper Integer, conforme segue: int valor = 15; System.out.println(Integer.toHexString(valor)); //Imprime f Só então após mostrar este exemplo, ficou claro que ele precisava exatamente do contrário, ou seja, qual a forma mais fácil de converter um número hexadecimal para um número decimal para atribuição a uma variável primitiva inteira. Esclareci que para isso não havia necessidade de conversão, bastaria usar uma literal hexadecimal presente na linguagem Java da seguinte forma: int valor = 0xf; // ou 0XF System.out.println(valor); //Imprime 15 Este episódio me motivou a escrever este post sobre os literais da Linguagem Java, então vamos lá. De acordo com a especificação da linguagem (The Java™ Language Specification

Entendendo como funciona a programação de computadores: linguagens de programação, lógica, banco de dados

Nesse post, diferente dos últimos que foram mais enfáticos nas experiências com tecnologias, vou focar um pouco mais nos profissionais que estão começando, ou pretendem ingressar na área de desenvolvimento de software, falando sobre conceitos fundamentais relacionados a programação em geral . Mercado de trabalho para programação Conforme já sabemos, o mercado de desenvolvimento de software, especialmente no Brasil, continua em franca expansão, sendo que cada vez mais as empresas buscam desenvolver seus próprios sistemas usando as mais diferentes e novas tecnologias. Algumas matérias interessantes: As seis profissões mais valorizadas em 2010 no IDG Now! Muitas vagas e sensação de reaquecimento da economia Por isso, a área de desenvolvimento de software tem despertado interesse em muitos profissionais de outras áreas que desejam mudar de profissão, já que as oportunidades de trabalho tendem a ser maiores. Esse é um perfil presente em muitos dos clientes da Globalcode que acabou m