Ambiente de Requisitos de Software e Testes de Aceitação para Softwares Web Terceirizados

Ambiente de Requisitos de Software e Testes de Aceitação para Softwares Web Terceirizados Rodison dos Santos Ferreira, Anita Maria da Rocha Fernandes Pós-Graduação em Qualidade e Engenharia de Software Universidade do Vale do Itajaí (Univali) Florianópolis SC Brasil rodison@gmail.com, anita.fernandes@univali.br Abstract. Writing requisites and software acceptance tests in a clean way, with rastreability and warranties of a documentation always updated is a big challenge. This paper shows the definition and deployment of a method for requirements specification and acceptance tests to outsourced web systems based on agile methods using tools like FitNesse, Selenium and Prologa to achieve this objective. Resumo. Escrever requisitos e testes de aceitação de software de forma clara, com rastreabilidade e com garantias de que a documentação não fique desatualizada é um grande desafio. Este artigo mostra a definição e implantação de um método de documentação de requisitos e testes de aceitação para sistemas web terceirizados baseado em métodos ágeis com o uso das ferramentas FitNesse, Selenium e Prologa para atingir este objetivo. 1. Introdução Requisitos e testes de aceitação de software são partes importantes do desenvolvimento de sistemas. O desenvolvimento de software começa com a especificação de requisitos. Não adianta nada você ter a melhor equipe de desenvolvedores do mundo se a especificação que eles recebem é incompleta, superficial ou burocrática demais [Helm e Wildt 2014]. Se a especificação de requisitos não for boa, o resultado será a criação de um software que não atende às necessidades do usuário. Segundo Martin et al (2015), um grande problema que muitos projetos acabam enfrentando é o problema de Projeto Morto por Requisitos (Project Death by Requirements). Segundo este conceito, o desenvolvimento inicia com uma boa especificação e com bons desenvolvedores normalmente. Mais tarde, perto do fim do projeto, a equipe descobre que o que os clientes desejavam não é exatamente o que foi implementado e que as partes do sistema não podem ser integradas uma a outra porque suas interfaces são incompatíveis. Isto ocorre devido a vários fatores: porque os requisitos geralmente são escritos na forma de linguagem natural; porque o sistema só consegue ser integrado por completo ao final do projeto; e porque as mudanças que são feitas no sistema se mostram complexas e testá-las se torna muito difícil. Ainda segundo Martin et al (2015), o problema dos requisitos escritos em linguagem natural é que eles são necessários mas não são o suficiente. Isto porque é normal haver má interpretação das descrições de requisitos em linguagem natural. O problema do sistema só ser integrado por completo ao final do projeto é quando não são feitos testes de integração e de aceitação do sistema e, com isso, não se antecipa os problemas de integração que possam vir a existir entre os componentes do sistema ou entre a integração do sistema com outros sistemas externos. E o problema dos testes complexos e difíceis após mudanças, é que testes manuais funcionais baseado nas telas

