Application lifecycle management and test management tools typically get implemented or evolve in isolation within an organisation. Solutions and tools get implemented that fail to deliver cross team collaboration because different tools are implemented by different teams with differing needs within the organisation.
The trouble with this organic approach is that significant inefficiencies develop where integration between teams largely ends up being resolved with an ad hoc solution. For example business requirements get created in one tool by the business analysts. Those requirements are then imported into the test case management system for the QA team. Those same requirements might be fed to the development team in another format or imported into another tool. The problems then start developing when requirements get changed later in the lifecycle. Lack of visibility and the resulting poor levels of collaboration result in products that fail to meet the clients demands. Worse still the business pays a heavy cost for these inefficiencies as these issues are corrected late in the product development life cycle.
The goal then is to bring together different teams involved in the development lifecycle, possibly geographically distributed teams, and provide these teams with a solution that delivers real collaboration capabilities. Collaboration capabilities that capitalise on the collective knowledge retained within your business. Unlocking that collective knowledge and reducing inefficiencies that come from
- different teams using different tools
- project artifacts stored in different formats
- manual workaround methods that perpetuate these issues
You want to provide your QA and development teams with greater visibility of requirements that are written and developed outside of your test management tool. You need to see changes to those requirements flow automatically between requirements capture tools (like Accept360, etc) and Quality Center. Only when QA and development have full visibility of requirements and changes to requirements do you stand any chance of delivering exactly what your customer demands.
Your development team are using TFS whilst the QA team is using QC to track testcases and defects. When the QA engineers raise defects in QC it’s important that the development team get quick visibility of these defects in TFS. When developers update these defects in TFS and move them to a resolved state it’s critical that the QA team see this updated status in Quality Center so that they know they have defect fixes to retest.
Developers need full traceability of source code changes within their defect and test management solution. So changes to source files that are instigated by a defect or requirement in QC can be traced. For example a check in to Subversion (or similar tool) will show up in QC requirements and defect records. This gives development and QA full 360 visibility and traceability from actual source code changes to the requirements and defect artifacts that prompted those changes.
The benefits of integrating the tools used by different cross functional teams are significant. Integration leads to visibility, traceability and manageability. With this comes the ability to:
- align resources
- better control change and the impact of change
- reduce risks
- improved progress monitoring
- collaborate more effectively
The ability to collaborate across functional teams allows people to provide early input to changes. For example requirements updated by BA’s in one tool get reflected through to testers within their test management tool. This sort of immediate visibility gives the QA team the potential to provide early input on changes at the point at which it matters. At the start of the change. Not, as so often happens, at the point where the change has been implemented and unpicking it results in significant additional costs to the business.
Ultimately this all leads to a more unified and cohesive approach to the software development lifecycle. An approach where the analysis, development, test and delivery phases are all in sync. All in sync for both co-located functional teams and globally distributed teams.