How to Build Effective Relationship Between Software Testing & Development Teams

How to Build Effective Relationship Between Software Testing & Development Teams

For delivering a high-quality software product, it is of utmost importance that healthy relationship is inculcated among the software testing & development teams through strong leadership in the organization. Project managers constantly strive to constructively manage conflicts & handle technical and organizational problem scientifically at individual as well as at different team levels.

Let us analyze different factors influencing successful relationship between software testing engineers & developers.

A) Attitudinal Difference in Developers vis-a-vis Testers
Developers are good at building codes. Once they have created what they feel to be a successfully functional piece of code, they tend to keep little interest in trying to unearth its possible defects. Developers are responsible for making the code work, and they tend to take it for granted that it will. Thus despite best intentions, a developer is bound to be less enthusiastic about finding problems with

the code he/she has written.Whereas, testers, get a sort of thrill in breaking the code coming their way. They possess an inherent knack for it. They live for bugs, relish them, and treat them like their bread & butter. Professional testers devise their own use cases – some of which will align with what the developer might have visualized others which will not. They enjoy exploring a multitude of “what if” questions that may lead to the discovery of more defects. Testers know what is state of the art in the test discipline and also have an understanding of the software. Unlike developers, they believe the code they�ve been given will not work and will strive to identify the maximum number of bugs. Bugs are their passion and their numbers are the indicators of their success, so they hunt for them relentlessly.

B) Organizational Balancing between Development & Testing
Software building organizations face great challenge in maintaining a right balance between the two groups of software testing & development, while ensuring that neither one is too strong or dominant.

Experts declare that when developing large, mission-critical software systems, a clear separation of development and software testing is required to provide objectivity and ensure that the important defects get removed. It is a generally accepted practice that SVT, and any other parts of the verification process that follow it, are positioned at the middle management level in the own organization. The true balancing is remains between the code development and the FVT teams.

C) Diplomacy of Relations among Testers & Developers
Even if there is a barricade between Function verification testing teams and the development teams, yet they tend to oversee each other & deliver the goods quite effectively while working together.

The function verification tester generally reviews the developer�s specification, design documentation, and code in order to create their test plan. At the same time he/she relies on the knowledge & expertise of the developer, to some extent. Simultaneously the function verification tester considers his/her own expertise on the issues and requirements at hand when defining and executing tests to find flaws in the flow and design of the code. These flaws can show themselves as unexpected results from scenarios that don�t match the design specifications, as an abnormal termination of an invoked process or function, or by any number of other symptoms.

The function verification testers define tests based on their judgement on the customer�s usage of a function. System verification testers can be considered the function�s first customer and with their knowledge of real customer environments, they will have a different perspective and different test scenarios.

D) Rapport building among Testers & Developers
Since all software has bugs, every tester will eventually get the satisfaction of finding a problem. When the tester identifies what he thinks is a defect in the design or code, he must then apprise the developer that something doesn�t seem quite right. Especially a new tester needs to approach the situation with a thick skin and a sense of diplomacy. Challenging a veteran developer for the first time can be a tough & memorable experience for a new tester.

As the tester discovers numerous and more complex defects, he becomes more confident in his ability to uncover the problems with the biggest impact on customers. Over a passage of time, testers develop a rapport with developers and, instead of a confrontation, they will engage in a discussion about a software defect and arrive at an amicable and comprehensive solution to problems. In the software development industry, managed conflict generally yields a superior quality product.

E) Establishing Technical Credibility an Effective Rapport Building Measure for Testers
Testers can build a valuable and respectful relationship with the development personnel by establishing their technical credibility. In many organizations, experienced designers and programmers who have vast experience of building complex software applications and have received positive feedback from their customers lead the development team. Such feedback acts like a golden feather in their cap & builds good reputation of the developer in addition to improving their confidence, and attitude – whereas testers sometimes struggle to achieve such a reputation. By enhancing their own technical credibility, testers can certainly be at par or even better than developers and can build a mutually beneficial relationship.

The answer to how as a tester you can build your technical credibility is twofold.
1) Get a broad view of how the software you are involved with works, both externally and internally.
2) Go deeply into every component of the software to understand it thoroughly.

Having achieved an in-depth knowledge of one area, you will discover that it is quite easy to branch out and extend your low-level knowledge in other areas of the software as well.