do sistema demoram muito para serem executados, o que implica em um custo muito alto. E como os testes são manuais, é normal para estes testes não considerarem algumas partes do sistema, perdendo a cobertura de testes necessária, o que implica em feedback de testes pobres, tanto que não é raro um sistema ser testado durante dias e mesmo assim ocorrerem vários bugs quando o mesmo entra em produção. Estes problemas de integração se acentuam ainda mais quando não se está desenvolvendo um software, mas sim um módulo de um software terceirizado, onde a equipe não possui acesso ao código-fonte do sistema, pois sem os códigos-fontes fazer testes de integração e aceitação se torna uma tarefa muito mais difícil. Devido a este cenário, o intuito deste artigo é apresentar a proposta de um método de documentação de requisitos e elaboração de testes de aceitação para ferramentas web de terceiros através de um exemplo que foi implantado na equipe do autor na empresa na qual ele trabalha utilizando conceitos de metodologias ágeis e as ferramentas FitNesse, Selenium e Prologa. A seguir, para melhor compreensão do trabalho, serão apresentados o referencial teórico, as ferramentas para especificação de requisitos e testes de aceitação, a criação e implantação do método de especificações de requisitos e testes de aceitação e a conclusão do trabalho. 2. Referencial Teórico Segundo Bourque e Fairley (2014), especificação de requisitos de software estabelece a base para um acordo entre a empresa de desenvolvimento de software e o cliente estipulando o que o produto deve fazer e o que não é esperado que ele faça. Ela permite que uma rigorosa avaliação dos requisitos seja feita antes que se comece a codificação do sistema, reduzindo o redesign. Ela também provê uma base realística para estimativas de prazo, custo e risco do projeto. Geralmente estes requisitos são escritos na forma de linguagem natural, mas eles também podem ser escritos de maneira formal ou semi-formal. Os métodos tradicionais de desenvolvimento de software propõem várias formas de se especificar os requisitos de software. Com o advento dos Métodos Ágeis de desenvolvimento de software, novas formas de se especificar os requisitos surgiram. Métodos Ágeis [Prikladnicki, Willi e Milani 2014] são conjuntos de novos métodos de desenvolvimento de software que começaram a ser criados a partir de meados dos anos 90 em resposta aos antigos processos de desenvolvimento de software considerados excessivamente regrados, lentos, burocráticos e inadequados à natureza da atividade. Estes métodos ágeis são baseados em desenvolvimento iterativo, no qual requisitos e soluções evoluem pela colaboração entre equipes auto-organizadas e multifuncionais, encorajam frequentemente inspeção e adaptação, uma filosofia de liderança, alinhamento entre o desenvolvimento e os objetivos das empresas ou dos clientes e um conjunto de boas práticas de engenharia que permita entregas rápidas e de alta qualidade. Os Métodos Ágeis introduziram vários novos conceitos. Um deles foi o Test Driven Development (Desenvolvimento Orientado a Testes - TDD). Segundo Prikladnicki, Willi e Milani (2014), TDD é um conjunto de técnicas que consistem em conduzir o desenvolvimento a partir de testes criando o código em iterações muito curtas. Estas iterações são compostas pelas seguintes etapas: primeiro se escreve um teste automatizado antes de escrever qualquer código de produção; depois se escreve um

código de produção da forma mais rápida e minimalista possível o suficiente para fazer o teste passar com sucesso; então, deve ser feita a refatoração do código, ou seja, devese melhorar o design do código já funcional; e, por último, se roda novamente os testes para garantir que o código continua com seu comportamento externo. Este ciclo deve ser feito com trechos muito pequenos de código, de forma se que possa executar este ciclo em questões de segundos ou minutos. Testes automatizados executados facilmente e com frequência cultivam a confiança na equipe quanto à qualidade do sistema, assim como promovem a coragem e a segurança para modificar o design, já que qualquer passo em falso será detectado imediatamente. Com o advento do TDD, outras variações surgiram, como o Acceptance Test- Driven Development (Desenvolvimento Orientado a Testes de Aceitação - ATDD). Um dos trabalhos mais difíceis em desenvolvimento de software é comunicar claramente o que o sistema deve fazer e o ATDD ajuda muito neste ponto. O ATDD prega que antes de se implementar cada funcionalidade, o time de desenvolvimento deve criar exemplos de uso das funcionalidades. Então estes exemplos devem ser traduzidos para testes de aceitação automatizados. Estes exemplos e testes definem um vocabulário do sistema padronizado, se tornam parte do conhecimento compartilhado do time e definem uma descrição precisa de pronto para cada funcionalidade [Gärtner 2013]. Outra variação do TDD que surgiu foi o Behaviour-Driven Development (Desenvolvimento Orientado a Comportamento - BDD). Segundo North (2015), BDD é uma série de práticas e designs que eliminam algumas das ambiguidades e falta de comunicação que ocorrem entre pessoas técnicas e pessoas de negócio. O BDD utiliza os conceitos oriundos do TDD, porém aplicados a especificação de requisitos. BDD define uma linguagem ubíqua para escrever histórias de usuário usando o padrão: Sendo [X] para definir quem é o ator da história; Posso [Y] para definir a funcionalidade que será feita; Para que [Z] para definir o benefício ou valor da funcionalidade. E para os cenários das histórias, o BDD utiliza o padrão Given-When- Then composto da seguinte forma: Dado que [A] para definir o contexto inicial; Quando [B] para definir quando um evento ocorre; Então [C] para definir quais serão as saídas. Escrevendo as histórias de usuário e cenários usando estes padrões, deve-se então codificar os testes sendo que os nomes dos métodos devem ser as mesmas sentenças destes padrões citados acima. Desta forma, se faz um link entre o código de teste e a especificação escrita desta maneira. Utilizando-se uma ferramenta de BDD, como o JBehave (que será citado mais a frente), é possível executar os testes a partir da especificação. 3. Ferramentas para especificação de requisitos e testes de aceitação Existem várias ferramentas que podem ser utilizadas como ferramentas de especificação de requisitos: Microsoft Word: para se fazer uma especificação de requisitos, um simples editor de texto é uma alternativa, principalmente se a especificação for apenas em linguagem natural. Enterprise Architect (EA) [Sparx Systems 2014]: é uma ferramenta muito completa destinada a especificação de requisitos. Ela possui vários recursos como: elementos para se documentar necessidades do usuário, regras de negócio, casos de uso e até mesmo diagrama de classes de software. Esta ferramenta permite criar cada um

