Extreme Programming: Testing and Pair Programming

Testing in XP

• XP employs a testing approach done after every change.
• Testing features include test-first development, incremental test development from scenarios, user involvement is key to and the use of automated testing frameworks.
• Tests are written before the code, which helps clarify implementation requirements.
• Tests are written as programs to allow for automatic execution.
• Tests include a check to ensure correct execution.
• A testing framework like Junit is generally used.
• All previous and new tests are run automatically with new functionality to look for newly introduced errors.
• Customers develop acceptance tests for stories in the next system release.
• Stakeholders write tests alongside developers, which is used to validate the code.
• Test 4 for Dose Checking includes inputs such as single dose of the drug in mg and number of single doses per day and outputs such as OK or error message

Pair Programming

• Programmers work in pairs together to develop code which can help develop common code ownership.
• It spreads knowledge across the team and serves as an informal review process.
• Refactoring is encouranged, so the team can benefit from it.
• Development productivity is similar to that of two people working independently.
• People sit together at the same workstation to develop the software.
• Pairs are created dynamically so everyone works with everyone during the development.
• The sharing of knowledge is very important, to reduce the risk of losing that knowledge when a team member leaves.
• A pair working together can be more efficient than if they are working separately.
• Collective ownership and responsibility for the system is supported.
• Individuals aren't held accountable for the code, the team is.
• Functions as an informal review process because each line of code is looked at by at least two people.
• Supports refactoring because where pair programming and collective ownership are used, others benefit immediately from the refactoring.

Scrum Approach

• Managers must manage the project, so the software is delivered on time and within budget.
• The standard approach to project management is plan driven.
• Managers create a plan for deliverables, delivery dates, and team members working on those deliverables.
• Agile project management requires a different approach that's adapted to incremental development and fits the strengths of agile methodologies.
• Scrum focuses on managing iterative development, as opposed to emphasizing specific agile practices.
• 3 Scrum phases:
• The initial phase, involving outline planning, aims to establish the project’s general objectives and the design of the software architecture.
• Sprint cycles, where each cycle develops an increment of the system.
• The project closure phase, wrapping the project up, completes necessary documentation, assesses lessons learned.
• Sprints usually last 2-4 weeks, and correspond to the development of a release of the system in XP.
• Planning starts with the product backlog which is a list of the work.
• The entire project team collaborates with the customer during the selection phase to choose features and functionality for sprint development.
• Agreed upon features allow the team organize themselves to develop the software.
• 'Scrum master' communication goes through them as the stage isolates the team from the customer and the organization.
• The Scrum master protects the development team from external interference.
• Work done during a sprint is reviewed and presented to stakeholders, and the next sprint cycle begins.
• Scrum master facilitates arranging & running daily meetings, tracks the backlog of work to be done, records all decisions, measures progress against the backlog.
• This role also communicates with customers and management outside the team.
• The team gathers for short periods to discuss progress since the last meeting and arising problems.
• With problems, teams re-plan short-term work to cope with them.
• The product is broken down into set of pieces that are manageable and understandable
• Unstable requirements do not hold up progress.
• Customers see on-time increments that are delivered, and gain feedback on how the product works.
• Trust is established between everyone, and a positive culture is created expecting the project to succeed.