Workshop - Plano de Testes End to End com o Microsoft Test Manager

Terças de ALM e Operações
Workshops
Planos de Testes End to End com o Microsoft Test Manager
Alan do Nascimento Carlos
Microsoft Specialist, System Center & ALM

Reflexão
O tempo de execução de um Caso de Teste está mais rápido hoje em comparação à 12
meses atrás?
Nos últimos 12 meses, você diminui o tempo de preparação de ambiente para testes?
Quando preparo meus Casos de Testes, conheço do negócio (não do requisito)?
Faço manutenção periódica do meu ambiente?
Faço manutenção dos meus Casos de Testes?
Conheço técnicas de Testes de Software?
Qual foi a última vez que assisti um Webcast Técnico?
Qual foi a última vez que implementei uma melhoria no meu processo?

Certifique-se!

Entendendo o Test Manager
É seu Gerenciador de Testes
Composto pelo Test Center e Lab Center
Possui o Test Runner (Ferramenta de Apoio de Testes) disponível também na Web
O Caso de Teste do MTM, mal comparando, é seu antigo CHECKLIST com os passos em
questão

Vantagens
- Usando o Record & Play, você pode dar velocidade em seus testes funcionais,
principalmente em momentos em que se acha BUGS no final de uma execução de
Caso de Teste, sendo possível reproduzir os passos até onde você parou de forma
automática (se a aplicação suportar) pelo Record & Play
- Padronização em Gestão de Configuração, evitando-se erros e entendimentos
incorretos sobre ambientes homologados
- Reaproveitamento de Casos de Testes, Planos de Testes em versões diferentes
- Centralização e organização de seus artefatos de testes (Team Foundation Server)

Vantagens
- Uso de Shared Steps, facilitando a criação de casos de testes
- Coleta automática de dados do ambiente, passos, telas, aplicativos em execução,
ajudando o time de desenvolvimento na análise de bugs
- Acompanhamento da evolução na entrega de requisitos
- Reativações de bugs, indicadores, relatórios

Criando um Plano de Testes

- Crie o Plano de Testes, e defina:
Escopo:
O Plano de Testes será para todo o produto?
O Plano de Testes será por módulo do produto?
Tempo:
Será um Plano de Testes para toda a versão?
Será um Plano de Testes para cada Iteração/Sprint?

Pode ser ter um Plano de Testes para
todo o Produto ou Módulo
Pode ser ter um Plano de Testes para
todo o Produto ou Módulo dividido por
Iterações

Criando uma Suíte de Testes

Depois do seu Plano de Testes criado, identifique quais as suítes de testes serão
executadas e associe seus casos de testes:
- Testes Exploratórios
- Testes Regressivos
- Testes Funcionais
- Testes Não Funcionais

Criando um Caso de Teste Funcional

Importante
Um caso de teste é como um requisito, não possui tempo e pode deve sofrer melhorias
ao longo do tempo, diminuindo ou aumentando o tempo de execução na prática.
Deve possuir uma gestão efetiva, inclusive de manutenção para a melhoria contínua.
Sua manutenção é como a de um requisito, por isso devem estar associados entre si,
inclusive ele é a prova real de como um requisito se comporta, ou seja, a melhor
documentação junto com o código fonte e é através dele (Caso de Teste) que devemos
no basear o estado atual e funcional de tal requisito.

Importante
- Um Caso de Testes Funcional só poderá existir se houver um requisito associado, caso
contrário seu Caso de Teste é Exploratório, Regressivo (sem rastreabilidade) ou Não
Funcional (sem rastreabilidade), pois mesmo um Regressivo ou Não Funcional devem
deveriam estar associados à Requisitos;
- Um ou mais Casos de Testes podem validar um requisito;
- Um Caso de Teste deve estar associado a um requisito;

Selecione sua Suíte de Testes Funcionais  New Test Case e descreva os passos, e outras
informações e depois crie um vínculo com o Requisito que será validado.

