A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Relatório de Fechamento do Projeto São Paulo, 07 de Janeiro de 2013 Projeto XXXX.

Apresentações semelhantes


Apresentação em tema: "Relatório de Fechamento do Projeto São Paulo, 07 de Janeiro de 2013 Projeto XXXX."— Transcrição da apresentação:

1 Relatório de Fechamento do Projeto São Paulo, 07 de Janeiro de 2013 Projeto XXXX

2 Casos de Teste - Métricas do Projeto Ferramenta utilizada para Gestão dos Testes - TestLink Ferramenta WEB Cadastro e Cobertura de Requisitos Elaboração do Plano e da Execução dos Testes Indicadores e Relatórios de Execução dos Testes Integração com o RedMine Interagir - Números do projeto de teste: Requisitos 109 casos de usos, 100% com casos de teste especificados Casos de testes 510 casos de teste especificados. Status em 17/12/ casos de teste executados (72% do Geral) 76 casos de teste falhados (21%) 240 casos de teste passados 52 casos de teste bloqueados por falta de massa e defeitos

3 Casos de Teste - Métricas do Projeto Números do projeto Interagir de teste por Marca: Tenda 119 casos de teste 26 casos de teste falhados (22%) 79 casos de teste passados (66%) 14 casos de teste bloqueados por falta de massa e defeitos (12%) Gafisa 144 casos de teste 28 casos de teste falhados (19%) 98 casos de teste passados (68%) 18 casos de teste bloqueados por falta de massa e defeitos (13%) Alphaville 105 casos de teste 22 casos de teste falhados (21%) 63 casos de teste passados (60%) 20 casos de teste bloqueados por falta de massa e defeitos (19%)

4 Casos de Teste - Métricas do Projeto Números do projeto Interagir de teste por Prioridade: Alto – 182 casos de testes 89 casos de teste passados (49%) 48 casos de teste falhados (26%) 45 casos de teste bloqueados (25%) Médio – 162 casos de testes 134 casos de teste passados (83%) 21 casos de teste falhados (13%) 07 casos de teste bloqueados (4%) Baixo – 24 casos de testes 17 casos de teste passados (71%) 07 casos de teste falhados (29%) 00 casos de teste bloqueados (0%)

5 Defeitos - Métricas do Projeto Ferramenta utilizada para Gestão dos Defeitos - RedMine Ferramenta WEB Gerencia de projeto e Bug-tracker Integração com a ferramenta TestLink Volume de defeitos do projeto Interagir : 584 bugs abertos pelos KeyUsers e Aitec 10 bugs Duplicados, 13 Cancelados e 27 Rejeitados 288 bugs fechados 246 bugs abertos que serão tratados em produção Para cada caso de teste executado foi aberto 1,7 defeitos. Esta densidade de defeitos (170%) está muito elevada para testes de aceitação num projeto desta natureza (referencia normal de 20% a 30%). Recomenda-se uma avaliação do porquê deste fato (para tal acontecer ter-se-ão verificado uma sequencia de fatores)

6 Defeitos - Métricas do Projeto Números do projeto Interagir de Defeitos por Marca: Tenda – 185 defeitos 125 bugs fechados (67%) 60 bugs abertos que serão tratados em produção (33%) Gafisa – 270 defeitos 146 bugs fechados (54%) 124 bugs abertos que serão tratados em produção (46%) Alphaville – 155 defeitos 85 bugs fechados (55%) 70 bugs abertos que serão tratados em produção (45%)

7 Esforço - Métricas do Projeto Números de Indisponibilidades 846 horas previstas de projeto Interagir 911,7 (Nov/12 + Dez/12) horas realizadas do projeto Interagir 49,46 (Nov/12 + Dez/12) horas de indisponibilidade de ambiente (5,42% do Geral); 96,28 (Nov/12 + Dez/12) horas de atraso na entrega do sistema (10,56% do Geral); 207 (Nov/12 + Dez/12) horas no aguardo de massa de dados e cadastro de conteúdo (22,70% do Geral); Tivemos um total de 352,74 horas Fora de Contexto no projeto que totalizaram 38,70% das horas realizadas Obs.: Algumas indisponibilidades, conseguimos reaproveitar em outras atividades Relatório de execução dos casos de testes Status Report Final dos casos de testes Relatório detalhado da execução dos testes para aprovação

