Todd Suzuki

Subscribe to Todd Suzuki: eMailAlertsEmail Alerts
Get Todd Suzuki: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Can't We All Get Along?

How to live with and even come to love your QA team

We've all had days when QA made things difficult. When we take a closer look at what caused it we usually find that there was some miscommunication between QA and the programmers. And this miscommunication was most likely caused by the business having unrealistic expectations of the development team or the business/programmers not understanding the best way to utilize QA. So where does QA fit?

Sometimes programmers forget that for most companies QA is actually part of the development team. But programmers should be aware that most QA persons (me for one) think a bit differently about the application being developed and tested.

Programmers want to have new code validated to substantiate their work. Having a new program or modification pass QA gives a programmer a sense of accomplishment. QA, on the other hand, may feel that if it passes a new enhancement the first time through, then a bug has been missed. The difference in thinking is only natural. We (QA included) all want a sense of accomplishment - "I created this new module," "I created this new report." But remember that when a new modification is delivered to the customer QA wants to be sure that it's is not going to break, whereas the cocky developer is thinking, "It is going to work."

Programmers typically think about use cases for making a system work as designed, whereas QA is interested in making sure the user can't break it. How can programmers and QA use these different approaches to get the application developed?

Just as programmers like to divide and conqueror so does QA. QA benefits from an iterative development process the same as programmers. If QA gets a beta version of huge new modifications and the scheduled release date is two days away it's under the gun and is probably just going to find the big obvious bugs to get the release out. That way the overall quality of the software suffers...the showstoppers are found, but important bugs may be missed.

Is there a competent developer anywhere who wants important bugs missed? Obviously not, so how does a programmer help QA find bugs? It's simple. By incorporating QA into the development process early and often. Planning for QA early and often in the development process creates a less stressed development environment. According to many books on development, utilizing QA for at least 20 minutes out of every 100 minutes of development greatly reduces the number of unintentional transition errors.

If QA detects bugs shortly after they're introduced this will give a programmer the opportunity to take corrective action earlier. The longer a bug remains in code the longer it usually takes to eradicate it. Having QA test throughout an iterative development cycle helps insure a smoother development cycle.

Is QA Part of the Development Team or Just a Thorn in Your Side?
Instead of having an adversarial relationship with QA, act as a team with the goal of creating quality, on-time software.

A strained relationship with QA comes primarily from miscommunications and a lack of understanding about the design specification. A good business analyst clearly defines what the programmer is supposed to create to satisfy the businesses needs. The business analyst should also make sure that both QA and development understand what is expected. For QA this means understanding what the testing's baseline should be; whereas for the programmer this means being able to deliver work that meets both QA and the business analyst's requirements. Making sure one understands what's supposed to be created early avoids the miscommunications that lead to delays in development, so taking care of any potential miscommunications early helps to avoid the dreaded rework.

Some miscommunications are caused by fear of communicating (programmer to QA).Sometimes when programmers are afraid of QA, the real status of the development process isn't being accurately portrayed to the business. Why? Because the business thinks no news is good news and that everything must be on schedule. When programmers are afraid of falling behind the development schedule, they have a tendency of only showing the things that are complete.

This pattern of behavior is called Johnson's Syndrome after President Lyndon B. Johnson. During the Vietnam War, President Johnson's aides initially brought him some intelligence that showed the bombing campaigns weren't going as well as they should have, which ticked Johnson off. So to avoid making the president angry, his aides started avoiding showing him the negative data, which gave the president an inaccurate impression of the situation.

When a developer is thrust into an "everythingis okay" work environment QA can actually become an asset. Instead of the programmer always being behind the expected development process, QA can present that certain elements have been completed the alpha or beta process.

Can QA Make a Difference in the Development Cycle?
If QA is doing what it should be doing and spending most of its time developing regression testing scripts and programs it's contributing to the development cycle and is saving programmers from the monotony of verifying manually that every window functions/works as it should.

