# Script de Desenvolvimento

# Definição



# Instruções para preenchimento do Script de Desenvolvimento

#### **O que é o Script de Desenvolvimento?**

O Script de desenvolvimento é um documento que deve ser preenchido pela equipe de desenvolvimento e encaminhado à equipe de Qualidade quando o status do caso passar para “Aguardando testes”.

Sendo que todo o caso, deverá conter necessariamente um script de desenvolvimento.

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.

O documento será disponibilizado nas pasta do caso através do SVN, no formato .ODT. O mesmo deve ser preenchido após o termino do tratamento e ter as alterações adicionadas ao SVN.  
Para gravar o arquivo depois do preenchimento, usar o padrão "Script\_Desenvolvimento\_ + Numero Caso". Exemplo: *"Script\_Desenvolvimento\_0043310"*

Na conclusão do caso, a Qualidade esta responsável por gerar um arquivo .PDF e disponibilizar no caso do Mantis, para acesso dos setores de Suporte, Projetos e demais interessados. O objetivo é fornecer a informação das alterações realizadas para demais setores envolvidos.

---

#### **Estrutura do Script**

Para auxiliar no preenchimento do script de desenvolvimento corretamente, as seguintes informações deverão ser fornecidas:

**Caso 00XXXXX -** <span lang="zxx"><u>[https://mantis.supersoft.com.br/desenvol/view.php?id=XXXXX](https://mantis.supersoft.com.br/desenvol/view.php?id=XXXXX)</u></span>

<span lang="zxx">**Programador:** Nome</span>

<table cellpadding="4" cellspacing="0" id="bkmrk-%23-resumo-sim-n%E3%83o-1-cr" width="680"><tbody><tr valign="top"><td width="29">**\#**

</td><td width="521">[**RESUMO**](#bkmrk-resumo)

</td><td width="49">**SIM**

</td><td width="48">**NÃO**

</td></tr><tr valign="top"><td width="29">**1**

</td><td width="521">Criação de tabela(s)

</td><td width="49"></td><td width="48"></td></tr><tr valign="top"><td width="29">**2**

</td><td width="521">Criação de campo(s) em tabela(s) já existente

</td><td width="49"></td><td width="48"></td></tr><tr valign="top"><td width="29">**3**

</td><td width="521">Criação de menu(s) / tela(s)

</td><td width="49"></td><td width="48"></td></tr><tr valign="top"><td width="29">**4**

</td><td width="521">Alteração em tela(s) já existente

</td><td width="49"></td><td width="48"></td></tr><tr valign="top"><td width="29">**5**

</td><td width="521">Alteração de lógica / validação / processo

</td><td width="49"></td><td width="48"></td></tr><tr valign="top"><td width="29">**6**

</td><td width="521">Correções de erros

</td><td width="49"></td><td width="48"></td></tr><tr valign="top"><td width="29">**7**

</td><td width="521">Adição de pastas / arquivos na instalação do sistema

</td><td width="49"></td><td width="48"></td></tr></tbody></table>

[<span style="text-decoration: underline;">**Sistemas Alterados**</span>](#bkmrk-sistemas-alterados-0)

<span style="text-decoration: underline;">**[Detalhamento das Alterações](#bkmrk-o-que-foi-corrigido%2F-0)**</span>

<span style="text-decoration: underline;">**[Resultado Esperado](#bkmrk-qual-o-resultado-esp-0)**</span>

**<span style="text-decoration: underline;">[Validações](#bkmrk-o-que%2Fonde-validar%3F)</span>**

<span style="text-decoration: underline;">**[Caso está no branch de versão?](#bkmrk-caso-est%E3%A1-no-branch-d-0)**</span>

<span style="text-decoration: underline;">**[Units Alteradas / Adicionadas / Eliminadas](#bkmrk-units-alteradas%2Fadic)**</span>

---

#### <span style="text-decoration: underline;"></span>**Preenchimento do script de desenvolvimento**

Neste tópico, serão passadas algumas orientações à respeito das informações que devem ser fornecidas em cada tópico do script, para exemplos práticos verificar o capítulo de [exemplos](https://wiki.supersoft.com.br/books/script-de-desenvolvimento/chapter/exemplos) de scripts de desenvolvimento.

##### **Resumo**

Nesse quadro é indicado quais os tipos de alterações realizadas no caso através da marcação das opções com "X".

##### **Sistemas alterados**

Neste tópico é preenchido quais módulos foram alterados com o tratamento e devem ser liberados.

##### **Detalhamento das alterações**

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. Observe que, quando bem respondida esta questão, é fácil identificar o que exatamente foi corrigido, implementado ou alterado, facilitando e simplificando o processo de testes por parte da equipe da qualidade.

Neste tópico, pode-se indicar qual caminho é feito para chegar até a tela alterada, utilizando a seguinte notação

<table border="1" id="bkmrk-menu-%3E-sub-menu-%3E-su"><tbody><tr><td>Menu &gt; Sub-menu &gt; Sub-Menu &gt; Sub-menu &gt; Sub-menu

</td></tr></tbody></table>

Caso seja necessário realizar alguma ação na tela alterada, como preenchimento de algum campo, ativação de algum evento (saída, entrada, mudança de aba, etc), isso também deve ser respondido neste tópico.

Além disso, qualquer melhoria ou correção feita que esteja fora do escopo inicial do caso, também deve ser informada neste espaço.

É opcional a adição de imagens ilustrativas (print screen), para destacar algum menu/tela/campo novo, alteração de descrição de componentes, modificações em telas, etc. Em caso de novas implementações, é recomendado o uso de imagens, para ficar claro para os demais setores (Suporte/Projetos), quais foram as alterações visuais.

##### **Resultados esperado**

Indicar qual o comportamento esperado para o sistema nos locais onde os testes devem ser validados de maneira descritiva.

##### **Validações**

Este tópico é de suma importância para garantir que os testes sejam feitos de maneira completa e efetiva. Para isso, o desenvolvedor deve especificar quais telas devem ser testadas e sob quais circunstâncias, podendo informar alguns exemplos iniciais para que a equipe de qualidade, ao elaborar/seguir o roteiro de testes considere tais situações e elabore situações semelhantes que considerem relevantes para a validação do teste.

<p class="callout info">Nota: Não cabe ao desenvolvedor informar COMO os testes devem ser realizados e sim o que deve ser levado em consideração ao validar as implementações feitas.</p>

##### **Caso está no branch de versão?**

Informar apenas com SIM ou NÃO.

<p class="callout info">Nota: Idealmente, os casos nunca deverão ser vinculados à algum branch de versão sem antes serem testados e validados nos branches dos casos. Então, espera-se que a resposta para essa pergunta seja "não" na grande maioria das vezes.</p>

##### **Units alteradas/adicionadas/eliminadas**

Neste espaço do script, recomenda-se que o desenvolvedor informe brevemente as alterações realizadas (de maneira semelhante as <span style="text-decoration: underline;">[mensagens de versionamento](https://wiki.supersoft.com.br/books/padroes-de-codigo/page/versionamento)),</span> assim, caso ocorra de outro desenvolvedor trabalhar em uma situação relacionada à essa, ele consiga ter uma noção do contexto em que foi realizado tais alterações.

Após isso, deve-se relatar quais units foram adicionadas ou alteradas. Por exemplo:

<table border="1" id="bkmrk-units-adicionadas-pa"><tbody><tr><td>**Units adicionadas**

Pasta\_pai/pasta\_filha/Unit1.pas (Unit criada para implementação da classe X)

</td></tr></tbody></table>

<table border="1" id="bkmrk-units-alteradas-past"><tbody><tr><td>**Units alteradas**

Pasta\_pai/pasta\_filha/Unit2.pas (Tela de cadastro/alteração da entidade Y)

Pasta\_pai/pasta\_filha/Unit3.pas (Tela de cadastro/alteração da entidade W)

Pasta\_pai/pasta\_filha/Unit4.pas (Tela de geração dos recibos A, B, C)

</td></tr></tbody></table>

<table border="1" id="bkmrk-ajustes-e-padroniza%E3%A7%E3"><tbody><tr><td>**Ajustes e padronização de código**

Pasta\_pai/pasta\_filha/Unit.pas (Pequenos ajustes e padronização de código. Validar tela Z)

</td></tr></tbody></table>

<p class="callout info">Nota: A alteração/criação de novos campos, tabelas, etc., também deverão ser relatadas nesse tópico.</p>

# Exemplos

Capítulo destinado à exemplos de scripts de desenvolvimento preenchidos e situações que podem ser semelhantes em outros casos

# Exemplo de Script de Desenvolvimento - Casos de erro

Neste documento iremos citar exemplos práticos de como devem e como não devem ser preenchidas cada uma das perguntas referentes ao Script de Desenvolvimento. As respostas devem ser sempre claras e objetivas, facilitando o entendimento da equipe de Qualidade e dos demais outros setores de qual era o problema do caso, o que foi feito para corrigi-lo e qual o resultado esperado.

Para saber mais sobre o que é o Script de Desenvolvimento e sua estrutura, acessar o capítulo <span style="text-decoration: underline;">[Definição](https://wiki.supersoft.com.br/books/script-de-desenvolvimento/chapter/definicao).</span>  
  
Utilizaremos o caso [<span style="text-decoration: underline;">0043310</span>](https://mantis.supersoft.com.br/desenvol/view.php?id=43310) como exemplo para o preenchimento das etapas do Script de Desenvolvimento.

---

#### **Resumo geral**

##### **Forma correta de preenchimento:**

> <table cellpadding="4" cellspacing="0" width="680"><tbody><tr valign="top"><td width="29">**\#**
> 
> </td><td width="521">**RESUMO**
> 
> </td><td width="49">**SIM**
> 
> </td><td width="48">**NÃO**
> 
> </td></tr><tr valign="top"><td width="29">**1**
> 
> </td><td width="521">Criação de tabela(s)
> 
> </td><td width="49"></td><td width="48">X
> 
> </td></tr><tr valign="top"><td width="29">**2**
> 
> </td><td width="521">Criação de campo(s) em tabela(s) já existente
> 
> </td><td width="49">X
> 
> </td><td width="48"></td></tr><tr valign="top"><td width="29">**3**
> 
> </td><td width="521">Criação de menu(s) / tela(s)
> 
> </td><td width="49"></td><td width="48">X
> 
> </td></tr><tr valign="top"><td width="29">**4**
> 
> </td><td width="521">Alteração em tela(s) já existente
> 
> </td><td width="49">X
> 
> </td><td width="48"></td></tr><tr valign="top"><td width="29">**5**
> 
> </td><td width="521">Alteração de lógica / validação / processo
> 
> </td><td width="49">X
> 
> </td><td width="48"></td></tr><tr valign="top"><td width="29">**6**
> 
> </td><td width="521">Correções de erros
> 
> </td><td width="49"></td><td width="48">X
> 
> </td></tr><tr valign="top"><td width="29">**7**
> 
> </td><td width="521">Adição de pastas / arquivos na instalação do sistema
> 
> </td><td width="49"></td><td width="48">X
> 
> </td></tr></tbody></table>

<p class="callout success">Neste exemplo podemos verificar que foi criado campo(s) em tabela(s) já existente, alteração em telas já existente e alteração de lógica ou funcionamento de algum processo. Com essas informações é possível ter uma noção inicial de quais tipos de validação deveram ser realizadas no caso.</p>

##### **Forma incorreta de preenchimento:**

> <table cellpadding="4" cellspacing="0" style="height: 412px; width: 679px;" width="680"><tbody><tr style="height: 35px;" valign="top"><td class="align-center" style="height: 35px; width: 169px;">**\#**
> 
> </td><td class="align-center" style="height: 35px; width: 170px;">**RESUMO**
> 
> </td><td class="align-center" style="height: 35px; width: 170px;">**SIM**
> 
> </td><td class="align-center" style="height: 35px; width: 170px;">**NÃO**
> 
> </td></tr><tr style="height: 35px;" valign="top"><td class="align-center" style="height: 35px; width: 169px;">**1**
> 
> </td><td class="align-center" style="height: 35px; width: 170px;">Criação de tabela(s)
> 
> </td><td class="align-center" style="height: 35px; width: 170px;"></td><td class="align-center" style="height: 35px; width: 170px;"></td></tr><tr style="height: 57px;" valign="top"><td class="align-center" style="height: 57px; width: 169px;">**2**
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">Criação de campo(s) em tabela(s) já existente
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">X
> 
> </td><td class="align-center" style="height: 57px; width: 170px;"></td></tr><tr style="height: 57px;" valign="top"><td class="align-center" style="height: 57px; width: 169px;">**3**
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">Criação de menu(s) / tela(s)
> 
> </td><td class="align-center" style="height: 57px; width: 170px;"></td><td class="align-center" style="height: 57px; width: 170px;"></td></tr><tr style="height: 57px;" valign="top"><td class="align-center" style="height: 57px; width: 169px;">**4**
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">Alteração em tela(s) já existente
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">X
> 
> </td><td class="align-center" style="height: 57px; width: 170px;"></td></tr><tr style="height: 57px;" valign="top"><td class="align-center" style="height: 57px; width: 169px;">**5**
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">Alteração de lógica / validação / processo
> 
> </td><td class="align-center" style="height: 57px; width: 170px;">X
> 
> </td><td class="align-center" style="height: 57px; width: 170px;"></td></tr><tr style="height: 35px;" valign="top"><td class="align-center" style="height: 35px; width: 169px;">**6**
> 
> </td><td class="align-center" style="height: 35px; width: 170px;">Correções de erros
> 
> </td><td class="align-center" style="height: 35px; width: 170px;"></td><td class="align-center" style="height: 35px; width: 170px;"></td></tr><tr style="height: 79px;" valign="top"><td class="align-center" style="height: 79px; width: 169px;">**7**
> 
> </td><td class="align-center" style="height: 79px; width: 170px;">Adição de pastas / arquivos na instalação do sistema
> 
> </td><td class="align-center" style="height: 79px; width: 170px;"></td><td class="align-center" style="height: 79px; width: 170px;"></td></tr></tbody></table>

<p class="callout danger">Neste exemplo podemos que não foram preenchidos os campos que não tiveram alterações, mas é importante a indicação do mesmo em todos os casos.</p>

#### **Sistemas alterados**

> VENDAS, COMPRAS, ESTOQUE

<p class="callout warning">Nesse tópico deve se atentar em indicar quais módulos foram alterados, para que sejam realizados os testes corretamente e posteriormente sejam liberados para os clientes.</p>

#### **Detalhamento das alterações**

##### **Forma correta de preenchimento:**

> “Corrigido o tratamento que verifica se o USUÁRIO logado possuí cadastro no menu  
> 'Manutenção &gt;Vendedores &gt; Login de Vendedor &gt; 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;
> 
> [![image-1612816473705.png](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/scaled-1680-/image-1612816473705.png)](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/image-1612816473705.png)
> 
> 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'.
> 
> [![image-1612816487933.png](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/scaled-1680-/image-1612816487933.png)](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/image-1612816487933.png)
> 
> OBSERVAÇÃO: Não foram tratadas nesse caso as telas de 'Clientes' e 'Interessados'.”

<p class="callout success">Neste exemplo podemos identificar facilmente onde é realizado o vínculo entre usuário/vendedor (menu "Manutenção &gt; Vendedores &gt; Login de Vendedor &gt; Cadastra/Manutenção") e que o problema é que a atribuição do código do vendedor não estava sendo feita corretamente quando cadastrado um segundo documento, podendo ser Orçamentos, Pedidos ou Notas Fiscais.  
Além de ter corrigido o erro principal relatado no caso, o desenvolvedor realizou melhorias nos menus de manutenção de documentos, especificando o que foi feito.   
Foi utilizado imagens ilustrativas para destacar os campos que tiveram impacto no tratamento realizado (opcional).  
Observar também que o desenvolvedor deixa claro que neste caso não foram tratados os menus de "Clientes" e "Interessados".</p>

##### **Forma incorreta de preenchimento:**

> “Corrigido o tratamento que verifica se o USUÁRIO logado possuí vínculo de usuário/vendedor e não estava fazendo a atribuição do código do vendedor corretamente nos documentos.
> 
> Realizado ajustes para padronização na tela de manutenção dos documentos."

<p class="callout danger">Verificar neste exemplo que o desenvolvedor nos diz que o erro do caso é referente à não atribuição correta do código do vendedor nos documentos quando o mesmo possui vínculo de usuário/vendedor, porém não deixa claro qual menu do sistema pode ser consultado o cadastro de usuário/vendedor, quais documentos apresentam o problema e nem que o problema acontecia somente no cadastro de um segundo documento.  
O desenvolvedor cita que foram realizados ajustes para padronização do menu de manutenção de documentos, porém também não especifica o que foi feito. Também não foi citado que este caso não tratou os menus de "Clientes" e "Interessados", deixando brecha para que outros departamentos entendam que os mesmos também foram corrigidos.</p>

#### **Resultados esperado**

##### **Forma correta de preenchimento:**

> “Em todas as telas de cadastro e edição, o resultado deve ser a atribuição correta do Código e Nome do Vendedor quando o usuário logado no sistema possuir cadastro de "Login de Vendedor".  
> Para usuários que não possuírem registro de "Login de Vendedor" não deve ser atribuído automaticamente nenhum código de vendedor no cadastro, edição ou pesquisa (menu manutenção) dos documentos."

<p class="callout success">Neste exemplo o desenvolvedor deixa claro qual comportamento o sistema deve ter quando o usuário logado no sistema possuir registro de "Login de Vendedor" e quando o usuário não possuir.</p>

##### **Forma incorreta de preenchimento:**

> "Atribuir corretamente o Código e Nome do Vendedor quando o usuário logado no sistema possuir cadastro de "Login de Vendedor".

<p class="callout danger">Não deixa claro em quais documentos deve ser atribuído corretamente o Código e Nome do Vendedor, se deve ser incluído somente no cadastro, se somente na edição, na consulta (manutenção) de documentos, etc.  
Também não cita o que deve acontecer quando o usuário logado no sistema NÃO possuir registro de "Login de Vendedor".</p>

#### **Validações**

##### **Forma correta de preenchimento:**

> Telas de manutenção de Orçamento, Pedido e Nota Fiscal (todas as Notas e Recibo):
> 
> - Usuário que possuí "*Login* de Vendedor";
> - Usuário que NÃO possuí "*Login* de Vendedor";
> - 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):
> 
> - Usuário que possuí "*Login* de Vendedor";
> - Usuário que NÃO possuí "*Login* de Vendedor";
> - 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 &gt; Parâmetros  
> Adicionais da Empresa &gt; Comissão de Vendedores &gt; "Tem mais de um vendedor por nota"').  
> Validar os itens citados nos ajustes e padronização do código.”

<p class="callout success">Neste exemplo o desenvolvedor deixa claro que deverão ser realizados testes nas telas de manutenção (edição) e cadastro de Orçamentos, Pedidos e Notas (todos modelos da NFmodel1), citando alguns exemplos do que validar. É especificado também que os testes deverão ser realizados com usuários que possuam "Login de vendedor", usuários que NÃO possuam "Login de vendedor" e com o usuário Supervisor.  
É citado que deverão ser realizados testes com empresas que utilizam comissão com vários vendedores e especificado qual o caminho para configurar tal parâmetro.  
Lembrando: No Script de Desenvolvimento o desenvolvedor deverá descrever o que e onde validar, porém caberá ao departamento de Qualidade analisar o caso, o que foi feito e então elaborar um Roteiro de Testes para fazer a validação do tratamento.</p>

##### **Forma incorreta de preenchimento:**

> "Realizar o cadastro de documentos e verificar se o código de vendedor será preenchido corretamente quando o usuário logado no sistema possuir vínculo de "Login de vendedor"."

<p class="callout danger">Neste exemplo o desenvolvedor orienta para realizar testes no cadastro de documentos e verificar se o código do vendedor será atribuído corretamente quando o usuário logado no sistema possuir vínculo de "Login de vendedor", porém não orienta em quais documentos houveram alteração e precisarão ser validados, sobre testes com usuários que não possuam "Login de vendedor" e com usuário Supervisor. Também não é orientado sobre testes com outras parametrizações, como por exemplo se estiver assinalado o parâmetro que utiliza mais de um vendedor por nota. </p>

#### **Caso está no Branch da Versão?**

> Não.

<p class="callout warning">Resposta apenas com "SIM" ou "NÃO", portanto não há preenchimento "certo" ou "errado".  
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.</p>

#### **Desenvolvimento - Units alteradas/adicionadas/eliminadas:**

##### **Forma correta de preenchimento:**

> “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).”

<p class="callout success">Neste exemplo o desenvolvedor primeiramente faz um resumo para o próprio Desenvolvimento das alterações que foram realizadas, depois deixa claro todas as Units que foram adicionadas, alteradas e as que realizou algum tipo de ajuste e padronização de código.  
Em frente de cada Unit é especificado qual o Menu/Tela do sistema está relacionado à Unit, dessa forma é fácil para a equipe da Qualidade ou para qualquer outro departamento saber exatamente em quais menus/telas do sistema houveram alterações.</p>

##### **Forma incorreta de preenchimento:**

> **"Units Adicionadas:**  
> Sistemas/Rotinas Comuns/Classes/Vendedor.Classes.pas  
>   
> **Units Alteradas:**  
> Sistemas/SSVendas/NFMod12.pas  
> Sistemas/SSVendas/Orcamvd2.pas  
> Sistemas/SSVendas/Pedidos1.pas  
> Sistemas/SSVendas/Pedidos2.pas"

<div id="bkmrk--0"><svg class="svg-icon" data-icon="link" role="presentation" viewbox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"></svg></div><p class="callout danger">Neste exemplo não foi feito o resumo para o próprio Desenvolvimento sobre as alterações que foram realizadas.  
O desenvolvedor apenas cita as Units que foram adicionadas e alteradas, porém não as relaciona com os menus/telas do sistema, dificultando para que a equipe da Qualidade e demais setores saibam exatamente quais menus/telas sofreram qualquer tipo de alteração no caso.</p>

# Processos do Script de Desenvolvimento



# [BETA] Processo de criação, preenchimento e postagem - Desenvolvimento / Qualidade

##### **Criação do Branch do caso e adição do Script de Desenvolvimento (Desenvolvimento):**

Inicialmente é necessário cria a pasta do Branch conforme a estrutura básica padrão ([<span style="text-decoration: underline;">SVN - Estrutura básica</span>](https://wiki.supersoft.com.br/books/organizacao-e-dinamica-de-casos/page/svn-estrutura-basica)).

Após a criação do Branch e *Checkout* do mesmo, adicionar o arquivo "Script\_Desenvolvimento.odt" em anexo nesta [<span style="text-decoration: underline;">página</span>](https://wiki.supersoft.com.br/books/script-de-desenvolvimento/page/instrucoes-para-preenchimento-do-script-de-desenvolvimento), dentro da pasta ***"*****Documentos*****"**.*

Em seguida é necessário realizar o processo de adição do arquivo ao projeto no SVN através do menu ***"TortoiseSVN &gt; Add"***:

[![image-1612957731129.png](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/scaled-1680-/image-1612957731129.png)](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/image-1612957731129.png)

O próximo passo é submeter (*commit*) a adição do arquivo, conforme exemplificado a seguir:

[![image-1612957909730.png](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/scaled-1680-/image-1612957909730.png)](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/image-1612957909730.png)

<p class="callout info">**EXTRA:** Ao criar um novo caso, também será necessário realizar a adição do [ROTEIRO\_TESTES.ods](https://wiki.supersoft.com.br/attachments/23), seguindo os mesmo passos dessa pagina.</p>

Os documentos devem ficar organizados na seguinte disposição:

<table border="1" class="align-center" id="bkmrk-pasta-do-programador" style="border-collapse: collapse; width: 83.5802%; height: 29px;"><tbody><tr style="height: 29px;"><td class="align-center" style="width: 100%; height: 29px;">*Pasta do Programador / Pasta do Caso / Pasta do Codigo Fonte + Documentos / Script de Desenvolvimento*</td></tr></tbody></table>

 **Exemplo:** .../branches/Programador/Caso-43616/Documentos/SCRIPT-DESENVOLVIMENTO.docx (figura abaixo)

[![image-1612813252099.png](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/scaled-1680-/image-1612813252099.png)](https://wiki.supersoft.com.br/uploads/images/gallery/2021-02/image-1612813252099.png)

##### **Alterações do Script de Desenvolvimento e *commit* no *SVN* (Desenvolvimento):**

Após preenchimento do Script de Desenvolvimento, as alterações devem ser submetidas (*commit*) ao *SVN*, da mesma forma que é realizado com o código fonte.

##### **Publicação do Script de Desenvolvimento no caso do Mantis (Qualidade):**

Quando o caso for finalizado, realizado todas as etapas de testes e o mesmo for liberado em uma versão, a Qualidade deve gerar um arquivo .PDF do *Script* de Desenvolvimento e disponibilizar o mesmo no caso do Mantis.

O objetivo é que outros setores interessados, como Suporte, Projetos, etc, tenham acesso ao documentos para ficar informado sobre as alterações, implementações e correções realizadas no caso.