The list of reasons why developers "toss stuff over the wall" is too large to tackle individually, but there are a few classics. Deadlines, end of day jitters, and irresponsibility are common and top the list. For the uninitiated, "tossing stuff over the wall" refers to an unspoken paradigm where programmers send unverified code over to quality assurance for testing. In these cases, programmers perform little to no personal testing to verify the intended requirement is being met. Although this might sound like a bad concept, it does have supporters. Some argue that developers are expensive and their time is valuable; therefore, time is better spent in code. Additionally, the question of, "Why do we have QA, if I have to test it as well?" arises. There are benefits to that approach, but the hidden costs are greater.
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.
odeProject