Depois de concluído a confecção dos seus Casos de Testes, os mesmos estarão prontos
para execução assim que o Requisito estiver pronto para os testes.
Então inicie criando a Tarefa (Task) de execução, informe o tempo previsto de execução
(bem alinhado com seu time) e associe ao Requisito em questão.
Depois assine o Caso de Teste ao Testador para que o mesmo seja executado.
Importante:
Tarefa: Associação de trabalho, medição de tempo, vinculação de bugs, comentários
sobre a atividade.
Caso de Teste: Conteúdo, passos da execução, gravação, massa de dados, uso futuro,
reaproveitamento.

Criando um Caso de Teste Não Funcional

Um Caso de Teste não funcional são testes que validam os requisitos não funcionais
relacionados ao uso da aplicação em termos de desempenho, usabilidade,
confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas.
Não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um
software de qualidade, ficando a cargo do desenvolvedor ou gerente de produto optar
por atender esses requisitos ou não, desde que não sejam obrigatórios por legislação.
Normalmente esses testes são associados a técnicas adicionais e ferramentas próprias
para auxiliar na execução desses casos de testes, ex.:
Load Test: Visual Studio Test Professional
Security Test: Fiddler com Plugins do CodePlex como XSS

Importante
Você pode associar itens relacionados a testes não funcionais com testes funcionais,
dando velocidade a seu teste e atingindo objetivos de forma rápida. Ex.:
- Todos seus testes Web devem estar sendo executados em HTTPS;
- Em testes de interface (Windows Forms) validar o uso de usuários do grupo Power Users ou
Users, com restrições, inclusive ACL, NTFS e SMB;
- Todos seus testes de banco de dados, devem usar usuários DB_OWNER com direitos apenas
nas bases de dados em questão;
- Usar os softwares de forma restritiva, por exemplo, o uso de um SQL Express e uma edição
do Windows Server mais básica como a Standard, em testes, ajuda a entender e delimitar o
funcionamento do produto e já de quebra garantir que funcionará em ambientes mais
completos (SQL Enterprise, Windows Enterprise ou Datacenter);
- Associar testes de processo reto com quantidade considerável de massa de dados, auxilia na
validação de um teste não funcional de desempenho.

Em conjunto com o Test Manager, você pode usar ferramentas para executar testes de:
- Segurança
- Desempenho

Criando um Caso de Teste Regressivo

O Caso de Teste Regressivo nada mais é do que um Caso de Teste que já foi executado
alguma vez baseando-se em algum requisito, sendo que pode ser funcional ou não
funcional. Então um Caso de Teste Regressivo não se cria em um planejamento, ele é
um Caso de Teste Funcional bem sucedido já existente de uma versão ou Sprint anterior.
Devido ao custo de um caso de teste regressivo, o mesmo só deve ser executado nas
seguintes opções:
- Quando o requisito em questão que atinge o caso de teste foi alterado;
- Quando há dúvidas sobre a atuação do código fonte alterado em cima de
determinados requisitos;
- Quando algum requisito em hierarquia é alterado;
Obs.: Se ocorrer com frequência esses itens, o time de Testes deve alinhar possíveis
automações e trabalhar com o rastreamento de Requisitos x Casos de Testes.

Importante
- Escolha uma Suíte de Caso de Teste Regressivo importante, que necessite sempre ser
executado e que não se pode abrir mão da execução desses Casos de Testes. Ex.:
- Teste de Processo Reto;
- Testes das Principais Funções (Veja mais em AppInsights);
- Dessa Suíte, identifique o tempo e trabalhe na melhoria contínua desses casos de
testes (revisão de métodos, automação, laboratórios);
- Um ou mais Casos de Testes podem validar um requisito;
- Um Caso de Teste pode estar associado a mais de um requisito;

Criando um Caso de Teste Exploratório

