TechNet - e-Book- Artigos sobre Test Manager

Visual Studio ALM
Artigos sobre
Test Manager

1
Sumário
- Introdução
- Quem são os Wiki Ninjas
- Sobre o e-Book: Artigos sobre o Test Manager
- Um pouco sobre ALM (Application Lifecycle Management)
- O que é DevOps?
- Por quê Testar Software?
- Microsoft Test Manager
- Iniciando
ALM – Testes – Abordagens de Testes de Software
- Planejando e Executando
ALM – Coletores de informações de Test Manager
ALM - Test Manager - Criando um Caso de Teste Funcional
ALM – Test Manager – Criando Caso de Teste Exploratório
ALM – Test Manager – Criando um Caso de Teste Regressivo
ALM – Test Manager – Criando um Caso de Teste Não Funcional
ALM - Usando o Microsoft Test Manager – Atualizando Casos de Testes
ALM – Gerenciando Casos de Testes com Passos Compartilhados
ALM – Configurando o Lab Management para o Microsoft Test Manager
ALM – Atribuir um Caso de Teste a um Testador
ALM - Test Manager - Executando um Caso de Testes
ALM – Alterando seu caso de testes para um novo Build
ALM - Test Manager - Clonar ou Copiar Work Items?
ALM – Coletando informações de Bugs com o Test Manager
ALM – Test Manager – Criando um Plano de Testes (End-to-End)
ALM – DevOps – Dashboard do seu Lab do Microsoft Test Manager
Conclusão

2
Introdução
O que é o Portal do TechNet Wiki?
Por Ed Price e Alan Carlos
O que começou há alguns anos atrás como uma idéia agora está na sua frente.
Através dos esforços de base e de trabalho de muitos, o TechNet Wiki
desembarcou e a nossa forma de ver o conteúdo nunca mais será a mesma. É um
experimento desenhado para aumentar a largura, profundidade e imediatismo de
conteúdo técnico e evoluir a nossa forma de trabalhar com o conteúdo.
Este é um esforço de base liderado por você e nós: nós da comunidade. Nós não
temos todas as respostas. Haverá torções no sistema, lições a aprender com a
comunidade, recursos para explorar e processos para evoluir. E haverá conteúdo.
Lotes de grande conteúdo escrito por todos nós.
Esse portal é focado em tecnologias Microsoft, onde podemos abordar assuntos
como:
- Instalações;
- Dicas;
- Integrações com outras soluções;
- Novidades;
De vários assuntos como Windows Server, Windows Cliente, SQL Server, Sharepoint
Server, Project Server, System Center, Visual Studio, Application Lifecycle
Management, Windows Phone, Microsoft Azure, Office 365, e muitos outros.
É um portal mantido pela comunidade técnica que conta com colaboradores de
peso que ajudam a manter ele organizado e funcional.
Quem são os Wiki Ninjas?
Os Wiki Ninjas são membros da comunidade apaixonados por tecnologia e sempre
prontos para ajudar a todos. São formados por profissionais altamente qualificados
e apaixonados por tecnologia e dispostos a ajudar a comunidade, como MVP, MCT,
MTAC, MCSE, MCSA, Funcionários da Microsoft e muitos outros, que estão
espalhados ao redor do mundo mantendo esse incrível portal em diversas línguas
para as comunidades.

3
Sobre o e-Book: Artigos do Test Manager
Esse e-Book tem como objetivo trazer artigos do Portal do TechNet Wiki,
selecionados por assuntos e ordem, ajudando a comunidade com informações
relevantes sobre determinado assunto, soluções, ferramentas, tecnologia ou
conjunto de processos.
Um pouco sobre ALM (Application Lifecycle Management)
Por Luciano Condé
A atividade de construção de aplicações é executada através do emprego intenso
do trabalho humano, consequentemente exige das empresas somas de
investimento financeiro. Parte deste investimento é consumido por atrasos de
cronograma, retrabalho, testes inadequados e outros. Estima-se que em 2002,
gastaram cerca 20 bilhões de dólares só com testes inadequados de software feito
por desenvolvedores de software.
Em paralelo, desde a década de 90, a tecnologia da informação está cada vez mais
presente dentro das empresas e na vida das pessoas. A Tecnologia da informação
(TI) surgiu inicialmente dentro dos mainframes, passou pela revolução da
microcomputação para as massas, até chegar na computação na nuvem. Hoje
podemos ver bolsas de valores automatizadas, empresas de telecomunicações
administrando milhares de chamadas simultâneas, cadeias de suprimentos
totalmente integradas e tanto outros segmentos usando massivamente TI.
Com isto temos um paradoxo: de um lado há o uso contínuo e massivo de
aplicações no dia-a-dia das empresas e usuários e do outro lado a dificuldade em
produzir as mesmas aplicações de forma sofisticada e com a qualidade desejada.
Esse desafio vem motivando o surgimento de métodos e ferramentas de trabalho
para a organização dos processos de produção de aplicações e engenharia de
software. O objetivo deste artigo é apresentar uma introdução sobre o
gerenciamento do ciclo de vida de uma aplicação, desde sua concepção até o
processo de manutenção evolutiva, também conhecido como Application Lifecycle
Management (ALM).
Em contabilidade, um ativo é todo o bem ou direito que uma empresa possui
resultante de alguma transação econômica. Um ativo pode ser tangível ou
intangível; o primeiro representa um bem ou direito que possui um corpo físico,
por exemplo, terrenos, máquinas ou equipamentos. Já os ativos intangíveis são
aqueles que não possuem um corpo físico, por exemplo, patentes, marcas ou