dos itens acima como elementos e permite que se criem dependências entre eles, o que permite que seja feito todo o controle de rastreabilidade entre os elementos. A ferramenta possui, inclusive, um mapa de rastreabilidade, que mostra na forma de uma tabela quais elementos estão relacionados entre si. JBehave [JBehave.org 2015]: é uma ferramenta destinada à utilização do BDD. Ele permite descrever os requisitos de software utilizando uma linguagem Given- When-Then, muito parecida com linguagem natural, de forma que tanto desenvolvedores quanto clientes conseguem ler as regras escritas neste formato e entendê-las. Esta ferramenta possui integrações com o código-fonte e com ferramentas de desenvolvimento. Por exemplo, para a linguagem Java, é possível adicionar Annotations nas classes Java para associar os métodos das classes à escrita dos requisitos. Dessa forma, se tem uma ligação direta do código fonte com os requisitos. FitNesse: é um servidor web, uma wiki e uma ferramenta de teste automatizado para software [Martin et al 2015]. É baseado no Framework for Integrated Test (Framework para Teste Integrados - FIT). O FitNesse permite escrever tanto testes unitários quanto testes de aceitação. A grande diferença desta ferramenta em relação às outras, é que os testes são escritos em uma linguagem natural na wiki através de tabelas chamadas Tabelas Fit (também chamadas de Tabelas de Decisão ou Tabelas Verdade), de forma que tanto técnicos quanto não técnicos possam entender e acompanhar os testes e regras que estão sendo utilizadas. Estas tabelas são usadas ao invés de texto puro ou linguagens de programação porque as linhas e colunas da tabela fornecem uma estrutura clara e simples, principalmente porque muitas pessoas já estão acostumadas a usarem tabelas em planilhas, páginas Web e outros documentos. O FitNesse possui dois Sistemas de Teste: o FIT e o Slim (Simple List Invocation Method). O FIT é mais antigo, maior e mais lento e utiliza parse de HTML para executar os testes. O Slim é mais novo, leve, mais rápido e fácil de portar. Estes dois Sistemas de Teste interpretam as tabelas de decisão. As tabelas de decisão usadas pelo FitNesse possuem entradas e saídas. A primeira linha da tabela é o nome da tabela, que representa o nome da classe que rodará o teste. A segunda linha da tabela contém as colunas de cabeçalhos. As primeiras colunas representam as entradas de dados e as últimas colunas representam as ações que serão executadas de acordo com a entrada dos dados. As demais linhas são os dados das entradas e das ações. Cada uma destas outras linhas se tornará um caso de teste. Com todas as combinações possíveis entre as entradas dos dados, se tem a cobertura total do teste para estas condições. O FitNesse ainda permite que os testes sejam executados automaticamente simplesmente clicando em um botão disponível na própria página wiki. Os resultados dos testes aparecem na própria tabela mostrando cores diferentes em caso de sucesso ou falha de forma muito intuitiva. Para que se possa testar sistemas web acessando o sistema como se fosse o usuário final através de navegadores de Internet, se utiliza o Selenium. O Selenium é uma ferramenta de automação de testes voltado principalmente para testes de sistemas web [Selenium Project 2015]. Ele provê uma ferramenta de gravação de testes (chamada SeleniumIDE) que permite exportar os testes gravados para várias linguagens de programação, como o Java, por exemplo, e possui também API s (Application Programming Interface) que permitem que os testes possam ser programados em várias linguagens de programação. Estes testes interagem diretamente com o navegador de internet fazendo ações como cliques de botão, acionamento de opções em combo boxes, seleção de valores da tela, abertura e fechamento de janelas, etc. Uma vez gravados ou