O caso de teste exploratório é muito importante para você utilizar afim de explorar uma
funcionalidade sem definição formal e com o objetivo de se tirar os seguintes resultados:
- Criar Casos de Testes
- Ganhos na velocidade dos testes com o time (inicio do projeto/iteração)
- Criar BUGS não formais (desvinculados a requisitos)
- Não substitui Casos de Testes Funcionais
- Devem ser usados nos casos:
Preparação de Casos de Testes (Inicio de Projeto)
Conhecimento de uma funcionalidade (baseado no requisito)
Projetos com abordagens ágeis em que a rastreabilidade de relatórios de
requisitos não serão abordadas.
- Diferentemente do Caso de Testes Funcional ou Não Funcional, não é reaproveitado,
pois não se gera passos (Shared Steps).

Caso de Teste Exploratório sem Rastreabilidade de Relatório (Teste Não Formal):
- Crie uma Suíte de Teste Exploratório
- Adicione a sua Suíte um Requisito
- Crie uma Task para a Execução estipulando o tempo de execução dessa suíte ou teste
- Execute os testes usando a gravação
- Crie Casos de Testes a partir desse cenário
- Crie um BUG dentro do próprio Test Manager
- Um Caso de Testes Exploratório é no contexto de Planejamento, então cada um deve
fazer o seu próprio. Dúvidas de como começar? Clique aqui!

Gerência do seu Plano de Teste

Gestão de Configuração
- Cadastre todos os sistemas operacionais, bancos de dados, navegadores e outros
itens a qual seu aplicativo é homologado e padronize o mesmo, para que no Plano
de Testes, Caso de Testes e Release Notes saia corretamente e evite não
conformidades.

Gestão de Casos de Testes
- Gerencie seus Casos de Testes, realizando melhoria contínua nele, levante perguntas
como:
- Posso melhorar o tempo de execução?
- Posso diminuir ou aumentar os passos de testes?
- Posso melhorar o tempo de preparação de ambiente?
- Qual foi a última vez que foi encontrado um BUG nesse Caso de Teste? Devo
continuar utilizando-o?

Gestão de Casos de Testes
Você pode deve reaproveitar seu Casos de Testes em novas versões de produtos ou em
novas Sprints da mesma versão, onde você irá repetir um Caso de Teste ou até mesmo
uma Suíte.
Cópia: Quando deseja testar novamente um Caso de Teste de uma mesma versão,
apenas em Sprint/Iteração (tempo diferente), sendo que se tiver alteração no Caso de
Teste cópia, ela refletirá na versão original.
Clone: Quando deseja usar um Caso de Teste como base para uma nova versão,
inclusive podendo alterar sem afetar o Caso de Teste origem.
http://msdn.microsoft.com/pt-br/library/hh543843.aspx

Gestão de Casos de Testes - Bugs
Um BUG pode ter as seguintes ocorrências:
- Impeditivo: Ocorrência que impede o uso do sistema. Não existe forma de contorná-la.
- Funcional: Ocorrência não impeditiva, ou seja, pode ser contornada pelo usuário e
- é relativa ao funcionamento do sistema. É o não cumprimento de algum requisito.
- Interface: Ocorrências relativas à interface, como problemas de renderização, cores, etc.
- Texto: Qualquer ocorrência relacionada ao uso incorreto de algum idioma.
- Melhoria: Sugestões de melhorias para o sistema.

Um BUG pode ter a causa raiz em:
- Serviço
- Banco de Dados
- Especificação
- Regra de Negócio
- Erro de Layout
- Outro (Desconhecido)

Quando você está executando seus passos de testes dentro do Caso de Teste e
encontra um BUG, abra o mesmo, atribua o BUG ao responsável, salve seu Caso de
Teste e saia.
Depois de corrigido o BUG, redefina para ATIVO seu Caso de Teste que falhou, execute
os passos novamente (caso tenha usado o Record & Play, você poderá executar ele até
onde parou), de sequência manualmente e valide se o Caso de Teste passou.
http://msdn.microsoft.com/pt-br/library/dd293545.aspx

