Agile Testing is the testing practice for projects using agile methodologies.Agile Testing follows the agile manifesto, treating development as the customer of testing.Agile testing does not emphasize rigidly defined testing procedures, but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective.

 

What is Test Driven Development?

 

Test-driven development (TDD) is a Agile development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes.The goal of TDD is specification and not validation.

 

In this method begin by writing the test cases covering the new functionality, then write the production code necessary to make the test pass, and after you refactor the code to make it more maintainable.

 

TDD can be summarized as a set of the following actions

 

1.Write the test - Programmer write the test by going through the requirements.The programmer must fully comprehend the requirements. At first, this test will fail because it is written prior to the feature.

 

2.Run all of the tests and make sure that the newest test doesn’t pass. This insures that the new test is not passing by accident, making it irrelevant

 

3.Write the minimal code that will make the test pass Write code that will successfully pass the test. The code written at this stage will not be final, it is just the code that will pass the test.

 

4. Make sure that all of the previous tests still pass

 

5. Refactor the code In this stage programmer improves his code. By running the test cases again, the programmer can be sure that the refactoring restructuring has not damaged the code in any way.

 

6.Repeat the cycle with a new test Now the cycle is repeated with another new test.

 

 

Refactoring is a disciplined technique for improving the structure of existing code without changing the observable behavior.

 

from Fowler, the definition of Refactoring: “...the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its iternal structure.”

 

One main activity and goal of refactoring is to remove Code Smells through small iterations.

 

 

In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Often the deeper problem hinted by a code smell can be uncovered when the code is subjected to a short feedback cycle where it is refactored in small, controlled steps, and the resulting design is examined to see if there are any further code smells that indicate the need of more refactoring.

 

List of common Code Smells.

 

Duplicate code: identical or very similar code exists in more than one location. Large method: a method, function, or procedure that has grown too large.

Large class: a class that has grown too large, see God object.

Feature envy: a class that uses methods of another class excessively. Inappropriate intimacy: a class that has dependencies on implementation details of another class.

Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by derived class.

Lazy class: a class that does too little.

Duplicated method: a method, function, or procedure that is very similar to another.

Contrived Complexity: forced usage of overly complicated design patterns where simpler design would suffice.

 

 

In an agile environment, acceptance tests are often expressed as "storytests" by capturing the user stories/requirements together with acceptance criteria (tests) that validate their implementation. Joshua Kerievsky first coined the term storytesting, a term which is being used more and more in the agile community.

 

When creating acceptance test cases, the following points (some obvious) should be covered:

 

All scenarios of the User Story should be covered in the test cases, and the expected outcome mentioned so that a tester can verify each function and use case.

 

The acceptance test case needs to be at a broad overview level and not have details such as field validations, etc. because those will be covered by unit test cases.

 

The test cases should precisely define the steps and their sequence that the tester should take; the inputs; and the expected outputs.

 

When testing a non-UI based module, an acceptance test case can be an automated test case which also records the response. This will allow us to examine the output and see if it is acceptable.

 

The acceptance test cases need to be reviewed and approved by the Product Owner in order to ensure that the coverage is complete.

 

Once test cases are created and approved, they should be given to the developer prior to start of development work. This allows the developers to get better understanding of the requirements as compared to what they might otherwise understand from just the User Story. This implies that the test cases need to be made before the actual development starts.

 

 

 

The technique of expressing requirements as user stories is one of the most widely applicable techniques introduced by the agile processes. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it and testers can start write test cases on it.

 

How to write a good user story

 

1. Make them customer-focused. The easiest way to do this is to have the customer write them eg "Improve Order reporting performance" instead of "add clustered index to the Order table"

2.Make them elevator-friendly.A good story should be something that can be explain on an elevator in 30 seconds.

3. Make them the right size. Not too big, and not too small.

4. Make them testable. An untestable story might be something like "Make the order screen easy to use".A better wording choice might be: "A novice user be able to load, enter information, and submit an order within 5 minutes."

 

Acceptance Test in Agile

 

1. The customer writes stories.

2. The development team and the customer have conversations about the story to flesh out the details and make sure there is mutual understanding.

3. If it is not clear how an acceptance test could be written because there is not enough to test it against yet, the developer does some exploration to understand the story better.

4. When the exploration is done, the developer writes a “first cut” at one or more acceptance tests for the story and validates it with the customer.

5. Once the customer and the developer have agreed on the "first cut" acceptance test(s), he hands them over to business people (QA people on our project) to write more tests to explore all boundary conditions, etc.