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

2º Bate Papo do SP-GTUG - Divulgação

Pessoal, Para aqueles que já estiveram presentes nas atividades do SP-GTUG (encontros ou bate papos na Globalcode), e para os que ainda não puderam estar presentes, teremos um novo bate papo acerca de mais duas tecnologias do Google: AdSense e Python no GAE. Este será o nosso segundo bate papo do SP-GTUG, nos mesmos moldes dos minicursos da Globalcode . Local e data O bate papo acontecerá no dia 27/03/10, das 10:00 às 13:00 na Globalcode. Para fazer sua inscrição e participar acesse a home da Globalcode e vá até a parte de "Minicursos Gratuitos da Semana ". Conteúdo das apresentações Abaixo seguem as descrições passadas pelos palestrantes: Título: "Algoritmos em Python" Resumo: Python é uma linguagem considerada frugal, simples, sem ser simplória! Entenda como construir algoritmos ninjas com essa linguagem, adotada pela Google e pelo MIT. Veremos muito, muito código, desde algoritmos clássicos até tutoriais do

10 reasons why we love JSF

1. One-slide technology: it's so simple that I can explain basic JSF with one slide. 2. Easy to extend: components, listeners, render kit, Events, Controller, etc. 3. Real-world adoption: JBoss, Exadel, Oracle, IBM, ... 4. Architecture model: you can choose between more than 100 different architecture. 5. Open-mind community: using JSF you are going to meet very interesting people. 6. We are using JSF the last 5 years and we found very good market for JSF in Brazil 7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard! 8. Many professionals now available 9. It's a standard. It's JCP. Before complain, report and help! 10. Ed Burns, spec leader, is an old Globalcode community friend! EXTRA: My wife is specialist in JSF. She's my F1 for JSF :) Nice job JSF community! -Vinicius Senger

JSF 2 - Composite Components, você não precisa mais ser um ninja

Estamos em uma nova era da computação, os dados não estão mais localizados em um banco dentro de sua empresa, vivemos a explosão de redes sociais, informações são geradas a todo instante, e se torna essencial que sua aplicação conheça os serviços disponíveis na web e consumam suas APIs geralmente disponíveis por serviços REST. Legal, mas como ficam meus aplicativos Java EE neste novo cenário? Para quem vem acompanhando a evolução da plataforma, é notório que todo esforço vem sendo utilizado para aumentar a produtividade e a integração com novos serviços. Basicamente duas especificações surgem com muita força para atender este cenário, a JSR - 314 (JSF-2) e JSR - 311 (JAX-RS), neste post exploraremos a JSR-314 (JSF2) e sua nova forma de criar Composite Components. Uma das grandes queixas dos desenvolvedores JSF era a complexidade em criar composite components, era necessário um vasto conhecimento sobre o ciclo de vida de uma aplicação JSF. Agora, você não precisa ser mais um “ninja” em

Gosta de informática e sonha ser programador Java um dia ?

A Globalcode está procurando jovens que queiram ser programadores no futuro, para fazer parte de sua equipe de vendas e operacional na unidade Paraíso em São Paulo somente. O grande diferencial é o planejamento para carreira de programador. O planejamento de cursos do portifólio da Globalcode: Academia do Programador, Academia Java, Academia Web, Robótica, Eletrônica, etc, será realizado periodicamente de acordo com o desempenho e interesse individual. Atenção : Este não é um estágio para trabalhar com Java, são duas vagas CLT administrativas para pessoas que queiram ser programadores no futuro. Perfil : Conhecimentos de informática básica, saber lidar com pessoas e trabalhar em equipe. Deve ter concluído o ensino médio, ter boa escrita, ser organizado, responsável, comprometido e dinâmico. Interesse por computação, programação, internet, robótica, eletrônica,... Temos duas vagas para jovem-aprendiz abertas: 1) Setor operacional No dia a dia Serviços externos Controle de estoqu

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

TDC INNOVATION lança University Pass

Modalidade de ingresso tem como objetivo ajudar na capacitação dos universitários Uma pesquisa realizada em 2020 pela Associação Brasileira das Empresas de Tecnologia da Informação e Comunicação (Brasscom) diz que até o ano de 2024 o Brasil precisará de cerca de 420 mil profissionais na área de Tecnologia da Informação. Porém, por ano, a mesma pesquisa diz que o país forma apenas 46 mil profissionais capacitados no nicho. Pensando nisso, para ajudar na formação e capacitação desses jovens profissionais, o TDC INNOVATION, segunda edição do ano do The Developer's Conference, lança o University Pass, modalidade de ingresso que possibilita aceso digital gratuito a todas as palestras do evento, ou com 50% de desconto para quem preferir ir pessoalmente. Com o tema central “Desafios para a criação do futuro Digital”, o TDC INNOVATION ocorrerá entre 1 e 3 de junho, de forma híbrida: presencialmente no Centro de Convenções CentroSul, em Florianópolis, e com transmissão simultaneamente pela