Geração Automática de Release Notes
Demonstração

Visual Studio para Testes de Software

Gerência do seu Laboratório

Demonstração

Lab Management

- Crie ambientes em menos de 20 minutos usando o AppController (Microsoft Azure
on-premisses) com o SCVMM
- Integre seus testes com o Lab Management
Demonstração
- Evite bugs abertos incorretamente devido a problemas de configuração de pré-requisitos
- Dê velocidade aos times com integrantes novos, preparando seu próprio ambiente
em 04 cliques
- Associe seu laboratório com o Operations Manager e tenha informações detalhadas
de falhas no software e coletores com o Management Pack do SCOM.

- Configure os coletores de seu ambiente de testes conforme a necessidade do time de
desenvolvimento.

Instalando e Configurando o Hyper-V

Análise e Boas Práticas

Análise - Ferramentas
- Dashboard do seu Laboratório
- Monitorando Aplicações .NET e JAVA com o System Center
Demonstração
- Monitorando Aplicações com o AppInsights
- Monitorar Aplicações Web
- Testes de Segurança
- Análise de Incidentes de Aplicativos (Confiabilidade, Memory Leak, Congelamento de
Threads, Consumo Excessivo de Recursos, Falhas de Escrita/Leitura)

Análise - Relatórios
DeRemlatóorions sdet rAacoçmãpaonhamento de Requisitos, Tendências, Reativações de bugs

Relatórios
Demonstração

Plano de Testes – End-to-End

Importante - Rastreabilidade
Para que você tenha uma rastreabilidade de seus artefatos, é muito importante os vínculos
estarem bem associados. Veja a tabela de relacionamento para um CMMI.

Importante - Rastreabilidade
Para que você tenha uma rastreabilidade de seus artefatos, é muito importante os vínculos
estarem bem associados. Veja a tabela de relacionamento para um CMMI.
http://msdn.microsoft.com/pt-br/library/dd293534.aspx

Para ter uma efetividade no rastreamento do seu trabalho, observe nesse link os
relacionamentos entre Work Items.
Dependendo de onde você estiver criando o relacionamento, o link irá mudar. Por
exemplo:
Você está no Requisito e vai criar um Link com o Test Case: Link Type Tested By
Você está no Test Case e vai criar um Link com o Requisito: Link Type Tests
Tabela de Relacionamento (Work Items)
Importante

Fluxo
Requisito
Tarefa de
Desenvolvimento
Tarefa de
Testes
Caso de Teste BUG

Reunião de Alinhamento
Na definição do Requisito, participe da reunião com o Arquiteto de Solução,
Desenvolvimento, Analista de Produto, para entender quais os objetivos a serem
atingidos, necessidades do cliente, funcionamento do requisito, expectativas, regras de
negócio, Demonstração
impactos, inclusive opinar e anotar informações para repassar ao time ou
demais envolvidos que podem não estar presente na reunião.

Estudo
Valide se você e o time possui conhecimento suficiente de regra de negócio a qual o
requisito pretende atingir, e colha materiais inerentes a esse requisito como telas,
protótipos, documentações legais, documentos gerados pelo time de produtos e passe
ao seu time para juntos explorarem o requisito e iniciar a confecção dos Casos de Testes.
Demonstração
Lembre-se que normalmente o Requisito ainda não foi finalizado e você precisa estar já
confeccionando seus Casos de Testes.

Abordagem
Valide se o Requisito é Funcional ou Não Funcional, para ter uma abordagem direta e
correta do que será testado (por exemplo: - Vamos validar Desempenho?)
Demonstração
Verifique se é uma alteração que afetará em um requisito já existente diretamente ou
indiretamente e se será necessário Casos de Testes Regressivos.
Importante que você use sua experiência nesse momento, pois você precisará ser
assertivo na escolha dos regressivos, pois o custo é alto nesse momento (pense que
sempre será necessário estar reduzindo o tempo gasto em testes regressivos).