4
direitos autorais. O propósito dos ativos é servir de ferramentas para que as
empresas possam produzir os seus produtos ou gerar os seus serviços.
Com a incorporação de TI no dia-a-dia das empresas, as aplicações tornaram-se
ferramentas para auxiliar o processo de produção de produtos ou serviços. Vemos
bancos, bolsas de valores, empresas de telecomunicações, empresas de logísticas e
outras, todas dependentes de aplicações especializadas para cuidar dos seus
processos de negócios. Por causa desta situação, podemos considerar que as
aplicações são ativos intangíveis das empresas. E como qualquer ativo, elas
necessitam de cuidados na aquisição/construção, na utilização e por final na
manutenção.
Podemos definir ALM como todo o processo que guia a vida útil de uma aplicação
desde a sua concepção, passando pela construção, operação e evolução. O ALM
não apenas observa qual é o método de construção, mas preocupa também em
como a empresa está gastando o seu dinheiro no gerenciamento daquele ativo
corporativo.
Um destaque importante é a diferença entre ALM e Software Development
Lifecycle (SDLC). O SDLC pode ser definido em uma tradução livre, de acordo com
Jayaswal & Patton [J&P1], como “como um processo focado no desenho, criação e
manutenção de aplicações”. O ALM é um guia que acompanha toda vida da
aplicação, tendo o SDLC como uma das fases do ciclo de vida.
O que é DevOps?
Por Microsoft Corporation
Em 2009, um grupo de engenheiros começou a conversa sobre como forjar uma
melhor colaboração entre as equipes de desenvolvimento de software que
constroem e as equipes de operações que implantam e executam o software. Essa
conversa rapidamente assumiu a alcunha de "DevOps".
DevOps estende perspectivas da indústria ao redor Application Lifecycle
Management (ALM) e metodologias ágeis para resolver dois fatores adicionais:
- A importância crítica de transparência, comunicação e colaboração entre as
equipes de desenvolvimento e de operações;
- A inclusão do empresário do projeto na discussão.
Praticar DevOps com soluções da Microsoft podem ajudar as equipes de
desenvolvimento e operações de responder em conjunto às pressões da indústria,

5
da concorrência e o ritmo de desenvolvimento de aplicações corporativas.
Rastreabilidade e colaboração organizacional melhorar por meio da automação
previsível e repetitivo que elimina o erro processos manuais propensas.
As organizações também podem gerenciar ambientes de forma mais eficiente e
criar economias de custo com uma combinação de no local e recursos de nuvem.
As soluções da Microsoft suportam ambiente self-service com provisionamento e
uso dos recursos gerenciados, minimizando os riscos de segurança em ambientes
híbridos.
Melhoria das práticas de qualidade ajuda a identificar defeitos precoces no ciclo de
desenvolvimento, o que reduz o custo de fixação. Praticar DevOps Você pode
praticar DevOps com as soluções da Microsoft para encontrar a causa raiz de
problemas na produção e acelerar o tempo da implantação. Dados ricos obtidos
por meio de soluções Microsoft DevOps pode dar dicas sobre problemas de
desempenho e comportamento do usuário para conduzir as prioridades e
investimentos futuros.
DevOps deve ser considerada uma jornada, não um destino. Deverá ser aplicada de
forma incremental por meio de projetos de forma adequada com escopo, a partir
do qual a demonstrar o sucesso, aprender e evoluir.

6
Por quê Testar Software?
O teste do software é a investigação do software a fim de fornecer informações
sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o
processo de utilizar o produto para encontrar seus defeitos.
O teste é um processo realizado pelo testador de software, que permeia outros
processos da engenharia de software, e que envolve ações que vão do
levantamento de requisitos até a execução do teste propriamente dito.
Não se pode garantir que todo software funcione corretamente, sem a presença de
erros, visto que os mesmos muitas vezes possuem um grande número de estados
com fórmulas, atividades e algoritmos complexos. O tamanho do projeto a ser
desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda
mais a complexidade. Idealmente, toda permutação possível do software deveria
ser testada. Entretanto, isso se torna impossível para a ampla maioria dos casos
devido à quantidade impraticável de possibilidades. A qualidade do teste acaba se
relacionando à qualidade dos profissionais envolvidos em filtrar as permutações
relevantes.
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação
pode estar errada ou incompleta, ou pode conter requisitos impossíveis de serem
implementados, devido a limitações de hardware ou software. A implementação
também pode estar errada ou incompleta, como um erro de um algoritmo.
Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do
sistema.
O teste de software pode ser visto como uma parcela do processo de qualidade de
software. A qualidade da aplicação pode e, normalmente, varia significativamente
de sistema para sistema.
Microsoft Test Manager
O Microsoft Test Manager ajuda a definir e gerenciar seus planos de teste para
testes de sistema manuais e automáticos. Esses planos de teste estão armazenados
em Team Foundation Server e são integrados às suas ferramentas de
gerenciamento de ciclo de vida do aplicativo e à sua compilação.
O Microsoft Test Manager é instalado junto ao Visual Studio Ultimate, Visual Studio
Premium e Test Professional.

