Rotina de Testes

Neste livro detalharemos os principais processos e o que devemos buscar durante a realização dos testes no sistema.

Definição do Processo
Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Documentação inicial no Mantis/Trello (Processo a parte "Documentação no Mantis/Trello")
[padronizar] Geração de executáveis (sub processo não relacionado - desmembrar em exe por caso/branch e exe para liberação)
[padronizar] Elaboração do roteiro
[padronizar] Roteiro de testes padrão
[padronizar] Exemplo de preenchimento do roteiro de testes
[padronizar] Preparação do ambiente de testes e início da tarefa
[padronizar] Resultado dos testes por caso e documentação no Mantis/Trello (sub processo relacionado à "Rotina de Testes")
[padronizar] Revisão de testes (Branch da Versão) - (Sub processo relacionado à "Rotina de Testes")

Definição do Processo

Resumo do processo

Os testes do sistema fazem parte do projeto de desenvolvimento de um software, o objetivo dos testes é de descobrir falhas no sistema, identificar erros e após sua identificação, conferir se os mesmos foram corrigidos, garantindo maior qualidade na entrega do produto ao cliente.

Para que possa dar início aos testes de um caso, o mesmo precisa ser liberado pelo desenvolvedor, ou seja, estar com o status "Aguardando testes" no Mantis e na coluna "Aguardando testes" no Trello [linkar com página de sub processos de documentação no Mantis e Trello]

Envolvidos no processo

Indiretamente, toda a equipe de desenvolvimento e qualidade fazem parte do processo de testes. Diretamente estará envolvido o testador, pessoa responsável por executar os testes e o desenvolvedor, pessoa que realizou a tarefa (caso) que está sendo validado.

Etapas do processo

Documentação inicial no Mantis e Trello [padronizar como sub processo não relacionado]
Geração de executáveis para testes (por caso) [padronizar como sub processo não relacionado]
Elaboração do roteiro de testes [padronizar como um sub processo relacionado]
Preparação do ambiente de testes [padronizar como um sub processo relacionado]
Resultado dos testes por caso [padronizar como um sub processo relacionado]
Revisão de testes (Branch da versão) [padronizar o documento da etapa]

Ponto inicial do processo

O processo de testes se inicia quando o desenvolvedor responsável pelo caso finaliza a implementação/correção do código, altera o status no Mantis e cartão no Trello para "Aguardando testes".

Ponto final do processo

O processo de testes finaliza quando o caso puder ser considerado como concluído, ou seja, quando todos os itens do roteiro de testes forem validados e aprovados tanto nos testes por caso quanto na revisão de testes. Neste momento, o status do caso no Mantis e Trello devem estar como "Aguardando liberação de versão".

Resultado esperado

Garantir que toda a implementação/correção realizada pela equipe de Desenvolvimento seja validada e que as versões que serão entregues aos clientes atendam suas necessidades da melhor maneira possível.

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Documentação inicial no Mantis/Trello (Processo a parte "Documentação no Mantis/Trello")

Quando os casos forem liberados pela equipe de desenvolvimento, no Mantis o status será alterado para "Aguardando Testes" e o cartão no Trello será movido para a coluna "Aguardando Testes", isso quer dizer que estes casos foram finalizados pelo desenvolvimento e estão aptos para serem testados pela equipe de Qualidade.

Atualizando os cartões no Trello para início dos testes

No trello quando um tester for iniciar os testes em um caso, primeiramente deverá "Ingressar" no cartão, assim todos os colaboradores/equipes que acompanham o Trello saberão qual desenvolvedor/tester está trabalhando naquele caso. Para isso, clique sobre o cartão referente ao caso que for iniciar os testes e em seguida no botão "Ingressar":

Após ter ingressado no cartão do caso que irá começar a testar, mova-o para a coluna "Em testes (por caso)", assim os demais membros da equipe saberão que você está testando aquele caso no momento:

$mover_cartao_trello.jpg$

O cartão do caso deverá permanecer na coluna "Em testes (por caso)" até que o mesmo seja finalizado e tenha um resultado definido. De acordo com o resultado dos testes faremos a movimentação dos cartões no Trello.

Indicação de testes no Mantis

