I read an article the other day that questioned if collaboration actually impacts productivity. As software testers in the age of agile we’re encouraged to embrace the concept of collaboration as something that will improve the way in which we work. We’re pushed to collaborate within the test management process and other business processes. And we’re pushed into working in groups in open plan offices.
There’s probably some merit in this argument that collaboration might result in reduced productivity. In an open plan office we’re constantly interrupted by other people. We find it easier to waste time chatting with people. Getting things done in dedicated and focused work sessions has become more difficult. Some blame this on our desire to be more collaborative. There are probably pros and cons to both sides of this argument. As always there will be a balance to be struck.
There are however, many merits in integrating the tools you use. If your QA team need visibility of defect status in their test management application, or the dev team need to see source code check ins in their defect tracking application then integration is going to help. The aim being that each functional team gets to use their tool of choice which best serves their needs. Yet one tool that works for the development team may not be the right tool for the QA team. Jira is one example.
Jira is used by many development teams to track requirements and defects. The application of choice for many. Yet Jira doesn’t work well for managing test cases. The defect tracking workflow is not a good workflow for test management. So typically a test team ends up picking a different solution. At which point both functional teams end up with different silos of data. Data that in many cases both teams need access to. So we end up dipping in and out of two different tools and duplicating data.
Enter the new (or maybe not quite that new) breed of test management and ALM integration tools. Tools like OpsHub Integration Manager that allow you to synchronize data between completely different applications. OpsHub allows you to keep records maintained in two completely different applications in lock step. For example the QA team raise a defect in Quality Center. Trouble is the development team are using Jira and don’t get visibility of this new issue. With OpsHub configured the QC defect can be automatically created and updated in Jira. When a code change has been made to resolve the issue, and the issue status updated to resolved, that update is automatically sync’d back to QC. The QA engineer then sees this up to date status without having to check back in Jira.
The big advantage of this type of integration is that both parties see the same data even though it’s displayed in different tools. Testers don’t need to leave their test management tool of choice to raise defects in development tools. Team members don’t have to maintain duplicate records in different system manually. Everyone gets the right information, at the right time, in the right application, conveyed in the manner which best meets their needs.
Whilst setting up such integration tools might not be simple the benefits once you’re up and running are huge. In an upcoming post we’re going to look at how this comes together from a practical perspective and see how we can integrate our test management process with other processes that are critical to the project lifecycle. And whilst the argument continues about the potential drop in productivity caused by collaboration at physical level, we can move forward and exploit the definite benefits that tool integration provides.
