Guias

Guia de boas práticas de levantamento de requisitos usando EPE

Versão do documento: 2.0, 21/09/2018

Introdução

Imagine uma empresa onde trabalhem pessoas de toda a parte do mundo. Para você se comunicar, provavelmente a empresa estabeleceu um idioma comum, por exemplo, o inglês. Parece fácil né? Mas se fosse, não haveria inúmeros problemas por causa da comunicação, principalmente em desenvolvimento de software, onde o cliente usa uma linguagem diferente do líder técnico, que por sua vez fala diferente dos analistas de testes. Há muito ruído na comunicação, mesmo todas essas pessoas falando o mesmo idioma.

É nesse momento que entra o BDD - Behavior Driven Development. É uma técnica de desenvolvimento, onde a comunicação é através de um vocabulário pequeno e comum, diminuindo a distância entre o negócio (cliente ou Product Owner) e a equipe de T.I. (Arquitetos, Programadores, Analistas de Testes). Nesta técnica as atividades de desenvolvimento se iniciam com os requisitos e a visão do cliente até o detalhamento dos artefatos de software (ciclo outside-in). = Foco no por que da criação do código e não em detalhes técnicos. Em BDD, um programador, ou profissional do setor de qualidade ou até mesmo o cliente podem escrever os testes que basicamente são compostos em duas partes, a definição da funcionalidade a ser implementada (User storie) e os cenários de uso que irão validar este requisito.

Quais os benefícios reais do BDD?

  • Evitam-se erros de compreensão e interpretação das histórias de usuário;

  • Os que antes eram requisitos funcionais e requisitos não funcionais, são transformados em comportamentos funcionais do software e critérios de aceitação;

  • Fornece uma forma de comunicação (vocabulários) comum a todos envolvidos, facilitando a compreensão por parte de todos;

  • A equipe fica ciente de que os comportamentos serão aceitos pelos usuários com antecedência;

  • A equipe entende como os comportamentos são relacionados, evitando confusão.

O que é cucumber?

É uma ferramenta para que possibilita a prática do BDD. Com ele, as funcionalidades do sistema são escritas em arquivos de texto e em uma linguagem de domínio específico chamada Gherkin, muito semelhante à linguagem natural, mas que contém algumas palavras chaves. Vale destacar que Gherkin aceita mais de 40 línguas.

A automação realizada com a utilização dos testes de BDD é composta, basicamente, por arquivos que especificam as funcionalidades (também denominada como “features”) e por arquivos de definição de passos (“steps”). Os arquivos com as funcionalidades são compostos por cenários, que exemplificam uma regra de negócio do sistema descrevendo o comportamento do sistema.

Linguagem Gherkin

Gherkin é uma linguagem criada especificamente para a descrição de comportamentos. Isto lhe dá a habilidade de remover detalhes lógicos dos testes de comportamento. O Gherkin serve como documentação do seu projeto, bem como para testes automatizados.

É uma linguagem orientada a espaços, ela usa indentação para definir a estrutura. Os fins de linha encerram as declarações (Passos) e espaços ou tabs também podem ser usados para indentação. Finalmente, todas as linhas em Gherkin iniciam com uma palavra chave especial:

image

Especificação por Exemplos

A Especificação por Exemplo é baseada nos conceitos trazidos pelo BDD, trata-se de uma nova abordagem para documentar requisitos onde estes são descritos baseados no comportamento e saídas geradas pelo sistema, utilizando uma linguagem simples que pode ser entendida por todos os envolvidos no projeto.

Bem como a especificação de caso de uso, a Especificação por Exemplos é baseada na visão do usuário, porém é conduzida para que seja possível reproduzir a realização os testes do sistema, simulando os comportamentos que devem ser gerados ao testá-lo, após a implementação.

Na especificação por exemplos são definidas algumas palavras-chave oriundas da sintaxe Gherkin, que permitem a conversão da especificação em scripts de teste e demais automatizações:

Tabela 1. Tabela EPE
Palavra-Chave Função

Funcionalidade

Descreve o para quem, o porque e o para que serve a funcionalidade.

Contexto

Define as condições iniciais para a execução de uma funcionalidade. Dados que devem estar previamente cadastrados no banco de dados, itens que devem previamente terem sido acessados ou configurados.

Cenário

Permite descrever um fluxo que será executado e poderá retornar apenas uma resposta para o usuário.