7
Sobre o conteúdo do e-Book
Esse e-Book aborda o tema “Testes de Software” utilizando as soluções de
Application Lifecycle Management da Microsoft. A solução da Microsoft em Testes
de Software é independente de qual a linguagem de programação que o software
foi escrito ou ambiente a ser testado. O e-Book divide-se em duas seções com
coleções de artigos em seu formato original extraídos do Portal do TechNet Wiki
Brasil.
Iniciando
Artigos que abordam de forma geral, o que é testes de software e como definir o
escopo de projeto de seu teste de software.
Planejando e Executando
Artigos relacionados a como configurar, planejar e executar seus testes de
software, ambientes e gestão de configuração.
Artigos do Portal do TechNet Wiki
Iniciando
Antes de iniciar seu processo de testes de software, é necessário que seu processo
de desenvolvimento de software esteja bem definido, para que as abordagens de
testes de software, fluxos e processos, estejam de acordo o planejado.
Acompanhe os próximos artigos que poderão lhe auxiliar a entender a abordagem
de teste de software mais adequada, bem como preparar seus testes.

8
ALM – Testes – Abordagens de Testes de Software
Autor: Alan do Nascimento Carlos
Introdução
Atualmente em desenvolvimento de software, possuímos diversas abordagens de processos, conforme a
realidade da empresa, funcionários e necessidades. Sendo que cada modelo se adequa ao negócio, ficando
a cargo dos envolvidos entenderem se há necessidade de mudanças ou não, conforme seus projetos,
planejamentos e cenários.
Nesse artigo são destacados algumas das diversas abordagens, na parte de Testes de Software, para
conhecermos e entendermos um pouco mais de cada uma. Cada abordagem aqui possui seu valor e
objetivo, conforme a realidade da empresa que a utiliza.
Abordagens de Testes
Testes Analíticos
Características
- Testes são uma atividade técnica e rigorosa;
- Testes são um Branch da ciência da computação e matemática;
- Software é um artefato lógico;
- Teste é uma ciência baseada em Computação e Matemática: Objetivo, rigoroso e compreensivo;
- Técnicas de testes devem ser objetivas: apenas uma resposta certa;
- Teste é uma atividade técnica;
Empresas que utilizam
- Indústrias de Telecom;
- Sistemas Críticos (Aviões, Navios, Medicina);
Instituições Divulgadoras
- Academias

9
Técnicas de Testes
- Testes de Caixa Branca;
- Testes estruturais;
- Testes de cobertura de código.
Testes Convencionais
Características
- Testes gerenciados: Previsível, repetível, planejado;
- Testes valida o produto;
- Testes medem o progresso do desenvolvimento;
- Enterprise IT;
- Desenvolvimento para Governo.
- IEEE Standards Boards;
- Instituições certificadoras de Teste: ISTQB, ALATS, entre outras.
Técnicas de Testes
- Matriz de Rastreabilidade (Identifica se todos os requisitos foram testados);
- V-Model

10
Testes Baseados em Quality Assurance
Características
- Disciplinado;
- Testes determina se o processo de desenvolvimento está sendo seguido;
- Cada bug é um problema de processo;
- Testadores devem proteger os usuários dos softwares ruins;
- O software não está pronto até que o QA (Controle de Qualidade de Software) concorde;
- Testes é o ponto de partida para a Melhoria do Processo;
- Organizações sob leis e obrigatoriedades
- American Society for Quality (ASQ);
- Software Engineering Institute (CMM);
- International Standards Organization (ISO);
Técnicas de Testes
- Testes baseados em processos;
- Suítes de Testes definidas conforme as normas instituídas;
- Validação por um time de QA que identifica se os processos foram finalizados;
Testes Dirigidos ao Contexto
Características
- Teste deve encontrar bugs;
- Teste provê informações para o projeto;
- Teste é uma atividade mental que requer habilidade;

11
- Teste é multidisciplinar;
- O valor de qualquer prática depende de seu contexto;
- . Existem boas práticas em determinado contexto, mas não existem melhores práticas;
- As pessoas, trabalhando em conjunto, são a parte mais importante do contexto de qualquer projeto;
- Projetos se desdobram ao longo do tempo de maneiras normalmente imprevisíveis;
- O produto é uma solução. Se o problema não foi resolvido, então o produto não funciona;
- O bom teste de software é um processo intelectual desafiador;
- Somente por meio de julgamento e habilidade, realizados cooperativamente ao longo de todo projeto,
somos capazes de fazer as coisas certas nos momentos certos para testar nossos produtos de forma
efetiva.
- Softwares Comerciais;
- Market-driven Software (Software dirigido ao Mercado)
- LAWST Workshops;
- Los Altos Workshop on Software Testing;
- StarEast/StarWest
Técnicas de Testes
- Testes Exploratórios (Exploratory Testing);
- Execução e Design feitos de forma concorrente;
- Aprendizado Rápido (Rapid learning);
- Execução baseada em Missão e Estratégias;
- Difícil Gerenciamento;
- Preparado para mudanças. Adapta o planejamento dos testes baseado nos resultados;
- Efetividade das estratégias são verificadas colocando-as em prática;

12
- Pesquisas de testes requerem estudos empíricos e psicológicos
- Foco na habilidade ao invés da prática/método;
Testes Ágeis
Características
- Testes mostram que uma história está completa;
- Testes devem ser automatizados;
- Desenvolvedores devem fornecer frameworks para automação dos testes
- Consultorias
- Agile Workshops
Técnicas de Testes
- Testes Unitários;
- Test-Driven Development (TDD);
Ferramentas para Testes de Software
A Microsoft disponibiliza atualmente uma solução completa para auxiliar os times de testes das empresas,
independente da abordagem utilizada. O Visual Studio ALM, permite que suas soluções se adequem a
necessidade do cliente, não sendo necessário o cliente se adaptar a ferramenta.
Desde Templates de Processos prontos como SCRUM, CMMI, até a possibilidade de customizações fáceis
nos processos para atender o fluxo de trabalho do cliente.
Destaque para as ferramentas de Testes de Software como:
Microsoft Test Manager: Solução de gerenciamento de Testes de Software, com gestão de Casos de Testes,
Record & Play, coleta automática de informação de ambiente, entre outras características.
Microsoft Azure: O Azure integra-se com as tecnologias locais da Microsoft, de modo que você pode tirar
vantagem completa do seu conhecimento, habilidades e investimentos existentes da Microsoft, e usar um
desenvolvimento comum e uma estrutura de teste que abrange desde o datacenter até a nuvem. Tudo no
Azure pode ser totalmente automatizado, então você pode realizar spin up e desmontar ambientes virtuais

