GSAN Software Testing Process

Apresentação em tema: "GSAN Software Testing Process"— Transcrição da apresentação:

1 GSAN Software Testing Process
GSTP GSAN Software Testing Process

2 Testes Evolutivas e Corretiva

3 O Processo O desenvolvedor deve:
Desenvolver (criar ou alterar) uma funcionalidade; Realizar o checklist pré-teste; Liberar o pacote de funcionalidades para teste; Realizar os ajustes necessários de ocordo com as RMs que foram abertas. O checklist de tela do GSAN está disponível no link: Observação: No momento só temos esse checklist, mas, em breve, novos checklists estarão disponíveis para os produtos mobile e para batch.

4 O Processo O engenheiro de testes deve:
Verificar se o checklist pré-teste foi realizado pelo desenvolvedor; Realizar o checklist pré-teste; Realizar os testes; Abrir RMs.

5 O Processo Após receber uma funcionalidade para teste, o engenheiro de testes deverá verificar se o checklist foi realizado. Caso não tenha sido, uma RM do tipo ‘Erro de Checklist’ deverá ser aberta solicitando a realização do mesmo. Caso tenha sido realizado, o testador deverá executar os passos do checklist para verificar se nenhum problema de pequeno porte está acontecendo na funcionalidade. Caso alguma falha seja econtrada, uma RM do tipo ‘Erro de Checklist’ deverá ser aberta reportando o problema. Caso não, o testador deverá executar os outros testes previstos para a funcionalidade e abrir RMs de outros tipos caso seja necessário.

6 Testes de Versão Final

7 O Processo – Versão Final
O desenvolvedor deve: Realizar as correções das falhas encontradas; Liberar o código para o merge; O gerente de configuração deve: Realizar o merge dos códigos liberados para a versão; Disponibilizar o pacote para testes; O engenheiro de testes e o analista devem: Realizar os testes de versão; Duplicar ou abrir nova RM;

8 Reportando as falhas Projeto:
As falhas encontradas deverão ser reportadas na ferramenta Redmine, no subprojeto do projeto IPAD, chamado ‘QUALIDADE’. Tipos das RMs: Documentação Quando for encontrado algum problema no Caso de Uso Melhoria de Funcionalidade Sugestões de melhorias no sistema, por exemplo: melhoria de usabilidade Erro de Aplicação Quando alguma falha for encontrada no sistema Erro de Checklist Quando for encontrada alguma falha de checklist pré-teste Erro Conhecido Erros já existentes no GSAN e de conhecimento dos membros da fábrica

9 Reportando as falhas Novos campos:
Novos campos foram incluídos e deverão ser preenchidos corretamente e com muita atenção: RM pai: Deverá ser preenchido de acordo com as seguintes situações: Preencher com o número da RM de solicitação da nova funcionalidade ou da correção de uma já existente. Geralmente a RM aberta pelo cliente. Caso a RM que está sendo aberta seja uma RM reportando uma falha encontrada após a correção de outra já reportada, esse campo deverá ser preenchido com o número da RM que já foi corrigida, mas que gerou novas falhas.

10 Reportando as falhas Novos campos: Severidade: Baixa
Quando o problema não impede o usuário de utilizar a funcionalidade. O usuário talvez nem perceba o erro. Normal Quando o problema impede o usuário de utilizar parte a funcionalidade. O usuário talvez consiga utilizar a funcionalidade usando um caminho alternativo. Impeditiva Quando o problema impede a utilização da funcionalidade ou quando a funcionalidade não corresponde ao esperado (por exemplo, não salva as informações corretamente no banco).

11 Reportando as falhas Atenção Quantidade de falhas por RM
Problemas nos casos de uso – podem ser agrupados numa única RM de documentação, porém, caso seja encontrado algum problema grave no documento, recomenda-se abrir uma RM só para esse problema. Problemas de implementação – deve ser aberta uma RM para cada problema encontrado. Preenchimento das RMs Nenhuma RM deverá ficar sem dono, ou seja, o campo ‘Atribuído para’ deverá ser sempre preenchido e modificado. Muita atenção durante o preenchimento dos campos ‘Setor’ e ‘Severidade’.

12 Reportando as falhas Situações das RMs Registrada
Quando for criada uma nova RM (deverá ser atribuída ao líder técnico do time) Em Análise Quando a RM estiver sendo analisada pelo líder técnico ou pelo desenvolvedor (o líder deverá atribuir ao desenvolvedor responsável) Iniciada Quando a RM estiver sendo corrigida pelo desenvolvedor responsável (a RM deverá estar atribuída ao desenvolvedor) Pronta para Teste Quando a falha registrada na RM for corrigida e o sistema estiver pronto para reteste ( o desenvolvedor deverá atribuir para o testador que abriu a RM ou o testador do time) Concluída Quando a RM foi retestada e a falha não existe mais (continua atribuída ao testador) Rejeitada Quando a RM foi retestada e a falha persiste (o testador deverá atribuir para o desenvolvedor responsável) Cancelada Quando a falha for considerada inválida ou duplicada (já existe uma outra RM para o mesmo problema). Antes de usar essa situação, as pessoas envolvidas (líder técnico, desenvolvedor, testador e, às vezes, o analista de teste) deverão discutir sobre o problema. (deverá ser atribuída ao líder técnico do time) Não reproduzível Quando não for possível reproduzir a falha descrita na RM. Antes de usar essa situação, o desenvolvedor deverá conversar com o testador para tentar reproduzí-la. (deverá ser atribuída ao desenvolvedor que não conseguiu reproduzir) Pendente Quando a falha for considerada válida mas não há tempo hábil para realizar a correção. (deverá ser atribuída ao líder técnico do time)

