Revisión | 84 (tree) |
---|---|
Tiempo | 2022-07-19 03:10:36 |
Autor | derekwildstar |
Listas To-Do atualizadas
@@ -269,34 +269,76 @@ | ||
269 | 269 | |
270 | 270 | Refresh; |
271 | 271 | 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 } | |
291 | 281 | |
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 } | |
292 | 292 | |
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) } | |
293 | 324 | |
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 } | |
294 | 332 | |
333 | + { TODO : Ao rejeitar uma tarefa, a atribuição dela também muda. Acredito que isso não deva acontecer } | |
295 | 334 | |
296 | 335 | |
297 | 336 | |
298 | 337 | |
299 | 338 | |
339 | + | |
340 | + | |
341 | + | |
300 | 342 | // testar rejeição, impedimento e execução bem como o checkbox |
301 | 343 | // implementar a execução = rejeição, cm abertura de comentário |
302 | 344 | // possivelmente vc vai precisar incluir mais um caso especial |
@@ -32,6 +32,11 @@ | ||
32 | 32 | |
33 | 33 | { TFormLogin } |
34 | 34 | |
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 | + | |
35 | 40 | procedure TFormLogin.FormShow(Sender: TObject); |
36 | 41 | begin |
37 | 42 | inherited; |
@@ -775,7 +775,7 @@ | ||
775 | 775 | // acordo com regras específicas |
776 | 776 | ACTNSendToTest.Hide; |
777 | 777 | 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 | |
779 | 779 | aprovação de homologação, esta ação altera o status para homologado. Leve isso |
780 | 780 | em conta } |
781 | 781 | ACTNApprove.Hide; |