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é.
O Spring Brasil User Group nasceu forte e saudável junto com o ano novo e, com menos de um mês de vida, já conta com mais de 100 membros. Venha participar também desta comunidade! Se ainda não é um membro, clique aqui!.
Através de um grande apoio e incentivo da Globalcode realizaremos uma reunião presencial do SBUG em formato de Casual Class no auditório da Globalcode em São Paulo. Neste Casual Class abordaremos a plataforma da SpringSource e não somente o produto mais famoso Spring Framework. Este evento será muito especial, reunindo diversos profissionais com experiência prática. Contaremos com a participação de membros do Spring Brasil User Group e instrutores da Globalcode que farão uma apresentação do framework, o lançamento oficial do grupo, uma apresentação sobre a integração do Spring com o cenário de Cloud Computing, uma apresentação da ferramenta de produtividade Spring Roo e as ferramentas de produtividade como SpringSource Tool Suite, tc Server e dm Server. As inscrições estão abertas através do site www.casualclass.com.br.
Por enquanto (até 05/fev), a aplicação web de exemplo baseado no Spring Framework 2.5 estará disponível para acesso online na plataforma de computação em nuvem da SpringSource e, chamada de SpringSource Cloud Foundry, acessível através de um endereço disponibilizado pela Amazon Web Services (Elastic Cloud Computer): Exemplo Globalcode Casual Class Spring 2.5.
Postagens
