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 informado neste espaço.
O que/onde validar?
ObservarEste tópico é de suma importância para garantir que nesteos tópicotestes sejam feitos de maneira completa e efetiva. Para isso, o desenvolvedor indicadeve ondeespecificar 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 validado,levado porémem nãconsideração apontaao como os testes deverão ser realizados. Comvalidar as informaçimplementações disponibilizadasfeitas.
|
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?
Resumo deIndicar qual o resultadocomportamento esperado nopara o sistema apósnos olocais tratamentoonde doos caso.testes devem ser validados de maneira descritiva.
Caso está no branch de versão?
RespostaInformar apenas com apenas “SIM”SIM ou “NÃO”O.
Nota: se o caso já está vinculado ao branch da versão.Obs: IdealmenteIdealmente, os casos nunca deverão ser vinculados diretamenteà aoalgum branch dade versão sem
antes serem testados e validados nonos branchbranches dodos caso.casos. Então, espera-se que a resposta para essa pergunta seja "não" na grande maioria das vezes.
Units alteradas/adicionadas:adicionadas
NesseNeste tópicoespaço primeiramentedo script, recomenda-se que o desenvolvedor deveráinforme fazerbrevemente umas resumoalteraçõ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 feitorealizado paratais oalterações.
Após próprioisso, desenvolvimento,deve-se 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á apontarrelatar quais units foram alteradasadicionadas 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 Pasta_pai/pasta_filha/Unit.pas (Pequenos ajustes e padronização de código. Validar tela Z) |
Nota: A criaçalteração/alteraçcriaçã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.pico.