programados estes testes, o Selenium permite que eles sejam executados automaticamente em vários navegadores de internet modernos, como o Internet Explorer, Chrome, Firefox, etc., o que permite que os testes verifiquem se o sistema web funciona independentemente do navegador utilizado. 4. Criação e Implantação do Método de Especificações de Requisitos e Testes de Aceitação Como citado anteriormente, foi criado um método de especificação de requisitos e testes de aceitação na equipe da empresa do autor. Esta equipe era responsável por fazer customizações em um sistema web de terceiros. Ela enfrentava problemas principalmente na questão relativa a testes. A equipe não possuía um setor de testes e nem pessoas destinadas cem por cento do tempo à área de testes. No caso, eram os analistas de negócio que faziam os testes das aplicações. Eram testes manuais, alguns baseados em algum templates de testes já existentes e outros baseados em roteiros de testes elaborados pelos mesmos. Neste cenário, estas eram as principais dificuldades encontradas pela equipe: sistemas muito complexos com customizações igualmente complexas; e testes manuais difíceis de serem executados e com execução muito demorada. Como os testes demoravam muito para serem executados manualmente, quando algum erro era encontrado, era necessário corrigir o erro e retestar o sistema todo novamente, o que fazia com que a etapa de testes demorasse muito mais do que o esperado. No fim, a equipe trabalhava em um ciclo de duas semanas de desenvolvimento mas que levava mais de duas semanas de teste. Desta forma se perdia a característica ágil que a equipe buscava alcançar. Outro problema enfrentado pela equipe era a constante mudança de requisitos. Os requisitos anteriormente eram armazenados em arquivos.doc. Tantos eram os requisitos que quando um requisito era alterado, a equipe não conseguia determinar qual era o impacto que uma mudança iria causar. A equipe não possuía uma rastreabilidade dos requisitos com o código e nem mesmo uma rastreabilidade entre os próprios requisitos, de forma que não se sabia quais os códigos seriam afetados pelas mudanças e nem quais os outros requisitos que também seriam afetados. Para resolver este problema de rastreabilidade, a equipe começou a utilizar o software Enterprise Architect (EA). Com ele, a equipe criava elementos que representavam as necessidades do cliente, as regras de negócio e utilizava casos de uso para documentar os requisitos. No entanto não havia uma rastreabilidade direta com o código. Se o código fonte do sistema fosse alterado, a documentação não era alterada automaticamente. O resultado disso eram documentações desatualizadas que perdiam a sua utilidade prática e muitos bugs causados em partes não previstas do código, mesmo depois de passar pela etapa de testes do ciclo de desenvolvimento. Isto em grande parte porque os colaboradores que executavam os testes davam mais ênfase aos testes das funcionalidades que haviam sido alteradas, dando menos ênfase às outras funcionalidades que em teoria não haviam sido impactados. Com a aquisição de um novo sistema destinado a substituir a antiga solução existente na empresa do autor, a equipe viu a oportunidade para que estes problemas não viessem a se repetir no novo software.

Pesquisando entre várias soluções disponíveis no mercado e conversando com consultores existentes na própria empresa, a equipe decidiu por utilizar um conjunto de ferramentas que possibilitasse gerenciar melhor os requisitos escritos, mantendo uma rastreabilidade entre os requisitos e entre os requisitos e o código. Bem como fazer com que os requisitos não se tornem desatualizados e que eles possam ser testáveis de forma automática, de forma que os testes dos requisitos não se tornem um gargalo de tempo para as entregas da equipe. Considerando-se as ferramentas analisadas acima, o Word e o EA foram desconsiderados devido à falta de sincronização automática entre o código e a documentação de requisitos. Então pesquisou-se o JBehave e o FitNesse. No fim, apesar das duas ferramentas serem muito parecidas e atenderem as questões citadas acima, o FitNesse foi o escolhido pois um problema que também era enfrentado pela equipe era como disponibilizar a documentação de forma que ficasse fácil para o cliente visualizar os requisitos e que o próprio cliente pudesse alterar estes requisitos e os testes já serem executados informando o impacto da alteração. Como no FitNesse todas as documentações e testes ficam na wiki, o ponto citado acima é atendido pelo FitNesse mas não pelo JBehave. O método utilizado pela equipe do autor do presente artigo, optou por utilizar o ATDD para testar sistemas web terceirizados utilizando o FitNesse para isto. O sistema testado pela equipe foi o IBM SmartCloud Control Desk 7.5.1. O Control Desk é uma ferramenta web que permite gerenciar solicitações de serviço para uma empresa. Ele gerencia a criação de solicitações de serviço e todo o seu ciclo de vida desde manter o controle de quem irá atender à solicitação de serviço, o que será feito para atendê-la, gestão de documentos envolvidos na sua resolução, gestão de interações entre a empresa e o cliente que criou a solicitação de serviço e gestão de cumprimento de prazos. O Control Desk está sendo utilizado pela empresa do autor para fazer a gestão das solicitações de serviço de seus clientes. O Control Desk é uma ferramenta altamente adaptável, baseado em fluxos de trabalho que são desenhados dentro da própria ferramenta. Desta forma, pode-se criar fluxos de trabalho extremamente complexos e que precisam ser muito bem testados para garantir a correta utilização do produto. A equipe definiu que três fluxos de trabalho precisariam ser criados dentro do Control Desk: um fluxo de suporte, um fluxo de correções e um fluxo de evoluções. O fluxo de suporte é destinado a atender solicitações de serviço de orientações dos clientes. Quando o cliente possui alguma dúvida ou deseja algum esclarecimento, o fluxo de suporte é executado. O fluxo de correções é executado quando o cliente identifica algum bug em algum dos sistemas desenvolvidos pela empresa do autor e solicita a sua correção. O fluxo de evoluções é executado quando o cliente solicita alguma alteração ou nova funcionalidade nos sistemas. Inicialmente o FitNesse foi utilizado para fazer a especificação e cobertura de testes do fluxo de suporte, que é o primeiro fluxo que foi implantado nesta nova ferramenta. Para isso, o primeiro passo da equipe foi instalar o FitNesse e configurá-lo para começar a funcionar. O próximo passo foi desenhar o processo de suporte que seria criado na ferramenta. Com o processo desenhado, a equipe passou então a escrever todas as funcionalidades que o Control Desk permitiria executar dentro deste fluxo. Para isso foi criada uma página wiki no FitNesse onde foi colocada uma lista simples das funcionalidades. Foram levantadas 19 funcionalidades. Foram nomeados identificadores únicos para estas funcionalidades: de F1 a F19.