13
com um pressionamento de tecla. E graças à funcionalidade de escala do Azure, é possível fornecer
capacidade adicional sob demanda e com custo reduzido, para projetos de curto prazo e iniciativas com
prazo maior
App Insights: É uma ferramenta de análise de aplicações Web e Móveis que tem como objetivo ajudar o
desenvolvedor a monitorar suas aplicações, independentemente de onde estejam instaladas, como
celulares, tablets, televisores, servidores, em qualquer parte do mundo. Com essa poderosa ferramenta,
você poderá avaliar como seu aplicativo está se comportando nos tablets espalhados pelo mundo, quais as
funcionalidades mais usadas, quais as funcionalidades menos usadas, quais os navegadores mais utilizados
para acessarem sua aplicação, entre outros recursos.

14
Planejando e Configurando
Depois de definida a abordagem, o momento é de se planejar e configurar. 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, impactos, inclusive opinar e anotar informações para repassar
ao time ou demais envolvidos que podem não estar presente na reunião
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.
Lembre-se que normalmente o Requisito ainda não foi finalizado e você precisa
estar já confeccionando seus Casos de Testes, preparando seu Laboratório de
Testes e Realizando sua Gestão de Configuração.
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?)
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).
Identifique como serão as entregas (requisitos e ordem), sprints, builds da versão:
- Semanais
- Mensais
- Ciclos
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.

15
ALM – Coletores de informações de Test Manager
No Microsoft Visual Studio Test Professional, temos o MTM onde podemos utilizar para realizarmos nossos
testes. O Microsoft Test Manager é uma ferramenta poderosa e muito útil, com diversos utilitário e dentre
eles destaco os coletores.
Esses coletores servem para nos apoiar a identificar um BUG, reproduzir passos, automatizar testes. Veja
abaixo como ativar e para que serve cada um:
Action Log – Log de Ações – Captura todos os passos e cliques que você executar no computador,
gerando depois um código C# que pode ser reaproveitado em fazendo o teste de forma “automática”
reproduzindo o que você fez, ou você pode garimpar esse código e transformá-lo de fato em um teste
automatizado. Essa captura só funciona no modo cliente (execução local).
ASP.NET Client Proxy for IntelliTrace and Test Impact – Proxy para apoio na coleta de aplicativos Web
de Servidores quando você ativa o IntelliTrace. Use sempre que seu cliente for um Web Server.
Code Coverage – Cobertura de Código – Coletar para capturar dados de códigos de aplicações ASP.NET
que rodam no Internet Information Services.
Event Log – Log de Eventos – Captura os eventos do Windows conforme a execução do teste. Muito úitl,
pois caso dê uma exceção no momento do teste, a mesma estará possivelmente registrada no evento.
Serve local como remoto (cliente e servidor).
IntelliTrace – Fornece a visão detalhada do comportamento de um aplicativo. (cliente e servidor)
Screen and Voice Recorder – Gravação em vídeo e áudio do seu desktop no momento do teste. Muito
útil em situações como
System Information – Informações completas do sistema. (cliente e servidor).
Test Impact – Ajuda a decidir quais testes precisam ser executados novamente quando for liberada uma
próxima build. (cliente e servidor).

16
ALM - Test Manager - Criando um Caso de Teste
Funcional
Introdução
Um caso de teste é como um requisito, não possui tempo e 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.
- 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 deve deveriam estar associados à Requisitos;
- Um ou mais Casos de Testes podem validar um requisito;
- Um Caso de Teste deve estar associado a um requisito;
Criando um Caso de Teste Funcional
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.

17
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.
Pronto, apenas execute o Caso de Teste e depois sinalize na Tarefa que estará informando o tempo e
andamento para conclusão do Requisito.

18
ALM – Test Manager – Criando Caso de Teste
Exploratório
Introdução
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 (início 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á abordada.
Diferentemente do Caso de Testes Funcional ou Não Funcional, não é reaproveitado, pois não se gera
passos (Shared Steps).
Criando um Caso de Teste Exploratório
- 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;

19
- 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 planejar um Caso de Teste Exploratório? Clique aqui!

20
ALM – Test Manager – Criando um Caso de Teste
Regressivo
Introdução
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, apenas observa-se se será executado
novamente, 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;
Importante: 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.
Criando um Caso de Teste Regressivo
Importante:
Escolha uma Suíte de Caso de Teste importante ou um Conjunto de Casos de Testes (que já foram
executados antes), 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);
Passos:
Selecione o Plano de Teste da Versão Anterior;
Observe que nesse Plano o Caso de Teste está definido na Suite Funcional.

21
Faça um Clone desse Plano para uma nova iteração, selecionando as Suites que deseja que sejam
executadas novamente (lembrando que todas que já foram executadas, se tornarão Regressivo).
Acompanhe o progresso do clone.
Depois, abra o novo Plano de Testes.

