Mudanças entre as edições de "Padrões para o cadastro de bugs"

De MSTECH wiki
Ir para: navegação, pesquisa
(→‎Exemplo)
 
(6 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
−
Ao realizar o cadastro de bugs é importante que tenha um padrão e organização dos campos utilizados, abaixo tem a relação dos campos e uma breve descrição de cada um.
+
Versão 1.0 de 12/09/2016
  
−
'''Ambiente:'''
+
Um bug deve conter o máximo de elementos para que o desenvolvedor possa entender rapidamente o problema. Segue a relação das informações a serem utilizadas no cadastro de bugs e uma breve descrição de cada uma.
−
* Indicar se é local, no caso de ser local indicar se é no branch Main/DEV, se for publicado indicar a url
+
  
−
'''Banco de dados:'''
+
==Informações do bug==
−
* Quando possível indicar qual o banco de dados utilizados, por exemplo no Gestão escolar existem mais clientes e cada um possui um banco específico
+
  
−
'''Navegador:'''
+
===Ambiente===
−
* Indicar quais navegadores e versões do mesmo em que o teste foi realizado
+
* O ambiente em que o teste foi realizado. Indicar se é localhost, publicado, etc. No caso de ser local, indicar o branch (Main/DEV). Se for publicado indicar a URL.
  
−
'''login/senha:'''
+
===Banco de dados===
−
* Indicar o login, senha, perfil do usuário
+
* Indicar qual o banco de dados utilizado. Por exemplo no Gestão escolar existem mais clientes e cada um possui um banco específico.
  
−
'''Descrição:'''
+
===Navegadores===
−
* Realizar uma descrição clara do problema e indicar o que deverá ser o comportamento. Nesta parte se tiver partes do documento de requisitos é indicado colocar, assim é possível evidência melhor que a situação descrita não corresponde ao que foi pedido.
+
* Indicar os navegadores e suas versões.
  
−
'''Passos para reproduzir a situação:'''
+
===Dados de acesso===
−
* A descrição dos passos facilita para o melhor entendimento do bug
+
* Indicar o login, senha, perfil do usuário utilizado.
  
−
'''Anexos'''
+
===Descrição===
 +
* Realizar uma descrição clara do problema e indicar qual deverá ser o comportamento esperado. Indicar, se houver, a descrição do comportamento no documento de requisitos, assim é possível evidênciar melhor que a situação descrita não corresponde ao que foi pedido.
 +
 
 +
===Passos para reproduzir a situação===
 +
* A descrição dos passos facilita para o melhor entendimento do bug.
 +
 
 +
===Anexos===
 
* Imagens, vídeos e/ou documentos que facilitem para o entendimento do problema.
 
* Imagens, vídeos e/ou documentos que facilitem para o entendimento do problema.
  
−
'''Categoria do bug'''
+
===Categoria e subcategoria do bug===
−
* Indicar uma das categorias disponíveis no youtrack, caso esse campo não esteja disponível no projeto é necessário procurar um colaborador do escritório para habilitar o campo  
+
* Indicar uma das categorias disponíveis no Youtrack, caso esse campo não esteja disponível no projeto é necessário procurar um colaborador do escritório para habilitar o campo. Consultar os [[Padrões para classificação de bugs]].
 +
 
 +
===Criticidade do bug===
 +
* Indicar a criticidade (severidade) do bug. Consultar os [[Padrões para definição de criticidade de bugs]]
 +
 
 +
===Outros===
 +
* Quando o teste for realizado em algum dispositivo móvel é importante colocar, por exemplo, versão do Android, modelo do aparelho, versão do aplicativo.
 +
 
 +
* No reteste do bug é importante informar os dados de teste e versão em que o bug foi retestado.
 +
 
 +
 
 +
==Exemplo==
 +
 
 +
Ambiente: http://sgphomsp-sgp.mstech.com.br
 +
Navegador: Chrome 41
 +
Usuário: admin
 +
Senha: 74561
  
−
'''Criticidade do bug'''
+
Dados:
−
* Indicar a criticidade do bug disponíveis no youtrack
+
DIRETORIA REGIONAL DE EDUCACAO ITAQUERA
 +
EMEF CLOTILDE ROSA HENRIQUES ELIAS, PROFA.
 +
2015 - Ensino Fundamental de 9 anos - 5 horas
 +
7º ano
 +
2015 - Calendário Escolar de 2015
 +
7A (7º ano) - Manhã
  
 +
Descrição:
 +
Ao acessar a paginação 2, selecionar os 10 alunos da página e gerar o boletim, o sistema exibe o erro "Sequence contains no elements".
 +
Quando seleciona menos alunos por vez o erro não acontece.
  
−
Pontos gerais:
+
Passos:
−
1 - Quando o teste for realizado em algum dispositivo móvel é importante colocar, por exemplo, versão do Android, modelo do aparelho, versão do aplicativo.
+
1. Acessar o relatório com os dados informados
 +
2. ir até a paginação 2
 +
3. Selecionar os 10 alunos
 +
4. Gerar o boletim
  
−
2 - No reteste do bug é importante informar os dados em que o bug foi retestado e versões também.
+
Resultado obtido: Exibe o erro "Sequence contains no elements".
 +
Resultado esperado: Não exibir o erro.
  
−
3 - No testes realizados no Gestão escolar na maioria das situações somente o login e senha não são o suficiente para reproduzir o bug, neste caso informações como escola, curso, turma são importantes nos dados do bug, o importante é que ao cadastrar os bugs os dados da situação descrita seja o mais completo para permitir que qualquer pessoa consiga reproduzir a situação.
+
Anexo: Imagem do erro.

Edição atual tal como às 19h35min de 16 de fevereiro de 2017

Versão 1.0 de 12/09/2016

Um bug deve conter o máximo de elementos para que o desenvolvedor possa entender rapidamente o problema. Segue a relação das informações a serem utilizadas no cadastro de bugs e uma breve descrição de cada uma.

Informações do bug

Ambiente

  • O ambiente em que o teste foi realizado. Indicar se é localhost, publicado, etc. No caso de ser local, indicar o branch (Main/DEV). Se for publicado indicar a URL.

Banco de dados

  • Indicar qual o banco de dados utilizado. Por exemplo no Gestão escolar existem mais clientes e cada um possui um banco específico.

Navegadores

  • Indicar os navegadores e suas versões.

Dados de acesso

  • Indicar o login, senha, perfil do usuário utilizado.

Descrição

  • Realizar uma descrição clara do problema e indicar qual deverá ser o comportamento esperado. Indicar, se houver, a descrição do comportamento no documento de requisitos, assim é possível evidênciar melhor que a situação descrita não corresponde ao que foi pedido.

Passos para reproduzir a situação

  • A descrição dos passos facilita para o melhor entendimento do bug.

Anexos

  • Imagens, vídeos e/ou documentos que facilitem para o entendimento do problema.

Categoria e subcategoria do bug

  • Indicar uma das categorias disponíveis no Youtrack, caso esse campo não esteja disponível no projeto é necessário procurar um colaborador do escritório para habilitar o campo. Consultar os Padrões para classificação de bugs.

Criticidade do bug

Outros

  • Quando o teste for realizado em algum dispositivo móvel é importante colocar, por exemplo, versão do Android, modelo do aparelho, versão do aplicativo.
  • No reteste do bug é importante informar os dados de teste e versão em que o bug foi retestado.


Exemplo

Ambiente: http://sgphomsp-sgp.mstech.com.br
Navegador: Chrome 41
Usuário: admin
Senha: 74561

Dados:
DIRETORIA REGIONAL DE EDUCACAO ITAQUERA
EMEF CLOTILDE ROSA HENRIQUES ELIAS, PROFA.
2015 - Ensino Fundamental de 9 anos - 5 horas
7º ano
2015 - Calendário Escolar de 2015
7A (7º ano) - Manhã

Descrição:
Ao acessar a paginação 2, selecionar os 10 alunos da página e gerar o boletim, o sistema exibe o erro "Sequence contains no elements".
Quando seleciona menos alunos por vez o erro não acontece.

Passos:
1. Acessar o relatório com os dados informados
2. ir até a paginação 2
3. Selecionar os 10 alunos
4. Gerar o boletim

Resultado obtido: Exibe o erro "Sequence contains no elements".
Resultado esperado: Não exibir o erro.

Anexo: Imagem do erro.
Disponível em "http://wiki.mstech.com.br/index.php?title=Padrões_para_o_cadastro_de_bugs&oldid=4366"