GSAN Software Testing Process

1. 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: https://spreadsheets.google.com/viewform?formkey=clpybXhCV18ybHlhRXVaMmFvdk11RGc6MA • 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. • Casonã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:

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:

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

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.