22
Altere seu Status.
Renomeie as suítes.
Observe que seu Caso de Testes mudou de identificação no Clone, pois é um novo, e as referências com o
Requisito anterior não existem mais.

23
Apenas fica a referência com o Caso de Teste Origem, para conhecimento de onde veio esse novo Test
Case.
Pode-se clonar Planos de Testes, Suítes, etc.
Plano de Testes – Entre Versões – Função Clonar
Suítes e Caso de Testes – Entre Suítes – Função
Pode-se também realizar uma cópia direta, realizando os seguintes passos:
No novo Plano de Testes, na Suite de Regressivo, vá em Add Test Case.
Execute a query e selecione o Caso de Teste que você deseja:
Em seguida, clique para criar uma Cópia:

24
Será criado um novo ID, porém ele levará todos os itens associados, nesse caso você deverá identificar se
há ou não necessidade de uso desses itens e referências.
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.
Importante:

25
ALM – Test Manager – Criando um Caso de Teste
Não Funcional
Introdução
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
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.

26
Criando um Caso de Teste Não Funcional
Nesse exemplo, vamos criar um Teste Não Funcional de Stress (Estresse)
Abra seu Test Manager –> Selecione a Suite de Testes Não Funcionais –> Crie seu Caso de Teste Não
Funcional
Importante salientar que um Caso de Testes Não Funcional, deve estar associado a um Requisito Não
Funcional de preferência, ou muito bem alinhado na determinação do teste junto ao time de
desenvolvimento.
Por exemplo: Fixou-se um limite de 50.000 Requisições por minuto que um Web Service de transação suporta.
Sendo assim, seu Caso de Teste irá validar esse limite em ciclos constantes e acompanhando se com o passar
dos ciclos, o software apresenta degradação de desempenho, congelamento, ou consegue operar
normalmente.
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.
Importante:
Para executar esse teste, você poderá usar o Visual Studio Online, alocando seus Servidores Web e usando
a feature de Load Test do Visual Studio. Maiores informações, clique aqui.
Também pode se usar seu ambiente local e o Fiddler. Maiores informações, clique aqui.

27
ALM - Usando o Microsoft Test Manager –
Atualizando Casos de Testes
Introdução
Imagine o seguinte cenário:
Um requisito foi removido do projeto e você precisa atualizar o status de cem casos de teste
correspondentes a esse requisito. Fazer isso manualmente um por um é possível mas, você teria muito
trabalho, porém há um jeito muito mais fácil de fazer isso.
Web Access
Do seu Visual Studio acesse o portal Web Access:
Em seguida faça uma consulta correspondente ao requisito:
Selecione os casos de testes em conjunto:
Em seguida clique com o botão direito e altere o item.

28
No caso, mudei o status para “Removed”
E pronto!
Excel
Há outra forma fácil também, você deve abrir o Excel, selecionar a aba Team e clicar em New List, em
seguida selecionar o projeto:

29
Depois que a célula aparecer, filtre apenas os Test Cases, em seguida altere o Status de um Test Case, no
caso aqui foi para Closed, depois copie, selecione todos os casos de testes que deseja mudar e cole.
Depois apenas clique no botão Publish e pronto!
Você pode usar essa técnica para atualizar e modificar diversos parâmetros, como State, Assign to, entre
outros.
Introdução
Imagine o seguinte cenário:
Um requisito foi removido do projeto e você precisa atualizar o status de cem casos de teste
correspondentes a esse requisito. Fazer isso manualmente um por um é possível mas, você teria muito
trabalho, porém há um jeito muito mais fácil de fazer isso.
Web Access
Do seu Visual Studio acesse o portal Web Access:

30
ALM – Gerenciando Casos de Testes com Passos
Compartilhados
Passos compartilhados é uma das melhores ferramentas do Microsoft Test Manager, pois com ele, você
pode escrever passos padrão como por exemplo abrir uma aplicação Web, desde clicar no Internet
Explorer, até realizar o logon e deixar como passo compartilhado e sempre usar em todos os casos de
testes que você necessita usar esse passo, sendo assim, você não precisa mais reescrever tais passos. Isso
economiza um tempo enorme.
Segue link abaixo da Microsoft falando mais sobre os passos compartilhados (shared steps).
http://msdn.microsoft.com/pt-br/library/dd286655(v=vs.100).aspx
Mas esse post tem como objetivo, mostrar como gerenciar Casos de Testes que possuem Passos
Compartilhados. Os passos para identificar esses casos é simples, siga abaixo:
Abra o Web Access do TFS e vá em View Work Items, em seguida clique em Editor e selecione Work Items
and Direct Links e faça o filtro conforme abaixo:
E pronto, sua pesquisa está pronta, onde você consegue identificar quais Casos de Testes estão usando o
mesmo passo compartilhado e assim editar, mudar, etc. Você pode inverter os filtros ou fazer de outra
forma, ficando a seu critério.

