Insights from Our Experts
Development and testing teams: hand-in-glove partners
It helps for a tester to have been in development. It makes it easier for he/her to be in the shoes of the people whose work he/she is testing. But it is not necessary though. Mindsets differ for testers and developers. The developer who codes away to glory is also expected to carry out unit testing of her own code as well as peer review other developers’ codes. This is perfectly ok by her as she does not perceive any ‘territory violation’ here. Nobody is stepping on no one else’s toes. But the developer’s concern starts when a third party comes in to carry out testing on the system to see how the application works. It stems from a natural dislike of being finger pointed and apprehensions over the intentions of the ‘policing’ tester.
But how right is the developer in thinking thus?
The key point to note in here by all members of any project is that testing, that is system testing done by professionals in the field, is hardly a policing act. It is the application that is being parsed for defects, not the developer of the code that built the application. The tester’s point of view is in sync with that of the users of the business. And that is seldom colored by knowledge of code and its syntax. It should not be.
Tester raises a bug. Developer disputes it contending that it is not a bug. Project Manager or coordinator steps in to mediate and sort out the conflict. With several such instances cropping up, the project could be bogged down by avoidable delays. How to avoid situations like this?
Tester encounters an unambiguously faulty design and raises a bug. Developer sends same for closure without trying to reproduce it.
Tester tests a few modules and finds himself suddenly crunched for time. The window of testing has now been shrunk, caused by delay in code delivery, volatile requirements or the DBA not coming up with environment in time. Tester realizes that he/she has left out half of the intended test cases untested. What risk does it pose to the delivery?
Well, all these point out to the need for developers and testers to work in close coordination… and this coordination better start early in the project. While maintaining an objective distance from each others’ work is essential for unbiased testing (socializing is ok!) the big picture of the application that they all are working towards should never be lost sight of. A tester ought to know the requirements of the entire application like the inside of his palm while a developer can afford to take a more parochial approach. He can confine his focus to a particular module, say. But the bottom line is that practitioners of both trades ought to know what each other are looking for.
In the first scenario if the developer or lead developer has included the tester in the walkthrough of his initial high level design document the latter would have had a better handle on the design. Potential bug situations could have been rightly envisaged at that point by the tester. Much rework and heartbreaks could have been avoided then and there.
In the second scenario again by participating earlier on in the project (requirements planning stage ideally and/ or in the high level design discussions) the tester would have gained the wisdom to know that the project will live with a certain faulty design as a ‘way of design’ as it is far less feasible to fix it, technically and economically.
The third scenario throws a bigger issue, that of risk management in testing. The delivery is at risk. It is in the ambit of the tester to probe the business analyst and understand the risks associated with each requirement. The development’s buy in has to be sought as well. Coding can be done keeping risk prioritization in mind. Testing, which invariably suffers the time crunch can be subsequently carried out such as to cover the high risk elements first. This way it is ensured that the critical components are covered and also that the smoke test does not fail before release to production.
Well, the above should clarify to some extent why testing is not policing and why developers need not feel threatened by ‘this QA person breathing down my neck’ and other perceived hostilities.