Have you ever been asked any of the following questions regarding work items: Is bug #123 ready for testing yet?, or When will I be able to test bug #456?, or What bugs are in the pipeline that will be ready for testing next?
If you're like me, you've probably answered the above questions at some point in the past something like: "Sure, it's been ready for testing for two days.", or "Bug #456 will be ready for testing after the next nightly build.", or "I don't know what bugs will be coming next, let me run some queries and get back to you."
Now, I'm a huge fan of Team Foundation Server but I hadn't stopped to take the time to put together a couple of relatively simple queries that would not only save myself and my fellow co-workers some time, but also make everyone's job just a little bit easier. Before I detail the two queries that eliminated the above questions, here's some details on our environments and automated builds.
Currently, we develop projects and push them through four environmental stages:
- Development: this is where all developers work on a daily basis - more-or-less isolated from the rest of the world.
- System Test: this is the environment that our testers perform their daily testing.
- Integrated Test ("Staging"): this is where we test out the integration points among multiple applications.
- Production: of course this is the environment in which our daily business runs.
Now, for each of our Team Foundation Server projects, we have three standard build types:
- Continuous Integration Build: this build type is automatically executed with each check in and deploys any binaries, files, etc. into the Development environment.
- System Test Build: this build type is executed nightly on a scheduled basis. All binaries, files, etc. are deployed to the System Test environment where our QA/Testers can "work it over" the following day.
- Integrated Test Build: this build type merely stages the various binaries, files, etc. to be pushed by the Integrated Test environment via CM processes.
So, back to the original goal of eliminating the original questions above. To do this, I created two queries named:
- Work Items Staged for Testing - this query, when ran, returns a list of all work items (e.g. Bugs) that have a State of "Resolved" and an "Integration Integration Build" (displayed as "Resolved in build" on the Work Item's Details tab) beginning with the text "Continuous Build" (the name of our CI build type). So, basically, this returns a list of all Work Items that have been associated with a changeset that has gone through the CI process, which means it has been deployed to the development environment and will be deployed to the System Test environment after the next nightly build.
- Work Items Ready for Testing - this query, when ran, returns a list of all work items that have a State of "Resolved" and an "Integration Build" that does not begin with "Continuous Integration Build" and is also not empty. I do not specifically check for a "System Test Build" in this query because I am assuming that any build type other than the CI build deploys the changes into an environment from which they can be tested.
With the recent acquisition of TeamPlain by Microsoft, we have deployed the TFS portal within our project teams giving our testers a nice web-based interface into TFS. Now, when they are curious about the state of existing work items, they can run the queries detailed above and get their answers immediately.
One caveat to all of this, if you decide to implement similar queries then you must ensure that your developers associate work items with their changesets when checking in source code (or other files).
Also, your build types must have the <UpdateWorkItems> element in your build scripts set to "true". This setting is what causes the "Integration Build" value to be updated to the latest build number associated with the work item.
Without the integration of TFS & Visual Studio, these types of queries would be a lot more difficult (if even possible) to build.
No comments:
Post a Comment