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 - https://wiki.supersoft.com.br/desenvol/view.php?id=XXXXX
Programador: Nome
|
# |
SIM |
NÃO |
|
|
1 |
Criação de tabela(s) |
|
|
|
2 |
Criação de campo(s) em tabela(s) já existente |
|
|
|
3 |
Criação de menu(s) / tela(s) |
|
|
|
4 |
Alteração em tela(s) já existente |
|
|
|
5 |
Alteração de lógica / validação / processo |
|
|
|
6 |
Correções de erros |
|
|
|
7 |
Adição de pastas / arquivos na instalação do sistema |
|
|
Caso está no branch de versão?
Units Alteradas / Adicionadas / Eliminadas
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 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
|
Menu > Sub-menu > Sub-Menu > Sub-menu > Sub-menu |
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.
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.
Caso está no branch de versão?
Informar apenas com SIM ou NÃO.
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.
Units alteradas/adicionadas/eliminadas
Neste espaço do script, recomenda-se que o desenvolvedor informe brevemente as alterações realizadas (de maneira semelhante as mensagens de versionamento), 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:
|
Units adicionadas Pasta_pai/pasta_filha/Unit1.pas (Unit criada para implementação da classe X) |
|
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) |
|
Ajustes e padronização de código Pasta_pai/pasta_filha/Unit.pas (Pequenos ajustes e padronização de código. Validar tela Z) |
Nota: A alteração/criação de novos campos, tabelas, etc., também deverão ser relatadas nesse tópico.
No Comments