Planejamento
- Identifique como serão as entregas (requisitos e ordem), sprints, builds da versão:
Semanais
Mensais
Ciclos
Demonstração
- Como será abordado a entrega do requisito conforme o andamento do projeto e
principalmente a definição de pronto.
- E classificação de prioridade de BUGS pelos times de desenvolvimento. Não podemos
perder tempo do time com demoras nas entregas, desorganização, espera exagerada
em análise de bugs, troca de prioridades constantes, etc.

Montagem do Plano de Testes
Inicie seu Test Manager para criar um novo Plano de Testes
Dê um Nome ao Plano de Testes
Associe o Plano de Teste a Versão ou Iteração (conforme definido no planejamento)
Demonstração

Configuração do Plano de Testes
Vá na em Lab Center  Test Settings:
- Configure os coletores, conforme a necessidade
do Demonstração
time de desenvolvimento para identificar BUGS
com as informações coletadas.

Configuração do Plano de Testes
Verifique as configurações do Plano de Teste:
- Ambientes que serão homologados (Sistemas Operacionais, Bancos de Dados,
Navegadores): Nesse passo, é importante que você tenha um laboratório que tenha
templates de ambientes, para que a preparação de um ambiente de testes não leve
dias e sim horas ou até minutos!
Demonstração
Obs.: Se você desejar que seu
Caso de Teste automaticamente assuma
as configurações do TCM, deixe a opção
Default habilitada. Cada ambiente é um
Ponto de Teste (Test Point).

Crie as Suítes de Testes
Definido em seu Planejamento, crie as Suítes necessárias. Importante salientar o uso de
Clones de Suítes e Casos de Testes, para dar velocidade nessa etapa. Isso é feito no
contexto de Planejamento. Nesse Caso, iremos definir uma Suíte Estática baseada em
Casos de Testes.
Demonstração

Demonstração
Demanda
X 0
Requisito
X 1
Codificação
X 10
Caso de
Teste
X 30 - 70
Operação
X 40 - 1000
Crie as Suítes de Testes - Importante
Participe das reuniões de alinhamento das demandas para que o Custo de BUG seja
reduzido com Casos de Testes mais próximos a realidade do cliente.

Demonstração
Demanda
X 0
Requisito
X 1
Codificação
X 10
Caso de
Teste
X 30 - 70
Operação
X 40 - 1000
Crie as Suítes de Testes - Importante
Lembre-se que dependendo da abordagem da empresa (Escola de Testes de Software),
você deverá validar se a implementação do Requisito foi feita com sucesso, mas
também validar se o objetivo do negócio foi atendido, e só participando, conhecendo o
negócio e entendendo a demanda (feature) você poderá chegar nesse cenário.

Crie as Suítes de Testes
Suíte (Casos de Testes Funcionais) e suas subcategorias:
Adequação, que mede o quanto o conjunto de funcionalidades é adequado às necessidades do
usuário;
Acurácia (ou precisão) representa a capacidade do software de fornecer resultados precisos ou
com a precisão dentro do que foi acordado/solicitado;
Interoperabilidade que trata da maneira como o software interage com outro(s) sistema(s)
especificados;
Segurança mede a capacidade do sistema de proteger as informações do usuário e fornecê-las
apenas (e sempre) às pessoas autorizadas. Segurança também pode estar dirigida em, processar
gerar e armazenar as informações.
Conformidade trata da padronização, politicas e normas de um projeto.
Demonstração

Crie seu Caso de Testes
Crie seu caso de teste, baseado no requisito
e no negócio e escreva os passos.
(pode iniciar com passos básicos)
Demonstração
Coloque valores de parâmetros com @
Para um futuro Record & Play
O Caso de Teste é a ação de execução
de um usuário.

