We’ve been seeing a lot of agile driven development the last few years and have also heard about the need for intra and inter discipline collaboration. There is a need for:
- Clear communication
- Accurate and detailed reporting to meet the needs of the entire team to empower quick and accurate decision making
- Reducing overhead on use of systems (be it version control, defect management, IDE, build generation etc.)
- Enabling global teams to work in unison
- Minimizing re-work
One solution that most companies are resorting to address all these requirements is an “ALM (Application Life Cycle Management) implementation”. IDC forecasts continuing growth in the ALM services segment, with expected revenue approaching the US$61 billion mark by 2011. Clearly an enterprise level ALM implementation calls for support from the overall management team and representation from all product disciplines, however given the features that ALM suites offer these days, several cost effective alternatives that are available in the market, it is a lot easier to justify the ROI from such an implementation, to get the management’s buy in.
Here are some clear areas where the test team will stand to benefit from an ALM implementation, which should be highlighted if an implementation decision is impending. I’ve also highlighted below some points to consider when making the choice between a commercial and an open source ALM, and the associated pros and cons.
- Collaboration with other disciplines – quick visibility into changing requirements, checked in code, project plan, readiness of builds
- Improved Productivity – better toolset for manual and automated functional testing, load testing, defect logging, result logging and reporting
- Improved Quality and Reduced Re-work – integrated platform for reviewing test artifacts, more detailed bugs with trace information, video files of test workflows, more consistent and predictable test artifacts review process with cross disciplines, code coverage and traceability to product code and requirements
- Better Knowledge Sharing – Use of integrated knowledge systems to share articles on test processes, workflows, methodologies, how-to’s
- Improved Focus on Value-Add and Core tasks – the integrated system promotes better delegation of tasks to create more time for testers to focus on core tasks – e.g. empowering developers or build engineers to run build verification tests
- Holistic view into project, product and team – rather than working in an individual silo which promotes creative and out-of-box thinking in the test effort
- Better visibility for the overall test effort – enhanced reporting with varied levels of detail depending on target audience, dynamic dashboards to give snapshots of test results
Obviously, commercial ALMs offer comprehensive features and a more thoroughly tested for product, which means better quality, however an ALM implementation is often a huge investment, from time and money angles, which makes the decision difficult to reverse. Commercial ALMs also often have a more predictable release cycle and better support during and post the implementation phase. Given the number of disparate systems that you will need to integrate into the ALM, the migration effort is often sizeable and can pose quite a few challenges. So, the technical support you would get from the ALM vendor will be totally worth it, as you go through the process. That said, there may be situations where the ALM may lack converters, plug ins, add ons to successfully complete your integration process and getting these in place for a commercial ALM is more difficult than for an open source ALM. Open Source ALMs such as JABOX are gaining a lot of popularity and user base in the recent years and given the active community contribution to gather requirements, develop and test it, it is certainly an option to consider not having to go the traditional route of commercial ALMs (such as ones from Microsoft, HP, IBM…)
Every ALM implementation is a very customized effort. Take a close look at parameters such as goals of adopting an ALM, timelines, budget, existing processes and tools, availability of out-of-box features to complete the ALM implementation, stakeholders buy in etc. before deciding which one to go with. As a closing note, an ALM implementation is a project in itself, with representation needed from all disciplines!