No Trello vimos que a indicação de que estamos trabalhando em determinado caso é indicada pela mudança da coluna nos cartões e, dessa forma, conseguimos acompanhar as atividades da equipe em tempo real e programar/entregar as entregas dos casos.

No Mantis também devemos fazer o apontamento de quando iniciamos e finalizamos os testes, para isso, logo que for começar os testes deveremos acessar o caso no Mantis e no quadro "Controle de Horas" apontar o horário de início dos testes e clicar em "Selecionar":

Verificar que ao clicar em "Selecionar" será adicionado um registro de apontamento de hora no Mantis, com o tipo de tarefa selecionado, neste exemplo, "Teste" e com a data e início da atividade. A coluna "Tempo" será exibida como "em andamento" até que o teste seja finalizado:

Quando finalizar os testes, seja por ter completado e analisado tudo o que precisava de acordo com o roteiro de testes ou porque precisou parar, como por exemplo saída para almoço, fim do expediente, etc., deverá preencher o horário de término e clicar em "Interromper":

Os apontamentos não devem ser realizados somente quando finalizar todo o teste do caso.

O apontamento de horário no Mantis deve ser feito sempre que iniciar os testes e quando finalizar, assim quando algum outro tester ou outro colaborador qualquer acessar o caso saberá que o mesmo está em andamento e não correrá o risco de testar em duplicidade.

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Geração de executáveis (sub processo não relacionado - desmembrar em exe por caso/branch e exe para liberação)

Para garantir que os testes sejam realizados com um executável 100% atualizado e ter menores chances de conflito/erro, o testador deverá compilar o executável quando for iniciar os testes.

Para começar a gerar os executáveis, primeiramente deverá ser acessada a Máquina Virtual (VM) que possui acesso ao Delphi e por onde o executável poderá ser compilado:

Por enquanto existem duas máquinas virtuais, uma para o ERP e outra para o FISCO e que podem ser acessadas com o endereço, usuário e senha abaixo:

Máquina Virtual FISCO:
Computador: 172.16.0.89
Nome de usuário: compiladorfisco
Senha: 1
Máquina Virtual ERP:
Computador: 172.16.0.87
Nome de usuário: compiladorerp
Senha: 1

Após acessar a "Máquina Virtual" é necessário executar o programa "LogOutSVN.exe", para executá-lo basta dar duplo clique com o mouse, clicar com o botão direito do mouse e em seguida em "Abrir" ou então selecioná-lo e apertar "Enter" no teclado:

Caso o programa já tenha sido executado e o usuário executá-lo novamente, será apresentada a mensagem abaixo, indicando que já não existe nenhum usuário logado no SVN e portanto não poderá ser feito o Logout:

Após executar o "LogOutSVN.exe" o usuário poderá seguir para a compilação dos executáveis, onde deverá realizar o checkout, merge e commit do branch do caso do desenvolvedor. Para saber mais sobre esses procedimentos, conferir o livro "SVN Básico".

Nos testes por caso "URL" utilizado será "https://svn.supersoft.com.br/svn/desenvolvimento/branches/", seguido pelo nome do desenvolvedor+número do caso.

Após realizar o checkout, merge e commit, o executável poderá ser compilado. Para a compilação do executável para testes não é necessário seguir todas as etapas da página "Geração de executáveis para liberação das versões", deverá ser realizado apenas o processo do trecho "Compilando os executáveis", porém, também não é necessário a princípio gerar os executáveis de todos os ambientes para teste, pode-se testar apenas com o executável do ambiente SuperSoft, exceto em situações de casos específicos onde o erro acontece apenas no ambiente Nooven, por exemplo.

Após compilar os executáveis para testes o usuário deverá fechar a conexão com a máquina virtual para liberar acesso aos demais usuários. É aconselhado executar novamente o "LogOutSVN.exe" antes de fechar a conexão com a máquina virtual, garantindo assim que suas credenciais sejam limpas antes de um novo usuário começar a utilizar a VM.0

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Elaboração do roteiro

O Roteiro de Testes é um documento para auxiliar o testador a validar se a tarefa (caso) em que ele irá começar a trabalhar atendeu as expectativas e se está condizente com aquilo que foi proposto ser feito. Idealmente o mesmo deverá ser montado em uma espécie de lista, com tópicos que deverão ser validados, facilitando para que o testador siga uma ordem e não se perca nos testes.

