Agile Software Development

Testing in Agile software development approach is quite different from the traditional testing methodologies as it requires testing at every phase of the development and not only by the Quality Assurance team but by developers and business analysts as well.

This is because 1) Agile software development requires testing throughout the lifecycle of the project and 2) Developers and Business Analysts are under the system and the business better, respectively.

According to Ambler, the basic strategy of testing in Agile software development is testing throughout the lifecycle and therefore can be divided into following four phases:

1)     Initiation – This is often short and includes indentifying initial acceptance tests, setting up the testing environment and identifying a testing team for the project. The benefit of this test phase is to set-up testing groundwork, possibly install the tools that will be needed for testing as well.

2)     Construction – This may comprise of any number of iterations depending on how the scope and management of the project. A significant amount of testing occurs during this phase. Concepts such as ‘confirmatory’ and ‘investigative’ testing is employed here by the agile developers who test often, test early and usually test first. Confirmatory and Investigative testing, as described by Ambler, are briefly defined below:

a.     Confirmatory Testing – This focuses on verifying that the system fulfills the intent of the stakeholders as described to the team to date. Two aspects of confirmatory testing, as presented by Ambler, are:

i.    Agile Acceptance Testing – is a mix of traditional functional testing and traditional acceptance testing because the development team and their stakeholders are doing it collaboratively. Developer testing is a mix of traditional unit testing and traditional class/component/service integration testing.

ii.    Developer Testing – strives to verify the application code and the database schema and to look for coding errors, perform at least coverage if not full path testing, and to ensure that the system meets the current intent of its stakeholders.

It is often done in a test-first manner, where a single test is written and then sufficient production code is written to fulfill that test. (Ambler, Agile Testing Strategies)

b.    Investigative Testing – This strives to discover problems that the development team didn’t consider.

Agile teams produce working software at the end of each construction iteration and hence a new version of the system should ideally be given to a separate test team that which can be assigned the goal to explore potential scenarios that neither the development team nor business stakeholders may have considered. (Ambler, Agile Testing Strategies)

3)     Release – At this stage, the project is ready to be delivered to the user and is tested from user acceptance point of view at this stage.

4)     Production – Once the system has been delivered, defects may arise and Agile testing ensures that these defects are fixed in a timely and appropriate manner.

Testing Tools
It is not necessary to use a tool, solely designed for testing in an Agile development methodology. Automated testing holds a key place in agile development because of the sheer amount of testing that is required throughout the lifecycle.

Some tools that have been used by agile development and testing teams include JUnit for Unit testing, Fit and Fitnesse for acceptance testing, Autoit and Selenium for functional testing etc.

Microsoft Visual Studio is the first IDE that introduced integrated unit testing tool (Ingles)

Test Documents
Agile software development encourage going as light as possible, hence the need for singular reference points and avoidance of multiple documents and redundant information as is the norm in traditional approaches. (Ambler, Single Source Information – An Agile Practice for Effective Documentation)

The main documentation work required in Agile software development is:

1)     Test plan to ensure comprehensive coverage of the software and guarantee quality (Black)

2)     Traceability Matrices – these matrices are used in testing phases to link functionality and test cases to specific requirements.

Risks involved

There are however certain risks involved in Agile development as suggested by some researchers. Some of these have been quoted below (Agile Software Development):

·         Lack of structure and necessary documentation

·         Incorporates insufficient software design

Requires too much cultural change to adopt
Can lead to more difficult contractual negotiations

Can be very inefficient — if the requirements for one area of code change through various iterations, the same programming may need to be done several times over.

Whereas if a plan were there to be followed, a single area of code is expected to be written once.

Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements

Drastically increases the risk of scope creep due to the lack of detailed requirements documentation

Agile is feature driven, non-functional quality attributes are hard to be placed as user stories

Test Standards
The standards that have been introduced for agile software development include ISO/IEC 12207:1995 and its replacement ISO/IEC 15288:2002. Other standards that are also of interest to software development are ISO/IEC 15939:2002 (Software measurement process) and ISO/IEC 14143 (Software measurement – Functional size measurement). (W.H. MORKEL THEUNISSEN)

Bibliography
28 July 2008 <http://fit.c2.com/>.

28 July 2008 <http://www.junit.org/>.

28 July 2008 <http://fitnesse.org/>.

28 July 2008 <http://www.autoitscript.com/>.

28 July 2008 <http://selenium.openqa.org/>.

“Agile Software Development.” Wikipedia. 28 July 2008 <http://en.wikipedia.org/wiki/Agile_software_development#Criticism>.

Agile Software Development: Definition. 28 July 2008 <http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm>.

Ambler, Scott. Agile Testing Strategies. 28 July 2008 <http://www.ddj.com/development-tools/>.

—. “Single Source Information – An Agile Practice for Effective Documentation.” 28 July 2008 <http://www.agilemodeling.com/essays/singleSourceInformation.htm>.

Black, Rex. 28 July 2008 <http://media.techtarget.com/searchSoftwareQuality/downloads/Mging_the_Testing_ProcessCh2.pdf>.

Ingles, Paul. 28 July 2008 <http://www.oobaloo.co.uk/articles/2006/03/14/visual-studio-the-first-to-offer-integrated-unit-testing>.

W.H. MORKEL THEUNISSEN, DERRICK G. KOURIE AND BRUCE W. WATSON. “Standards and Agile Software Development.” 28 July 2008 <http://espresso.cs.up.ac.za/publications/mtheunissen_etal_saicsit2003.pdf>.