Para a primeira funcionalidade - funcionalidade de cadastro de solicitação - foram levantadas quais seriam as condições para que ela pudesse ser executada. Foram levantadas 6 condições: o cliente deve ter acesso ao cadastro de solicitação e o cliente deve preencher os campos detalhes, produto, módulo, local e serviço. Criando uma tabela de decisão levando em conta todas as combinações possíveis entre estas 6 condições, temos 64 casos de testes no total para esta funcionalidade. Para ter uma cobertura de testes de 100% das regras desta funcionalidade, deveríamos implementar os 64 casos de teste. No entanto, é preciso avaliar o custo de se implementar estes testes com os resultados práticos que se terão com eles. Às vezes é melhor desenvolver menos testes que tenham uma cobertura mais significante do que implementar todos estes testes. Esta afirmação é feita baseando-se no Princípio de Pareto [Koch 2000] (também conhecido como Princípio 80-20, que diz que 80% das consequências advêm de 20% das causas). Tendo-se isso em conta, se fizermos cerca que 20% dos casos de testes, poderemos prevenir 80% dos problemas. No caso de testes, estes não são valores fixos, mas são apenas exemplos de que se deve fazer a cobertura dos casos mais importantes, se não for possível cobrir todos os casos. Para não ter que desenvolver os 64 casos de teste e encontrar os casos de teste mais significativos, a equipe utilizou um software chamado Prologa [Vanthienen 2015]. Ele é um gerenciador de tabelas de decisão. Entrou-se com as condições para se montar a tabela de decisão neste aplicativo. Ele automaticamente gerou as 64 combinações que se tornariam os 64 casos de teste. Este aplicativo também possui uma funcionalidade de otimizar a tabela de decisão. Com isso, podemos dizer para o aplicativo ignorar a ordem das condições, eliminando desta forma casos de teste que produzem as mesmas ações, o que resultou em bem menos casos de teste que teoricamente cobrem a mesma quantidade problemas. Desta forma, acionando a funcionalidade de simplificação da tabela de decisão, a quantidade de casos de teste foi reduzida para 7 casos de teste. Com a quantidade de casos de testes definidos para esta funcionalidade, então o próximo passo foi exportar a tabela gerada pelo Prologa para o FitNesse. Ao exportar a tabela de decisão para a ferramenta, foi necessário fazer algumas alterações. Primeiro, foi preciso adicionar uma linha na tabela de decisão. Esta tinha que ser a primeira linha da tabela e deveria conter o pacote e nome da classe que iria executar os testes. A outra alteração feita foi alterar as ações para sempre terminar com um ponto de interrogação, é a forma do FitNesse fazer a distinção do que é uma condição e o que é uma ação. Uma vez exportada a tabela para a ferramenta, a tabela foi salva no FitNesse e os testes foram executados no próprio FitNesse. Ao executar os testes se pôde observar que todos os testes falharam pois não havia sido adicionada a classe Java responsável por executar os testes na ferramenta Control Desk. Desta forma, o próximo passo foi criar esta classe Java. Para isso, criou-se um projeto Java e o FitNesse foi configurado para apontar para o diretório onde se localizavam os códigos fontes desse projeto. Então, criou-se a classe Java para a execução dos testes. No caso, a equipe utilizou o padrão F1CadastrarSolicitacaoFixture como nome da classe responsável por executar os testes da funcionalidade F1 - Cadastrar Solicitação. Para os testes da funcionalidade 2 foi criada a classe F2AvaliarSolicitacaoFixture e assim por diante. Nesta classe, criou-se um método set para cada condição da tabela de decisão e criou-se um método para cada ação da tabela. Os métodos set devem ter o nome das condições escritas na tabela de decisão. Por exemplo, se existe uma entrada de dados