Esquema do Cenário

Permite descrever um fluxo que será executado e poderá retornar respostas diferentes para o usuário de acordo com um estado ou condição no sistema.

Exemplos

Permite definir para um Esquema do Cenário os diversos valores a serem utilizados na repetição dos testes.

Além disso, toda funcionalidade descrita deverá ter um ou mais cenários, que são exemplos de casos específicos de utilização da funcionalidade. Cada cenário consiste em um título e uma sequência de passos que representam as interações do usuário com o software.

Na língua portuguesa, considerando a sintaxe Gherkin, são utilizados os seguintes passos:

Tabela 2. Tabela Passos
Passo Função

Dado/Dados

Dada/Dadas

Especifica as pré-condições e/ou passos anteriores para que ocorra a ação de interesse do cenário.

Quando

Especifica o evento que deve ocorrer para que o cenário seja executado. Sempre é usado para representar uma ação do usuário.

Então

Especifica as pós-condições, expectativas a respeito dos resultados da execução dos eventos do cenário. Será utilizado sempre após a ultima ação do usuário e poderá ser seguido de um ou mais conectivos “E”.

E

Permite dar continuidade a qualquer dos seguintes passos:

  • Dado;

  • Dada;

  • Dados;

  • Dadas; e

  • Então.

É importante ressaltar, que segundo a documentação oficial do cucumber, é altamente recomendável que você tenha apenas um único passo Quando por cenário, sendo assim não é recomendável que haja um passo E após o passo Quando. Quando a especificação sugere que seja necessário mais que um passo Quando, geralmente é um sinal de que você deve dividir o cenário em dois ou mais cenários.

Na imagem a seguir, está sendo demostrado uma feature de Especificação por Exemplo.

image
Funcionalidade

Identifica um conjunto de comportamentos do sistema (como incluir ou alterar um cadastro).

Forma de utilização

  • Sempre no início da especificação, após o cabeçalho;

  • Declaração obrigatória;

  • Sempre iniciada com letra maiúscula seguida de dois pontos (:) ;

  • Após sua declaração, deve ser descrito (na mesma linha) qual funcionalidade, fluxo transacional ou ação, descrita no infinitivo (Incluir, Alterar, Excluir, Visualizar, Homologar, etc) será tratada.

Ex: Funcionalidade: Incluir Tipo de Assunto

  • Logo após a declaração da funcionalidade, deve-se fazer uma breve descrição de quem poderá ter acesso a ela, o que ela fará e qual a sua finalidade (para que):

    1. Quem Ex: Como um usuário que tenha permissão

    2. O que? Ex: Quero incluir uma empresa

    3. Para que? Ex: Para utilização dos dados cadastrados

Obs: É aconselhável que na declaração da funcionalidade, sejam inseridas informações na qual seja possível entender o motivo da funcionalidade e para que ela serve, então, desde que se enquadre nestas três perguntas, o texto é livre para inserção de qualquer informação. image::requisitos-boas-praticas/image4.png[image,width=624,height=60]

Contexto

Utilizado para identificar as condições iniciais que devem ser atendidas para a execução da funcionalidade, como uma carga inicial no banco de dados, itens que devem previamente ter sido acessados ou configurados, etc.

Forma de utilização

  • Não é obrigatório declará-lo;

  • Utilizado após a declaração da “Funcionalidade” no caso de contextos gerais, onde haja informações que serão úteis a mais que um cenário;

  • Contextos úteis apenas para validação de cenários específicos, devem ser utilizados dentro do contexto do cenário facilitando a leitura da EPE. Sempre representado pela palavra-chave “Dado/Dada/Dados/Dadas”.

  • Utilizar o passo “Dado" (ou suas variações) somente uma vez em cada cenário, caso o contexto necessite de mais informações utilizar o conectivo “E”;

  • Permite a utilização de tabelas para representar conjunto de dados;

Abaixo um contexto geral de uma funcionalidade:

image
Cenário

Identifica um fluxo por meio do comportamento do sistema considerando qual a sua reação com as entradas que passamos a ele. (Entrada – Processamento – Saida)

Forma de utilização

  • Sempre utilizado após a declaração do “Contexto” quando este existir. Pode ser utilizado após outros cenários ou esquemas do cenário;

  • Sempre iniciado com letra maiúscula seguida de dois pontos (Ex: Cenário:) ;

  • A declaração do cenário, virá seguida de um nome que deverá ser dado a ele. Este nome deve ser o mais específico possível, como por exemplo:

