Objetivo
Este guia tem o objetivo de apresentar, de maneira resumida, informações sobre o processo de Pré-QA dos apps desenvolvidos pelos parceiros da fluig Store.
Visão Geral
Após finalizar o desenvolvimento e testes do seu app, é o momento de enviá-lo para o quality assurance (QA). Para quem já é um parceiro fluig Store, acesse o documento completo do checklist de QA no Portal da fluig Store.
Porém, antes do envio para o QA de fato, existe essa etapa que chamamos de Pré-QA onde são avaliados alguns pré-requisitos antes mesmo da utilização do app.
Esse documento contém instruções a serem seguidas para agilizar o processo de Pré-QA do seu app. Seguindo corretamente essas instruções, podemos encaminhar o seu app para a etapa final no processo de QA.
Essa etapa de Pré-QA tem como objetivo verificar itens básicos como: código-fonte no git.fluig.com(Stash), build do projeto, deploy e ativação no fluig, disponibilidade e fácil acesso a documentação, confirmar se o app está consultando o License Server(LS) através do slotId e outros itens.
Itens Avaliados
1. Adequação e clean code
Widgets, Layouts e outros componentes do fluig já possuem uma estrutura padrão com pastas pré-definidas (css, js, images). Mantenha essa estrutura organizada.
Referenciar todo e qualquer biblioteca de JS no arquivo application.info.
Não deixe arquivos que não estão sendo utilizados dentro do componente. Se houver, remova-os antes de enviar para o QA.
O fluig já inclui algumas das bibliotecas mais utilizadas, como jQuery, jQuery UI e o próprio fluig Style Guide. Não é necessário adicioná-las novamente.
Internacionalização: Ao criar qualquer label, avisos, títulos e demais informações, é necessário internacionalizar os textos.
Utilizar a verificação de licença através da API de Licença.
2. Componente adaptado para a fluig Store
Para a fluig Store, padronizamos a estrutura que o componente deve ser desenvolvido, cujo objetivo também é acelerar o processo de QA, além de formatá-los para o download e instalação por meio da plataforma fluig de forma simples e rápida (Itens da Store). O componente deve seguir os padrões demonstrados no exemplo Sample Component, atendendo aos requisitos abaixo:
O arquivo final deve ser do tipo EAR. O pacote pack é o responsável por criar esse arquivo .ear.
É essencial que o app/componente tenha o arquivo component.xml. Ele contém o component code, que é o código do seu componente dentro da fluig Store e no fluig do cliente que será instalado. Lembre-se que esse código é geral para todos os apps na fluig Store, ou seja, não pode existir mais de um app/componente com o mesmo component code.
Recomendamos a utilização do pages.xml para criação de uma página dedicada especialmente para o seu app/component, além de um ícone próprio personalizado.
O Sample Component pode ser simulado como um app dos Itens da Store, efetuando o download e instalação de maneira simples e rápida. Leia o README.md para verificar os detalhes. Para maiores informações entre em contato com o pessoal da fluig Store.
3. Fazer o upload do código
Assim que o app/componente estiver adaptado para a fluig Store, o próximo passo é enviar para o processo de App Review. Acesse o Portal do Parceiro Fluig e veja como enviar: https://portal.fluigstore.com/enviarapp
4. Documentação
Juntamente com a entrega do app, solicitamos também uma documentação, contendo informações e detalhes da utilização. Os itens a seguir são fundamentais:
Fácil acesso a documentação
- Compatível com a versão do app (exibir apenas as features que contém no app e não features que estão em Road Map)
- Layout agradável e amigável. Se possível com imagens ou vídeos.
5. Envio para App Review
Após a verificação dos itens acima (que é um processo rápido, em torno de 1 a 2 dias úteis), o app está apto a iniciar as análises do código-fonte e os testes exploratórios, que é o QA propriamente dito. Assim que for finalizada esta etapa, será enviado o resultado por meio de um relatório, que indicará se o app está aprovado ou não.
Caso aprovado, o app já estará pronto para submissão na fluig Store, faltando apenas pequenos detalhes. Nesta etapa, precisamos fazer o upload do app para o repositório de arquivos. Essa submissão será realizada através de um processo no Portal fluig Store, juntamente do preenchimento de um formulário, com nome, descrição, e-mail de suporte, landing page e outras informações.
Caso não seja aprovado, o relatório irá detalhar os motivos e quais ajustes deverão ser feitos.
Fique atento!
Confira as principais causas de reprovação de um app:
- Implementações que não tratam alto volume de dados: usuários, documentos, etc;
- Funcionamento em ambientes restritos: DMZ, HTTPs, alta disponibilidade, etc;
- Documentação incompleta;
- Configurações complexas ou que dificultem/impeçam o uso de app em ambientes cloud;
- Canais de suporte não documentados;
- Falta de feedbacks ao usuário durante as operações (o quê, quando, onde?)
- Validações de campos de formulários, botões e pesquisas
Boas práticas
Seguem algumas dicas e boas práticas para você ter sucesso na aprovação do seu app:
- Testes
- Elabore e crie um Roteiro de Testes para o seu app. Confira aqui uma dica de como criar um roteiro para testes de usabilidade.
- Peça para alguma pessoa, que não seja um desenvolvedor do app, para fazer alguns testes. Geralmente o desenvolvedor fica 'viciado' nos testes e acaba sempre optando pela rota que funciona.
- Faça testes contemplando todo o ciclo da jornada do usuário. Desde a ação inicial até completar o processo. Repita sempre que possível.
- Efetue uma instalação do app em um fluig 'zerado'. Para isso, você pode utilizar uma imagem do fluig em Docker. Acesse o tutorial no Portal da fluig Store.
- Caso utilize metodologia Ágil e o modelo de Sprints, assim que finalizar uma Sprint, marque uma demonstração com a equipe da fluig Store para apresentar a evolução do app. Mesmo que ele não esteja finalizado, podemos dar sugestões/alterações para o andamento.
- Se estiver trabalhando com um sistema de controle de versões como o Git, utilize o conceito de Pull Requests: assim mais de um desenvolvedor avalia o código criado por um único desenvolvedor. Isso pode prevenir e diminuir erros no fonte.
Siga também as boas práticas de desenvolvimento relacionadas aqui.