31
ALM – Configurando o Lab Management para o
Veja também esses links:
System Center – Instalando o System Center Virtual Machine Manager – Pré Requisitos
System Center – Instalando o System Center Virtual Machine Manager – Instalando Management Server,
VMM Console
Esse artigo tem como objetivo explanar a configuração e integração do Team Foundation Server
(TFS) com o System Center Virtual Machne Manager (SCVMM) SP1 e poder usar o ambiente de
virtualização da solução da Microsoft para criação de ambientes de Testes com o Lab Management.
Obs.: Esse post parte do pressuposto que já há um ambiente configurado com o SCVMM 2012 SP1 e
Hosts com Hyper-V configurados e um servidor TFS 2013 com suas coleções de projetos já criadas.
REQUISITOS
- Visual Studio Agents 2013
Necessário para a instalação do Test Controller
http://www.microsoft.com/en-us/download/details.aspx?id=40750
- Servidor do Virtual Machine Manager Console 2012 (System Center Virtual Machine Manager) SP1
e o Hyper-V
Instalação do Hyper-V no Windows 2012:
http://technet.microsoft.com/pt-br/library/hh846766.aspx
Instalador do SCVMM 2012:
http://technet.microsoft.com/pt-br/evalcenter/hh505660.aspx
Nesse link segue os passos de instalação do SCVMM 2012
http://technet.microsoft.com/pt-br/library/gg610617.aspx
Obs.: No SCVMM 2012 SP1 não há mais o portal de autoatendimento, então ignore o passo de
instalação do guia da Microsoft.
– Permissões

32
Permissão de Administração para as contas do TFS no SCVMM Console
- Permissão de Administração para as contas do TFS no Servidor do SCVMM
- Permissão de Administração no computador local (Test Manager) para a conta de serviço do Test
Controller
INSTALAÇÃO DO SCVMM 2012 SP1 CONSOLE
ADMINISTRATOR NO TFS
Será necessário realizar a instalação do SCVMM 2012 SP1 CONSOLE no Servidor do TFS, para conexão e
gerenciamento.
Depois da instalação, realize um teste de conexão a partir da Console para verificar se o Servidor TFS
acessa o servidor com o SCVMM 2012 SP1 e o Hyper-V.

33
CONFIGURAÇÃO DA INTEGRAÇÃO DO TFS COM O SCVMM
2012 SP1
Depois de instalado o SCVMM Console no servidor TFS, entre na Console de Administração do TFS e vá
em Lab Management, clique em Configure e digite o nome FQDN do servidor com o SCVMM 2012 SP1,
depois clique emTest.
Depois, escolha a Coleção de Projetos (Collection) que você deseja que use o Lab Management (pode
ser uma ou todas) em Team Project Collections, vá na aba Lab Management e clique em:
Configure Library Shares: Para configurar a Biblioteca Compartilhada (que possui templates de hardware,
VHD, ISO, etc.) de que o SCVMM 2012 SP1 possui.

34
http://technet.microsoft.com/en-us/library/gg610598.aspx
Configure Hosts Groups: Para configurar o Grupo de Hosts (que irão hospedar suas virtualizações) que o
SCVMM 2012 SP1 possui.
http://technet.microsoft.com/en-us/library/gg610645.aspx
INSTALAÇÃO DO TEST CONTROLLER
A partir do computador que possui o Microsoft Test Manager, realize a instalação do Test
Controller que está disponivel no Visual Studio Agents 2013.

35
- Configuração do Test Controller
Depois de instalado, execute a configuração do Test Controller, colocando os dados da Coleção de
Projetos, Logon e Senha da conta que irá executar o serviço do Test Controller (conta com direitos de
administração nas virtualizações, acesso no compartilhamento da biblioteca do SCVMM), e valide as
configurações.
Depois clique em Apply e valide se foi configurado corretamente.

36
Pronto, está já configurado a pronto para uso.
Abra o Test Manager e vá em Lab Center, crie um novo ambiente e veja que a integração está funcional.
ALM – Configurando o Lab Management para o

37
Depois de planejar seus Casos de Testes no Microsoft Test Manager, você pode distribuir esses casos para
diversos testadores membros do time. Para fazer isso é simples:
Em Plan, clique com o botão direito do mouse em cima do Caso de Teste que deseja atribuir e selecione no
menu “Assign testers for selected tests”
Em seguida selecione o testador.
Depois de salvo, quando for executar, selecione em Test – Filter e selecione o Testador.
Pronto, perceba que o Caso de Teste está marcado para aquele testador que você atribuiu e ele poderá
executar o mesmo.
Depois de planejar seus Casos de Testes no Microsoft Test Manager, você pode distribuir esses casos para
diversos testadores membros do time. Para fazer isso é simples:
Em Plan, clique com o botão direito do mouse em cima do Caso de Teste que deseja atribuir e selecione no
menu “Assign testers for selected tests”

38
ALM - Test Manager - Executando um Caso de
Testes
Para executar um Caso de Teste no Test Manager, siga os passos:
- Execução do Caso de Testes
Feche todos os programas de sua Workstation que não fazem parte do escopo do Teste –> -Vá no
contexto de Test –> Selecione o Caso de Teste –> Execute
- Passos para abrir 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

39
-Depois de aberto o BUG, assine o mesmo ao responsável, salve e feche seu teste que falhou.
- Relatório e Acompanhamento
Acompanhe a evolução do Requisito associado ao Caso de Teste que você executou e abriu um BUG,
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

40
-No momento há um BUG ativo para o Requisito
Essa rastreabilidade acontece pois:
- Há um Requisito Funcional
- Há Tarefas (Tasks) com Horas de Desenvolvimento e Testes associadas como Child a esse Requisito;
- Há Casos de Testes associados como Tests a esse requisito;
Então, conforme você abre um BUG no Caso de Teste associado, automaticamente o BUG é relacionado ao
Requisito e informado no relatório (conforme o ciclo de atualização do Reports do SQL Server do TFS).
E conforme você apontar as horas (diminuição ou aumento) em sua Tarefa de Teste (Não Caso de Teste)
será demonstrada a evolução no Requisito, até o estágio ser completado.
- Realizando novamente o Caso de Teste
Depois do BUG corrigido, resete o Teste para Ativo e execute novamente.

