What is Peer Dev Testing?

• An ideology loosely based on “Pair Programming”.
• “Pair Programming” is an agile software development technique in which two programmers work together at one work station. One developer is called Driver, writes code, the other one is called Navigator, reviews code as it is typed in.[Referenced from Wikipedia]
• Peer Dev Testing augments the testing efforts of your project in addition to the QA/Business testing for better project execution life cycle and for faster bug-free releases.

When is it needed?

• Budget constraints
• Technology complexities
• Need to reduce the development-testing-feedback-release life cycle of the software project

More about this…

• As a developer of the particular user story / bug he/she may not be willing to think out of box and always thinks according to what he/she has coded. So, someone who did not write the code is the best person to test the user story / bug along with the primary developer (Primary developer still tests before handing it to peer developer).
• Simple UI or text changes need not attract much efforts as it can be easily tested out. We can create automated UI tests for testing this. No need of peer testing.
• If a task requires more than a week development ( Analysis + Technical Design + Coding and self testing) or cannot be automated, then it needs a special attention and in this scenario, we would invite a peer developer (basically assign the user story to that developer for testing by lead/manager) to test the functionality developed by the primary developer.

Budget Constraints

• If your organization ends up with budget constraints for your project, where the manager/lead of the project has to make a decision whether to reduce development team so as to keep QA team or saving development team by willing to release QA team.
• Example scenario: A project has 6 developer and 3 testers. The company thought of reducing the budget spent on the current project and tells the project manager that he would be paid only for 6 resources. Now manager has two options:
  • Can reduce the number of developers in his team to 4 and keep 2 testers.
  • Can keep 5 developers and one tester.
• Manager’s decision depends upon the current phase of the project. If there is more development effort needed for the completion of the project and is willing to sacrifice the external testing efforts, he would stick with the second option i.e., keeping more or all developers in his team and one or zero testing team members.
• The benefit of this approach is development will be continued approximately with the current pace, with the only downside is reduced or no QA team to validate the outcomes regularly.
• This scenario mandates the need for peer dev testing.

* External – Outside development team

Technology constraints

• If the project is not a typical commercial project and is more technology oriented, then the project cannot be tested by external QA team.
• Only the development team has the full understanding of the project and the changes cannot be validated by manual testers or automated testing tools.
• This scenario also mandates Peer Dev Testing.
• Example Scenarios: A middleware project that involves creating messaging queues in RabbitMQ, PowerShell script to provision multiple VMs in cloud and other dynamic requirements which needs specialized skillset which takes time for testing teams to understand and learn.

Reduce the release life cycle

• If a project is taking more time to release to production or more bugs found in UAT and developers are pressurized to adhere the release life cycle, manager may decide to increase stringent testing before releasing to UAT.
• This requires more involvement of developers to test their code before deploying to QA/UAT environment for testing and approvals.
• It would be more difficult to accommodate changes at UAT phase rather than identifying and fixing bugs or scope creeps earlier during development phase. It adds more pressure on the development team to fix bugs during UAT phase.

What is the workflow for Peer Dev Testing?

• Developer is assigned a task by the Lead / Manager.
• Developer writes technical specification document or high-level / low-level design documents. Gets the approval for the specification/design document from lead and/or other expert in the project.
• Developer writes code and adds unit tests for the code coverage.
• Tests his code and fixes if there are any bugs found.
• Does code review with the lead and another team member who has expertise on the module or the feature worked, if it is already existing. Otherwise, a person who can help validate the coding.
• Gets code approval or suggestions for the changes. If there are suggestions provided, developer works on it and again send another code review request till the code is approved.
• Once code is approved, deploys the code in the test environment. Writes test cases detailing the testing procedure.
• Either lead or the other developer who has been involved in technical specification document review and the code review phases, will validate the functionality deployed in test environment by going through the test cases and the technical design documents and provides feed back to the developer.
• Based on the feedback, developer acts on the next step to be completed i.e. Code merge to main branch or release branch.
• Once the product is deployed in QA and/or UAT environments, QA and Business validates the functionality, performs regression testing to check the affected areas and gives approval/feedback to the developer.
• Based on the feedback/approval, development team either proceeds to move the change to Production environment or roll-backs the change.
• The extra validation by the another developer helps in second hand or extra level verification.

 

