|
|
| Linha 29: |
Linha 29: |
| | | | |
| | [[Decisões tomadas da equipe de Testes]] | | [[Decisões tomadas da equipe de Testes]] |
| − |
| |
| − | Atualizado em 16/06/2016.
| |
| − |
| |
| − | {| {{table}} class="wikitable"
| |
| − | | align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| |
| − | | align="center" style="background:#f0f0f0;"|'''Atividades'''
| |
| − | | align="center" style="background:#f0f0f0;"|'''Status'''
| |
| − | | align="center" style="background:#f0f0f0;"|'''Resolução'''
| |
| − | |-
| |
| − | |Não há uma categorização padrão de bugs||Definir categorias||Finalizado||Foi criado o documento [[Guia para classificação de bugs]]
| |
| − | Novos campos de classificação adicionados ao TFS e ao Youtrack (apenas em projetos criados a partir de 25/05/2016).
| |
| − | |-
| |
| − | |Não há como garantir a qualidade no final da sprint apenas||Definir critérios de aceite de um requisito||Finalizado|| 1. Requisito finalizado (todas as tarefas da sprint para o requisito terminadas)
| |
| − | 2. Testes unitários aprovados (passou ou não) - Opcional
| |
| − |
| |
| − | 3. Testes funcionais (pelos testers ou teste cruzado)
| |
| − | Como comprovar teste cruzado?
| |
| − | Criar tarefa e o escritorio validar se foi realizado
| |
| − |
| |
| − | 4. Review ser no ambiente de Homologação Interna - opcional
| |
| − |
| |
| − | 5. Aprovação do PO (PO aprovaria requisito com baixa criticidade)
| |
| − | |-
| |
| − | |Entender como o desenvolvedor recebe o bug: o que pode ser melhorado?||Pesquisa com desenvolvedores||Finalizado||Vídeos só em casos em que o problema é complicado de explicar
| |
| − |
| |
| − | Imagens - utilizar anotações na imagem e anotar, no nome da imagem, uma descrição rápida do bug + data
| |
| − |
| |
| − | Tudo, até ortografia, deve ser registrado
| |
| − |
| |
| − | Anexar também evidências de que o item foi corrigido
| |
| − | |-
| |
| − | |Entender os casos de teste: utilidade, eficácia, armazenamento||Realizar dinâmica para cada um apresentar como descrever caso de teste
| |
| − | Como tratar o armazenamento dos casos de teste pensando no reaproveitamento deles
| |
| − |
| |
| − | Apresentar planilha usada pela célula do Gestão
| |
| − | ||Finalizado||Realização de Dojo na construção de casos de teste
| |
| − | Avaliação do TestLink
| |
| − | |-
| |
| − | |Solicitações para não cadastrar bugs||Alinhamento com a equipe de testes||Finalizado||Bugs devem ser cadastrados sempre. Se foi aberto por engano, deve ser fechado, e não excluído. Não há exceções.
| |
| − | |-
| |
| − | |Acessibilidade||Definir escopo dos testes||Finalizado||Testar funcionalidades aparentes de acessibilidade, como tamanho de fonte e alto contraste.
| |
| − | |-
| |
| − | |Não há uma categorização padrão de bugs||Definir critérios para a priorização de severidade||Finalizado||Criado critério de severidade inicial. Será publicado na Wiki.
| |
| − | |-
| |
| − | |Entender os casos de teste: utilidade, eficácia, armazenamento||Ferramenta de registro de caso de teste: Avaliar o TestLink||Finalizado||Testlink foi avaliado e, nesse momento, não parece adequado para nossa realidade. Revisitar futuramente.
| |
| − | |}
| |
| | | | |
| | ==Documentos e guias== | | ==Documentos e guias== |
Edição das 15h49min de 28 de junho de 2016
Sobre o teste de software na MSTECH
A MSTECH tem um longo histórico de comprometimento com a qualidade dos produtos desenvolvidos. Criou, estimulou e dá constante suporte à equipe de testes de softwares, que foi se adaptando e evoluindo para atender às necessidades internas.
A equipe
Contamos com oito profissionais de testes que estão aptos para realizar diversas verificações nos produtos da empresa.
Conheça o time de testes da MSTECH!
- André Iguera
- Ana Guedes
- Elizabeth Fidencio
- Halana Camuci
- Jaqueline Sgarbi
- Marrielly Garcia
- Paulo Souza
- Taynara Jacon
Testes funcionais e não funcionais
A equipe de testes da MSTECH está preparada para realizar diversas verificações nos produtos desenvolvidos: teste funcional baseado em requisitos, teste exploratório, teste de acessibilidade, teste de performance e teste de segurança.
Melhorias do produto e experiência do usuário
Os analistas de testes podem sugerir melhorias aos responsáveis pelos produtos com base em suas experiências de uso do software, sempre direcionando esfoços para oferecer aos nossos clientes a melhor experiência de uso.
Melhoria interna contínua
Através dos fóruns de especialidades, estamos criando, reciclando e discutindo novas formas de trabalho.
Fórum de especialidades
Decisões tomadas da equipe de Testes
Documentos e guias
Dicas de português
Guia para classificação de bugs
Guia para geração de relatórios de bugs do Youtrack
Padrões para definição de criticidade de bugs