41
Depois de concluído o caso de teste, finalize a Tarefa de Teste (vinculada ao requisito).
Importante:
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

42
Acompanhamento dos Relatórios
Observe que o Relatório de Overview de Requisitos, se atualizou, demonstrando que o requisito está
completo.
Depois de concluído todos os testes, e finalizado o Plano de Testes, mude seu Status de In Progress para
Completed.
Pronto, seu Plano e Casos foram executados com sucesso.
ALM - Test Manager - Executando um Caso de
Testes

43
ALM – Alterando seu caso de testes para um novo
Build
Imagine o seguinte cenário, você está em executando um Caso de Teste no Microsoft Test Manager e
conforme foi encontrando bugs foi reportando a equipe de desenvolvimento onde depois de algumas
horas um novo Build foi liberado para ser testado. Como proceder para que seu Caso de Teste seja
executado em cima desse novo Build?
Simples! Veja abaixo:
Ao executar seu Caso de Testes no Test Manager, selecione a opção Run with options.
Selecione a Build liberada e pronto, mão na massa!
ALM – Alterando seu caso de testes para um novo
Build
Imagine o seguinte cenário, você está em executando um Caso de Teste no Microsoft Test Manager e
conforme foi encontrando bugs foi reportando a equipe de desenvolvimento onde depois de algumas
horas um novo Build foi liberado para ser testado. Como proceder para que seu Caso de Teste seja
executado em cima desse novo Build?
Simples! Veja abaixo:
Ao executar seu Caso de Testes no Test Manager, selecione a opção Run with options.

44
ALM - Test Manager - Clonar ou Copiar Work
Items?
Introdução
A ferramenta Test Manager traz um excelente recurso para facilitar o gerenciamento do seu Plano de
Testes, a possibilidade de Clonar ou Copiar seu Caso de Testes, Suíte de Testes, e Plano de Testes, dando
velocidade na criação de Casos de Testes.
Importante
- Se você trabalha dentro de uma mesma versão, com iterações ou sprints diferentes, tem todo o sentido
você copiar ou adicionar um caso de teste com todos os seus itens atuais (Requisitos, Tasks de Tempo),
pois faz parte da mesma versão, assim poupa-se trabalho de reescrever e realizar os links em cima de um
requisito, e até criar tarefa, caso o seu processo permita “zerar” uma Tarefa de medição de tempo e
reutilizar a mesma na próxima sprint ou Iteração dentro da mesma versão de produto.
- Se você trabalha em um nova versão, e deseja manter links com work items anteriores, inclusive
requisitos, mas que não serão alterados, tem todo o sentido você criar uma suite dentro de um plano de
testes, realizar um add de caso de teste e copiar esse caso de teste, pois irá gerar um caso de testes com
os work items relacionados do antigo, mas que você poderá manter ou remover, sem afetar o origem.
- Se você trabalha em uma nova versão, e deseja apenas manter os passos e descrição do work item, sem o
relacionamento com outros work items, tem todo o sentido você clonar o plano de testes diretamente,
pois os casos e suites serão clonados, mas não terá link com requisitos anteriores, dando a você a
possibilidade de realizar um link que um requisito novo versionado.
Cenários
Abaixo segue exemplo de cenários e qual a melhor forma de utilização:
Usar os mesmos Casos de Testes dentro do mesmo Plano em Suites de Testes Diferentes
Esse cenário você ganha velocidade, pois os Work Items, Links com Requisitos e Tarefas irão se manter,
não sendo necessário escrever ou inserir novos dados.
Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, irá refletir no Caso de Teste
origem.

45
Se você alterar o Work Item de qualquer uma das suites, irá refletir no outro Work Item. Veja como
exemplo a alteração da prioridade do Work Item da cópia, e refletiu no original, ou seja, perde o histórico.
Usar os mesmos Casos de Testes de outras Iterações ou Plano de Testes em um Novo Plano ou
Iteração
Esse cenário você ganha velocidade, pois os Work Items, Links com Requisitos e Tarefas irão se manter,
não sendo necessário escrever ou inserir novos dados.
Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, irá refletir no Caso de Teste
origem. Você mantém a relação com o Requisito Primário.

46
Criar uma suíte, pesquisar os Work Items e Adicionar os Casos de Testes.
Usar os Dados (inclusive links) de um Casos de Testes de outras Iterações ou Plano de Testes em um
Novo Plano ou Iteração mas como um Novo Caso de Teste
Esse cenário você ganha velocidade, pois os Work Items, Descrição e Links irão se manter, não sendo
necessário escrever ou inserir novos dados.
Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, não irá refletir no Caso de
Teste origem. Você mantém ou não a relação com o Requisito Primário.
Criar uma Suite, pesquisar os Work Items e Copiar o Caso de Teste
Nesse cenário, você irá Criar um Novo Caso de Teste e ele levará os Work Items do Caso de Testes
Original. Nesse caso você poderá alterar o Caso de Testes e remover os Links que não irá alterar o Caso de
Teste origem.

47
Veja, foi removido o link Requirement do novo Caso de Teste.
E no original ainda mantém.
Usar apenas os Dados (Passos e Descrição do Caso de Teste) de um Casos de Testes de outras
Iterações ou Plano de Testes em um Novo Plano ou Iteração mas como um Novo Caso de Teste
Esse cenário você ganha velocidade, pois a Descrição e Passos do Teste irá se manter, sendo necessário
realizar o link novamente com Tarefas e Requisitos, por exemplo.
Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, não irá refletir no Caso de
Teste origem. Você deve criar uma nova relação com o novo Requisito (nova versão).

