Introduction to Software Testing with Extreme Programming Approach
During last couple of years many agile or iterative software development models have evolved. One famous type of agile models is eXtreme Programming model; in short it is called XP. XP approach emphasizes on the development of the tests for the product in the beginning itself. In XP the entire development remains test-driven. Every smallest bit of code written by the programmers is tested prior to moving on further. XP doesn’t expect detailed requirements documentation to begin with.
The product development takes place quickly through a small-team comprising of around 3-7 people. The programmers enjoy freedom to come out with their designs almost independently. XP empowers programmers to easily respond to the fast changing requirements from the customer.
Small sized teams develop the entire product with innovative features incrementally by the introduction of new technologies & concepts all along. Since developers enjoy great freedom for innovation, they frequently synchronize their ideas, thus resulting in excellent functioning of all components of the product. In XP the customer, managers, programmers & testers act as partners of a cohesive & collaborative team.
The team organizes itself around any problem with a collective aim of solving it in a most efficient manner.Software testing is extremely important in iterative development as compared to in sequential development. The reason being the product is continuously evolving & rigorous regression testing is done for every iteration. XP involves iterative process expecting frequent re-prioritizing, re-estimating & re-scheduling of activities.
Quality assurance is believed to be a most important aspect of XP. QA can be performed by a separate group, or it can be integrated into the development team itself. In either case, XP promotes the idea that the developers have a high degree of contact with the QA group; this is very much in line with the XP philosophy of closer communications between the stakeholders in a project.
A typical model of planning & feedback loop for XP as described in Wikipedia is shown below.
Advantages of deploying XP in Testing:
# XP lays strong focus on customer satisfaction.
# XP encourages early and frequent testing.
# XP looks to make the process as efficient and effective as possible by promoting the use of test automation.
# XP demands that all code have associated tests, and that where code is changed that the tests be re-executed.
# XP requires test design to be completed before coding has started, with all code having associated unit tests.
Different Types of Test in XP:
In XP we have just two types of tests like the following;
1) Unit tests: These are written by the developers to test their code. These are white box tests, which rely on the knowledge of the code and its purpose. After every change, may be bigger or smaller, the unit tests help in verifying that the change in the structure of the code had not introduced any change in the functionality. Generally when new functionality is added, there is a need for changing the unit tests to take care of the new functionality.
2) Acceptance tests: These are written with the help of the customer and the user stories, to validate some expected result from the system. These are black box tests, which are created using the user stories as well as direct user input where available. Generally customer owns the responsibility to verify the correctness of the set of acceptance tests. Customers review the test score for taking a decision as to which of the failed acceptance tests are of greater priority.
Test Automation in XP:
The use of test automation in XP is promoted to help save time, effort, and cost of testing. In addition to finding defects and verifying requirements, the testing tool can be used at both unit and acceptance testing.
XP Rules & Practices prescribed by experts:
XP operates on the foundation of set of following five underlying rules, designed to define various expectations out of team members. These rules help in development of a congenial environment conducive to promote empowerment & team collaboration. These set of rules are not a binding & can be bent to suit the specific requirement of your company.
In this article we are describing first four rules in a brief. However the last rule related to testing is being narrated in greater detail.
Rule – 1 For Planning:
# Writing of user stories
# Planning & creating a release schedule
# Doing small releases frequently
# Dividing the project into many iterations
# Beginning every iteration after planning
Rule – 2 For Managing:
# Providing freehand / open work space to the team
# Deciding an achievable pace
# Scheduling a short stand up meeting every day
# Measuring the work done on the Project
# Cross Training & rotating the people
# Fixing the process in case of problems
Rule – 3 For Designing:
# Keeping the design simple so that it works next time
# Selecting a simple system metaphor / naming conventions
# Creating effective solutions to technical design problems that seem to be risky, to reduce the risk at a later stage
# Adding functionality later for better speed
# Refactoring the old designs for better quality & time saving. It refers to adding flexibility wherever required & removing complexity where not helpful & combining the duplicated code.
Rule – 4 For Coding:
# The customer remains readily available to extend help to the development team
# Writing simple code that is easy and consistent & formatted to mutually agreed coding standards
# Writing the unit tests first, before writing the code
# Releasing the entire code for production that shall be pair programmed i.e. written by two programmers using the same computer
# Integrating the source code in parallel by the pair of people at the same time
# Integrating the code in the code repository by the programmers very frequently may be after every few hours itself
# Allocating one computer for integration & sequential release
# Ensuring that everyone remains accountable & bears the ownership towards project collectively
Rule – 5 For Testing:
# Creating a unit test framework first, then testing each & every class of the system
# Before releasing the product entire code must pass the decided unit tests
# When a bug is detected regression tests are created to ensure that it does not repeat
# Acceptance tests are created & executed before any debugging and their results are released to the team
Testing Related Rules for XP:
Following rules & practices are prescribed for the testing as a part of XP approach.
A) All code must have unit tests:
All classes in the software under development must have associated tests that are released into the code base alongside the code they test. Code that is found without a corresponding test cannot be released, and the unit test must be created as soon as possible to test the software.
All code must pass unit tests before the code can be released. A unit test framework like JUnit is an essential tool that should be used throughout the development and testing process to help test, as well as be used to formalize requirements, refine architecture, write, debug, integrate, release, and optimize code. It is possible to write your own unit test framework, but this must be balanced against the productivity gains that reusing a commercial or shareware product can deliver.
In XP, unit tests support the concept of collective code ownership; the unit tests act as a gatekeeper against accidental and deleterious changes to your code functionality. Since all code must pass unit tests before it can be released, there is good confidence that the code satisfies its required functionality, irrespective of who has worked on it.
In principal, this is an excellent agile best practice; implemented properly, it means that all code that resides in the code base has been validated by specific tests written against the specification / requirements / user story for that code. If only this were true for all components found in more traditional software development projects, there would be much higher confidence in the quality of the software components, with a corresponding simplification in the execution of the later testing phases.
B) Tests must be designed before coding begins:
This is an excellent best practice that ensures that the developers review the requirements for the software, understand them sufficiently well to have a clear idea of how they will be tested, and then design and implement the unit tests.
It is claimed that the overall time taken to create the unit test and write code is equivalent to the time taken to just code the software from scratch – plus you have a set of tests ready to run against the code – saving additional time and effort.
As a final thought, it is almost a development and testing clich� that coding always overruns and eats into the time planned for testing; create the tests before coding begins and you have a much higher chance of ensuring that proper testing will take place.
C) When a bug is found, tests are created:
In the event that a defect is found in production, tests are created to ensure that, once fixed, the defect remains fixed; the tests can be reused to ensure the defect does not reappear at a later point in the development process.
Working with the customer and the appropriate user story to develop an acceptance test, the programmer gains a better understanding of the nature of the defect as well as of the correct behavior the code should exhibit.
In the event that an acceptance test has failed, the programmer creates a unit test to show the defect from the source-code perspective; once the unit tests are all executed successfully, the corresponding acceptance test is rerun to ensure the defect has been fixed properly.
D) Acceptance tests are based on the user stories:
The software testing engineers create the acceptance tests out of user stories, the tests are run frequently, and the result is published – the acceptance tests are based on the user stories created in conjunction with the customer representative.
In iteration planning discussions for every iteration, a number of user stories are selected as the basis of the acceptance tests. A particular user story may result in one or more acceptance tests (the number being determined by what is needed to show the system performs as expected); every acceptance test is a reflection of the results out of the system.
The customer is responsible for reviewing the acceptance tests to ensure they are correct. The customer is also responsible for reviewing the test results and test scores for identifying which failures of the system are most important and specifying the priority for remedial work, with the developers scheduling the time at each iteration to correct any failed tests.
Any particular user story is treated to be incomplete until its all sets of acceptance tests have been cleared.
Best troubleshooting practices prescribed by XP Experts:
1) Automate the acceptance tests, in case of problem of large number of bugs during production.
2) Automate the unit tests, in case of problems during integration.
3) Enforce collective ownership of code in case of problem related to two programmers wherein they happen to have common ownership of some core classes of the system & need changes to be done.
A Noble Advise:
Though XP is a brilliant approach especially for projects that are risk prone; however we should not get overwhelmed with the eye catching concept. Believe it or not � XP doesn�t remain to be the only best solution for anything & everything in software development. Fact remains that while it has many pros it has several cons as well, that I will present in my next article on XP.