Improved software testing using Visual Studio and TFS 2010
6 likes3,140 views
The document discusses improved software testing using Visual Studio and TFS 2010. It advocates for structured testing with test plans, test cases, test execution, and test automation. TFS 2010 allows teams to create test plans and cases in MTM, execute manual tests with screenshots and logs, and develop automated unit, integration, and load tests in VS2010. Defects can be reported from tests directly into TFS as work items assigned to developers, improving traceability and fixing bugs earlier. The presentation demonstrates these capabilities to provide high quality, performant software through disciplined testing.
Improved software testing using Visual Studio and TFS 2010
- 1. Improved software testingusing Visual Studio and TFS 2010Alexander VanwynsbergheSoftware Engineer@vanwynsberghea
- 2. What is this presentation about?Software testing, why?Use structured testingThe capabilities of TFS 2010SummaryAlexander Vanwynsberghe – 09/05/2011
- 3. Software testing, why?It’s all about the qualityLets you measure how well software is designedFind the bugs!Checks how the product meets the requirementsTesting does not make software perfectAlexander Vanwynsberghe – 09/05/2011
- 4. Use structured testingWhat does that mean?http://www.flickr.com/photos/59068359@N04/5563821201
- 5. 1. Make test plansA summary of the test activities that will be performedShows how the tests will be organizedA list of tests which, if performed, will identify all of the requirements that have been setAlexander Vanwynsberghe – 09/05/2011
- 6. 2. Define test casesDescription of a specific interaction that a tester will have in order to test a single behavior of the softwareStep-by-step guide for the testerConsists of:PreconditionsTo-doResultAlexander Vanwynsberghe – 09/05/2011
- 7. 3. Execute testsRun all test cases from the appropriate test planFirst iteration test focuses on new featuresRegression testing usually involves executing all test cases which have previously been executedTest parallel with the developers, not only just before a releaseAlexander Vanwynsberghe – 09/05/2011
- 8. 4. Automate testsUser interfaces can be test-automatedEliminate repetitive tasksCan save the testers a lot of time if many iterations of testing are requiredDo not automate one-time-only testsAlexander Vanwynsberghe – 09/05/2011
- 9. 5. Report bugsAnd assign them to developer(s)http://www.flickr.com/photos/harmony19490/362411276/
- 11. The developer..All coding doneSome small ‘debugger-tests’Check-in/commitDeploy to a development environment“Test please” to tester…Alexander Vanwynsberghe – 09/05/2011
- 12. The tester tests..No plan available (no user stories)Lucky to find bugsWaste a lot of time on irrelevant thingsThis is called “Exploratory testing”Alexander Vanwynsberghe – 09/05/2011
- 13. ..and reports the bug..Email subject: Mayor bug found!!Email content: “I can’t quite remember what I did, but my data is gone !?”Where is my data?Alexander Vanwynsberghe – 09/05/2011
- 14. The dev tests and replies..Email subject: RE: mayor bug found!!Alexander Vanwynsberghe – 09/05/2011
- 15. ProblemsTester had no plan – Exploratory testing
- 17. “Unable to reproduce” = “Works on my machine”
- 18. Bug never gets fixed
- 19. Ship a buggy productAlexander Vanwynsberghe – 09/05/2011
- 20. There is a better wayhttp://http://www.flickr.com/photos/frau_k/3984560746//
- 21. Use the power of TFS 2010All data is stored in TFSAlexander Vanwynsberghe – 09/05/2011
- 23. Manual testing with MTM 2010Alexander Vanwynsberghe – 09/05/2011
- 24. What can a tester do with MTM?Create test plans
- 28. Screen recording
- 30. Inline bug creation with attachments Alexander Vanwynsberghe – 09/05/2011
- 31. What does the developer receive?A work-item of type ‘bug’ assigned to him/her
- 32. An email to inform about the bug (configured using TFS Alert Explorer)The performed testcase with completed steps
- 33. Necessary information to reproduce the bug
- 34. IntelliTrace to get to the ‘bug point’ in code
- 35. Video recording
- 36. Comments of the testerAlexander Vanwynsberghe – 09/05/2011
- 37. Ok, bug solved, what’s next?Check-in the changes
- 38. Link the bug to the changeset
- 39. The changes for a particular bug are traceable
- 40. Developer sets the bug work-item to ‘Resolved’
- 41. Tester can test again and check the influence of the code change on other tests (Test Impact Analysis)Alexander Vanwynsberghe – 09/05/2011
- 42. Some interesting thingsWhen the developer finds the bug:
- 43. Don’t fix it at first
- 44. Create an automated test from the recorded test
- 45. Let the test fail
- 46. Fix the bug
- 47. Run the test again
- 48. TDDWill be explained laterAlexander Vanwynsberghe – 09/05/2011
- 51. Automatic testing with VS2010Alexander Vanwynsberghe – 09/05/2011
- 52. What can be tested with VS2010?Code from the developer
- 53. Unit testing
- 55. User Interface = Coded UI testing
- 56. Database (stored procedures) = Database testing
- 58. Load testingAlexander Vanwynsberghe – 09/05/2011
- 59. Unit testsA piece of code that tests another piece of code
- 60. Readable
- 61. Understand!
- 62. What? Scenario? What will happen?
- 63. Maintainable
- 64. Trustworthy
- 65. If all unit tests passed = bug freeAlexander Vanwynsberghe – 09/05/2011
- 66. The structure of a unit testArrangeActAssert[TestMethod]public void Add_TwoPlusThree_EqualsFive(){// arrange int expected = 5; int first = 2; int second = 3; var calculator = new Calculator();// act int actual = calculator.Add(first, second);// assert Assert.AreEqual(expected, actual, “addition failed”);}Alexander Vanwynsberghe – 09/05/2011
- 67. Integration testIntegrates different pieces:
- 68. UI
- 69. Business Logic
- 70. Database
- 71. Touches:
- 72. File system
- 73. Database
- 75. Not in memoryAlexander Vanwynsberghe – 09/05/2011
- 76. Coded UI testTest that the user interface functions correctly
- 77. Created using recording, or using code
- 78. For web, Win-forms and Silverlight
- 79. Can check control behaviors (like label values)Alexander Vanwynsberghe – 09/05/2011
- 80. Database testing Unit test for database objects like stored procedures
- 81. Can execute T-SQL statements like:
- 82. SELECT * FROM Content.Workspaces WHERE WorkspaceId = 1 --will fail, because it existsAlexander Vanwynsberghe – 09/05/2011
- 83. Web performance testingSimulate a user performing a set of operations
- 84. Validate the responses to see if the application is working as expected
- 85. Created by recording a human user clicking through a Web application
- 86. Web tests can be made smarter by using Validation Rules, Extraction Rules, and Test Context Alexander Vanwynsberghe – 09/05/2011
- 87. Web performance testingAlexander Vanwynsberghe – 09/05/2011
- 88. Load testingContains web performance tests and unit tests
- 89. Simulate virtual users by setting the number of iterations
- 90. Collects all sorts of information like:
- 91. Response times of the executed requests,
- 92. Performance counters of the tested application infrastructure (like CPU, Memory, I/O, …)
- 93. The health of your load-testing infrastructure (load controller and agents)Alexander Vanwynsberghe – 09/05/2011
- 94. Load testingAlexander Vanwynsberghe – 09/05/2011
- 96. What you may not forgethttp://www.flickr.com/photos/niffgurd/3324865930
- 97. SummaryTesting is important, and easy with TFS
- 98. It gives confidence to those selling the product
- 99. The earlier a defect is found, the less development rework and re-test is required
- 100. Use proven high performance as a selling point
- 101. Testing needs disciplineAlexander Vanwynsberghe – 09/05/2011
- 102. Alexander Vanwynsberghe@vanwynsbergheaEngelse Wandeling 2, K18B-8500 Kortrijk, Belgiumalexander.vanwynsberghe@cognistreamer.comwww.cognistreamer.com