Chris Menegay's WebLog

Manual Testing - Team System's hidden gem

Unit testing gets a lot of Team System love, because programmers are currently the target of marketing (bad idea). A lot of people I talk to don't even realize that Visual Studio Team Test is going to be a tester's best friend. Some companies use tools such as Mercury's TestDirector to manage their manual test cases, and VSTT competes with that. Manual test cases are all those tests that people usually store in Word docs, or Excel spreadsheets, that are basically user click-throughs. They are step-by-step guides that testers use to test an application and report bugs. What VSTT provides is a way to manage those tests. Manual tests are treated exactly like unit tests, web tests and load tests. You even "execute" them from the Test Manager window within VSTT. When the tests are run, rather than running and passing, they go to a "pending" state where it is the tester's job to run through the steps. If the tester doesn't like the results, they "fail" the test (by clicking a button) and report a bug (which is part of work item tracking - see previous blog entry) The tests can be placed in source control just like other tests. The tests can be plain old text, or MS Word format. They can even be related to work items. So imagine this:

  1. Developer works on Requirement 42 (work item)
  2. Developer checks in code to source control and associates Req 42 as "resolved" (completed)
  3. Automated build runs that night and creates a build report that notes that Req 42 is ready for test (tester notified by email)
  4. Tester pulls up the manual test for Req 42, and executes the test.
  5. Tester finds bug and files a bug against Req 42
  6. Developer gets assigned the bug, looks for tests (they are part of the team project and in source control, so it's easy to find) associated with work item 42
  7. Developer duplicates the bug by running the manual test
  8. Developer re-assigns the bug because he'd rather play golf today (ok, just kidding, he knocks it out and "resolves" the bug)
Notice in this entire scenario, the tester NEVER had to talk to a programmer - isn't that tester bliss?  But all of the communication happened anyway...THAT is TEAM System - not those piddly graphical designers that MS likes to talk about so much because SOA is such a buzzword.
 
Posted: Feb 24 2005, 11:57 PM by cmenegay | with 4 comment(s)
Filed under:

Comments

Drew said:

Oh, dear. I hope that even less direct communication between dev and test isn't a VSTS goal. Or side-effect. Process can be good. Silos . . . I'm not so sure.

That said, I am looking forward to VSTS replacing <internal_stuff_I_won't_name_that_sucks> in my division.
# February 25, 2005 2:00 AM

Sipke said:

Looks like re-invention of Mercury TestDirector ?
# February 25, 2005 5:55 AM

Pedro Silva said:

Hey, nothing wrong with those SOA designers... :)
They're just targeted at a different audience; mainly the architects.
# February 25, 2005 1:47 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)