Para se montar um Roteiro de Testes, primeiramente deveremos ler o caso que começaremos a trabalhar e entender o que foi relatado, após isso, analisaremos o Script de Desenvolvimento para entender o que o desenvolvedor fez para corrigir o erro ou implementar a solicitação que foi feita. A partir disso teremos uma base de qual é a demanda (erro/solicitação) e o que será entregue (correção do erro/implementação no sistema).

Como cada tarefa (caso) é único, o roteiro de testes também deve ser. Para facilitar a montagem de um bom roteiro, deveremos seguir as etapas abaixo:

Qual o objetivo dos testes?

Como dito anteriormente, cada caso é único e portanto o objetivo dos testes também deve ser. Vamos supor que em um caso foi criado um novo relatório no sistema, o objetivo não deve ser simplesmente "Ver se o relatório está funcionando". Objetivos genéricos não "abrem nossa cabeça" sobre tudo o que precisaremos validar, como por exemplo, layout do relatório, facilidade no entendimento das informações, conferência dos dados, se o mesmo será compreensível ao usuário, etc.

Criação das tarefas/tópicos à serem validados

Com o objetivo principal dos testes em mente, passaremos a pensar em todos os passos que precisaremos validar para que possamos considerar o caso como "Testado". Ainda utilizando o exemplo da criação de um novo relatório no sistema, é difícil validarmos ele todo de uma vez se não o "quebrarmos" em pequenos "grupos", onde cada grupo é composto por algumas "tarefas" específicas e que irão nos dizer se o mesmo está aprovado ou não.

Exemplo:

1. Verificar criação/chamada da tela do relatório;
1.1. Verificar se no módulo XX, no menu "Relatórios > Emissão de Documentos" foi adicionada a opção "Teste novo relatório";
1.2. Verificar se a chamada do "Teste novo relatório" está sendo feita corretamente, se a tela está sendo aberta alinhada, layout da tela, etc.
1.3. Verificar se os botões da tela do relatório estão funcionando corretamente (minimizar, maximizar, fechar, etc.).
2. Validação dos campos;
2.1. Validar tab-order dos campos;
2.2. Validar preenchimento e validação dos campos (tamanho, código inválido, data inválida, campo vazio, etc);
2.3. Validar pesquisa dos campos pelo DLG, preenchendo manualmente ou pelo atalho F4;
2.4. Validar saída dos campos;

(...)

Esses tópicos deverão ser preenchidos até chegar a última etapa dos testes, que seria a visualização e validação das informações no relatório e cada um destes tópicos é um checkbox à ser assinalado se foi aprovado ou não, assim fica mais fácil de identificar tudo o que precisa ser validado e, caso tenham ajustes à serem feitos, onde exatamente está o problema.

Atenção: Em todos roteiros de teste deveremos considerar:

Analisar se o tratamento solicitado/proposto foi atendido e se está funcional;
Se o tratamento possui layout e usabilidade bem definida;
Identificar caminhos alternativos, como por exemplo parametrizações, configurações, tipo de cliente, atividade, etc. Que possam ocasionar:
- Erros no sistema;
- Erros de integridade das informações no banco de dados;
- Travamento no processo à ser executado pelo usuário;
- Se as correções/solicitações realizadas poderão "quebrar", não atender ou impactar negativamente no uso do sistema pelos demais clientes.

Qual o resultado esperado em cada uma das tarefas para considerá-las "Aprovadas" ou "Reprovadas"?

Antes de iniciarmos de fato os testes é fundamental que tenhamos definido qual o resultado esperado em cada uma das tarefas que foram criadas, assim saberemos exatamente o que precisa ser validado e se poderemos considerá-la como "Aprovada".

Vamos tomar como exemplo o item "2.2. (Validar preenchimento e validação dos campos (tamanho, código inválido, data inválida, campo vazio, etc.)", citado no exemplo anterior.
Se o campo que será validado for um campo do tipo "Data", por exemplo, será necessário verificar se o mesmo possui máscara, se está permitindo digitar datas inválidas (1/15/2020, 35,02/1999, 12/10/7, ...), entre outros. Cada tipo de campo possui validações específicas e por isso é importante que já saibamos o resultado esperado para cada uma das tarefas antes de iniciarmos os testes.

