• R/O
  • SSH
  • HTTPS

mantisbtmonitor: Commit


Commit MetaInfo

Revisión84 (tree)
Tiempo2022-07-19 03:10:36
Autorderekwildstar

Log Message

Listas To-Do atualizadas

Cambiar Resumen

Diferencia incremental

--- trunk/client/src/UDamoTask.pas (revision 83)
+++ trunk/client/src/UDamoTask.pas (revision 84)
@@ -269,34 +269,76 @@
269269
270270 Refresh;
271271 end;
272- { TODO : Ao Aocolocar uma tarefa em execução é necessário alterar o campo
273- Unidade Responsável Pelo Atendimento de forma que ela seja a unidade da pessoa
274- que iniciou a ação. Taciano solicitou isso a Kirlian e eu particularmente não
275- concordo, porque requer que se tenha permissão para alterar uma tarefa e isso
276- não deveria ser papel do desenvolvedor. Caso isso seja implementado você terá
277- de mapear o tipo TUnitId (UConfigurations.pas) para a unidade que deve ser
278- enviada via posta ao alterar a tarefa. Aparentemente para alterar só este
279- campo preciso mandar um post completo, como era de se imaginar. Tente
280- convencer taciano de que isso é obrigação do gestor e nao do programa }
281- { TODO : Quando a unidade de testes ou homologação abrir a tela rejeição,
282- todos os comentários devem ser varridos em busca de tags <reit>. Caso seja a
283- unidade testes, deve-se levar em conta os tags <reit> que são irmãos dos tags
284- <tere> (tests rejection) e caso seja a unidade de homologação, deve-se levar
285- em conta os tags <reit> que são irmãos de <hore> (homologation rejection). Com
286- a lista de tags <reit> considerados, deve-se ler o tag interno <num> e achar o
287- maior deles, o qual será usado como base para criação de novos itens de
288- rejeição na tela de rejeição, por exemplo, caso o maior numero achado seja 3,
289- significa que o próximo item de rejeição a ser adicionado nesta tela será o 4
290- e assim sucessivamente }
272+{ TODO : Ao colocar uma tarefa em execução é necessário alterar o campo "Unidade
273+Responsável Pelo Atendimento" de forma que ela seja a unidade da pessoa que
274+iniciou a ação. Taciano solicitou isso a Kirlian e eu particularmente não
275+concordo, porque requer que se tenha permissão para alterar uma tarefa e isso
276+não deveria ser papel do desenvolvedor. Caso isso seja implementado você terá de
277+mapear o tipo TUnitId (UConfigurations.pas) para a unidade que deve ser enviada
278+via post ao alterar a tarefa. Aparentemente para alterar só este campo preciso
279+mandar um post completo, como era de se imaginar. Tente convencer Taciano de que
280+isso é obrigação do gestor e nao do programa }
291281
282+{ TODO -cUES : Quando a unidade de testes ou homologação abrir a tela rejeição,
283+todos os comentários devem ser varridos em busca de tags <reit> (rejection
284+item). Caso seja a unidade de testes, deve-se levar em conta os tags <reit> que
285+são irmãos dos tags <tere> (tests rejection) e caso seja a unidade de
286+homologação, deve-se levar em conta os tags <reit> que são irmãos de <hore>
287+(homologation rejection). Com a lista de tags <reit> considerados, deve-se ler o
288+tag interno <num> e achar o maior deles, o qual será usado como base para
289+criação de novos itens de rejeição na tela de rejeição, por exemplo, caso o
290+maior numero achado seja 3, significa que o próximo item de rejeição a ser
291+adicionado nesta tela será o 4 e assim sucessivamente }
292292
293+{ TODO -cUES : A unidade de testes vai contar os ciclos de testes de uma
294+determinada tarefa, o que significa que cada rejeição mais a aprovação final
295+serão contabilizadas. A aprovação final é que gerará a pontuação no GEDES
296+Ranking, quando a quantidade de ciclos de testes será usada como multiplicador
297+do peso da tarefa. O MantisBT Monitor já realiza contabilizações de forma
298+genérica, no caso, de mudanças de estado então é fácil calcular a quantidade de
299+rejeições, o problema é que nem todas as rejeições podem ser contabilizadas.
300+Existem rejeições que não foram decorrentes de trabalho de teste realizado, mas
301+apenas rejeições que surgiram de trabalho de testes serão contadas como ciclo. A
302+forma como isso será feito ainda não foi definido nesta data (18/07/2022). A
303+forma mais fácil de isso ser automatizado seria se houvessem dois tipos de
304+rejeição, uma que decorreu de testes de fato e outra que não gerou qualquer
305+teste, como por exemplo um erro ao tentar logar na aplicação. Este erro geraria
306+uma rejeição e neste caso consequentemente um ciclo de testes, porém ao chegar
307+no desenvolvedor, descobriu-se que tal erro foi um erro de build e neste caso o
308+ciclo de testes nao deveria ser contabilizado. Isso dá a responsabilidade de
309+contabilização do ciclo para o desenvolvedor, que vai de fato dizer que isso
310+"não é problema dele", entretanto se houve o teste pra saber que aquilo
311+aconteceu, o colaborador de testes fez seu trabalho, então porque não contar o
312+ciclo? Uma ideia que surgiu é que ao implementar a rejeição no MantisBT Monitor,
313+o colaborador de testes tenha que escolher o tipo de rejeição. Rejeições normais
314+contam como ciclo completo e podem conter de 2 a vários itens. Rejeições normais
315+valem 1 ponto de multiplicador. Rejeições simplificadas ou especiais só podem
316+conter um item e por isso valerão meio ponto. Isso é algo que ainda precisa ser
317+definido. A forma como eu especifiquei aqui não é perfeita e é até ruim, porque
318+penaliza casos onde só há um ponto a ser testado. Me fata conhecimento do
319+funcionamento de testes. O ponto todo é: como contabilizar ciclos se alguns
320+deles não podem ser contabilizados? De quem é a responsabilidade por definir que
321+uma rejeição não deve ser contabilizada como ciclo? Como testes pode saber que
322+algo não é da conta do programador, rejeitar pra ele e ter seu ponto negado por
323+ não ser um ciclo? (dessa eu discordo totalmente) }
293324
325+{ TODO : Durante a primeira execução do programa, quando valores de registro são
326+criados, os botões de envio para testes e homologação não aparecem,
327+provavelmente porque algum objeto que deveria ser carregado após o login não
328+foi. Ao fechar o programa aparecem dois memory leaks que devem ter a ver com
329+isso. Faça o teste! apague tudo que tiver dentro de
330+HKCU\Software\TJPE\MantisBT Monitor e rode o programa monitorando
331+TFormTask.ConfigureStatusChangeActions }
294332
333+ { TODO : Ao rejeitar uma tarefa, a atribuição dela também muda. Acredito que isso não deva acontecer }
295334
296335
297336
298337
299338
339+
340+
341+
300342 // testar rejeição, impedimento e execução bem como o checkbox
301343 // implementar a execução = rejeição, cm abertura de comentário
302344 // possivelmente vc vai precisar incluir mais um caso especial
--- trunk/client/src/UFormLogin.pas (revision 83)
+++ trunk/client/src/UFormLogin.pas (revision 84)
@@ -32,6 +32,11 @@
3232
3333 { TFormLogin }
3434
35+{ TODO : É necessário criar um campo aqui para a unidade do usuário. caso esta
36+configuração não seja definida, os headers dos comentários não aparecerão
37+direito. Isso deve ser feito de forma que o tal campo seja salvo no registro do
38+Windows também, tal como é feito atualmente com outros campos }
39+
3540 procedure TFormLogin.FormShow(Sender: TObject);
3641 begin
3742 inherited;
--- trunk/client/src/UFormTask.pas (revision 83)
+++ trunk/client/src/UFormTask.pas (revision 84)
@@ -775,7 +775,7 @@
775775 // acordo com regras específicas
776776 ACTNSendToTest.Hide;
777777 ACTNSendToHomologation.Hide;
778- { TODO : Se o botão de aprovação referenciado abeixo for usado também na
778+ { TODO : Se o botão de aprovação referenciado abaixo for usado também na
779779 aprovação de homologação, esta ação altera o status para homologado. Leve isso
780780 em conta }
781781 ACTNApprove.Hide;
Show on old repository browser