February 2005 - Posts
In my previous blog about manual testing, I didn't mean to imply that the new designers in Visual Studio Team Architect aren't cool and sexy - they are. My problem is that I think Microsoft is falling into the trap of selling what's easy to sell. The process piece of Team System has the opportunity to fundamentally change how development teams work (for the better). The SOA designers are a design tool. We've had design tools for years. While Whitehorse is a huge step in designing better systems, if software teams don't get better at all the other things that take place (or oftentimes don't) during a development project, all the designers in the world won't save their project.
So, my problem is that Microsoft seems as though they might fall into the trap of marketing to developers, since that is the audience they know (for dev tools). Recently, MS did some national MSDN events where they had an hour on VSTS. It was 80% Whitehorse, as far as demos, etc. I had the pleasure of working with the Developer Community Champion for my area (Michael Benkovich) and we at least built a good "story" around the demos and slides. I wonder how many people saw this presentation in other parts of the country and left thinking VSTS = Whitehorse.
I also don't want to imply that I think that developers and testers shouldn't talk. I don't think they should talk about silly things, such as: What's in a build? What were you doing when this broke? Oh, you were running test case X, where is that? Those conversations don't need to be had, I'd rather they be talking about clarifying tests and requirements. They should be talking about real problems, not trivial stuff. The same goes for devs and PMs. Project managers shouldn't have to waste time getting status updates from developers. It's not productive, I'd rather they spend that time removing roadblocks, mitigating risks, etc.
I think I'm getting way to evangelical with regards to Team System... I'm just very jazzed by it, and very badly want to see it, and those that use it, be successful.
Apparently John works on the team responsible for Work Item Tracking and it sounds like they may address some of my concerns. I have two responses to this:
1. Happy! Happy! Happy! Joy! Joy! Joy! - I won't have to write this myself.
2. Sorrow - this was going to be an easy consulting sell for me to fix this problem for people adopting VSTS ;-) - I'll guess I'll have to stick with process tempate customization!
There is one thing I noticed in John's Blog that is just flat out wrong - that Hitchhiker's trailer is AWFUL! The new one is much better:
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:
- Developer works on Requirement 42 (work item)
- Developer checks in code to source control and associates Req 42 as "resolved" (completed)
- Automated build runs that night and creates a build report that notes that Req 42 is ready for test (tester notified by email)
- Tester pulls up the manual test for Req 42, and executes the test.
- Tester finds bug and files a bug against Req 42
- 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
- Developer duplicates the bug by running the manual test
- 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.
It seems that the more I play with VSTS, and learn cool new things, the less likely I am to blog about it. I find myself talking to people about Team System almost every day, but constantly don't think to record some of the more interesting bits here. So--- If you haven't looked at the full feature-set yet, you need to check out work item tracking (WIT). WIT is my favorite piece of VSTS, it allows you to manage and track your work, your bugs, risks, etc.
However, I'm extremely disappointed with the MS Project synchronization, I'm curious to see how that evolves prior to release. The problem is this: I think a developer should access their work items within VS, and know exactly what they should be working on. As they complete a portion of a task, they should be able to (from VS) mark it partially complete. The PM would then sync that data and update the project plan with % complete.
Neither of these scenarios are supported today (Dec. CTP). If a developer has 10 work items, there is no "start date" on them to indicate an order. Within a project plan, the PM usually sets that up, but there is no field to hold that in the work item itself. One of the guys that I work with is going to be exploring soon how hard it would be to add the additional field to the work items, and then modify the field mapping to Project. That way, if MS doesn't fix this, we'll have a solution. The same would need to be done for % complete data - though I think that may be there in beta 2.
Another annoyance is that people "assigned to" a work item, don't map to the "resource" within a Project task. This requires you to manally synchronize these important data items. I'm not sure what the product team is thinking on this, and I've already passed along my feedback. Of course, if MS doesn't correct these issues, and I can get them working on my own, that just means there is some opportunity :-).
More Posts