At a recent engagement I was asked about using Lab Manager 2012 for testing. I was happy to explain how and why Lab Manager can increase efficiency and quality for their development and testing practices. Lab Manager fits very nicely with DevOps practices, by automating the creation of new test environments which often is done manually by the Operations team. This can reduce the wall between Development and QA teams, since QA teams can self-provision new test environments that include the code versions they want to test.
We have all experience the invisible wall between Development/QA and Operations. You know the Ops team… They’re the guys that always say no and are paranoid over making even small changes. True be told, they have a good reason to be paranoid. Every bug, configuration changes, new updates, and non-tested software gives them that reason to be. The fact is, they’re going to be the ones first getting the midnight call when the software fails.
What I hear from the software teams over the years is we need to have fast, reliable, known production versions that we can control and have full automated deployments. This is a lot to ask for.
Virtualization has been around for a while, and we all have setup the virtual environment and created script to support software team’s requests. It’s a lot of work getting that end-to-end solution that supports building a clean, known good environment from the ground up, deploying the right version of the software, and even running the available automated tests. This is where Lab Manager, TFS 2012, Team Build/Deployment, Test Manager and Visual Studio all come together to create a clean end-to-end solution.
Having a quick reliable environment that mimics a known production version is a huge value at the organization level. We have all seen where a development or testing environments are so polluted with unrecorded configuration changes that testing is not effective or can’t be done at all. I’ve personally seen an instance where over 30% of the tester-logged bugs ended up simply being misconfigurations in the test environment. The dev team wasted a lot of time trying to reproduce bugs that weren’t really even bugs!
This one other reason why Operation teams are paranoid. They see that the environment the software team is testing on is 8 versions ago and the system configuration does not match what in production.
“Hey it works on their environment and it’s ready for production!”
Now I might be exaggerating just a little here, but I know I’m not to far off of the truth for some organizations.
You can reduce the paranoia and gain confidence within the Operation team by having a baseline template of a known good, production-like environment that spins up each time a build–deployment–testing is ran. The Operation team provides the baseline templates, while Lab Manager, TFS 2012 and Test Manager handle the automation.
The result is the Operation does not have to worry about the polluted environment that the software teams are testing on and the software team gets that full automation solution. Now the focus of bugs can on be on the build, deployment, and testing and not the environments and what was or was not installed or changed. To me that’s a win-win for all the teams – development, testing and operations!
There is some planning involved in rollout Lab Manager. The best guide I have found is the ALM Ranger guide for Lab Manger. This can be found here.
The guide has planning workbook and Hands-on labs are valuable in understanding the scale of depth of Lab Manager. There are many moving parts that involve multiple teams. Planning is a must.
Is the effort of incorporating Lab Manager, TFS 2012 and Test Manager worth it?
I guess the real question is, what is the cost and impact of not having a fully automated build – deploy – test solution that gives you a known production baseline version in your software development cycle? For most teams, there’s a massive amount of manual labor and wasteful activity that is, for the most part, hidden from sight. But it’s not just the waste you can trim out, but the impact of having a much, much faster Dev/Test cycle time.
Plus, you might even get the Operation team to be a little less paranoid and you might even hear a “Yes” to your requests.