A estrutura do roteiro de testes deverá ser montada de acordo com o "Roteiro de testes padrão".

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Roteiro de testes padrão

O roteiro de testes deverá ser montado em uma planilha com extensão .ODS e deve ser gravado com o seguinte padrão "Roteiro_Testes_ + Numero do caso". Exemplo: "Roteiro_Testes_0043616"

O documento deverá seguir a seguinte estrutura:

1 - Caso:

Link do caso do Mantis.

2 - Casos relacionados:

Relação de casos que deverão ser testados em conjunto ou que possam ter sido corrigidos através do tratamento realizado no caso que irá começar os testes.

3 - Desenvolvedor responsável:

Desenvolvedor que realizou o tratamento no caso.

4 - Sistemas:

Em quais sistemas foram realizados o tratamento e que deverão ser testados/entregues.

5 - Status do teste:

Status do teste após finalizá-lo. "Aprovado" ou "Reprovado".

6 - Observações:

Anotações e/ou observações que auxiliarão nos testes, link de passo a passo, fórum, etc.

7 - Item:

Número do item à ser testado (sequencial).

8 - Descrição do teste:

Descrição do que deverá ser validado no item.

9 - Aprovado:

Se a validação do item for positiva, preencher com "X" o campo "Aprovado".

10 - Reprovado:

Se a validação do item for negativa, preencher com "X" o campo "Reprovado".

11 - #1:

Número do teste/revisão do teste. Cada teste realizado deverá ser incremental em +1, iniciando do teste #1 até o teste #X, número da última revisão de teste realizada. Todo caso terá ao menos dois testes #1 (teste por caso) e #2 (revisão do teste).

12 - Data:

Preencher com a data da realização dos testes no formato DD/MM/AAAA.

13 - Testador:

Preencher com o nome do testador que realizou os testes de cada uma das revisions.

Exemplo de preenchimento dos campos 11 à 13:
#1 - 12/01/2021 - Fulano.
#2 - 15/01/2021 - Fulano.
#3 - 17/01/2021 - Ciclano.

14 - Observação ou descrição do erro/ajuste:

Caso o item tenha sido "Aprovado", porém há alguma ressalva/indicação a ser feita, pode anotar neste campo como uma observação. Pode-se utilizar as observações também para documentar os dados utilizados nos testes, exemplo, qual CFOP foi utilizado, produto, etc.

Se o item for "Reprovado", especificar os detalhes para reproduzir o erro e o que deve ser corrigido.

O nome do arquivo deverá seguir o padrão "ROTEIRO_TESTES_CASO_Número do caso".

O roteiro de testes padrão (em branco) está disponível em:

\\ss\qualidade\Documentos Supersoft - Qualidade e Desenvol\ROTEIRO_TESTES.ods.
Em anexo nesta página.

Adicionando o Roteiro de Testes no SVN

Após a criação do roteiro de testes ter sido finalizada, o mesmo precisará ser incluído na pasta do caso no SVN para que as equipes de desenvolvimento e qualidade tenham acesso ao mesmo, se necessário.

Para isso acessar a pasta "Documentos" dentro da pasta do caso no SVN e adicionar o roteiro:

Em seguida clicar com o botão direito do mouse na pasta do caso e realizar o commit do arquivo.

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Exemplo de preenchimento do roteiro de testes

Etapas de preenchimento do roteiro de testes

Os roteiros de testes deverão ser preenchidos da direita para a esquerda, de modo que o as colunas referentes ao teste que está sendo realizado sempre ficarão mais próximas das colunas "Descrição do Teste" e "Item". Todo caso terá ao menos dois testes, sendo um "teste por caso" e uma "revisão de teste (branch da versão)", porém dependendo do caso podem ser necessários diversos testes devido às vezes que o mesmo foi reaberto. Todos os testes e revisões de testes feitos deverão ser preenchidos no mesmo arquivo, sempre da direita para esquerda, assim teremos em um único documento todo o histórico de testes e saberemos quais itens foram reabertos, quando foram realizados os testes, quem realizou, etc.

Abaixo segue exemplo do preenchimento de um roteiro de testes onde foram necessários quatro testes no total, sendo três deles "testes por caso" e uma "revisão de teste (Branch da versão)".

