This document provides an overview of Microsoft Test Manager (MTM) 2013 and how to use it for test planning, test case management, test runs, exploratory testing, and lab management. Key capabilities covered include creating test plans and test suites, managing manual and automated test cases, running tests and recording results, performing exploratory testing sessions, and setting up and using lab environments to collect diagnostic data during testing. The document demonstrates these capabilities through examples and screenshots.

1. MICROSOFT TEST MANAGER
2013

2. Why MTM?
• Test Tool
• Different test types
– Manual/scripted
– Exploratory
– Automated (CodedUI/Unit tests)
• Integration

3. Visual Studio 2013 ALM

4. Resources
• Visual Studio 2013 Ultimate/Premium/Test
Professional
• TFS
• Visual Studio Online
• Brian Keller http://aka.ms/almvms

5. Agenda

6. Test Planning

7. Test Case
Management

8. Test Run

9. Exploratory
Testing

10. Lab
Management

11. Ready?

12. TEST
PLANNING

13. • Test plans1
• Test suites2
• Test configuration and
test settings3
Overview

14. Testing Hierarchy

15. TEST PLAN

16. Test Plan

17. Test Plan Creation

18. Test Plan Creation

19. Test Center
• Define tests you plan to run for a specific
sprint/iteration
• Execute the tests from your plan
• Measure progress/quality

20. Test Plan Properties

21. Test Plan Run Settings

22. Create Test plan from Web

23. TEST PLAN - DEMO

24. TEST PLAN - SUITES

25. Test Suites Overview
• Test Suites
• Static Test Suites
• Query-based Test Suites
• Requirement-based Test Suites
• Copying Test Suites
• Cloning Test Suites

26. Test Suites
• Group your test cases into a hierarchy of test suites
– Root node (suite) contains all other test suites

27. Test Suites
• Static
– Contains test cases and other test suites
• Query-based
– Contains test cases based on a query
– Test cases that fit the query criteria are dynamically
added
– Cannot contain other test suites
• Requirements-based
– Group your test cases by requirements
– Based on the work items that belong to the Requirement
category (Requirement, Product Backlog Item, User
Story, etc.)

28. Adding Test Cases to Static Test Suites
• Add existing or create new test cases for your static
test suites

29. Query-Based Test Suites
• Query-based test suites are defined by work item queries
that select test cases
– Example: All test cases with priority = 1
• Any new test case with priority set to 1 will be dynamically added to the
test suite

30. Requirement-Based Test Suites
• Add existing requirement (work item) to your test
plan to create test suite
• Each requirement has its own suite
• Test cases added are linked to requirements
• Helps to determine test coverage and completion
of your requirements

31. Create Test Suites from Web Interface

32. Copying Test Suites and Test Plans
• Copying
– Copies test cases “by reference”. New suite shares same
test cases
– Useful for testing with different test plans but same test
cases
– Can be done from the GUI

33. Copying Static Test Suites

34. Cloning Test Suites and Test Plans
• Cloning
– Copies test cases “by value”. New copies of test cases are
created
– Useful for testing two different releases simultaneously
– Command line

35. Cloning Test Suites and Test Plans

36. Cloning Test Suites – What Gets
Cloned?

37. TEST SUITES - DEMO

38. TEST CONFIGURATION
AND TEST SETTINGS

39. Test Configuration and Settings Overview
• Test Configurations
• Creating Test Configurations
• Defining Configuration Variables
• Selecting Test Configurations
• Test Settings
• Data Adapters
• How to Collect Data

40. Test Configurations
• Configuration
variables specify
setup required
for testing
– Examples:
Operating
system,
browsers,
software,
hardware, SP,
anything
• Can be
associated with
test plans, suites
and test cases

41. Create Test Configurations
• From Test Plan
Run Settings
• From Organize
tab

42. Defining Configuration Variables

43. Selecting Test Configurations
• Set default configuration(s) for your test plan
– You may override at test suite and test case levels
• A test case and test configuration pair is a test point
• Test results are saved for each test point

44. Test Settings
• Test settings use diagnostic data adapters to collect
data when running manual tests, automated tests,
or both

45. Test Settings

46. Test Reports
• View test run results in real time in MTM
• Use predefined test reports (Microsoft Excel, SQL
Server Reporting Services)
• Create your own reports (Microsoft Excel, SQL
Server Reporting Services)

47. Reporting on Test Progress: Test Plan

48. Reporting on Test Progress
• Test Case Readiness: Shows how many test cases
are in Design vs. Ready

49. Reporting on Test Progress (continued)
• Test Plan Progress: Tracks how many tests have
been run and how many are failing

50. Reporting on Test Progress (continued)
• Healthy version vs. unhealthy version
Healthy version Unhealthy version

51. Reporting on Test Progress (continued)

52. TEST CONFIGURATION
AND SETTINGS - DEMO

53. TEST CASE
MANAGEMENT

54. • Manual Test Cases1
• Test Steps Parameters2
• Shared Steps3
Overview

55. MANUAL TEST CASES

56. Manual Test Cases
• Test cases are work items
• Test results are saved on each run
• Manual test cases contain test steps (test
script)
– May contain test steps with validation
– A tester indicates pass or fail at the test step level
• A test case can be assigned to a tester

