Bringing Development and Quality Assurance Teams Together

With the proliferation of mobile apps and their criticality to work and play, pressure to update apps with new features is relentless, yet corporate expectations regarding development budgets and policies often remain entrenched. Poor app ratings can literally impact corporate reputations, yet the rush to market makes it difficult to test adequately. 

One area where teams do have control of their actions - and can effect beneficial change through them - is by collaborating more effectively. The old practice of programmers working on code until they think it’s done and then punting it over the wall to the QA department simply doesn’t work in today’s development environment, and yet the practice continues.

Following are some thoughts, based on my experience, on the ways to start achieving more “people integration” while gaining a better product and a less stressful work environment in the process.

The need for team collaboration in technology development isn’t anything new, but it has become more urgent. In 2012, researchers at San Francisco State University determined that the primary reason 10% of software development projects fail (and more than 50% miss their target release date or go over budget) was lack of communication, organization and teamwork. 

They postulated that companies could predict whether or not a project would experience problems by measuring how often the various teams involved in the project collaborated, communicated via email or performed other types of interaction. All of their findings indicated that these soft skills are critical to software project success, and yet every day, I work with companies whose development and QA teams are still siloed in their own separate worlds.

The problem, of course, is that humans are creatures of habit, and it is easier to keep doing things in a manner that is counter-productive than it is to make a change - no matter how beneficial it might be. Consider team building exercises where, even for an hour, developers sit with testers/QA folks, and vice versa. Take a walk in each other’s shows (with guidance from the “expert,” of course) and see how much it changes outlooks. 

In my experience, developers who have adopted at least some elements of agile methodologies have the easiest time working with others as a team. Most firms with whom I work are functioning with elements of both waterfall and agile - effectively a hybrid solution environment. 

If companies have reached the point where testers are developing test cases before coding starts, and developers are building functionality in incremental units, collaboration between the development and QA teams becomes a much easier process. 

Why is this? For one thing, with agile methodologies, projects don’t progress so far down the road that when problems occur late in the development cycle, it’s easier to place blame than to just fix the problem. Second, the faster pace of agile iterations nearly forces teams to work together at some level, which encourages them to continue moving towards a truly collaborative environment.

As long as development and QA teams are circling one another, engaging in finger pointing when release dates slip or defects aren’t discovered until production, it’s difficult for them to see each other as allies. Testers blame programmers for careless coding; developers say testers didn’t write appropriate use cases or weren’t testing fast or often enough. The best way to end this practice is through better documentation and accountability. 

Tools or enforced documentation policies can help with this effort. There are myriad ways to implement such efforts (and likely dozens of books to guide you), and the approach you take will be highly dependent upon the methodologies and development/testing platforms you have adopted. To illustrate the possibilities, I have provided two examples from the Orasi arsenal, both of which work only with HP products. 

- Deploy an accountability tool or mechanism that manages workflow and requires digital authentication and verification of who worked on which tasks. One example is Orasi Digital Authenticator, which helps HP ALM clients get regulatory compliance documentation under control.

- Structure (and preferably automate) the communication flow between developer and tester. One example is JIRA Bridge, one feature of which is to automatically synchronize information about defects and requirements between the developer and tester. When a bit of code fails testing, the system automatically sends the details and circumstances of the defect back to the coder, leaving no room for misinterpretation.

This approach may seem counter-intuitive to the idea of open communication, but requiring teams to validate their work and document their communications will reduce blame-laying. Furthermore, the simple act of digitizing (and even better, automating) these communications speeds the development process, reduces errors and shows teams how much more they can achieve working collaboratively and communicatively.

Some of these suggestions may be beyond the reach of your firm; others may already be in place. Take from this article what works for you - the idea is to upset the apple cart in a positive way and change team attitudes (likely including your own) to be one of unity, not division.

Inventive teams will explore a variety of avenues for initiating the dialog, even if it’s not in person. The reality is that crossing the aisle needn’t be a physical walk. Often, it’s more a matter of shifting one’s mindset than moving one’s feet. Be the first one in your company to shift yours and see if company leaders don’t take notice.