The Issue

Products need to be tested thoroughly before release. The more problems that your own QA and Product engineers find, means that your customers will have that much more of a smoother experience with your product.

At the same time you also need to shrink your product release cycle times so as to more quickly respond to customers’ new and changing requirements. Nowadays customers have so many choices for software vendors that if you take too long to deliver a feature or enhancement, then there is a real chance that your customers will find an alternative, including developing a solution themselves – after all they have their own deadlines to meet.

Often we are tempted to take the approach of keeping Developers and QA engineers neatly siloed from each other. Developers develop software and hand it off to QA engineers to test. You have an elaborate hand-off process with lots of design and other documents going back and forth. On paper this sounds like an organized process that will be easy to manage.

However, these documents take time to prepare and are usually out of date quite quickly. This leads to longer release cycles with potentially erroneous software in case there is an undocumented disconnect between Developers and QA staff.

Confusion also creeps in when requirements change too quickly, or features are delayed and start to get out of sync with planned releases, or if too many bugs are found, or if incomplete or out-of-date documents are exchanged between the teams.

Your neat process can quickly get out of control when plans go awry and you have to then take corrective measures which usually more processes that can also go awry.

Don’t get me wrong, I think having consistent processes is good but these have to be simple and easy to follow. When you have as many moving parts and actors, as you have in product development, then I think a different, less siloed approach is better overall.

The Solution

I like a more agile process where Developers and QA engineers are on the same organizational team and jointly developing the product for release with truly shared responsibility.

In essence it is one development team with developers, architects, QA engineers, etc. all working together and following the same shared responsibility structure.

The more the siloes are broken down and the more that Developers and QA engineers work together everyday, the more information will be quickly and accurately exchanged. This will in turn allow for faster release cycles as QA and Developers know what the other is doing and the end-to-end process for software delivery can be optimized.

QA engineers are best at developing and executing automated and/or manual test cases. They are usually quite fast at this as this is their domain of experience. However, they get bogged down and lose a lot of time in the data gathering phase before they can develop the test cases.

Usually Developers and QA report up distinct organizational hierarchies and as such there is a hand-off process between Developers and QA. This hand-off is sometimes quite elaborate with many design and other documents being exchanged and sometimes quite chaotic if developers don’t have the time to put these documents together.

In the former case, this adds significant overhead to a software release. Developers spend a lot of time trying to document the explanations about their features – why they exist, how they work, what are valid and invalid inputs and workflows, etc. On the other side, QA engineers spend a lot of time reading these documents and trying to understand them, then going back and forth with Developers if something is not clear. If by chance, requirements change too quickly, then you have a hand-off nightmare with the real chance that it is done incorrectly and the obvious consequence of buggy software being released. Sometimes you also face the risk where QA engineers follow the given documents word for word and develop neat and tailored test cases. However, users don’t tend to use products like this. They come up with wild and whacky ways of crashing your products. Often using it in ways that it was probably not intended for.

In the latter case, if the hand-off is more chaotic, then information slips through the cracks in the exchange and either the QA process gets stretched as QA engineers have to constantly ping Developers (with the obvious consequence of delaying your next release) or once again buggy software is released as features are tested incorrectly or not thoroughly.

Having Developers and QA engineers working together from day one helps to mitigate a lot of these issues which stem from broken and/or inefficient communication channels.

If QA engineers are involved right from the design phase of a product release, then

• They will know right from the start about why a particular feature or product is being developed
• They will understand each workflow well
• They will be able to provide feedback early in the process about how to make the product more robust and easier to test
• They will be able to suggest instrumentation in the product itself to support automated testing (e.g., the inclusion of CSS selectors for UI-driven tools like Selenium) to detailed error logs (e.g., to automate trouble-ticket creation)
• They will be able to more closely mimic end-users and design test cases to stretch your software, e.g., with many more so-called corner cases
• Some of the instrumentation and techniques will also be invaluable when the product is released to operations and fast and accurate troubleshooting is required during production
• Developers will learn first-hand what it takes to make software robust and eventually this thinking will start to permeate even their version 1 product designs and will help perpetuate and virtuous cycle of quality development

There are many more benefits for organizations who break down these siloes I have only attempted to enumerate a few of them.