57. Manual Test Cases (continued)
• Test cases can be added to multiple test suites in
the same or different test plans
• Test cases are associated with 1..n test
configurations
– Creating 1..n test points
Team Project
Test Plan
Test
Suite
Test
Case
Test Suite
Test
Case
Test
Case
Test Plan
Test
Suite
Test
Case
Test Suite
Test
Case
Test
Case
Test
Case
Test
Suite
Test
case

58. Create Manual Test Cases from MTM

59. Create Manual Test Cases from MTM
(continued)
• Add test steps using Microsoft Test Manager (MTM),
Microsoft Excel, or Microsoft Word (via copy and paste)
• Add test steps
using
Microsoft Test
Manager
(MTM),
Microsoft
Excel, or
Microsoft
Word (via
copy and
paste)

60. Create Manual Test Cases from Web
Interface

61. Create Test Cases from an Assembly
of Automated Tests
• Use tcm.exe
• You must use a lab environment
• Make sure that the test project is a part of
your build definition
• The test cases will have the same names as
the test methods

62. Assign Test Cases to Testers
• Individually or in bulk
• Assign at test point level

63. TEST STEPS
PARAMETERS

64. Test Steps Parameters
• Parameters
allow a manual
test case to run
multiple times
with different
data
– Example:
@username,
@password
• Parameters can
be added to
actions or
expected results

65. Test Steps Parameters (continued)
• Overall test results are based on all iterations
passing

66. SHARED STEPS

67. Shared Steps
• Used for repeated sequences of steps, such
as logging in, that occur in many test cases
• Avoiding having to enter these sequences
again and again, create shared steps

68. Create Shared Steps
• While you’re editing a test case, select a sequence of
steps that you want to share
• Steps you selected are replaced with a link to the new
shared steps work item

69. TEST CASE
MANAGEMENT - DEMO

70. TEST RUN

71. • Running manual test
cases1
• Action recordings2
• Reporting bugs3
Overview

72. Running Manual Test Cases
• Run individual tests or entire suites
• A test result is recorded for each test run
• Create action recordings
– Used for future runs
– Action recording can be used in CodedUI tests
• Submit new bugs or update existing bugs
directly
• Attach comments, indicate pass or fail, take
screenshots
• Test case management features also available in
Web Portal

73. Running Manual Test Cases
(continued)

74. Action Recordings
• Record a manual test (or shared steps) to
allow for a later run of certain parts of
manual tests
– Example: Login, entire smoke test
• Use it to help with:
– A test that you will want to run multiple times
– Different manual tests that contain common
steps via action recordings
– Verifying a bug fix
– Automate by importing it to a Coded UI Test

75. Creating Action Recordings

76. Playback Action Recordings

77. Preview Steps Before Playback

78. Submitting Bugs
• Submit a bug from Test Runner
– Information automatically added about the test
environment, comments, screenshots, video
recording
• Submit a bug from Test Manager when you
view the manual test result
– No diagnostic data added via this route

79. Submitting Bugs (continued)

80. TEST RUN - DEMO

81. EXPLORATORY
TESTING

82. Exploratory Testing
• Test the application without a predefined test
script
• Record screenshots, comments, attach files,
video and audio narration
• Submit bugs you find while testing
– Includes rich diagnostic data collected through
testing
– Uses the recorded steps to create a manual test
case

83. Exploratory Testing (continued)
• Explore the application selecting a user story/requirement
– Bugs created will be automatically linked to the user
story/requirement
• Explore the application without selecting a user
story/requirement

84. Exploratory Testing (continued)
• Update comments, add screenshots and files
as you work, or add a bug

85. Exploratory Testing Sessions

86. EXPLORATORY TESTING
- DEMO

87. LAB
MANAGEMENT

88. Lab Environment
• A group of computers that you manage as a
single entity
• Lets you collect diagnostic data from all the
machines in the lab while you’re performing
your tests. The data, such as event actions,
are attached to the test results and to any
bug that you create
• Automate the process of building, deploying,
and running automated tests on your lab
environment

89. Lab Environment

90. Standard Lab Environment
• Both physical computers and virtual
machines can be added to a standard
environment
• On each machine:
– Configure a user account and a password that
has administrative privileges. All the machines
must have the same username and password. It
doesn’t matter whether the account is a domain
or a local account
– Make sure that file sharing is enabled

91. Standard Lab Environment (continued)

92. Standard Lab Environment (continued)
• Define the environment by adding the
computers. Enter the fully-qualified domain
name of each computer
• Set the role of each machine

93. Standard Lab Environment (continued)
• When the environment’s status is ready, this means that
test agents have been installed on each machine, and that
they are communicating with your team project’s test
controller. The test agents let you collect diagnostic
data from its machines while you run your test

94. Use Standard Lab Environment
• Mark the environment as in use to assign it to
yourself
• Connect to the environment

95. Use Standard Lab Environment
• Log into its machines and install the latest
build of your software

96. Use Standard Lab Environment
• In testing Center, plan, properties, set the test
environment to the environment you chose. This
allows you to collect event logs and other
data from the machines in the environment

97. Questions?

98. Thank you!
Raluca Suditu
raluca.suditu@gmail.com
http://ralucasuditu-softwaretesting.blogspot.ro/