Most of us have been exposed to project that never follows actual project plan; the changes can be new features, new add-ons, defect fixes or new integrations. For every test manager these projects take a snow-ball effect, that is they keep on growing along the way, and you are never sure what to expect from them. And to make the mater worse more rapid the changes or defect fix, lesser the duration between the builds. But the area to test keeps on increasing. Another factor to consider is the trend of software development companies to “fall” in to Agile Development, where they “think” everything must be parallel.
Now what it do to test managers is very scary, you cannot get the automation kick in, as application is being updated regularly, you cannot add more resources, as “You don’t need more resources, you already have got it tested”, while if they do not get it all tested, you get to hear, “Mr. what are you doing, look there is very important bug your team missed”.
To tackle all this I have made my policy that for a project that is behaving like this (let’s say every new build is within less than two weeks of other) I usually deploy two resources; both resources do test new features for first week. For next week depending upon the available time, needs to change test cases, I on daily basis try to cast a net on areas that are near to new features, where one resource test the application, and other update the test data and test cases for next build.
And for last couple of days before the next build, we do a strategic exploration of application, which is for every build we select one or two modules and do exploration for the application.
This is not the ultimate test management process, but honestly since the advent so called agile development, and lack of cohesion between builds and marketing team’s insistence of new build every other day; this is the best I could devise in 5 years of my test management.