"Usuário tem acesso à tela", deve ter um método "setusuariotemacessoatela". Os métodos de ação devem ter o mesmo nome das ações da tabela de decisão. Se existe uma ação "Cadastrar Solicitação?", deve existir um método "cadastrarsolicitacao". Os métodos set devem receber por parâmetro os valores das condições da tabela de decisão. Já os métodos das ações devem ser programados para executar os testes no sistema alvo usando os valores das condições que foram atribuídos nos métodos set. Após a execução do teste, os métodos das ações devem retornar o valor que foi definido na tabela de decisão, mesmo que seja um valor boleano dizendo se a ação foi executada com sucesso ou não. Neste caso, os métodos de ações devem executar testes no Control Desk. Para os testes das funcionalidades, foram gravados os testes no SeleniumIDE para cada um dos 7 casos de testes da funcionalidade 1 e exportados para a linguagem Java para que eles pudessem ser chamados pela classe F1CadastrarSolicitacaoFixture. Uma vez alterada a classe F1CadastrarSolicitacaoFixture para executar os testes do Selenium, ao mandar executar o teste direto no FitNesse, o FitNesse passou a mostrar as linhas da tabela de decisão em verde quando o teste foi executado corretamente ou em vermelho se algum teste falhou. Desde que este método começou a ser implantado, já foram encontrados cerca de 30 bugs que não haviam sido previstos inicialmente e que foram descobertos ao se executar os testes do FitNesse. Também já foram realizadas 2 alterações nas configurações do Control Desk onde foi identificado que seria necessário alterar 5 funcionalidades configuradas no Control Desk após alterar as tabelas de decisão para refletir as alterações solicitadas e executar os testes do FitNesse. 5. Conclusão Com este método é possível então listar todas as funcionalidades de um sistema web terceirizado, definir as suas regras de negócio através de tabelas de decisão, definir qual será a cobertura de teste que será implementado em cima de todas as combinações possíveis das tabelas de decisão e garantir que o software atende às regras de negócio. Foram encontrados benefícios que foram além das benfeitorias relatadas na literatura de cada conceito e ferramentas. Alguns exemplos serão listados abaixo: organização da documentação do sistema, versionamento da documentação e das regras do sistema, rastreabilidade indireta entre funcionalidades e requisitos, documentação executável e sempre atualizada, aumento da confiança da equipe para desenvolver novas funcionalidades ou realizar alterações no sistema, aumento do acerto das estimativas para se fazer uma nova funcionalidade ou alteração e realizar alterações no sistema e maior garantia ao se fazer atualizações do sistema. Organização da documentação do sistema: como o FitNesse também é um servidor wiki, todas as informações do projeto foram documentadas no FitNesse, centralizando toda a documentação do sistema em um único ponto. Antes as documentações ficavam espalhadas em vários pontos: no Enterprise Architect (ferramenta que era utilizada para se documentar das regras de negócio), em arquivos do Microsoft Word, no sistema de versionamento da empresa (foi utilizado o Microsoft Team Foundation Server, o TFS), na wiki corporativa da empresa, no antigo sistema de gerenciamento de solicitações da empresa, em e-mails, etc. Outro ponto positivo é que além da documentação ter ficado centralizada em um único ponto, o próprio cliente

