Archive for March, 2012

Test Environment considerations Part II

Several months ago, I blogged about the challenges around building out test environments that fit your software delivery process.  While I have never admitted to being a perfectionist, I tend to be a harsh critic of dumb process, or of asking of my team members things that i would never in good conscience do myself.  With that particular mindset, it has almost always been very difficult for me to make architectural decisions because of my ability to find flaws in even some of the most sound of ideas.  With that being said, months ago, I/we set out on a journey to build out an environment that was just enough to accomplish our strategic objectives for the next year, plus lay the ground enough to not screw ourselves into a hole, but allow for an architecture that could be expanded over time in order to improve quality, and increase tester productivity.

After many conversations and observations, it became clear that building out test environments is akin to architects building out software to solve business problems.  They can usually see clearly a vision of the next several months, but the outskirts beyond that are a blur.  You also do not truly have the ear of the power brokers who impact the future of product/software development, and yet you can not accomplish your mission without making some basic predictions about the future.

In my particular case I am a fan of the promotion policy.  The theory is that each Scrum team has their own environment, but through continuous integration, teams have the ability to become aware of other teams software changes daily and elect to develop and test against the latest functionality.  While each team has their own QA environment to test their change set against several products, there still exists an QA Integration environment where the full suite of products and services exist that allows for a wider range of tests to be conducted.

The QA Integration environment is not really ‘owned’ by one team, but instead representatives from each of the teams to make sure their interests are represented, common sense rules of the road are followed and that each team are good stewards of the environment.

So, that leaves us with a Commit, Acceptance and QA Integration stage in our Continuous Delivery pipeline

The commit stage is responsible for automated build creation and unit test

The acceptance stage is responsible for automated Middle Tier/Business logic tests

The QA Integration stage is responsible for functional product testing, as well as testing software integration of products ‘owned’ by other teams

The verdict is still out on if this approach is optimal, but, it is simple, it is lightweight and was designed with the agile iterative concept in mind.





Leave a comment