The combination of technical breadth and depth is a powerful one. An expansive understanding of the entire software package will give you perspective. It will enable you to draw inferences from system behaviors that a developer who is narrowly focused on a single component might miss. On the other hand, insight into one component will put you on par with its developers. You�ll speak their language, understand their issues, and be able to contribute in meaningful ways to problems they are trying to solve. Any developer would consider such a tester to be a valued partner. Together, these two dimensions create a multiplier effect on your technical credibility.

F) Other Dimensions to the Relationship among Developers & Testers
Although there are diverse opinions among IT community on permitting developers as testers of their own code; yet let us deliberate on this question:

Q. 1: Whether software developers should test their own code?

According to experts it is not a healthy practice for an individual to be solely responsible for testing his/her own code, especially while developing mission-critical software. Generally such software demand that it needs to be tested by unbiased software testing engineers having diversified focus against multiple objectives.

It is quite acceptable for the developers performing unit testing of their own piece of code. Verification of code at the unit test level benefits directly from the developer�s familiarity with it. The program�s design was based on a specific set of input, an expected set of output, and targeted functions. The developer is responsible to ensure that the program produces the desired results based on the input provided in a given environment. It is safe to assume that developers will attempt to address all of the use cases they visualize. The software developer holds a prime responsibility of getting a clean compile of the program and make it work.

Unit testing is first an individual effort and then an integrated effort with other developers to validate the initial creation or modification of a component or function. Some software developers believe that a clean compile of the program completes the unit testing. This approach falls short from a quality perspective. An explicit, individualized set of unit testing actions lets the developer confirm that the simplest mistakes are handled.

The integrated unit testing effort is targeted at uncovering the basic module-to-module integration failures. The consolidated knowledge of the group of developers performing the integrated test helps bring the first degree of objectivity to the entire assembly of the code. The diverse skills and personalities of the people integrating the code provide an improved level of review of the whole function or component.

Q. 2: Whether developers should perform the �Function Verification Tests� & �System Verification Tests�?

According to experts it is not a healthy practice to permit the developers to execute the function verification test & system verification test. Although developers will have best intentions, yet their objectivity is likely to get compromised as they review their own piece of code.

As per the developer�s perspective, the programs do exactly what they were created to do. The developer has built the code based on the use cases identified during the design phase, and it is quite natural for them to test only those paths that they know the code is designed to handle. There remains a great likelihood of the developer declaring the software as ready to ship after unit testing.

A seasoned tester may try things the developer possibly didn�t anticipate. Hence it is a good practice to draw a distinct demarcation between testing and development teams at the beginning of the function verification phase.

Few Tips for the Testers:

1) Develop your knowledge of behaviors and symptoms of all parts of the software under test.
2) Through repeated iterations, develop your knowledge of areas other than just your own specialty of testing.
3) Get mentoring and coaching from seasoned testers, to gain insight into components, different perspectives on how components operate, and knowledge of appropriate test approaches, techniques, and tools.
4) Teach your teammates what you know to generate insightful questions that will help you see things from a different angle and force further investigation on your part.
5) Carry out your own diagnosis of defects or problems as they arise to build your diagnostic skills to a level that many developers attain with great difficulty.
6) Continue debugging task, to engage developers in spending most of their time fixing defects rather than identifying them.
7) Be careful in reporting too many problems that could end up being branded as “user errors” or unimportant issues. These can have a dent on your hard-earned credibility.

Few Tips for the Developers:
1) Deeply focus on every aspect of a component or function, or on a set of modules or objects.
2) Know all the inputs, outputs, and functions, to deepen the technical skill in that particular area.

Few Tips for the Organizations:Organizations can come out with high-quality software product by promoting effective & healthy relationship between their software testing & development teams by;

1) Deploying veteran test leaders and role models having technical insight and the interpersonal, negotiation, and communication skills with responsibilities of educating and supporting people with less experience.
2) Use of the best practice of discouraging developers from being the sole testers of their own piece of code.
3) Involving testers right from the beginning of the design and development process to provide suggestions for ways & means of introducing testability into the product.
4) Encouraging testers to come together to form a software testing community that would share common issues, concerns, and best-of-breed tools and practices.
5) Forming a cross-organizational communication forum led by a senior & technically strong function verification tester who is respected by the test and development communities across the organization.
6) Positioning developers and testers in the same first-line department, enabling them to create schedules promoting cross-discipline interaction, resulting in more opportunities for continual improvement of skills, education and exchange of knowledge.

Many More Articles on Software Testing Approaches