When was last time one heard that ‘we do not need testing or testers or automation’. Could have been a while. The importance of formal testing process emerging out of formal QA strategy has picked two to three decades ago after several disasters occurred in the software industry specifically with Y2K and the amount of time, money and effort spent on the same. Ever since then this stream has picked up. This blog is not about over emphasizing the importance of the testing or how (automation/manual) or when (Iterative/Waterfall) testing should be done, but is more about the partnership between development and test teams that had evolved since then in a product based or IT consulting company. While both streams realize the importance of each other in a subjective manner and purely due to an engineering hierarchy, this partnership is now the very backbone of any software engineering organization.

Lets imagine a world where development was all test driven and we simply called everyone an engineer. A set (A) of people have understood the requirements from a user and have written some code while another set (B) of people have written code to assert several assumptions about the code which were written after some discussions with Set (A). Set (A) has misunderstood or misinterpreted several requirements which percolated down to the unit test code written by Set (B). In addition, when components written by Set (A) where integrated, there were tons of issues as the Set (B) engineers did not identify a way to assert those integration scenarios. This example was to highlight the fact about different types of collaboration scenarios that initiate partnership between development and test teams. In addition, there was recent effort/discussions to write code which is 100% bug free there by obviating the need for more formal testing which is very ambitious and unrealistic. I really wish this was the case.

Lets also discuss the point where companies decide the ratio of a developer and a tester. This varies but is usually in the range of 3d:1t or 3d:2t depending upon the complexity of the code (SDET roles are not covered in this ratio). With this as a background, behavioral aspects take precedence for this discussion in the overall engineering cycle and deliverables thereon.

Triggers driving behavioral aspects

While the quality of the code is measured by the severity of the defects, the individual developer also starts to sense that he or she is being measured by the number of defects or the type of defects logged or assigned to him or her. This often results in argumentative discussions during the defect triage meetings which often are mediated by an experienced Program Manager or Project Manager in assigning appropriate severity such as (High, Medium or Low).

[Can we change this?]

Assign the severity for the defects using an organization standard judiciously and not assigning something because the tester thought so. There is always some level of discussion which is healthy and needs to happen which may uncover more data points for a different or similar issue. In the absence of a Project Manager, the senior test resource needs to objectively follow organization standards or use expert judgment without bumping up the severity

B)Unless following an agile mode where the preceding sprint is subjected to automation tests, most likely, the test design is done in parallel but actual testing happens in a very tightly planned schedule where there is a stretch from the test team which often leads to late working hours

[Can this be avoided?]

Yes. One can negotiate with the Project Manager to introduce absorb this into planned slack or obtain a buddy build from the development team which is provided much ahead of time to validate the test scenarios or write test automation code or record performance scenarios etc..

C)Not Reproducible defects (Won’t Fix) – The big killer

[Can you convince a tester about not doing this?]

Yes. Careful validation of the defect steps before tracking it in the defect database. This is usually a bad metric which reflects up on the testing effectiveness. Tools such as Test Lab from Microsoft or leveraging VM technology from any vendor should alleviate this problem. These obtain a snapshot of the point in time environment for reproducing at a later time. Make sure this does not happen in large numbers. 1 to 2% is still acceptable which leaves room for improvement

D)Last minute requirements resulting in incorrectly triaged bugs, bugs in automation code, irreproducible bugs which start to open up a new can of worms

[How both teams can avoid this or work towards this?]

A push back coming from both development and test teams and if need arise prioritizing the same as a joint effort and understanding the impact of each stream should there be addition of new set of requirements in an unplanned manner. There is a CR process in most of the organizations and of course there are exceptions always due to market needs and competition

E)Bandwidth of a Developer during deployments related to testing builds or custom debug builds required for code coverage or performance etc…

[Can you convince a developer to get this done?]

This is purely a relationship building experience between the development and test team. How one can influence to get a working debug build or a build specific to facilitate performance tests should need be, which is not a planned activity. A great deal of this depends on how the relationship is maintained and discussing the benefits out of this collectively

F)Dead Code resulting in incorrect metrics and fluctuating many related metrics

[Are you able to influence to clean this up?]

Once you have completed tool based code coverage and identified portions of code that never get used, the responsibility or onus is on both the streams. Cleaning up the code without causing additional bugs and testing the same to make sure existing functionality is not lost. It is also important to emphasize that this rudimentary code may cause the metrics such defects per kloc or defect density to depict incorrect numbers.

Now, m

apping these 5 points into different development-test models in the industry

To conclude, there are no set of standard practices that greatly improve the development-test working relationship. Certain simple and easy to implement win/win techniques by both disciplines shall pave way for a great product or service while leveraging the behavioral aspects of different individuals from different streams. To simplify the same, smooth communication is the key to sustain and improve the development-test relationship.