As teams become more agile, or, add more agile like practices to traditional
development practices, I’m seeing increasing frustration on the part of test
managers.  Rapid development cycles and scrutinized bottom lines are putting
more pressure on them to deliver comprehensive testing in tighter time
frames.  More and more testing is being taken on by development teams, and while
that is a positive trend to be sure.  More stringent testing performed by
development is a good thing, as a long time QA manager myself, I used to pray
for consistent unit and integration testing, but, ultimately, developers are not
trained to think in the same way that QA does.  Development testing is meant to
ensure that the code, service, or integration performs the way it was conceived;
it doesn’t always cover the assurance that the business process is being met
and it doesn’t replace the end to end perspective that an organization needs to
ensure that the highest quality software is being delivered. Development testing
is faster, to be sure.  End to end testing takes more time, but it’s necessary.
Test managers must do something to prevent testing being co-opted by development
at the expense of business value.

I’ve discussed seeing the trends that show test management becoming a more
strategic function within the application lifecycle – as discussed in The Dawn
of Dynamic SQA from earlier this year, and as 2009 has passed, this
strategic shift has shown us that traditional test management tools are not
enough.  What we are seeing at Forrester is that the walls between development
and QA continue to crumble – and as well they should – in order to allow the
developers and testers to work more effectively together.  In order for test
managers to be truly effective and to streamline the application development and
delivery process, they must extend their visibility further into the lifecycle –
that means that they need to have insight into planning, requirements, build
changes and potential service issues.  This allows test managers to be able to
anticipate what’s coming that is going to impact their test plans and avoid
being that classic “QA Bottleneck”. 

Extending this visibility means that test managers must take advantage of
tools that provide ability to drill into multiple layers of the application
lifecycle – from planning to deployment.  It’s no longer enough to use just test
management suites, defect management, Excel and Word to plan their test
cycles. test managers must add the following tools to their arsenal:

1. Application lifecycle management (ALM) – these tools provide the ability
to determine build status, configuration changes and monitor requirement
changes.  If there is a problem with a build, the test manager can see how that
will affect his/her test schedules.  If there are requirement errors,
development errors or changes, the test manager can immediately know that tests
may need to be reprioritized, rescheduled, or scrapped.  In a continuous build
cycle, this can significantly reduce the amount of unnecessary testing that is
all too normal in QA environments.  Vendors such as MKS, IBM, HP provide the
ability to integrate test management with ALM to provide this level of
visibility.

2. Service management or help desk tools – these tools can help the test
manager see what potential problems are coming down the pike and can prepare the
test team with prioritized test cases to quickly test any fixes that are being
planned by development. Together with ALM, test managers can be ready for quick
break/fix cycle updates so that there are no delays in getting a fix out to the
field, nor will they have to rely on only development testing to approve the
fix. I’ve talked with several Forrester customers that are beginning to pull in
service desk information into their test planning for maintenance projects. 
With QA being a critical element of the deployment team, I expect to see
more.

3. Project portfolio management (PPM) – for the really strategic test
manager, this environment will enable test managers to see active collaboration
at the project level, not just at the task or activity level.  If there are
risks, issues and/or scope changes,  test managers can quickly see them and
suggest schedule changes and test plan changes proactively, instead of
scrambling at the last minute to make sure there is coverage.   HP, MKS, Serena
and Microsoft all provide various forms of information at this level and IBM
should be joining the mix soon.  CA and Planview offer requirements management
within their tools, so that if there are requirements changes, the test manager
with access to the team project page can make necessary changes and contribute
to the requirements management as needed.

4. Ad hoc – wikis, SharePoint and a host of other options are out there as
well. Today, I think this is probably the most widely used manner of bringing
test management into the process, however, without linking to artifacts, there
is still the chance of missing critical touch points.

Bottom line, test managers that are forced to scramble to find out time
sensitive information will continue to be squeezed out of the application
lifecycle – it’s time to start tearing down the walls at the tools level, too. 
ALM shares important project artifacts that test manager must use not as an
occasional, but a daily part of their management process.  PPM and service
management tools should also be on the short list to raise the visibility and
cut down on the communication barriers.   I’m interested to hear – what other
tools do you think should be part of the test management toolbox?