The first part of the series, Approaches to Agile Testing- Part 1- An Introduction, Introduced the concepts of Agile development Methodologies and Agile Testing. In the second part of the series on Agile Testing, we look at a derivate approach, Extreme Programming.



In Extreme Programming, instead of designing whole of the system at the start of the project, the preliminary design work is reduced to solving the simple tasks that have already been identified.



The developers communicate directly with customers and other developers to understand the initial requirements. They start with a very simple task and then get feedback by testing their software as soon as it is developed. The system is delivered to the customers as soon as possible, and the requirements are refined or added based on customer feedback. In this way, requirements evolve over a period of time, and developers are able to respond quickly to changes.



The real design effort occurs when the developers write the code to fulfill the specific engineering task. The engineering task is a part of a greater user story (which is similar to a use case). The user story concerns itself with how the overall system solves a particular problem. It represents a part of the functionality of the overall system. A group of user stories is capable of describing the system as a whole. The developers refactor the previous code iteration to establish the design needed to implement the functionality.



During the Extreme Programming development life cycle, developers usually work in pairs. One developer writes the code for a particular feature, and the second developer reviews the code to ensure that it uses simple solutions and adheres to best design principles and coding practices.



Test-driven development, which is one of the core practices in Extreme Programming, is discussed in greater detail later (see below).



When to Use Extreme Programming



Extreme Programming is useful in the following situations:



1. When the customer does not have a clear understanding of the details of the new system. The developers interact continuously with the customer, delivering small pieces of the application to the customer for feedback, and taking corrective action as necessary.



2. When the technology used to develop the system is new compared to other technologies. Frequent test cycles in Extreme Programming mitigate the risk of incompatibility with other existing systems.



3. When you can afford to create automated unit and functional tests. In some situations, you may need to change the system design so that each module can be tested in isolation using automated unit tests.



4. When the team size is not very large (usually 2 to 12 people). Extreme Programming is successful in part because it requires close team interaction and working in pairs. A large team would have difficulty in communicating efficiently at a fast pace. However, large teams have used Extreme Programming successfully.



Visit Clevertester for more information about Beta Testing News, Quality Assurance News and Software Testing

To add a comment please login by clicking here