Click here to Skip to main content
13,558,063 members
Click here to Skip to main content
Add your own
alternative version

Tagged as

(untagged)

Stats

3.9K views
Posted 8 Nov 2013
Licenced CPOL

Tossing Stuff Over the Wall to QA

, 8 Nov 2013
Rate this:
Please Sign up or sign in to vote.
Time is precious and when a QA analyst feels that his/her time was wasted, respect towards developers can be diminished.
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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author


You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01-2016 | 2.8.180515.1 | Last Updated 8 Nov 2013
Article Copyright 2013 by Zac Gery
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid