I. Criação de Subtarefas:

Quando a tarefa a ser realizada se tratar do tipo "Issue" entendemos que é referente a uma manutenção a ser realizada no produto, para atuar nessa tarefa temos as seguintes ETAPAS OBRIGATÓRIAS:

Criar SubTask de Codificação: 

• Responsável: Analista 1
• Obrigatório: Sim
• Oque fazer: Fazer Check in dos fontes alterados no TFS ( Sempre no diretório de manutenção ) , Criar o documento técnico no TDN ( Incluir no campo do JIRA ) e criar/atualizar o documento de referência no TDN quando se aplica
• Ponto de Atenção: Utilizar SEMPRE a gestão de fontes, subindo a correção no último release existente

Criar SubTask de Execução de Teste Unitário: 

• Responsável: Analista 1
• Obrigatório: Não
• Oque fazer: Fazer um teste pontual da correção realizada e anexar um .doc  nessa subtarefa garantindo que o teste foi realizada

Criar SubTask de Execução de TA( Teste Automatizado ): 

Regras para a realização da automação: Conforme alinhado com a nossa gestão sempre que realizarmos uma issue de manutenção de algum fonte onde já existe mapa mental  / caso de teste / automação, precisamos OBRIGATORIAMENTE atualizar todos esses artefatos, inclusive realizando a inclusão de novos casos de teste quando necessário

• Responsável: Analista 1
• Obrigatório: Sim
• Oque fazer: Subir um .doc nessa subtarefa com o print da alteração realizada no mapa mental.
• Ponto de Atenção: Vamos criar essa tarefa obrigatoriamente SEMPRE !Quando tivermos orientação dos nossos gestores para a não realização devemos concluir essa subtarefa explicando os motivos de não ser realizada
• Ponto de Atenção: Mesmo quando NÃO EXISTA a necessidade de automação( pelas regras citadas acima ) precisamos criar uma subtarefa e encerrá-la informando que não foi realizada a automação pois não se trata de criação de fontes novos, e conforme alinhado com a gestão as automações serão realizadas apenas em fontes novos criados.
  
    Para a inclusão do mapa mental devemos realizar o CHECK IN do artefato no TFS vinculando a issue do JIRA( da mesma forma que fazemos com o fonte ), NÃO UTILIZAR "01\EXCEÇÃO", também não é necessário subir uma evidência .DOC na tarefa do JIRA, apenas a amarração do mapa mental já atende o processo, conforme abaixo:
  
  
    Para a inclusão de Casos de Teste precisamos através do link "Test Coverage" existente na issue do JIRA realizar a amarração dos casos de testes criados no Kanoah já com a sua execução realizada, conforme abaixo:
  
  

Criar SubTask de Execução de Teste Integrado: 

• Responsável: Analista 2
• Obrigatório: Sim
• Oque fazer: Fazer um teste abrangente de todo o cenário envolvendo a alteração e subir ou um arquivo .doc evidenciando que o teste foi realizado ou os casos de teste no KANOAH ( Fazendo o link com a tarefa do JIRA, na estória deve ser criado um link para o caso de teste executado e validado )
• Ponto de Atenção: O analista que finalizou o teste integrado tem a obrigação de avisar o analista de desenvolvimento assim que o teste integrado for finalizado para que seja realizado o merge, afim de ser garantida a entrega daquela manutenção na versão futura

Criar SubTask de Execução de Merge: 

• Responsável: Analista 1/ 2
• Obrigatório: Sim
• Oque fazer: Realizar o merge das alterações realizadas com a MAIN
• Ponto de Atenção: Essa tarefa é criada automaticamente pelo sistema após ser finalizado o teste integrado concluído
• Ponto de Atenção: O analista que finalizou o teste integrado tem a obrigação de avisar o analista de desenvolvimento assim que o teste integrado for finalizado para que seja realizado o merge, afim de ser garantida a entrega daquela correção na versão futura. Ou analista 2 pode realizar o Merge.

ATENÇÃO:  O analista que realizou a codificação NUNCA pode ser o mesmo a realizar o teste integrado !

ATENÇÃO: Quando estivermos atuando em uma issue durante o TESTE SISTÊMICO devemos obrigatoriamente criar um defeito para replicar aquela correção para a versão que esta sendo expedida 

II. Versões que devemos expedir para cada issue de acordo com suas características:

Para as entregas do TAF temos algumas particularidades com relação a expedição de release, conforme abaixo:

ECF: Fazemos as issues em todas as versões ( 11, 12.1.7, 12.1.14, 12.1.16 e 12.1.17 )

E-SOCIAL: Fazemos as issues nas versões 11, 12.1.16 e 12.1.17 (estamos tombando eSocial para 12.1.16)

EFD REINF: Fazemos as issues nas versões 12.1.16 e 12.1.17

DEMAIS ISSUES:

1. Se a versão do cliente for 12.1.17: Fazer correção somente na 12.1.17
2. Se a versão do cliente for 12.1.5, 12.1.7 ou 12.1.14: Fazer somente na 12.1.17 e orientar o cliente a migrar o seu release
3. Se a versão do cliente for 12.1.16:
   
   1. Se for Alta ou crítica:Fazemos nas versões 12.1.16 e 12.1.17
   2. Senão: Fazer somente na 12.1.17 e orientar o cliente a migrar o seu release
      Mensagem modelo de orientação do cliente:
      Caro Cliente, o problema reportado no ticket xxxxx já encontra-se corrigido no Release 12.1.xx (atual), de acordo com a política de ciclo de vida a release xx.x.xx já está com validade técnica expirada, por favor atualize seu Release.

PARA OS CLIENTES ABAIXO TEMOS QUE ATENDER A SUA VERSÃO ATUAL E A 12.1.17, INDEPENDENTE DE QUAL SEJA O PROBLEMA:

III. Geração de pacotes no spool de compilação:

Verificar se os campos abaixo estão preenchidos na issue:

Status Pacote: Gerar

Releases para Expedição: Versões em que devem ser gerados os pacotes

IV. Erros pré-existentes

No caso de erros que foram corrigidos anteriormente, devemos vincular na issue atual o link da issue onde foi feita a correção, informando que o erro não se aplica pois havia sido corrigido anteriormente.

V. Execução do Robô

É obrigatória a execução do robô local antes do check-in de qualquer fonte no TFS, considerando é claro que aquele fonte já possua script de automação desenvolvido, segue abaixo as regras para auditoria:

→ A execução do robô deve ser realizada pelo mesmo analista que realizou o check-in no TFS, quando existir desenvolvimento compartilhado o time deve se organizar para essa tarefa;

→ A execução do robô deve ocorrer até três dias antes da subida do fonte no TFS, ou seja, se executar o robô da TAFAINTEG hoje ( 02/10/2017 ) eu preciso fazer a subida do fonte no TFS até a data de 05/10/2017 

VI. Atualização do PimeFun.prx

O TAF também deve atender ao SÉRIE 1, sendo assim, sempre que criamos uma rotina nova é obrigatória a atualização do fonte PimeFun.prx, esse item faz parte do aceite de pronto de um requisito/issue.