Mudanças entre as edições de "Padrões para classificação de bugs"
De MSTECH wiki
| Linha 1: | Linha 1: | ||
| − | Versão | + | Versão 2.0 de 10/03/2017 |
==Introdução== | ==Introdução== | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Com o amadurecimento do processo de testes na MSTECH, surge a necessidade da implantação de métodos de melhoria contínua da qualidade. Os bugs representam muito mais do que descritivos de falhas. Através de uma análise estatística, podemos identificar padrões de defeitos e, dessa maneira, sugerir melhorias e planos de ação para diminuir essas ocorrências, aumentando a qualidade dos produtos desenvolvidos. A classificação dos bugs auxilia nesse processo, dando aos gestores os instrumentos necessários para identificar esses padrões. | |
| − | + | A versão 2.0 deste documento revisa as classificações de bugs com base na experiência adquirida pela equipe de testes, visando tornar as classificações mais claras, rápidas e precisas. | |
| − | + | As principais mudanças são: | |
| − | * | + | *'''Remoção da subcategoria''': Teremos apenas um campo para indicar a classificação do bug. Todas as opções ficarão no campo Categoria. Essa mudança corrige uma limitação da ferramenta Youtrack, que não filtrava a subcategoria pela categoria selecionada. |
| − | * | + | *'''Remoção de categorias que não são utilizadas''': A categoria Integração foi removida. Há uma limitação para identificar quando um bug foi gerado por problemas de integração de outras partes do sistema. |
| − | * | + | *'''Adição de novas categorias''': Novas categorias foram adicionadas para refletir os tipos de bugs identificados no processo de desenvolvimento. |
| − | * | + | *'''Remoção do campo Origem''': O campo Origem visava identificar bugs que são gerados em desenvolvimento, bugs que são encontrados na homologação e bugs que vêm da produção. O problema é que os bugs de homologação são corrigidos sem o registro de bugs no Youtrack e os bugs de produção entram como requisitos para as próximas sprints. |
| − | + | *'''Adição de Reasons''': As Reasons permitem identificar quando um bug foi deferido, quando o desenvolvedor não consegue reproduzir ou quando um bug está obsoleto. Isso permite gerar métricas mais confiáveis para o processo de desenvolvimento e de testes. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Edição das 21h00min de 10 de março de 2017
Versão 2.0 de 10/03/2017
Introdução
Com o amadurecimento do processo de testes na MSTECH, surge a necessidade da implantação de métodos de melhoria contínua da qualidade. Os bugs representam muito mais do que descritivos de falhas. Através de uma análise estatística, podemos identificar padrões de defeitos e, dessa maneira, sugerir melhorias e planos de ação para diminuir essas ocorrências, aumentando a qualidade dos produtos desenvolvidos. A classificação dos bugs auxilia nesse processo, dando aos gestores os instrumentos necessários para identificar esses padrões.
A versão 2.0 deste documento revisa as classificações de bugs com base na experiência adquirida pela equipe de testes, visando tornar as classificações mais claras, rápidas e precisas.
As principais mudanças são:
- Remoção da subcategoria: Teremos apenas um campo para indicar a classificação do bug. Todas as opções ficarão no campo Categoria. Essa mudança corrige uma limitação da ferramenta Youtrack, que não filtrava a subcategoria pela categoria selecionada.
- Remoção de categorias que não são utilizadas: A categoria Integração foi removida. Há uma limitação para identificar quando um bug foi gerado por problemas de integração de outras partes do sistema.
- Adição de novas categorias: Novas categorias foram adicionadas para refletir os tipos de bugs identificados no processo de desenvolvimento.
- Remoção do campo Origem: O campo Origem visava identificar bugs que são gerados em desenvolvimento, bugs que são encontrados na homologação e bugs que vêm da produção. O problema é que os bugs de homologação são corrigidos sem o registro de bugs no Youtrack e os bugs de produção entram como requisitos para as próximas sprints.
- Adição de Reasons: As Reasons permitem identificar quando um bug foi deferido, quando o desenvolvedor não consegue reproduzir ou quando um bug está obsoleto. Isso permite gerar métricas mais confiáveis para o processo de desenvolvimento e de testes.