Utilizing QA's ability to regress systematically through an application as soon as it's stable enough to be tested ultimately helps the business ensure the long-term stability of an application. It also helps the programmer(s) complete development quicker by identify the implications of unintended changes to a program. Most significantly, regression testing lets the development team identify bugs quicker than if the application is tested by manual QA methods.

What Kind of Code Architecture Can Ensure that QA Creates Effective Dynamic Regression Testing Scripts?

  • Employing Microhelp - This small coding best practice (see below) lets QA key on something that should be dynamic to an application. An example is when your application does an export. By having Microhelp enabled with information like "exporting line X of Y" the regression tool doesn't have to have manual delays set. and the logic can key in on the Microhelp status.

    long ll_index, ll_count

    ll_count = dw.RowCount()

    FOR ll_index = 1 TO ll_count
        IF Mod ( ll_index, 10 ) = 0 THEN
          w_frame.SetMicroHelp ( "Exporting line " + String ( ll_index ) + " of " + String ( ll_count ) )
        END IF
    ...(some task here)...
    NEXT

  • Avoid having your Datawindows overlap - IBM's Rational Robot has problems determining what control is supposed to be active if the controls overlap. The program has enough problems without having to worry what window it's supposed to be Setting Context to.
  • Consider a limit of seven levels of nesting in a Treeview - Especially when a Treeview can be dynamically created within your application. By doing this it allows for functional automated regression testing. Once again, automated testing tools, Rational Robot in particular, aren't capable of handling extreme levels of nesting in a TreeView control.
Conclusion
Involving QA early and continuously throughout the development process will speed up the overall development process. This is facilitated by open communication, which is enhanced by understanding how developer's thinking differs from QA. Putting these perspectives to use during an iterative development process gives both QA and programmers the ability to divide and conquer the development process. Finally, employing some basic coding architecture will allow QA's regression testing to be developed dynamically. All these items will ultimately give the application under development a greater chance of success.

More Stories By Todd Suzuki

Todd Suzuki with over 14 years of IT experience. Presently, employed by Integrated Data Systems-IDS. Previous employers include Symantec, City of Los Angeles, Sony Pictures, and the US Navy.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Danielle 08/11/06 11:28:13 PM EDT

Loved your article! Yes,at the end of the day it is all about communicating and raising questions early on. What are the effects of one small decision? How will it impact everyone involved. With that said, lets hope more folks reads this article and perhaps it will bring positive change to the industry Again, Thanks!!! Danielle

Cary Harwin 08/06/06 09:32:06 PM EDT

Dear Todd,

I enjoyed this article and appreciate your value of QA being recognized at the design and programming level. Logic portions, such as business rules and processes are especially critical.

With your familiarity of the subject, I was hopeful you'd share your reaction and opinion of our LogicGem 3.0, a software tool to create, edit, verify and compile decision table logic.

Here is a direct link to the LogicGem section of our website:

http://go.catalyst.com/logicgem4

With appreciation,

Cary Harwin
President/CEO

Todd Suzuki 08/04/06 03:42:03 PM EDT

Thanks for all the Positive feedback. Any questions comments are appreciated.

Regards,
Todd Suzuki(Author of Article)

SYS-CON Italy News Desk 08/03/06 02:51:18 PM EDT

We've all had days when QA made things difficult. When we take a closer look at what caused it we usually find that there was some miscommunication between QA and the programmers. And this miscommunication was most likely caused by the business having unrealistic expectations of the development team or the business/programmers not understanding the best way to utilize QA. So where does QA fit?

PBDJ News Desk 07/26/06 02:47:41 PM EDT

We've all had days when QA made things difficult. When we take a closer look at what caused it we usually find that there was some miscommunication between QA and the programmers. And this miscommunication was most likely caused by the business having unrealistic expectations of the development team or the business/programmers not understanding the best way to utilize QA. So where does QA fit?