Primeiro teste (#1 - Reaberto)

Verificar que o testador "Fulano" iniciou os testes pela revisão "#1", no dia 20/01/2021 e durante os testes identificou alguns itens que foram reprovados.

Quando o testador identificar itens que foram reprovados, deverá assinalar com "X" a coluna "Reprovado" e pintar a linha do item de vermelho para que o mesmo seja destacado:

$ex_roteiro_teste_1.jpg$

No exemplo acima os itens "1.2", "3.1" e "3.2" foram reprovados e portanto o caso deverá ser reaberto.

Enquanto houverem itens reprovados o "Status do teste" deverá ser "Reprovado".

Segundo teste (#2 - Reaberto)

No segundo teste realizado pelo testador Fulano, no dia 22/01/2021, os itens "1.2" e "3.2" foram corrigidos, porém o mesmo identificou que o item "2.1" que anteriormente estava funcionando corretamente agora parou de funcionar e foi reprovado. Além disso o item "3.1" que já havia sido reprovado anteriormente ainda precisará ser corrigido:

$ex_roteiro_teste_2.jpg$

Na coluna do teste #2, para os itens "1.2" e "3.2", por exemplo, que estava reprovados e agora estão aprovados, não é necessário adicionar nenhuma observação/descrição (caso queira pode adicionar) e as células da coluna não precisam ser pintadas. Porém nas células das colunas "Descrição do Teste" e "Item" destes itens deverá ser pintado na cor laranja. A cor laranja indicará itens que em testes anteriores foram "Reprovados" e que atualmente estão "Aprovados", isso indica um ponto de atenção tanto para o desenvolvedor quanto para o testador para as próximas correções/testes que serão necessários.

O item "2.1" estava aprovado no teste #1, porém no teste #2 foi reprovado e portanto deverá assinalar com "X" a coluna "Reprovado" e pintar a linha do item de vermelho.

Como os itens "2.1" e "3.1" estão "Reprovados" o caso deverá ser reaberto novamente.

Terceiro teste (#3 - Aprovado)

No terceiro teste realizado pelo testador Fulano, no dia 25/01/2021, todos os itens foram aprovados, portanto na coluna referente ao teste #3 as células dos itens não deverão ser pintadas.

Como os itens "1.2", "2.1", "3.1" e "3.2" foram "Reprovados" em algum momento as células destes itens nas colunas "Descrição do Teste" e "Item" deverão permanecer ou serem pintadas de Laranja para indicar ponto de atenção ao Desenvolvedor e ao testador que for realizar a revisão dos testes:

$ex_roteiro_teste_3.jpg$

Agora que todos os itens foram aprovados o "Status do teste" deverá ser preenchido como "Aprovado (por caso)".

Revisão de teste (#4 - Aprovado)

A revisão de testes deste caso foi realizada pelo testador Ciclano no dia 27/01/2021 e todos os itens permaneceram "Aprovados":

$ex_roteiro_teste_4.jpg$

Observar que temos da direita para a esquerda cada um dos testes realizados, todos em um único arquivo mantendo um "histórico" do caso.

Após a revisão de testes se todos os itens forem "Aprovados" o "Status do Teste" deverá ser preenchido como "Aprovado".

Arquivo de exemplo do roteiro de testes disponível em

\\ss\qualidade\Documentos Supersoft - Qualidade e Desenvol\Ex_preenchimento_roteiro_teste.
Em anexo nesta página.

Retorno do desenvolvedor (quando houverem itens que não procedem/não serão corrigidos ou implementados no caso em questão)

Existirão situações onde a qualidade irá apontar itens como "Reprovados" ao desenvolvimento e solicitar que os mesmos sejam corrigidos e/ou implementados, porém, após análise do desenvolvedor pode-se constatar que o erro não procede, que a situação já acontecia em versões anteriores e não está diretamente relacionada ao caso, necessitando então ser aberto um caso específico para correção, entre outros. Quando isso acontecer o desenvolvedor irá indicar no próprio roteiro de testes estes itens e o motivo de o mesmo não ser atendido no caso em questão.

No exemplo abaixo, vamos supor que após os primeiros testes realizados o testador Fulano reprovou os itens "1.2.", "3.1." e "3.2.":

$ex_roteiro_teste_1.jpg$

Após análise do desenvolvedor o mesmo identificou que o item "1.2." não se trata de um erro gerado pelo tratamento do caso em questão e que não está diretamente ligado ao processo do caso, ou seja, não impede que o caso seja testado e liberado sem essa correção/ajuste.

O desenvolvedor deverá pintar a linha do item com a cor azul para indicar que o item em questão tem um retorno do desenvolvedor (conforme legenda do roteiro de testes) e também deverá adicionar uma anotação (clique com o botão direito do mouse > "Inserir anotação") explicando o motivo de o item não ser tratado no caso em questão, conforme exemplo abaixo:

Esses itens deverão ser mantidos com a cor de preenchimento azul até a conclusão dos testes.

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Preparação do ambiente de testes e início da tarefa

Ambiente de testes

Antes de iniciar de fato a execução dos testes é necessário preparar o "Ambiente de testes", ou seja, certificar-se de que a base de dados que está utilizando, versões dos módulos/executável de testes, DLL (quando houver), parametrizações, etc., estão alinhadas com o objetivo dos testes e que com esse ambiente você conseguirá realizar e validar todas as situações necessárias.

Isso é importante para que possamos garantir que os testes sejam realizados corretamente. Por exemplo, se é necessário realizar testes de cálculo dos valores de PIS e COFINS na emissão de uma nota e exportação desses valores para os Livros Fiscais, se realizar os testes com a base de dados de um cliente que seja optante do Simples Nacional ou que não utilize o módulo Fiscal não poderemos dizer se o teste foi ou não efetivo, pois o ambiente de testes não é o correto para execução do mesmo.

Além disso, de acordo com o roteiro de testes que foi elaborado e das validações que serão necessárias realizar no caso, existem situações em que no mesmo caso precisaremos utilizar base de dados, parametrizações ou configurações diferentes. Por exemplo, se formos preparar o ambiente de testes para um caso que tratou a rotina de integração/exportação de documentos do Vendas para o Estoque, primeiramente precisamos saber quais as formas de realizar essa integração, que no caso é através de Pedidos, Reserva de Pedidos e Notas, portanto nessa situação precisaríamos ter as seguintes configurações:

Base de dados que integre o Estoque pelo Pedido (movimento de saída realizado no Pedido);
Base de dados que o Pedido gere reserva de venda (o pedido irá movimentar o Estoque, porém não realiza a saída de fato do produto, apenas faz a reserva. A saída será feita quando o pedido for faturado, ou seja, quando for importado para uma NFE);
Base de dados que integre o Estoque pela NFe.

A partir dessas três parametrizações iniciais, terão outras séries de variações/configurações que precisarão ser validadas e que devem ter sido consideradas no roteiro de testes, como por exemplo, emissão de documentos com CFOP que não integre o estoque, se parametrizado para integrar o Estoque com ou sem vínculo, rotina de exportação de dados para o Estoque, etc.

Reprodução/entendimento do erro ou solicitação

Após ler o caso onde foi relatado o erro no sistema ou solicitação do cliente, de montarmos o roteiro de testes e prepararmos o ambiente, idealmente devemos reproduzir o erro ou entender o motivo da solicitação do cliente. Essa etapa deve ser feita com o executável da versão apontada no caso em que ocorria o erro ou que ainda não contém o tratamento realizado pela equipe do desenvolvimento, ou seja, realizar um "pré-teste" com as versões que já foram liberadas para confirmar se o erro de fato ocorre, se o erro é somente o que foi apontado no caso ou se talvez seja necessário algum ajuste adicional que não foi previsto, etc.

Execução do teste

Agora que já foi elaborado o roteiro de testes, preparado o ambiente de testes corretamente e reproduzido o problema inicial, começaremos a de fato testar as correções ou implementações realizadas pela equipe de Desenvolvimento.
Os testes terão resultados positivos ou negativos e de acordo com cada um destes resultados daremos um direcionamento no Mantis/Trello.

Quando existirem casos relacionados ao caso que iniciará os testes, os casos relacionados também deverão ser testados. Se o caso relacionado é um caso "antigo" e que já foi fechado, deve ser testado para verificar se o problema não voltará a acontecer com o tratamento atual. Já se o caso for um caso "novo", ainda não resolvido, deve ser testado para verificar se o problema também será solucionado com o tratamento do caso que começará os testes.

Após a execução dos testes, confira aqui como proceder com a documentação e andamento do caso.

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Resultado dos testes por caso e documentação no Mantis/Trello (sub processo relacionado à "Rotina de Testes")

Tipos de resultado

De acordo com a realização dos testes por caso e dos resultados apresentados, existem três classificações (status) que o mesmo deverá ser classificado:

Testado;
Reaberto;
Aguardando retorno.

Abaixo detalharemos cada um destes status, quando classificá-los e quais os andamentos que deverão se realizados no Mantis e Trello em cada uma dessas situações.

Testado

Deverão ser classificados com esse status somente os casos onde todos os itens do roteiro de testes tiverem resultado "Aprovado", ou seja, somente quando o caso estiver 100% testado e condizente com o que foi corrigido/solicitado.

Documentação no Mantis (Testado)

Selecione a opção de status "Testado" e em seguida clique no botão "Alterar Status":

O caso passará a ser exibido com o "Estado = testado", conforme exemplo abaixo:

Em seguida o caso precisará ser vinculado à versão do módulo (caso pai do módulo) e ao branch da versão que ele será liberado. No exemplo do caso 0044250 que é um caso do Financeiro e que as alterações foram feitas apenas no Financeiro, ou seja, não há necessidade de liberação dos demais módulos, o caso será vinculado ao caso pai do módulo Financeiro e ao caso do Branch da Versão atual:

Se o caso for referente à uma customização e precisar de liberação de DLL, o caso pai da DLL (versionamento) também deverá ser relacionado.

Se a correção envolver outros módulos, como por exemplo alteração em rotinas comuns, todos os módulos que utilizarem essa rotina deverão ser relacionados, pois todos eles precisarão ser liberados.

O caso pai do módulo (neste exemplo o caso pai da versão atual do financeiro é o 0044226) também deverá ser relacionado ao caso do Branch da Versão:

$relacionamento_mantis2.jpg$

Após isso, no caso que foi realizado o tratamento, é necessário enviar um lembrete ao desenvolvedor responsável pelo caso dizendo que os testes foram realizados, que o tratamento está correto e que o caso deve ser vinculado ao Branch da Versão, conforme exemplo:

O roteiro de testes deverá ser adicionado à pasta do caso no SVN e comitado, conforme instruções do trecho "Adicionando o Roteiro de Testes no SVN".

Documentação no Trello (Testado)

Após a alteração do status do caso no Mantis e envio do lembrete, no Trello o cartão deverá ser movido para a coluna
"Testado (por caso)":

$trello_testado.jpg$

O cartão permanecerá nessa coluna até que o desenvolvedor o suba para o Branch da Versão, quando isso acontecer o desenvolvedor irá mudar o cartão para a coluna "Vinculados/Em testes (Branch versão)".

Reaberto

Deverão ser classificados com esse status somente os casos onde ao menos um dos itens do roteiro de testes tiverem resultado "Reprovado", ou seja, todos os casos onde houver alguma situação que precise ser corrigida/ajustada deverá ser alterado para o status "reaberto".

Documentação no Mantis (Reaberto)

Selecione a opção de status "Reaberto" e em seguida clique no botão "Alterar Status":

O caso passará a ser exibido com o "Estado = reaberto", conforme exemplo abaixo:

Em seguida deverá ser enviado um lembrete ao desenvolvedor responsável pelo caso, dizendo quis pontos foram reabertos (o detalhamento do erro/ajuste e o que deve ser feito deverá estar no roteiro de testes):

O roteiro de testes deverá ser adicionado à pasta do caso no SVN e comitado, conforme instruções do trecho "Adicionando o Roteiro de Testes no SVN".

Documentação no Trello (Reaberto)

Após a alteração do status do caso no Mantis e envio do lembrete, no Trello o cartão deverá ser movido para a coluna "Reabertos":

1. Abra o cartão do caso e clique no botão "Mover"
2. Clique no campo "Lista"
3. Selecione a lista "Reabertos" e clique no botão mover.

Obs: Também pode mover o cartão arrastando-o até a coluna "Reabertos".

Aguardando retorno

Deverão ser classificados com esse status somente os casos onde exista alguma situação que impossibilite a continuidade/conclusão dos testes e que dependam de resposta ou análise de outros setores.

Esse status não deve ser utilizado para tirar dúvidas básicas sobre funcionamento de determinado processo, se uma situação está errada ou não, etc. Esse tipo de dúvida deve ser tirada diretamente com a equipe de Desenvolvimento/Qualidade, pessoalmente ou através do comunicador para que o caso não fique "parado" e o andamento seja rápido.

O status deverá ser usado em situações específicas, como por exemplo, está realizando os testes de emissão de NFSe para a prefeitura de um determinado cliente, porém, para poder seguir com os testes precisa do certificado digital do cliente. Nessa situação não é possível seguir os testes sem o certificado digital e portanto o caso poderá ser alterado para "Aguardando retorno".

Documentação no Mantis (Aguardando retorno)

Selecione a opção de status "Reaberto" e em seguida clique no botão "Aguardando retorno":

O caso passará a ser exibido com o "Estado = aguardando retorno", conforme exemplo abaixo:

Em seguida deverá ser enviado um lembrete ao departamento/técnico que precisará lhe retornar com a resposta da dúvida, documentos solicitados, etc, conforme exemplo abaixo:

Documentação no Trello (Aguardando retorno)

Após a alteração do status do caso no Mantis e envio do lembrete, no Trello o cartão deverá ser movido para a coluna
"Aguardando retorno":

Abra o cartão do caso e clique no botão "Mover";
Clique no campo "Lista";
Selecione a lista "Aguardando retorno" e clique no botão mover.

Também pode mover o cartão arrastando-o até a coluna "Aguardando retorno".

Sub processos da rotina de testes para padronização (vincular posteriormente com o livro "Rotina de Testes" e conforme ordem das etapas do processo)

[padronizar] Revisão de testes (Branch da Versão) - (Sub processo relacionado à "Rotina de Testes")

Quando o desenvolvedor subir os casos que já foram testados para o Branch da Versão, no Mantis o status do caso será alterado para "Aguardando revisão de teste" e no Trello o cartão será movido para a coluna "Vinculados/Em testes (Branch versão)".

Estes casos já aptos para serem "retestados", ou seja, realizar a revisão dos testes no Branch da Versão para garantir que o mesmo permanece funcionando corretamente antes de liberá-lo ao cliente.

As revisões de testes devem ser prioridade da equipe de Qualidade, portanto estes casos devem ser testados logo após os desenvolvedores os subirem para o Branch da Versão. Também não deve-se deixar acumular diversos casos pendentes da revisão de testes no Branch da Versão, o ideal é subir um caso e testar logo em seguida, subir outro e testar e assim por diante.

A revisão de teste não deverá ser feita pelo mesmo testador que realizou os testes "por caso".

Quando iniciar a revisão de testes, o testador deverá ingressar no cartão do caso no Trello e fazer o apontamento do horário no Mantis (clique aqui), mesmo processo feito quando inicia os testes "por caso", com exceção de que por enquanto não será necessário mover o cartão no Trello para nenhuma outra coluna.

Em seguida deveremos realizar os mesmo processos vistos no livro Rotina de testes, salvo as seguintes exceções:

A geração do executável deverá ser feita através do endereço URL do Branch da Versão, como por exemplo:
"https://svn.supersoft.com.br/svn/desenvolvimento/branches/Versoes/ERP/042-Caso-0044323".
Não precisará ser feito um novo roteiro de testes, porém o mesmo precisará ser revisado e preenchido para garantir que os itens "Aprovados" inicialmente continuam funcionando da forma correta.
Os resultados dos testes permanecem os mesmos, exceto quando a revisão de testes estiver "Ok", nessa situação o caso deverá ter o status alterado para "Aguardando liberação de versão" e inserida uma anotação no Mantis dizendo que a revisão de testes foi feita, anexar o Script de Desenvolvimento em formato .PDF, o Roteiro de Testes do caso e mover o cartão do Trello para a coluna "Aguardando liberação".

Exemplo de anotação à ser inserida no Mantis:

"Revisão de testes realizada com a versão 6.556 do módulo de Vendas.
Caso finalizado, aguardando fechamento e liberação de versão."

Segue em anexo "Script de Desenvolvimento" e "Roteiro de Testes" utilizados no caso.

Os casos permanecerão com esse status no Mantis e coluna no Trello até que seja feita a liberação e fechamento do Branch da Versão.