8 Lições Aprendidas ID Fato Observado ConsequênciaSugestão 001 Documentação apenas de casos de uso e prototipo Dúvidas no planejamento e execução, consumindo o dobro do tempo para identificarmos a real funcionalidade do sistema. Necessário gerar documentos de solicitação de projetos por parte das usuárias e documentos de desenvolvimento, com isso temos como saber o que realmente foi desenvolvido, agilizando as execuções e abertura de defeitos. Necessário também um documento de layout de telas e o fluxo de navegação. 002Fases do projeto Não houve um planejamento adequado sobre as fases do projeto, por exemplo, o treinamento ocorrer durante ou depois das execuções. Necessário maior planejamento das fases do projeto: treinamento, execução, homologação, etc 003 Falta de Treinamento\Apresentação do sistema Por falta de treinamento, chegamos ao final do projeto, tentando descobrir algumas funcionalidades do sistema, isso dificultou e onerou o tempo das execuções. Necessário uma apresentação\treinamento do sistema por parte do desenvolvimento para sanar duvidas na criação dos casos de teste e execução, evitando abertura de defeitos por falta de entendimento. 004 Curto prazo para criação dos casos de testes. Com o curto prazo para elaboração dos casos de teste, e uma documentação não muito abrangente, houve a necessidade de correções do planejamento durante a fase de execução. Maior tempo para criação e revisão dos casos de teste, e a solicitação dos casos de teste pelos usuário deve ser nessa fase. 005 Início da execução dos casos de teste durante o desenvolvimento. A execução foi iniciada antes da finalização do desenvolvimento do sistema, o que dificultou o andamento das execuções dos testes. A equipe de desenvolvimento não tinha recursos suficientes para desenvolver o sistema e corrigir os defeitos. Necessário que a execução dos casos de teste seja iniciada após entrega pelo desenvolvimento. 006 Não houve a homologação dos casos de testes executados A homologação deve existir para que seja garantida a entrega do projeto.Homologação durante as execuções dos casos de teste. 007 Não houve Regressão do sistema após as entregas. Sem escopo de regressão não identificamos os problemas corrigidos que voltaram a ocorrer.Incluir escopo de regressão nos projetos. 008 Falta de controle de versão de deploy Vários casos de teste foram executados com a versão antiga do deploy, gerando retrabalho após a instalação do deploy correto. Confirmar a versão que foi instalada no ambiente de homologação 009 Demora na correção dos defeitos Houve muita demora na correção dos bugs, em consequência o projeto foi concluido sem a correção de todos os bugs que foram transferidos para produção Inserir um SLA de correção dos defeitos por prioridade 010 A participação das KeyUsers foi importante no processo de teste para sanar as duvidas Dúvidas sanadas mais rapidamente.Modelo a ser seguido 011 Deploy realizado durante a execução dos testes. Tivemos muito tempo ocioso, aguardando o término dos deploys, afetando diretamente nas execuções. Definir uma estrategia de Deploy em QA para realizar após as 20h para não afetar a equipe de testes 012 Criação de massa de teste nos ultimos dias de execução. Devido a demora na entrega das massas, vários casos de teste ficaram sem execução. A entrega da massa de teste deve ococrrer antes do inicio das execuções. 013 Algumas vezes não houve smoke teste a cada deploy realizado. Entrega de deploy com erros.Realizar smoke teste a cada deploy realizado 014 Liberação do sistema para os testes sem o devido desenvolvimento Abertura de muitos defeitos. Sugerimos um alinhamento com a equipe de Desenvolvimento para que a entrega seja feita em módulos e/ou funcionalidades 015Fluxo de Defeitos Não temos como saber por exemplo, se a quantidade de defeitos cancelados foi por falha do testador ou por erro na documentação, ou erro do desenvolvimento. Necessario definir uma metodologia para o ciclo de vida do defeito 016 Falta de controle de defeitos abertos. Vários defeitos foram duplicados. Necessário definir um fluxo de trabalho para evitar a abertura de defeitos duplicados

9 Sugestões de Melhorias Sugestões de Melhoria IDFato ObservadoSugestão 001 Acompanhamento da obra somente na área logada Sugerimos que o acompanhamento da obra, seja extendido para a área não logada, para que futuros compradores possam analisar e verificar que a gafisa entrega seus imóveis nas datas planejadas. Com essa opção a empresa gera mais credibilidade perante os compradores. 002Links sem usabilidade Verificamos que o sistema possui vários links (atalhos) sem funcionalidade específica, ou seja, ele apenas direciona para alguma página especifica. Sugerimos que esses links de acesso rápido, não sejam exibidos nas páginas em que ele direcionaria, exemplo. na página de autoatendimento que possui os serviços financeiros, não há necessidade de ter um link que chame essa mesma página. 003 Menus habilitados pra clientes que não possuem permissão de acesso Sugerimos que alguns menus estejam desabilitados quando o usuário não possuir permissão de acesso. Ex: Um cliente permutante não pode imprimir um boleto, mas a opção de 2ª via está disponível para ele. 004Menus repetitivos Existem vários sub menus repetitivos que geram poluição visual, ex: embaixo do menu 'O programa' repete novamente o menu 'o programa' e 'como funciona' 005 Ausência de metodologia de testes A falta de uma metodologia de teste dificulta no direcionamento dos processos. Utilizando o projeto Interagir como piloto conseguimos identificar alguns gaps nos processos e sugerir algumas melhorias nos processos. No projeto FTE iremos definir uma metodologia de testes para o qual todos os projetos passarão pelo processo de teste. 006Automação dos testesAutomatizar os testes para realizar as regressões das funcionalidades para ganhos de produtividade


Carregar ppt "Relatório de Fechamento do Projeto São Paulo, 07 de Janeiro de 2013 Projeto XXXX."

Apresentações semelhantes


Anúncios Google