Downloaded 280 times
More Related Content
![Data Structures - Lecture 10 [Graphs]](https://cdn.slidesharecdn.com/ss_thumbnails/datastructures-lecture10graphs-150305004608-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Test Case Management with MTM 2013
- 1.
- 2. Why MTM? • TestTool • Different test types – Manual/scripted – Exploratory – Automated (CodedUI/Unit tests) • Integration
- 3.
- 4. Resources • Visual Studio2013 Ultimate/Premium/Test Professional • TFS • Visual Studio Online • Brian Keller http://aka.ms/almvms
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. • Test plans1 •Test suites2 • Test configuration and test settings3 Overview
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. Test Center • Definetests you plan to run for a specific sprint/iteration • Execute the tests from your plan • Measure progress/quality
- 20.
- 21. Test Plan RunSettings
- 22. Create Test planfrom 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 • Groupyour 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 Casesto 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 Suitesfrom Web Interface
- 32. Copying Test Suitesand 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 TestSuites
- 34. Cloning Test Suitesand 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 Suitesand Test Plans
- 36. Cloning Test Suites– What Gets Cloned?
- 37. TEST SUITES -DEMO
- 38. TEST CONFIGURATION AND TESTSETTINGS
- 39. Test Configuration andSettings Overview • Test Configurations • Creating Test Configurations • Defining Configuration Variables • Selecting Test Configurations • Test Settings • Data Adapters • How to Collect Data
- 40. Test Configurations • Configuration variablesspecify 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.
- 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 • Testsettings use diagnostic data adapters to collect data when running manual tests, automated tests, or both
- 45.
- 46. Test Reports • Viewtest 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 TestProgress: Test Plan
- 48. Reporting on TestProgress • Test Case Readiness: Shows how many test cases are in Design vs. Ready
- 49. Reporting on TestProgress (continued) • Test Plan Progress: Tracks how many tests have been run and how many are failing
- 50. Reporting on TestProgress (continued) • Healthy version vs. unhealthy version Healthy version Unhealthy version
- 51. Reporting on TestProgress (continued)
- 52.
- 53.
- 54. • Manual TestCases1 • Test Steps Parameters2 • Shared Steps3 Overview
- 55.
- 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 TestCases from MTM
- 59. Create Manual TestCases 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 TestCases from Web Interface
- 61. Create Test Casesfrom 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 Casesto Testers • Individually or in bulk • Assign at test point level
- 63.
- 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.
- 67. Shared Steps • Usedfor 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.
- 70.
- 71. • Running manualtest cases1 • Action recordings2 • Reporting bugs3 Overview
- 72. Running Manual TestCases • 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 TestCases (continued)
- 74. Action Recordings • Recorda 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.
- 76.
- 77. Preview Steps BeforePlayback
- 78. Submitting Bugs • Submita 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.
- 80. TEST RUN -DEMO
- 81.
- 82. Exploratory Testing • Testthe 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.
- 86.
- 87.
- 88. Lab Environment • Agroup 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.
- 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 LabEnvironment • Mark the environment as in use to assign it to yourself • Connect to the environment
- 95. Use Standard LabEnvironment • Log into its machines and install the latest build of your software
- 96. Use Standard LabEnvironment • 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.
- 98.