Cenário: Validar Data Futura

  • Cenários diferentes podem abordar uma mesma regra, mas não pode haver cenários com nomes iguais no arquivo;

  • Geralmente utiliza os passos “*Dado*”, “*Quando*”, “*Então*” e o conectivo “*E*". Contudo o passo “Dado” pode ser suprimido, caso o contexto tenha sido informado;

  • Permite a utilização de tabelas para representar conjunto de dados, sendo necessário pelo menos um passo com conjunto de dados no cenário;

  • Não permite a utilização da palavra-chave “Exemplos”, pois é utilizada apenas no esquema de cenário;

  • Sempre os dados que forem ser manipulados em um cenário, seja por alteração, exclusão ou consulta, devem estar registrados no CONTEXTO.

image

Abaixo um cenário de exclusão:

image
Descrição dos cenários

  • Os cenários devem ser descritos de forma que se assemelhem a um teste da funcionalidade narrado pelo usuário;

  • Deve-se evitar a descrição do tipo de componente que será utilizado para a execução.:

Tabela 3. Tabela Certos e Errados
Certo Errado

Dado que existam os dados de:

Dado que foram cadastrados no banco de dados do sistema os seguintes dados

Quando o usuário solicita "Salvar"

Quando o ator clica no botão “Salvar”

Então o sistema apresenta os dados de "Usuários Bloqueados":

Então o sistema mostra os usuários bloqueados em um fieldset

E o sistema apresenta os dados, ordenando pelo campo "Data":

E o sistema carrega uma grid, com ordenação pela data, com os resultados da consulta.

  • Sempre devem ser declarados os passos “Quando” e “Então” sendo opcional a declaração do passo “Dado” ou conectivos "E";

  • Os passos (Dado/Quando/Então) não podem vir a ser repetidos dentro do cenário ou esquema do cenário: Dado, como pré-condição; Quando, como execução; e Então, como uma saída gerada.

  • Referências a campos e informações presentes em tela (Ações, Agrupamentos e Menus), é aconselhavel que estejam entre aspas:

Ex: Quando o usuário solicita "Salvar" ou E apresenta os dados de "Usuários Bloqueados"

  • Para passos que sejam seguidos de um conjunto de dados, são finalizados com dois pontos.

image

  • Para qualquer descrição informada no passo "Dado", ou se o conectivo "E" estiver antes do passo "Quando", é utilizado o tempo verbal no passado.

Ex: Dado que o usuário solicitou o menu "Empresa"

Regras de Negócio

  • Todas as regras de negócio devem da feature devem estar dentro da mesma feature. Mesmo que a mesma regra seja apresentada da mesma forma em arquivos features diferentes.

  • Todas as regras devem ser validadas em cenários ou esquemas de cenários, comprovando assim o comportamento do sistema perante à regra.

Esquema do Cenário

Para identificar um fluxo por meio do comportamento do sistema, O teste do Esquema do Cenário será realizado uma vez para cada linha da tabela de Exemplos.

image

O esquema de cenário também pode ser utilizado para representar cálculos:

image
Forma de utilização

  • A ideia do Esquema do Cenário, é repetir o mesmo cenário para cada linha da tabela de exemplos. Faz-se uma substituição das variáveis que estão dentro do cenário com os valores da tabela;

  • Sempre utilizado após a declaração do “Contexto”, quando este existir. Pode ser utilizado após outros cenários ou esquemas do cenário;

  • Sempre iniciado com letra maiúscula seguida de dois pontos (Ex: Cenário:) ;

  • A declaração do Esquema do Cenário, virá seguida de um nome que deverá ser dado a ele. Este nome deve ser o mais específico possível.

Ex: Esquema do Cenário: Calcular Valor Total

  • Cenários diferentes podem abordar uma mesma regra, mas não pode haver cenários com nomes iguais no arquivo;

  • Geralmente utiliza os passos “*Dado*”, “*Quando*”, “*Então*” e o conectivo “*E*". Contudo o passo “Dado” pode ser suprimido, caso o contexto tenha sido informado;

  • Permite a utilização de tabelas para representar conjunto de dados, sendo necessário pelo menos um passo com conjunto de dados no cenário;

  • Exige a utilização da palavra-chave “Exemplos”

  • Sempre os dados que forem ser manipulados em um esquema do cenário, seja por alteração, exclusão ou consulta, devem estar registrados no CONTEXTO.

