Tossing Stuff Over the Wall to QA
Join the DZone community and get the full member experience.Join For Free
Developers who subscribe to this model or have used it on occasion have a tendency to hide behind the knowledge that sometimes "tossing stuff over the wall" works. A programmer gets the concept right the first time and the work breezes through QA. Unfortunately, instead of feeling relief, some developers experience an increase in confidence. This can be a dangerous cocktail. Sending improperly vetted code to QA is an unhealthy practice in any environment. QA, as well as developers, should hold others accountable when this arises. A lack of accountability is a breeding ground for mistrust between DEV and QA. This will have a direct impact on a team's ability to produce fast, high quality output.
"Tossing stuff over the wall" boils down to respect. Time is precious and when a QA analyst feels that his/her time was wasted, respect towards developers can be diminished. Programmers also send an unspoken message that they do not fully respect the QA position. Additionally, creating software is an outward representation of a programmer's vision, design, and ability. Sending out unpolished work is akin to sending a first draft of a book for final printing. It displays a lack of respect for one's work.
Programmers should take ownership of the work they produce. Part of taking ownership is expecting high quality in a timely manner. Like raising a child, developers must guide their work to successful maturity. Anything less encourages sloppy work and opens the door for mediocrity. No one likes a dead-beat dad. The following describes a few techniques that encourage proper ownership:
- Before (or shortly after) taking on a task, have a conversation with QA about the work being completed. Give them a chance to ask questions and/or provide them insight into what is being changed. This conversation does not need to be formal but can be.
- Before sending code to QA, test all basic functionality. When record sets are involved use a simple Zero-One-Some model. It may be helpful to keep a list or refer to technical documentation for this step.
- After releasing new code to QA (regardless if it is a bug fix or new features), have another conversation with QA about the work completed. Re-emphasize what was released to QA and if anything is still pending.
- If bugs are found by QA, fix them in a timely manner. If this is not possible, actively communicate this and allow for feedback. A compromise may be required based on timelines or impact.
These recommendations might feel like overkill, but it's important to over-communicate. No one has ever been told to stop over-servicing a customer. For developers, QA is their customer.
Published at DZone with permission of Zac Gery, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.