Testes

De MSTECH wiki
Revisão de 22h35min de 24 de maio de 2016 por Andre.iguera (Discussão | contribs) (Testes funcionais e não funcionais)

Ir para: navegação, pesquisa

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
  • Elizabeth Fidencio
  • Fernando Oliveira
  • 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.


Decisões tomadas da equipe de Testes

Problema Raiz Atividades Status 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

Não há como garantir a qualidade no final da sprint apenas Definir critérios de aceite de um requisito Finalizado 1. Requisito finalizado (terminadas todas as tarefas da sprint para o requisito)

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.


Documentos

Guia para classificação de bugs