Palavra chave “Exemplos”

  • Permite gerar uma massa de dados para testes de um Esquema do Cenário;

  • Somente será utilizado em Esquemas do Cenário;

  • A referência dos dados listados na tabela de exemplos deve ser feita utilizando < >. Os valores atribuídos a < > serão substituídos pelos valores da tabela;

  • Deve indicar mais de um exemplo, pois, cada linha acrescentada será um novo teste aplicado ao Esquema do Cenário;

  • Será declarado após o passo “Então” sempre em uma nova linha, iniciando com letra maiúscula, no plural e seguido de ( : ) ;

image

Preparando a Especificação por Exemplos

Criando o Arquivo feature

Para iniciar uma Especificação por Exemplos, será necessária a criação de uma pasta com o nome da funcionalidade. Nesta pasta deverá ser adicionada duas subpastas uma para “FEATURE” e outra para “HTML”. Na subpasta “FEATURE” será incluída as Features da Especificação por Exemplo, na subpasta “HTML”, será criado o arquivo onde será gerado a Especificação por Exemplo em HTML.

image
image
Criando a feature no Intellij IDEA
PASSO 1

Iniciar o IntelliJ IDEA

image
PASSO 2

Para criar uma nova feature, o Analista deverá clicar em “File”, abrindo a opção “Open”, selecionando pasta com nome da funcionalidade que foi criada, desta forma, será exibido o nome da funcionalidade na lista de projetos recenetes.

image
image

Lista de projetos recentes, abrindo a pasta feature só será exibido "FEATURE", dificultando no momento que o analista trabalhar com mais de uma funcionalidade:

image
PASSO 3

Clicando com o botão direito do mouse, selecionando a opção “New” e em seguida “File”, o analista deverá salvar a feature com a nomeclatura

image
PASSO 4

Colocar a extensão .feature ao final do nome do arquivo criado.

image

“SigladoContrato_NOME DO CONTRATO_EPE001_N°Crescente(01)_ Funcionalidade_Ação.feature”.

Exemplo: EB_SIMATEX_EPE001_02_5389_ManterPedidoDeMaterial_Incluir.feature

Obs: Todas as EPEs deverão ser salvas com a extensão .feature. Este é um exemplo, o padrão de nomenclatura para EPE está previsto no Guia de Gerência de Configuração.

PASSO 5

Escrever o Cabeçalho no inicio do arquivo criado

# language: pt

# encoding: utf-8

image

Regras gerais da Especificação por Exemplo

Palavra chave “E”

  • Permite dar continuidade a qualquer dos passos (Dado, Dada, Dados, Dadas, Quando, Então) realizando a quebra de linha;

  • Deve ser utilizada sempre no início da próxima linha como letra maiúscula;

  • Não pode ser utilizada sem realizar a declaração que gere a continuidade do argumento da linha anterior;

  • A ação a ser realizada sempre será considerada a ação do passo anterior, como informar, solicitar, apresentar etc.

image
Comentar o Arquivo Feature

Como estamos lidando com uma linguagem técnica, assim como as demais linguagens de programação é possível inserir comentários que não irão ser apresentados no HTML gerado.

image

*Sendo assim, temos duas formas de comentários:*

Tabela 4. Tabela Comentários
Caracteres Forma

#

Inserindo uma cerquilha (ou Tag, HashTag) é possível comentar a linha inteira.

""" Bloco de Texto

Com Mais de uma linha ou não """

Inserindo um grupo de aspas duplas é possível comentar várias linhas da EPE. Desde que seja inserido um bloco de 3 aspas duplas no início e um bloco de 3 aspas duplas no final.
Inserção de tabelas

  • As tabelas são representadas por | Exemplo |, onde cada par representa uma coluna;

  • Sempre a primeira linha de | Exemplo | representa o cabeçalho da tabela, onde é descrito o tipo de dado;

  • As linhas posteriores representam os valores atribuidos ao tipo de dado;

  • Não deve ser informado valor na tabela utilizando aspas (“ ”) ou (< >). A própria tabela já indica que o conteúdo informado é um valor.

Exemplo do Arquivo feature:

image

Exemplo da exibição da tabela no HTML:

image