Figure 1 – Typical work flow

What is needed for the implementation?

• Developers need to have open mind to take the feedback positively by other developer/lead.
• Another developer who tests the functionality should be truly willing to help the coder in validating the functionality rather than just as a formality.
• Bugs found by the peer testing should not be highlighted to the team or management as it would discourage the open culture and team cannot move forward with this approach.
• Manager/Lead should motivate the developers by rewarding the developers. As per PMP guidelines, rewarding the team member is one of the requirements for successful project execution.

Benefits

Involvement of one more developer who is not the actual coder of the user story or the task facilitates:

1. At any point of time, two team members know the functionality.
2. If coder has to take time off and if it is a critical functionality, the other developer can step in and finish off the task with in the timelines.
3. Since the other developer understands the functionality, he/she could test better, thinking out of box as the original developer always thinks and tests from his perspective.
4. Early creation of test cases from developer’s end before actual testing begins in UAT. This provides chance for reviewing and modifying the tests in case additional steps or scenarios are required to complete the tests.
5. Early bugs detection and more quality code delivered to UAT.
6. Less/No pressure on the development team as the code is delivered with confidence and two phase testing.

Downsides 

• Truly speaking, there are no downsides of this approach except one additional resource spends extra time for other task that he is not a primary developer. But, the time he will spend may not be costly comparing to the cost of fixing scope creeps or bugs in UAT phase.
• Other downside is the primary developer feels in-secured if open culture is not provided in the team and finds fault with the code.

Lets review some hypothetical use cases.

Use Case 1: Budget constraints

• A team has 4 developers and 2 testers. Client has cut the budget and manager chooses to retain developers and let the testers move for some other project.
• Technologies used: ASP.NET MVC, C#, SQL Server 2014, SSRS
  • Manager calls lead and informs him/her about the decision.
  • They discuss on how to mitigate the risk for losing testers.
  • They discuss on the strategy to motivate the developers to perform both as a dev and a tester.
  • Developer 1 works on UI and Developer 2 works on C# backend code, Developer 3 creates reports using SSRS and Developer 4 does the database programming.
  • Dev 1 creates input forms that requests/sends data backend through C# resource/domain models. Developer 2 writes code in C# code to perform CRUD operations and develops business logic. Developer 3 develops SSRS reports that needs to be displayed in different formats when user clicks a button in the UI. Developer 4 writes stored procedures to perform CRUD operations.
  • Once developers have completed their tasks, code is deployed in the test environment.
  • Dev 2 understands the CRUD operations and business logic developed in C# better, so he tests the UI operations by putting debugger in his code and checks if right data is getting passed to the methods and right data is getting populated in UI.
  • Dev 1 tests the reports generated in different formats and validates if UI is rendering correctly in each format.
  • Dev 3 validates the stored procedures coded by Dev 4 by inputting test data and checking the output of the procedure.
  • Dev 4 validates what data is being sent by the backend code to the database and checks if the data is correctly inserted in to the table. Checks for duplicates and any data truncations happening because of the input form is allowing more characters than the column length in the table.
  • They present their validations to the lead and discuss the issues and gets to work on the fixes if any. Otherwise, deploys the code to UAT and gets the business approval.
  • Lead makes sure that code is reviewed properly and coordinates healthy environment in order to exchange information between developers and motivates them to work on each other’s findings.
  • In order to keep this going, Project manager steps in and nominates the developer whose code is bug free after testing in a month as the “Developer of the Month”, who gets the spot award of $50 from the management and also his/her details published in the intranet website.
  • Tester who finds more bugs and participates proactively is rewarded as the “Proactive team member of the Month”, who gets $50 from the management and also his/her details published in the intranet website.

Use Case 2: Gifting project to new team

