...

O  seu ponto de contato para a parte de Qualidade do processo:

• Analista de Qualidade :
  • Leonardo David Galleas Levandoski
    • Guia no processo: orientação sobre o processo de Review da Solução e o que esperar em cada fase.
    • Caminho da entrega: garante que você saiba onde e como submeter sua Solução no portal de parceiros.
    • Materiais de apoio: é responsável por criar as documentações técnicas que ajudam no seu desenvolvimento.

Suporte técnico e código

...

O  seu ponto de contato para a parte de desenvolvimento que vai ajudar você a construir a Solução corretamente:

• Desenvolvedores:
  • Luís Felipe de Andrade Rossi e William Cano Bizon 
    • Dúvidas de código: eles fornecem os requisitos e esclarecem todas as suas dúvidas técnicas enquanto você estiver desenvolvendo.
    • Validação técnica: são os responsáveis por validar tecnicamente se a sua Solução atende a todos os requisitos fundamentais.

Entendendo os requisitos e o processo de avaliação

...

Antes de enviar sua solução para o Review da Solução, é essencial validar se ela está totalmente alinhada aos requisitos. Certifique-se de que todos os critérios obrigatórios foram atendidos e que a solução está tecnicamente adequada. Além de cumprir todos os requisitos do Review, recomenda-se seguir também as boas práticas descritas abaixo, garantindo maior qualidade, organização e assertividade no processo de aprovação.

Adequação Técnica e Clean Code

• Organização e estrutura

  • Respeite o padrão: Mantenha a estrutura do TOTVS Fluig padrão com pastas pré-definidas (css, js, images) para Widgets, Layouts e outros componentes.

  • Limpeza: Antes de submeter para o Review da Solução, remova qualquer arquivo que não esteja sendo utilizado no componente (arquivos de teste, backups, etc.).

• Gerenciamento de dependências

  • Registro: Todas as bibliotecas JavaScript externas devem ser referenciadas no arquivo application.info.

  • Evite redundância: O TOTVS Fluig já carrega nativamente bibliotecas como jQuery, jQuery UI e o Fluig Style Guide. Não as adicione novamente ao seu projeto para evitar conflitos e peso desnecessário.

• Funcionalidades obrigatórias

  • Internacionalização (i18n): Todos os textos visíveis (títulos, labels, avisos) devem utilizar chaves de tradução, e não texto fixo no código.

  • Licenciamento: Implemente a verificação de licença utilizando a API de Licença oficial.

Componente adaptado para a Store

Para a Store no TOTVS Fluig, padronizamos a estrutura que o componente deve ser desenvolvido, cujo objetivo também é acelerar o processo de de review da solução, O componente deve seguir os padrões demonstrados no exemplo Sample Component, atendendo aos requisitos abaixo: 

• Estrutura e empacotamento

  • Artefato Final: O arquivo a ser submetido deve, obrigatoriamente, ter a extensão .ear.

  • Geração do Pacote: Utilize o pacote pack (disponível na estrutura do projeto) para compilar e gerar o arquivo .ear corretamente.

• Identificação da Solução (component.xml)

  • Arquivo mandatório: A presença do arquivo component.xml é essencial para o reconhecimento do componente.

  • Código único (component code): Este campo define a identidade da sua solução. Ele deve ser exclusivo em toda a Store(global). Certifique-se de que o código escolhido não entra em conflito com nenhuma outra solução já existente.

• Apresentação e experiência (Recomendado)

  • Página dedicada: Utilize o arquivo pages.xml para configurar uma página exclusiva para sua solução dentro do TOTVS Fluig.

  • Identidade visual: Inclua um ícone personalizado. Isso profissionaliza a entrega e facilita a identificação do app pelo usuário final.

Boas práticas gerais

...

Para garantir o sucesso e a agilidade na aprovação da sua solução, recomendamos a adoção das seguintes práticas de qualidade e gestão.

• Estratégia de testes e QA

  • Roteiro de testes: Não teste de forma aleatória. Elabore e formalize um roteiro de testes que cubra as principais funcionalidades.

  • Evite o "Viés de Desenvolvimento": Desenvolvedores tendem a seguir o "caminho feliz" (o fluxo que sabem que funciona). Peça para uma pessoa externa ao desenvolvimento realizar os testes para identificar falhas não previstas.

  • Testes Fim-a-Fim (E2E): Valide todo o ciclo da jornada do usuário, desde a ação inicial até a conclusão do processo. Repita esse ciclo sempre que houver alterações no código.

• Validação de ambiente

  • Instalação limpa (Clean Install): Efetue a instalação da solução em um ambiente TOTVS Fluig "zerado" (sem configurações prévias). Isso garante que sua solução não dependa de arquivos ou configurações residuais da sua máquina de desenvolvimento.

• Processos e Colaboração

  • Feedback contínuo (Metodologia Ágil): Caso utilize Sprints, agende demonstrações com o time de Ecossistemas ao final de cada ciclo. Apresentar a evolução, mesmo que parcial, permite receber sugestões antecipadas e evitar retrabalho.

  • Revisão de código (Code Review): Se utilizar controle de versão (como Git), adote o fluxo de Pull Requests. Permitir que outro desenvolvedor avalie o código antes da integração reduz drasticamente a incidência de bugs e erros lógicos.

Processo de avaliação 

...

Após finalizar sua Soluçãosolução e seguir as boas práticas citadas acima, ela passará por estas etapas de avaliação:pelas etapas descritas a seguir, que compõem o processo oficial de avaliação - Review da Solução. Cada etapa foi estruturada para garantir qualidade, segurança e conformidade com os padrões da plataforma TOTVS Fluig.