In my experience, there's a lot of animosity and poor communication between Development and QA. It's not that they don't appreciate one another so much as they never seem to stay on the same page.
QA: "What's the status on defect #4874?"
Dev: "Done."
QA: "Done?"
Dev: "Yeah, I fixed that Tuesday."
QA: "Err, ok. Well where is it? I mean where can I verify it?"
Dev: "No clue. I committed it Tuesday. It passed unit tests and built successfully."
QA: "Alright. I'll track it down."
Invariably, QA speaks with the build manager (if there is one) to find the build in which that defect was repaired. After discovering the correct build, now QA needs an environment stood up to house that build. But wait, the UAT environment is currently testing the next release. It can't be disturbed for another week.
At this point, the QA person's blood pressure heads for unsafe levels and the Dice.com browsing begins. But it doesn't have to be this way...
Lab Management in Visual Studio 2010 along with TFS solves many of these pains. Here's what the above scenario might look like with Lab Management:
QA doesn't inquire to the Dev about #4874 because it's already marked Resolved and back in QA's list of Defect Work Items. It's associated with a Continuous Integration Team Build instance which is marked with a Build Quality of Ready for UAT (meaning all unit tests passed and the build compiled successfully). Behind the scenes, as part of the build, Lab Management spun up a virtual web server, application server and database server. Team Build deployed the solution to this virtual environment and even sent an email to the build manager and the QA person (they chose to be alerted) saying this environment was ready for testing. This shop is currently testing four pending releases along with a production hotfix that's going out later today--all at the same time in completely separate environments.
Best of all, it's an amazing value. If you made/make the investment in Visual Studio 2010 Ultimate, you get Lab Management for free. Yes, that's right: free. That said, you will need some not insignificant hardware to serve as a host for these virtual servers...but you have that already, right?
QA: "What's the status on defect #4874?"
Dev: "Done."
QA: "Done?"
Dev: "Yeah, I fixed that Tuesday."
QA: "Err, ok. Well where is it? I mean where can I verify it?"
Dev: "No clue. I committed it Tuesday. It passed unit tests and built successfully."
QA: "Alright. I'll track it down."
Invariably, QA speaks with the build manager (if there is one) to find the build in which that defect was repaired. After discovering the correct build, now QA needs an environment stood up to house that build. But wait, the UAT environment is currently testing the next release. It can't be disturbed for another week.
At this point, the QA person's blood pressure heads for unsafe levels and the Dice.com browsing begins. But it doesn't have to be this way...
Lab Management in Visual Studio 2010 along with TFS solves many of these pains. Here's what the above scenario might look like with Lab Management:
QA doesn't inquire to the Dev about #4874 because it's already marked Resolved and back in QA's list of Defect Work Items. It's associated with a Continuous Integration Team Build instance which is marked with a Build Quality of Ready for UAT (meaning all unit tests passed and the build compiled successfully). Behind the scenes, as part of the build, Lab Management spun up a virtual web server, application server and database server. Team Build deployed the solution to this virtual environment and even sent an email to the build manager and the QA person (they chose to be alerted) saying this environment was ready for testing. This shop is currently testing four pending releases along with a production hotfix that's going out later today--all at the same time in completely separate environments.
Best of all, it's an amazing value. If you made/make the investment in Visual Studio 2010 Ultimate, you get Lab Management for free. Yes, that's right: free. That said, you will need some not insignificant hardware to serve as a host for these virtual servers...but you have that already, right?
Comments
By the way, Thanks for the this information.