Crie seu Caso de Testes
Relacione seu Caso de Teste ao Requisito (Tests)
Mude o Status do Caso de Teste para Ready
Faça isso para todos os Casos de Testes
Demonstração

Distribua entre a Equipe
Abra o Requisito que está associado ao Test Case
Crie a Tarefa de Testes (Tasks)
Estipule o tempo de execução (já definido no Planejamento)
Associe a Tarefa ao Requisito como “Child”
Demonstração

Insira as informações de tempo de execução, estado, disciplina, entre outras
informações.
Demonstração

Demonstração

Acompanhe os Relatórios e Backlog
Observe a hierarquia de:
Requisitos  Tarefas

Observe que no Relatório de Overview de Requisitos, o Requisito está com as horas restantes, pontos de testes e
resultados de testes prontos para começarem a ser contabilizados. Conforme as tarefas (vinculadas aos requisitos forem
sendo concluídas, o percentagem de horas irá ser carregada e as horas remanescentes serão diminuídas.

Executando o Caso de Teste
- Feche todos os programas
de sua Workstation
- Vá no contexto de Test
- Selecione o Caso de Teste
- Execute
Demonstração

Abrindo um BUG
- No decorrer dos passos ao encontrar um BUG, tire um Print Screen com o Test Runner
- Descreva o BUG de forma bem sucinta, pois o Test Runner coletará os dados como:
Passos da execução
Dados do computador e logs
Telas capturadas
Aplicações que estavam em execução
Demonstração

Abrindo um BUG
Demonstração
- Depois de aberto o BUG, assine o mesmo ao
responsável, salve e feche seu teste que falhou.

Abrindo um BUG
Demonstração

Observe que no Relatório de Overview de Requisitos, o Requisito teve mudanças, com tarefas já concluídas e BUGS ativos
no momento.
- Test Points – Três, devido as configurações de ambientes para um único caso de teste
- Horas completadas – das 27 Horas (Task de Desenvolvimento e Testes), 08 foram concluídas
- Test Results – dos 03 Test Points, 01 foi executado com falha
- No momento há um BUG ativo para o Requisito

Realizar novamente o Teste
- Depois do BUG corrigido, resete o Teste para Ativo e execute novamente.

Finalizar os Testes
- Depois de concluído o caso de teste, finalize a Tarefa de Teste (vinculada ao requisito).

Finalizar os Testes
- O Caso de Teste deve ficar sempre com status de Ready, pois seus estados são:
- Ready: Pronto para ser usado quando desejar
- Design: Está sendo preparado (configurado)
- Closed: Não será usado mais
http://msdn.microsoft.com/pt-br/
library/vstudio/dd380712%28v=vs.110%29.aspx#CloseTestC
ases

Observe que o Relatório de Overview de Requisitos, se atualizou, demonstrando que o requisito está completo.

Alguns relatórios são dinâmicos, onde o objetivo deles é demonstrar:
- Se o requisito foi concluído
- Se há bugs ativos no momento
- Se há casos de testes que falharam no momento

Alguns relatórios são dinâmicos, onde o objetivo deles é demonstrar:
- Overview de Requisitos – Irá demonstrar o quanto falta para concluir um requisito (Tarefas de Testes e
Desenvolvimento) e se há BUGS ativos no momento que impedem a continuidade (relatório dinâmico);
- Progresso de Requisito – Irá demonstrar o progresso do requisito até sua conclusão
- Plano de Testes – Irá demonstrar os Casos de Testes que serão executados, não tem vinculo com BUGS;
- Backlog – Irá demonstrar o andamento das entregas dos requisitos (tarefas que foram concluídas);
- Entre outros.

Workshops
Obrigado!

Workshop - Plano de Testes End to End com o Microsoft Test Manager

Mais conteúdo relacionado

Mais procurados

Semelhante a Workshop - Plano de Testes End to End com o Microsoft Test Manager

Mais de Alan Carlos

Último

Workshop - Plano de Testes End to End com o Microsoft Test Manager