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.
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?
Caso está no branch de versão?
DESENVOLVIMENTO
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.
O que foi corrigido/alterado? Por que?
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 informadoinformada neste espaço.
O que/onde validar?
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.
| TO-DO: 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. |
Qual o resultado esperado?
Indicar qual o comportamento esperado para o sistema nos locais onde os testes devem ser validados de maneira descritiva.
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
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.