This slide is to get a general understanding of Peer Developer Testing as per my experience and learnt during project execution. Any team can implement this and its practically possible and beneficial for Agile Development.
2. 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.
• 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.
3. When is it needed?
• Budget constraints
• Technology complexities
• Need to reduce the development-testing-feedback-release life
cycle of the software project
4. 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.
5. 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.
6. Budget Constraints Continued…
• 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
7. 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.
8. 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.
9. 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.
10. What is the workflow? Continued…
• 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.
11. What is the workflow? Continued…
• 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.
13. 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.
14. Benefits
• Involvement of one more developer who is not the actual coder of the
user story or the task facilitates:
a) At any point of time, two team members know the functionality.
b) 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.
c) 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.
d) 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.
e) Early bugs detection and more quality code delivered to UAT.
f) Less/No pressure on the development team as the code is delivered with
confidence and two phase testing.
15. 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.
16. 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.
17. Use case 1 Continued…
• 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.
18. Use case 1 Continued…
• 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.
19. Use case 1 Continued…
• 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.
20. Use case 1 Continued…
• 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.
21. 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.
22. Use case 2 Continued…
• 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.
23. Use case 2 Continued…
• 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.
24. Use case 2 Continued…
• 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.
25. Use case 2 Continued…
• 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.
26. 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.
27. Use case 3 Continued…
• 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.
28. Use case 3 Continued…
• 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.
29. 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.
