Instruções para preenchimento do Script de Desenvolvimento.
O que é o Script de Desenvolvimento?
O script de desenvolvimento é um documento que deverá ser preenchido pela equipe de desenvolvimento e encaminhado à equipe de qualidade sempre que o caso for “resolvido” e passar para o status “Aguardando testes”.
No script deverão conter detalhadamente todas as informações referentes ao tratamento realizado no caso. Essas informações deverão ser preenchidas de uma maneira clara e objetiva, facilitando o entendimento da equipe de qualidade e de possíveis outros setores de qual era o problema relacionado ao caso, o que foi feito para corrigi-lo e qual o resultado esperado.
Estrutura do Script
Para auxiliar no preenchimento do script de desenvolvimento corretamente, as seguintes informações deverão ser fornecidas:
QUALIDADE
O que foi corrigido/Alterado? Por que?
Validações
Qual o resultado esperado?
Caso está no branch de versão?
DESENVOLVIMENTO
Units Alteradas:
Preenchimento do script de desenvolvimento
Como exemplo para o preenchimento do script de desenvolvimento utilizaremos o caso 0043310, onde o erro apontado era que quando a empresa utilizava o vínculo de usuário/vendedor e o usuário cadastrava dois ou mais pedidos sem fechar a tela de cadastro, o campo “Código do Vendedor” era limpo e o usuário era forçado a preencher o código novamente à cada novo registro.
Abaixo segue exemplo de como os scripts de desenvolvimento deverão ser preenchidos:
2.1. O que foi corrigido/alterado e porque?
“Corrigido o tratamento que verifica se o USUÁRIO logado possuí cadastro no menu 'Manutenção >Vendedores > Login de Vendedor > Cadastra/Manutenção', e faz a atribuição do código nos documentos de Orçamento, Pedido e Nota Fiscal.
No cadastro de documentos:
- No cadastro de um segundo documento sem fechar a tela, não estava atribuindo corretamente o Código do Vendedor do Usuário logado. Realizado correção;
Na tela de manutenção de documentos:
- Padronizada a função para que seja feita da mesma forma que dentro dos documentos;
- Criada uma validação que trava os campos de 'Vendedor', quando existir registro em 'Login de Vendedor'.
OBSERVAÇÃO: Não foram tratadas nesse caso as telas de 'Clientes' e 'Interessados'.”
Nesse tópico esperamos que seja apontado de forma clara e objetiva onde de fato estava o problema e o que foi corrigido ou alterado para solucioná-lo. Observar que é fácil identificar que o problema acontecia no cadastro de um segundo documento sem fechar a tela, onde não estava atribuindo corretamente o código do vendedor do usuário logado no sistema.
Também identificamos facilmente que a correção feita, é referente ao processo do menu
Manutenção > Vendedores > Login de Vendedor > Cadastra/Manutenção.
2.2. O que/onde validar?
“Telas de manutenção de Orçamento, Pedido e Nota Fiscal (todas as Notas e Recibo):
1. Usuário que possuí 'Login de Vendedor';
2. Usuário que NÃO possuí 'Login de Vendedor';
3. Usuário SUPERVISOR:
- Abertura das telas e atribuição das informações nos campos de 'Código de Vendedor' e 'Nome';
- Avançar para a próxima aba (Botão 'Próximo') e voltar e validar se as informações ficaram corretas.
Telas de cadastro de Orçamento, Pedido e Nota Fiscal (todas as Notas e Recibo):
1. Usuário que possuí 'Login de Vendedor';
2. Usuário que NÃO possuí 'Login de Vendedor';
3. Usuário SUPERVISOR:
- Abertura das telas e atribuição das informações nos campos de 'Código de Vendedor' e 'Nome' (Modo: 'Novo', 'Alteração' e 'Visualização');
Validar quando a empresa utiliza Comissão com vários vendedores
('Manutenção > Parâmetros Adicionais da Empresa > Comissão de Vendedores > "Tem mais de um vendedor por nota"').
Validar os itens citados nos ajustes e padronização do código.”
Observar que neste tópico o desenvolvedor indica onde e o que deve ser validado, porém não aponta como os testes deverão ser realizados. Com as informações disponibilizadas pelo desenvolvimento cabe à qualidade montar o roteiro de testes baseado nas alterações do código, verificando quais pontos deverão ser testados, possíveis outras parametrizações, menus, etc.
Para mais informações sobre testes e roteiro de testes, verificar os arquivos:
“Roteiro de testes – em branco”, “Exemplo Roteiro de Testes e “Processos qualidade e testes”
disponibilizados em: \\qualidade\Documentos Supersoft - Qualidade e Desenvol.
2.3. Qual o resultado esperado?
“Em todas as telas, o resultado deve ser a atribuição correta do Código e Nome do Vendedor, quando configurado para ter atribuição automática baseada no 'Login de Vendedor'.”.
Resumo de qual o resultado esperado no sistema após o tratamento do caso.
2.4. Caso está no BRANCH VERSÃO?
“NÃO.”
Resposta com apenas “SIM” ou “NÃO” informando se o caso já está vinculado ao branch da versão.
Obs: Idealmente os casos nunca deverão ser vinculados diretamente ao branch da versão sem
antes serem testados e validados no branch do caso.
2.5. Units alteradas/adicionadas:
“DESENVOLVIMENTO
Criado a classe 'Vendedor.Classes' para adicionar função relacionadas a Vendedores, como no caso, a função de atribuição de LOGIN DE VENDEDOR nos documentos.
Classe e funções foram criadas para evitar replica desnecessária de código e para facilitar manutenção.
Units Adicionadas:
Sistemas/Rotinas Comuns/Classes/Vendedor.Classes.pas (Classe para funções de 'Vendedores')
Units Alteradas:
Sistemas/SSVendas/NFMod12.pas (Tela de Cadastro/Alteração de Notas Fiscais e Recibo)
Sistemas/SSVendas/Orcamvd2.pas (Tela de Cadastro/Alteração de 'Orçamentos')
Sistemas/SSVendas/Pedidos1.pas (Tela de Manutenção de 'Pedidos')
Sistemas/SSVendas/Pedidos2.pas (Tela de Cadastro/Alteração de 'Pedidos')
Ajustes, e padronização de código:
ClassesD10/ParâmetroDoSistema.pas (Apenas ajustes/padronização de código. Validar a
gravação do menu "Parâmetros do Sistema");
Sistemas/SSVendas/DetComis.pas (Apenas ajustes/padronização de código. Validar
preenchimento de comissão);
Sistemas/SSVendas/Pedidos4.pas (Apenas ajustes/padronização de código. Validar busca de
Produtos no Pedido).”
Nesse tópico primeiramente o desenvolvedor deverá fazer um resumo do que foi feito para o próprio desenvolvimento, assim, futuramente quando um desenvolvedor precisar mexer na mesma função, ficará fácil de entender o que foi feito anteriormente. O desenvolvedor também deverá apontar quais units foram alteradas ou adicionadas e quais os menus/telas do sistema
são referentes à elas.
A criação/alteração de novos campos, tabelas, etc., também deverão ser relatadas nesse tópico, assim como os ajustes e padronização do código.