48
Ou seja, você pode usar qualquer técnica, porém precisa se atendar aos detalhes nas alterações e
rastreabilidade.

49
ALM – DevOps – Dashboard do seu Lab do
INTRODUÇÃO
O Microsoft Visual Studio ALM possui uma poderosa ferramenta de gerenciamento de laboratório de
testes de software chamado Lab Management. Essa ferramenta permite a integração com servidores que
executem o Microsoft System Center Virtual Machine Manager dando assim uma gestão completa do seu
ambiente de virtualização de testes.
Para deixar mais completo seu ambiente, ainda contamos com o a Integração do Microsoft System Center
Operation Manager, que faz a gestão desse ambiente, monitorando as virtualizações em Hosts e deixando
o Gestor de Configuração por dentro do que se passa em seu ambiente. Com ele podemos gerenciar
memória, disco, processador, etc. e assim acompanharmos a evolução de nossa aplicação na questão de
uso de recursos de servidores e ajustarmos conforme a necessidade e até já determinando consumos
mínimos e máximos de hardware, testes de desempenho, performance, etc.
Dica: Você pode usar um ambiente misto com nuvem privada e publica em seu ambiente Lab Center.
Esse tipo de ambiente tem um custo benefício muito atraente, pois você pode alocar virtualizações
na Azure da Microsoft para testes específicos de Web Server por exemplo, onde haverá uma
simulação real de ambiente e link externo e depois de usado poderá desalocar o recurso para outros
testes. E tudo isso sendo gerenciado pelo System Center.
Para usar essa feature de gerenciamento de Dashboard é muito fácil.
Requisitos:
- System Center Operation Manager 2012 R2
- System Center Virtual Machine Manager 2012 R2
- Team Foundation Server 2013
- Microsoft Test Manager 2013
- Para monitorar os Hosts de Virtualização, instale também o agente do Operation Manager nos Hosts
- Management Packs do Virtual Machine Manager 2012 R2
System Center Management Pack for VMM Fabric Dashboard 2012 R2: http://www.microsoft.com/en-
us/download/details.aspx?id=39635
Obs.: Caso você use o VMM 2012 SP1 e não o R2, siga esses procedimento do Technet para poder
instalar o Pack for VMM Fabric Dashboard, para gerenciamento de ambientes mistos (nuvem
publica e privada).
http://technet.microsoft.com/en-us/library/hh882396.aspx
System Center Management Pack for Operation Manager Dashboard
VMM: http://www.systemcentercentral.com/wp-
content/uploads/2012/07/Virtual_Machine_Manager_Dashboards1.zip
Artigos de Apoio:

50
Artigos adicionais explicando como instalar ou integrar as soluções:
System Center – Dicas – Integrando o SCVMM com o Operation Manager
System Center – Instalando o Reporting Services do SQL Server 2012
System Center – Instalação do Operation Manager 2012 R2
System Center – Configurando o Operation Manager com o Virtual Machine Manager
ALM – Configurando o Lab Management para o Microsoft Test Manager
System Center – Instalando o System Center Virtual Machine Manager – Instalando Management Server,
VMM Console
System Center – Dicas – Performance and Resource Optimization – PRO
System Center – Configurando um Laboratório de Virtualização com o SCVMM
INSTALAÇÃO DO MANAGEMENT PACK
Na console de gerenciamento do Operation Manager, instale todos os Management Packs, conforme as
telas abaixo.

51
ACOMPANHAMENTO DOS DASHBOARDS E GERENCIAMENTO DO LABORATÓRIO
Depois de instalado aguarde alguns minutos para coleta das informações.
- Dashboards
Com essas informações você pode acompanhar o desempenho de sua aplicação dentro do seu ambiente
virtual, como consumo de memória, disco, processador;
Pode gerenciar liberando ou diminuindo os recursos para seu ambiente para simular ambientes hostis de
clientes;
Acompanhar o desempenho do seu Lab de Testes com o Pool de Servidores Hyper-V e determinar a
necessidade de alocar mais ou menos recursos para o ambiente;
Gerir de forma automática através de scripts e packs a gestão do ambiente para liberar ou remover
recursos em builds e execuções automáticas de testes;
Receber alertas e informações de forma automática por e-mail, mensagem, SMS, de execução de testes,
queda de serviços, aumento de memória, processamento, etc.

52
E muito mais.
- Execução remota de comandos:
Você pode gerenciar suas virtualizações, coletar informações de logs, análise tudo de forma fácil e
integrada.

53
GERENCIAMENTO DE SUA CLOUD HIBRIDA DE TESTES
Usando o VMM Fabric Dashboard você gerencia sua nuvem local (privada) e publica avaliando o
ambiente e qualidade de seu laboratório e testes de software.
Tudo isso de forma muito simples, apenas instalando os packs gratuitos disponíveis nos sites da Microsoft.

54
Conclusão
O Portal do TechNet Wiki é repleto de materiais de apoio com artigos excelentes
sobre as tecnologias e soluções da Microsoft, diversificado com muitos autores da
comunidade que dispõem do seu tempo para estarem escrevendo artigos para o
Portal.

TechNet - e-Book- Artigos sobre Test Manager

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a TechNet - e-Book- Artigos sobre Test Manager

Mais de Alan Carlos

TechNet - e-Book- Artigos sobre Test Manager