“Unusual” Pair Programming (Developer and QA Pair Programming)

Problem Statement
A common Software Development Life Cycle goes something like this:
Requirements Clarification -->Design -->Coding -->Testing -->Delivery

During this cycle, if we observe carefully, at a time, only one person – requirements analyst, designer, developer or QA/Tester – is responsible, for specific duration, to ensure the progress of the project for that particular stage. During this stage, all others are happily ready to raise their hands to avoid the responsibility of the on-time quality delivery of the product. E.g. during coding stage, testers always point to developers that developer is yet to complete his/her job after which we can start our work. Same way in case of testing phase, developers do run away from the responsibility of on-time deliveries by making QA people responsible for same (It’s a different story that QA quickly find defects into the product and send it back to developers to fix :-) ).

Some of the disadvantages of this methodology are as follows:
- Developer and QA rarely work together to come up with a quality delivery (although they pretend to do so). Most of the times they are busy blaming others for the problem.
- Two distinguished teams within a project team cannot have great overall team spirit which makes Project Manager’s life very difficult.
- Product moves between Defect Fixing à Testing à Defect Fixing cycle multiple times before final release. During each cycle, defects are identified, noted in defects logging system and are assigned to developers. Depending on project and code size, defects logging and maintenance can consume considerable amount of time. Moreover most of the times, the log of defects previously found but now fixed is no longer required in which case spending good amount of time in defect logging only for sake of communication between two distinguished teams is surely a wastage of time.

Pair Programming
Extreme Programming methodology introduces Pair Programming where two developers work together on one machine. While one developer (Driver) is writing code, other one (Observer or Navigator) observes/reviews the code. Both interchange the roles frequently and thus both concentrate on code being written.

Benefits of Pair Programming are better code quality, shorter programs, fewer bugs, learning and training while working, decreased management risk. Of course like every good process, Pair Programming also has some short-falls – e.g. some developers prefer to work alone, intimidation, egos and potential conflict etc. However even after such cons, Pair Programming gives higher productivity. Studies have shown that after training for the "people skills" involved, two programmers are more than twice as productive as one for a given task.

Developer and QA Pair Programming
I would prefer to enhance the concept of Pair Programming further, however with a pairing of developer and QA instead of two developers. Developers and QA being of different nature (in fact of totally opposite nature, can we apply nature’s rule – “negatives attract each other”?), they can come up with much better output.

Various benefits of this methodology that I can foresee are as follows:
- While developer is concentrating on coding, QA person can figure out all various possible scenarios which need to be handled. QA can make the developer aware of such scenarios which can then be taken care of immediately. In case of normal SDLC, all such scenarios which QA identifies, but developer wont, are nothing but the defects due to which application floats between developer and QA for multiple times.
- Developer and QA both are responsible for the quality delivery of the product throughout the life cycle (unlike SDLC where at a time only one person/group is responsible). Because of joint responsibility, there are more chances that Developer and QA work together towards ultimate aim of quality delivery rather than pulling others legs.
- As there are no sub-teams within a team, team spirit is on higher side.

One of the risks involved here could be that as both developer and QA together are involved right from beginning and so are working together rather than as two separate teams, there are chances of mutual alliances where both together may compromise on quality. This can be avoided by making slight change in the process. Developer and QA can work together as a one team during coding phase. During this phase, it’s their joint responsibility to produce quality output. It’s up to them to internally manage the defect log which they together can identify. There won’t be any need to log these defects in any Defects Logging System (after all who cares about such defects once they are fixed?). Once both of them mutually agree that code is now ready for check-in and thus merge in to main code branch, they can check-in the code. Once the code comes in the main branch, from this point onwards, developer and QA should separate. Ideally in this case, some other QA should be assigned the task to verify the quality of the task to ensure that the original Developer – QA pair has not missed any defect. All defects found by this new QA should be assigned back to the original pair of developer and QA so that both together can take care of such defects.

Hopefully, the pairing of Developer and QA should result in lesser defect skipped from coding phase to testing phase. Of course, there is no need to restrict this pairing only to SDLC. It can be equality effectively used with other methodologies like iterative, agile, extreme programming where the concept of developer and QA are bit different.