Monday, May 4, 2009

Understanding Agile Testing

Understanding Agile Testing

The concept of Agile testing rests on the values of the Agile Alliance Values, which states that:

 

"We have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

 

 

That is, while there is value in the items on the right, we value the items on the left more.
What is Agile testing?

 

1)    Agile testers treat the developers as their customer and follow the agile manifesto. The Context driven testing principles (explained in later part) act as a set of principles for the agile tester.

 

 

2)     Or it can be treated as the testing methodology followed by testing team when an entire project follows agile methodologies. If so what is the role of a tester in such a fast paced methodology?)

 

Traditional QA seems to be totally at loggerheads with the Agile manifesto in the following regard where:

 

·         Process and tools are a key part of QA and testing.

·         QA people seem to love documentation.

·         QA people want to see the written specification.

·         And where is testing without a PLAN?

 

 

So the question arises is there a role for QA in Agile projects?

 

There answer is maybe but the roles and tasks are different.

 

 

In the first definition of Agile testing we described it as one following the Context driven principles.

 

The context driven principles which are guidelines for the agile tester are:

 

1. The value of any practice depends on its context.

2. There are good practices in context, but there are no best practices.

3. People, working together, are the most important part of any project's context.

4. Projects unfold over time in ways that are often not predictable.

5. The product is a solution. If the problem isn't solved, the product doesn't work.

6. Good software testing is a challenging intellectual process.

7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

 

In the second definition we described Agile testing as a testing methodology adopted when an entire project follows Agile (development) Methodology. We shall have a look at the Agile development methodologies being practiced currently:

Agile Development Methodologies

 

·         Extreme Programming (XP)

·         Crystal

·         Adaptive Software Development (ASD)

·         Scrum

·         Feature Driven Development (FDD)

·         Dynamic Systems Development Method (DSDM)

·         Xbreed

 

In a fast paced environment such as in Agile development the question then arises as to what is the "Role" of testing?

 

Testing is as relevant in an Agile scenario if not more than a traditional software development scenario.

 

Testing is the Headlight of the agile project showing where the project is standing now and the direction it is headed.

Testing provides the required and relevant information to the teams to take informed and precise decisions.

The testers in agile frameworks get involved in much more than finding "software bugs", anything that can "bug" the potential user is a issue for them but testers don't make the final call, it's the entire team that discusses over it and takes a decision over a potential issues.

A firm belief of Agile practitioners is that any testing approach does not assure quality it's the team that does (or doesn't) do it, so there is a heavy emphasis on the skill and attitude of the people involved.

Agile Testing is not a game of "gotcha", it's about finding ways to set goals rather than focus on mistakes.

 

Among these Agile methodologies mentioned we shall look at XP (Extreme Programming) in detail, as this is the most commonly used and popular one.

 

The basic components of the XP practices are:

 

·         Test- First Programming

·         Pair Programming

·         Short Iterations & Releases

·         Refactoring

·         User Stories

·         Acceptance Testing

 

We shall discuss these factors in detail.

 

 

 

Test-First Programming

§  Developers write unit tests before coding. It has been noted that this kind of approach motivates the coding, speeds coding and also and improves design results in better designs (with less coupling and more cohesion)

§  It supports a practice called Refactoring (discussed later on).

§  Agile practitioners prefer Tests (code) to Text (written documents) for describing system behavior. Tests are more precise than human language and they are also a lot more likely to be updated when the design changes. How many times have you seen design documents that no longer accurately described the current workings of the software? Out-of-date design documents look pretty much like up-to-date documents. Out-of-date tests fail.

§  Many open source tools like xUnit have been developed to support this methodology.

 

Refactoring

§  Refactoring is the practice changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

§  Traditional development tries to understand how all the code will work together in advance. This is the design. With agile methods, this difficult process of imagining what code might look like before it is written is avoided. Instead, the code is restructured as needed to maintain a coherent design. Frequent refactoring allows less up-front planning of design.

§  Agile methods replace high-level design with frequent redesign (refactoring). Successful refactoring But it also requires a way of ensuring checking whether that the behavior wasn't inadvertently changed. That's where the tests come in.

§  Make the simplest design that will work and add complexity only when needed and refactor as necessary.

§  Refactoring requires unit tests to ensure that design changes (refactorings) don't break existing code.

 

Acceptance Testing

§  Make up user experiences or User stories, which are short descriptions of the features to be coded.

§  Acceptance tests verify the completion of user stories.

§  Ideally they are written before coding.

 

 

With all these features and process included we can define a practice for Agile testing encompassing the following features.

 

·         Conversational Test Creation

·         Coaching Tests

·         Providing Test Interfaces

·         Exploratory Learning

 

Looking deep into each of these practices we can describe each of them as:

Conversational Test Creation

§  Test case writing should be a collaborative activity including majority of the entire team. As the customers will be busy we should have someone representing the customer.

§  Defining tests is a key activity that should include programmers and customer representatives.

§  Don't do it alone.

 

 

      Coaching Tests

§  A way of thinking about Acceptance Tests.

§  Turn user stories into tests.

§  Tests should provide Goals and guidance, Instant feedback and Progress measurement

§  Tests should be in specified in a format that is clear enough that users/ customers can understand and that is specific enough that it can be executed

§  Specification should be done by example.

 

 Providing Test Interfaces

§  Developers are responsible for providing the fixtures that automate coaching tests

§  In most cases XP teams are adding test interfaces to their products, rather than using external test tools

 

 

Exploratory Learning

§  Plan to explore, learn and understand the product with each iteration.

§  Look for bugs, missing features and opportunities for improvement.

§  We don't understand software until we have used it.

We believe that Agile Testing is a major step forward. You may disagree.  But regardless Agile Programming is the wave of the future. These practices will develop and some of the extreme edges may be worn off, but it's only growing in influence and attraction.  Some testers may not like it, but those who don't figure out how to live with it are simply going to be left behind.

 

Some testers are still upset that they don't have the authority to block the release. Do they think that they now have the authority to block the adoption of these new development methods? They'll need to get on this ship and if they want to try to keep it from the shoals. Stay on the dock if you wish. Bon Voyage!

No comments:

Post a Comment