Erros comuns

Existem ferramentas que interpretam o arquivo .feature, e fazem algumas verificações para gerar o HTML. No momento podem ser utilizadas as duas ferramentas abaixo:

image

Pickles Pirilampo

Para a geração dos arquivos com o Pickles é obrigatório que toda a sintaxe da especificação esteja correta. Erros aparentemente banais podem impossibilitar a geração de arquivos ou de scripts de teste.

Portanto é indispensável que NÃO se cometa os seguintes erros:

  1. Escrever qualquer uma das palavras-chave ou passos com letra minúscula;

  2. Escrever Esquema de Cenário ao invés de Esquema do Cenário;

  3. Tabelas que não encerram com o | ;

  4. Valores atribuidos nos Esquemas do Cenário não estarem na tabela de exemplos;

  5. Esquemas do Cenário sem a declaração da tabela de exemplos;

  6. Declarar tabela de exemplos dentro do contexto;

  7. Declarar mais de uma vez na EPE o contexto ou funcionalidade;

Frases Padronizadas

Para a automatização do teste do sistema através da escrita da EPE, é indispensável que TODOS os analistas criem a EPE com frases padronizadas. Sendo assim, na definição dos passos, ou seja, o que eles representam mediante ao teste automatizado, é possível trabalhar sempre da mesma forma.

Sendo assim podemos listar as frases padronizadas para escrita da EPE, e todas foram adicionadas ao intelij para facilitar a inserção das mesmas:

Tabela 5. Tabela Frases Padronizadas
Ator Frase Padronizada Possíveis Variações

Contexto

Existam os dados de:

Existam os dados de "+Identificação do Dado":

Contexto

os dados de:

os dados de "+Identificação do Dado":

Sistema

apresenta os dados:

apresenta os dados de:

apresentou os dados

apresentou os dados de:

apresenta as ações

Usuário

Solicita o Menu "Nome do Menu"

Solicitou o Menu "Nome do Menu"

Usuário

solicita "Nome da Ação"

Solicitou "Nome da Ação"

Sistema

verifica +Descrição da Regra

verificou +Descrição da Regra

Usuário

informa os dados de:

informa os dados de "Nome do Agrupamento":

informou os dados de:

informou os dados de "Nome do Agrupamento":

informa os dados de "Nome do Campo", +Descrição da Regra

Sistema

apresenta a mensagem "Descrição da Mensagem"

apresentou a mensagem "+Descrição da Mensagem"

Sistema

efetua +Descrição da Regra

efetuou +Descrição da Regra

Sistema

Verifica +Descrição da Regra

verificou +Descrição da Regra

Sistema

atribui

atribuiu

atribuiu a "Cor" +Descrição da Cor

atribuiu "+Descrição da Regra"

Sistema

apresenta o formulário "+Nome do Formulário"

apresentou o formulário "+Nome do Formulário"

Usuário

Seleciona o registro:

Selecionou o registro:

Selecionou os registros:

Seleciona os registros:

Remove a seleção do registro:

Remove a seleção os registros:

Removeu a seleção do registro: Removeu a seleção os registros:

Sistema

remove os dados do campo:

remove os dados dos campos:

removeu os dados do campo: removeu os dados dos campos:

Sistema

Habilita o seguinte +Descrição da Regra:

Habilitou o seguinte +Descrição da Regra:

A descrição da regra é importante para o entendimento do passo no cenário, sendo assim, é um espaço livre para inserção da informação. Sendo separado por uma vírgula para atribuir uma informação a mais a este passo. É importante que este passo explique mas nunca exemplifique o que será representado no conjunto de dados abaixo. No exemplo abaixo é possível atribuir esta descrição para explicar o dado abaixo, que sem esta definição não é possível atingir o entendimento somente observando a regra:

image

Para descrição de campo ou um objeto atribuído, é importante que sempre estejam entre aspas, com isso torna a escrita parametrizável:

image

Histórico de Versões

Tabela 6. Histórico de Versões

Data

Versão

Autor

Revisor

Observação

04/09/2018

1.0

Fabrício Villela Andrade

Amanda de Oliveira Elias

Atualização do Documento para o novo modelo de escrita de EPE.

21/09/2018

2.0

Guilherme Peres

Cédric Lamalle

Conversão do documento para AsciiDoc.

Templates

Assistente virtual
Olá! Como posso te ajudar?