pôde acessar a documentação do sistema pois além de ficar disponível para ele, a documentação das funcionalidades e regras de negócio ficou escrita de uma forma prática e facilmente compreensível pois não existem detalhes técnicos nas regras de negócio escritas. Versionamento da documentação e das regras do sistema: todas as páginas wiki do FitNesse são armazenadas no formato simples de texto. Dessa forma, foi possível adicioná-las no sistema de versionamento da empresa. No caso do autor, as páginas do FitNesse foram adicionadas ao TFS. Desta forma, sempre que se aplicava um rótulo de nova versão no TFS, toda a documentação também recebia o rótulo da nova versão. Desta forma, ao se recuperar alguma versão antiga das configurações do Control Desk também se obtém quais eram as regras de negócio válidas naquele momento. Rastreabilidade indireta entre Funcionalidades e Requisitos: como já citado acima, os testes permitiram saber quais funcionalidades e requisitos estão relacionados de forma indireta. É de forma indireta pois é necessário algum teste quebrar para que se veja quais funcionalidades e requisitos estão relacionados. Documentação Executável e sempre atualizada: com o FitNesse é possível aplicar o conceito de Documentação Executável [Shore 2008]. Isto porque se a documentação for atualizada e as configurações do Control Desk não, os testes irão quebrar. E da mesma forma, se algum desenvolvedor resolver alterar as configurações do Control Desk sem atualizar a documentação, os testes também irão quebrar. Desta forma, todos os desenvolvedores se obrigam sempre a manter a documentação atualizada. Aumento da confiança da equipe para desenvolver novas funcionalidades ou realizar alterações no sistema: ao realizar alterações no sistema ou desenvolver novas funcionalidades, era só executar os testes do FitNesse para ver quais funcionalidades tinham deixado de funcionar. Os testes dão esta garantia de que alterações não se tornarão sinônimo de bugs em produção. Aumento do acerto das estimativas para se fazer uma nova funcionalidade ou alteração: quando se é necessário fazer uma alteração, é só, inicialmente, alterar o código da configuração da funcionalidade que se deseja alterar que os testes já mostrarão quais funcionalidades e regras de negócio terão que ser alteradas. Com esta informação é mais fácil fazer uma estimativa mais realista sobre o esforço necessário para fazer a alteração. Maior garantia ao se fazer atualizações do sistema: uma grande preocupação sempre é aplicar grandes atualizações de sistemas terceirizados como o Control Desk. Afinal, sempre que se aplica uma grande atualização, muitas configurações e adaptações realizadas deixam de funcionar. Embora o autor ainda não tenha passado por uma situação destas, espera-se que com os testes do FitNesse se possa identificar mais facilmente funcionalidades que deixem de funcionar devido a alguma atualização do sistema. Porém, alguns pontos negativos também foram identificados com o uso deste método: tempo gasto com a documentação e testes automatizados, falta de uma rastreabilidade direta entre Funcionalidades e Requisitos, falta de uma rastreabilidade com o código, necessidade de se gerar novamente toda a tabela de decisão quando a alteração é muito grande e demora na execução dos testes de Selenium.

Tempo gasto com a documentação e testes automatizados: aumentou o tempo gasto com documentação. Já que a atualização da documentação se tornou obrigatória, agora é necessário sempre gastar mais tempo com a documentação. E uma vez que se trabalha com tabelas de decisão, são descobertos mais casos de teste que devem ser implementados do que da forma antiga que a equipe trabalhava. Antes os casos de teste e sua quantidade eram determinados pela experiência do analista de negócio. Porém muitos casos de teste não eram feitos pois não se achava necessário. Porém, com a tabela de decisão se descobrem muito mais casos de teste. E um ponto ruim em se precisar de mais tempo para documentação e teste é ter que convencer os gestores de que este tempo é realmente necessário até que se tenha os dados que demonstrem que um esforço maior em documentação e testes reduzem a quantidade de bugs que vão para a produção. Falta de uma rastreabilidade direta entre Funcionalidades e Requisitos: como já citado, a rastreabilidade existente com a metodologia é a rastreabilidade indireta entre as funcionalidades e requisitos. A rastreabilidade é indireta pois é necessário quebrar os testes para se identificar quais funcionalidades e requisitos estão relacionados um com o outro. O ideal seria que o FitNesse ou alguma outra ferramenta gerasse uma matriz de rastreabilidade automaticamente entre as funcionalidades e requisitos. Falta de uma rastreabilidade com o código: na verdade este não chega a ser um problema do FitNesse, uma vez que ele permite que sejam executados testes caixa branca como testes unitários e testes de integração. O problema mesmo é devido à natureza do sistema testado. Como o Control Desk é um sistema terceirizado a equipe não possui acesso ao código-fonte. Por isso não é possível fazer uma rastreabilidade com o código. Necessidade de se gerar novamente toda a tabela de decisão quando a alteração é muito grande: quando a alteração de uma funcionalidade é muito grande, às vezes compensa mais gerar uma nova tabela de decisão do zero no Prologa e então adicioná-la e configurá-la novamente no FitNesse do que alterar a tabela de decisão já existente devido à grande quantidade de casos de teste identificados em uma funcionalidade. Talvez se houvesse alguma integração entre o Prologa e o FitNesse, estas alterações poderiam ser facilitadas. Demora na execução dos testes de Selenium: testes de Selenium demoram muito para ser executados. Embora a cada versão o Selenium esteja ficando mais rápido, ele ainda é muito lento se comparado a testes unitários, por exemplo. Isto porque ele precisa abrir o Firefox para executar os testes, carregá-lo, executar os testes e então fechar o Firefox. Principalmente o tempo de processamento e memória gastos para abrir o navegador é muito grande. Rodar todos os testes do FitNesse do projeto pode demorar algumas horas. E um dos princípios das metodologias ágeis é a Construção em 10 Minutos (Ten Minute Build). Segundo Shore (2008), um desenvolvedor deve ser capaz de construir, testar e instalar o sistema inteiro a qualquer momento ao clicar de um botão. Isto porque todo desenvolvedor deve ser capaz de saber a qualquer momento se é possível atualizar o sistema em produção neste momento e se o software está funcionando. Não ser capaz de responder estas questões frustra o desenvolvedor. Fazer uma construção automatizada e rápida é a forma mais fácil de aumentar a moral da equipe e aumentar a sua produtividade. Outro ponto é que nenhum desenvolvedor deve quebrar a construção do código. Se a construção for quebrada, o desenvolvedor deve

