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.