13 Fluxo das RMs

14 Reportando as falhas Fluxo das RMs Passos:
O testador abre o nova RM, na situação ‘Registrada’, e atribui ao líder da equipe a qual está alocado. O líder faz uma análise do problema ou solicita que algum desenvolvedor a faça, mudando a situação para ‘Em Análise’. Caso considere a falha inválida, os envolvidos (líder técnico, desenvolvedor, testador e, às vezes, o analista de teste) deverão discutir. Caso entrem num consenso de a falha não ser válida, o líder ou o desenvolvedor responsável deverá ‘Cancelar’ a RM e deixar atribuída a ele mesmo. Caso a falha seja válida e o desenvolvedor não consiga reproduzí-la, nem mesmo após conversar com o testador, a situação deverá ser alterada para ‘Não reproduzível’ e deverá estar atribuída para quem não conseguiu reproduzir a falha.

15 Reportando as falhas Fluxo das RMs Cont. dos Passos:
Caso seja válida e reproduzível e exista tempo hábil para a correção (no caso de RMs de Erro Conhecido), a situação deverá ser modificada para ‘Iniciada’ enquanto o desenvolvedor trabalha na correção da mesma. Deverá estar atribuída ao desenvolvedor. Caso seja válida e reproduzível e não exista tempo hábil para a correção (só nos casos de RMs de Erro Conhecido), a situação deverá ser modificada para ‘Pendente’ e estar atribuída ao líder técnico. Após a correção do problema, o desenvolvedor atribui a RM ao testador e modifica a situação para ‘Pronta para Teste’. O testador realiza o reteste. Caso a falha não esteja mais acontecendo, a RM deverá ser ‘Concluída’ e continuará atribuída ao testador. Caso a falha persista, o RM deverá ser ‘Rejeitada’ e atribuída ao desenvolvedor.

16 Observações Em relação ao campo Setor:
No campo ‘Setor’ deverá ser selecionada a opção referente à equipe que o testador está realizando o trabalho, ou seja, Evolutivas Time A, B ou C e Corretivas. Nunca deverá ser selecionado o setor ‘Testes’, que deverá ser retirado da lista tão logo as RMs já existentes tenham sido atualizadas para outros setores. Quantidade de falhas e rejeições de uma RM: O testador deverá registrar numa planilha o número de falhas por RM (lembrando que só RMs de Documentação poderão ter mais de uma falha) e o número de vezes que a RM foi rejeitada. Ao final de cada ciclo de testes, essa planilha deverá ser enviada ao analista de testes.

17 Observações Em relação à RMs de ‘Erro Conhecido’:
Essas RMs deverão ser atribuídas ao líder da equipe que encontrou o problema. Se essas RMs reportarem erros muito pequenos, de checklist ou impeditivos, os mesmos deverão ser corrigidos dentro da equipe (de origem). Se os erros forem não impeditivos e necessitarem de uma análise mais elaborada, os líderes da equipe de origem e da equipe de corretiva deverão conversar e entrar em consenso sobre quem tem mais disponibiliadade para efetuar a correção. Caso decidam pela equipe de corretiva, a RM deverá ser atribuída ao Comitê Corretivo para entrar na lista de prioridades. Essa atribuição deverá ser realizada pelo líder técnico. Testes finais de versão: Caso, durante o reteste de versão, uma falha já corrigida apareça novamente, o testador deverá duplicar a RM aberta anteriormente e acrescentar ao título as tags [RE][DUP_RMxxxx].

18 Relatórios O analista de testes deverá, após a geração da versão de produção: Elaborar e entregar o relatório de execução de testes; Elaborar e entregar o relatório de falhas encontradas;

19 Relatórios Relatório de execução de testes:
O objetivo desse relatório é apresentar os resultados gerais dos testes realizados, avaliar os resultados obtidos e propor melhorias ao processo de teste empregado nesse release. Esse relatório foca no resultado da execução dos testes. Relatório de falhas encontradas: O objetivo desse relatório é apresentar os resultados gerais das falhas encontradas durante a realização dos testes, por exemplo: quantas falhas foram encontradas em tal funcionalidade ou que tipo de falha é mais encontrado e avaliar os resultados obtidos. Esse relatório foca nas RMs abertas. Os dois relalórios deverão ser elaborado no final da execução de todos os testes e re-testes das funcionalidades, de todas as equipes de desenvolvimento, previstos para aquele release.