desfazer suas alterações no repositório do sistema e então corrigir o código na sua máquina. Se cada vez que a construção rodar ela demorar horas, são horas que o desenvolvedor terá que esperar até ter certeza que tudo está funcionando corretamente. Ou, pior ainda, se o desenvolvedor começar a trabalhar em uma nova funcionalidade enquanto a construção é executada e, depois de horas, a construção finalizar e informar que o desenvolvedor quebrou a construção, daí o desenvolvedor terá que parar a nova funcionalidade que estava fazendo, perdendo assim o seu foco, e corrigir o código que quebrou a construção. Com isso, conclui-se que esta metodologia vale a pena ser utilizada devido a todos os pontos positivos encontrados durante a execução da mesma. Como melhorias futuras, pode-se expandir esta metodologia para se utilizar em softwares desenvolvidos pela própria empresa. Dessa forma, tendo acesso ao código fonte do sistema, é possível usar o FitNesse também para execução de testes caixa branca como testes unitários e testes de integração, o que proporcionaria criar uma rastreabilidade indireta das funcionalidades e regras de negócio até o nível do código-fonte. Uma outra melhoria futura é utilizar o Selenium Grid2, que possibilita escalar a execução dos testes do Selenium em várias máquinas distribuídas, o que dessa forma permitiria que os testes rodassem de forma mais rápida. Referências Bourque, P. e Fairley, R. E. (2014) SWEBOK V3.0: Guide to the Software Engineering Body of Knowledge, IEEE Computer Society. Gärtner, M. (2013) ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, Addison-Wesley. Helm, R. e Wildt, D. (2014), Histórias de Usuário: Porque e Como Escrever Requisitos de Forma Ágil?, Historiasdeusuario.com.br, 2ª edição. JBehave.org (2015), What is JBehave?, http://jbehave.org/, fevereiro. Koch, R (2000) O Princípio 80/20: O segredo de se fazer mais com menos, Rocco. Martin, R. C. et al. (2015), FitNesse User Guide, http://fitnesse.org/fitnesse.userguide, fevereiro. Mugridge, R. e Cunningham, W. (2005), Fit for Developing Software: Framework for Integrated Tests, Prentice Hall Press. North, D. (2015) Introducing BDD, http://dannorth.net/introducing-bdd/, fevereiro. Prikladnicki, R., Willi, R. e Milani, F. (2014) Métodos ágeis Para Desenvolvimento De Software, Bookman. Selenium Project. (2015), SeleniumHQ: Browser Automation, http://docs.seleniumhq.org/, fevereiro. Shore, J. e Warden, S. (2008), The Art of Agile Development, O Reilly. Sparx Systems. (2014), Requirements Management with Enterprise Architect, Sparx Systems. Vanthienen, J. e Dries, E. (2015), Tabular Decision Modeling and Prologa, https://feb.kuleuven.be/prologa/, fevereiro.