• A company wants to end the offshore contract and wants to take the project onsite. Since the team has followed Agile methodologies, they did not concentrate much on detailed documentation. New team is formed at onsite with one architect, a senior developer and two junior developers.
• Architect works with senior developer in understanding the existing project and defining the strategy to move forward. After they gets the grip on the project, involves the junior developers to work on the project by mentoring them for each task at the beginning of the project.
• Junior developers gets vexed up with the project as they are introducing lot of bugs in the code and faces lot of pressure on them in fixing the bugs. So within few weeks, leaves the project.
• Then the company conducts interviews and on boards new developers. But same thing repeats with the new ones.
• Then management sits with the architect and the senior developer in understanding the situation and identifies the root cause of the issue i.e. junior developers are finding difficult to understand the code and so adding more bugs.
• They agrees to the proposal by the architect that whoever joins the team has to test the project by performing white-box testing. That is to put the debugger in the code and tests the functionality developed by senior developer for two months.
• They adds a testing team in the meantime but the project does not have UI and is a Web API with complex rules implemented, testing team will not handle all the scenarios. This strengthens their decision to add a new developer to the team and ask him to work on testing 80% with development 20%.
• Also team develops test harness tools to test their functionality without depending upon the testing team.
• A new developer joins the team and performs testing of the functionalities for two months and gets a clear understanding of the consumers for the service, interfaces and other dependencies, models added in the project code. After 2 months, another developer joins the team with the same task of testing for 2 months.
• This strengthens the team efforts in retaining developers in the team and reducing the number of bugs added in the new code.
• In parallel, they stabilizes their test harness tool to test new functionalities by adding more delegates as inputs and the new testing classes add their own implementations which makes their tool more like a plug and play.
• Management appreciates the efforts made by the architect and the senior developer and recognizes their efforts and standardizes some of the best practices across the organization.
• This initiative adds a new job title “DEV TESTER” in the organization.

Use Case 3:Technology constraints

• A company wants to add more middle level infrastructure in order to facilitate asynchronous communication between the systems developed in different languages. So, they wants to add RabbitMQ as a messaging system and MuleSoft product for developing micro-services and Enterprise Service Bus applications.
• At the same time, the company plans to move to Amazon cloud in 5 years in order to compete with the competitors.
• Adds few consultants from each area to start with and creates a base infrastructure. Then adds few developers to start development. But the dynamicity of the project starts increasing and the testing team will not be able to test all the changes.
• Though a system A publishes a message to the messaging queue, system B never gets the messages. Testing team logs the bug but they have no capability to validate the messaging queues.
• Though some systems moved to cloud, testing tools are not able to validate the provisioning of the VMs and PaaS instances, as it has to be validated by DevOps.
• On the other side the communication between the systems adds lot of complexities which forces the testing team to learn Python, GroovyScript and other languages in order to write their test scripts.
• Management identifies that the testing efforts for this project is not possible with testing team and comes up with the strategy that development team and DevOps team has to test their own implementations. So, the team splits up their tasks of implementation and testing among themselves in order to test their implementations instead of relying on testing team.
• Each team member implements his task and at the same time tests or validates other team member’s implementation. Exchanges their validations/suggestions and builds a more reliable architecture for their implementations.

Use case 4:Bugs found during UAT

• A project team faces a challenge of having bugs at UAT phase and gets notified to top level management. Then project manager gets called and asked to take some action.
• Project Manager discusses the problem with the Process Improvement team in the organization and Process Improvement team suggests early bug detection before committing the code and introduces the concept of developers testing each others’ code before releasing to QA/Business teams.
• Project Manager calls his team and informs his decision to involve two developers for each task. One will be the coder and other is the validator of the code and the functionality.
• Development team implements the new methodology and finds bugs before code check-ins and releases almost bug free code to UAT thus reducing the number of bugs introduced in the UAT phase.

 

You can watch and download the slides for the same at slideshare.

If you have come across any scenarios similar to this, please share. I will attribute/credit your shared scenarios in my article.