Seema Sonkiya: Agile Testing

Article based on agile SCRUM methodology recommendation of project testing, this article gives insight about testing in agile development methodology. This article talks about V model in agile testing, TDD and collaboration between developer and tester including how issues and bugs should be treated.

Agile testing strongly support V model, this model establish relationship between development and testing activities. This model ensures quality control and quality assurance throughout the project.

When we complete project and product scope using agile sprint, correctness and acceptance which includes verification and validation are performed by agile practices. Reviewing documents and designs, daily stand up meetings, continuous integration, refactoring, performing development and acceptance tests, holding focused reviews, enhancing communication are performed by involving product owner and customer along with development team which also includes test team members.

Three important deliverables are developed during project that forms the basis of V model:

1.       User Cases forms the basis of acceptance test cases.

2.       Simple design and visual modeling forms the basis of continuous integration and refactoring.

3.       Coding forms the basis of development or unit tests.

 Agile testing wires TDD. TDD is the combination of   TFD (Test First Development) and refactoring.

Steps of Test First Development:      

1.       Add a test.

2.       Run the test

a.      If pass then add another test.

b.      If fail then make required changes

                                                               i.      If pass then continue development tests.

                                                             ii.      If fail then again make required changes

When a new feature introduced, we need to first analyze whether the existing design is best design possible that allow us to implement that functionality. Two possibilities are:

1.       If existing design is suitable then we proceed via a TFD approach.

2.       If existing design is not suitable then we refactor the design to change the portion of design affected by the new feature. This enables us to improve the quality of design and making it easier to work with in future.

A developer using a TDD approach refuses to write a new function until:

1.       There is first a test that fails because that function is not present.

2.       There is test case for the code to be written.

Using TDD approach, programmer knows what need to be writing to pass the associated test cases. Once the code is written, tests are executed as our new code may break many existing tests as well as the new one.

TDD requires a great discipline, because it is easy to slip and write functional code before developing associated test case. Pair programmer helps the developer to stay on track.

TDD is performed in two levels:

1.       Development TDD:

a.      Development test cases are identified and designed during design & construction interleaved section of a sprint execution.

b.      When we add and run developer test, two cases are possible:

                                                               i.      If pass then we either add & run another developer test case or go to acceptance test case.

                                                             ii.      If fail then we make required changes and then again run the developer test case.

2.       Acceptance TDD:

a.      User stories forms the basis of acceptance test cases.

b.      High level user stories are identified during release planning. During release planning we just identify description of acceptance test cases for each corresponding user story to enable estimation as realistic as possible, during planning preferably in range of +-10%. For example: Add customer use case may  include acceptance test case for user to perform standard wildcard searches on first and last name

c.      Detailed acceptance test case instructions developed during Design & Construction interleaved of sprint. Like for above acceptance test case instruction may be defined as:

                                                               i.      Remove all customers

                                                             ii.      Add some customers

                                                            iii.      Display the Customer search screen.

                                                           iv.      In the First Name entry field, enter "%ob*"

                                                            v.      In the Last Name entry field, enter "S*"

                                                           vi.      Press the search button.

                                                         vii.      Identify and validate expected results.

d.      When all of the development test cases associated with newly developed functional code successful, we execute associated acceptance test cases.

                                                               i.      Add an acceptance test

                                                             ii.      Run acceptance test.

                                                            iii.      If pass then add and run another acceptance test or stop development of that functionality.

                                                           iv.      If fail then make little changes and run again.

Some other important notes about agile testing:

1.       When a deviation is identified after establishing definition of ‘done’ for all the user stories of sprint and these are demonstrated to customer, then this deviation is treated as bug.

2.       Whenever a bug is discovered it is treated as backlog item that is related to specific user story already in backlog.

3.       Bugs should be treated independently for the tracking and prioritizing.

4.       Bugs and story should be prioritized at the same level as each other and they should be estimated using the same standard and technique. i.e. relative story point.

5.       An issue is an problem that occurs mid sprint and is tightly coupled to a user story that has not yet met its definition of done i.e. It is still in the state of ‘in progress’ or ‘ready to verify’

6.       An issue is not a backlog item; this is part of evolving development or acceptance test cases.

7.       Our emphasis should be to address issues as soon as possible.

8.       It is recommended to completely finish one user story in its entirely including testing and rework than to partially finish multiple user stories.

9.        When agile tester performing exploratory testing on user story, and discovers an issue. Some important items need to be take care:

a.      As a user story is completed in it’s entirely, this user story should be the top priority of the developer working on it. Tester feels free to walk over to the developer to explain or demonstrate the issue as soon as it is found. Again, due to top priority, the programmer should leave whatever they are doing and immediately start work on the issue. This is based on agile principles where face to face conversion is preferred way of communication and working software is primary deliverable rather than documentation.

b.      If the developer is busy to resolve another issue discovered by tester earlier related to same story, then these details are captured or documented for later discussion with the developer.

c.      When issue is discovered, it should be treated as part of the acceptance criteria of the user story. This saves the tester from the pain of having to create a new bug, classify it, assign it, prioritize it etc etc. Tester need to simply enter a line to the acceptance criteria with a date/time stamp, some bullet points related to issue. When developer is free, a discussion is performed using the notes as a prompt. These notes should ensure that the developer can get needed details even if the tester is not around to maintain the momentum.

10.   After a user story completion, integration is performed as part of continuous integration and integration test cases are performed. Pair programmers have the responsibility for the continuous integration in the guidance of team leader.

11.   When all stories of sprint are complete then final UAT is performed, a backlog is created as collection of minor bugs. These are usually minor issues and take some minutes to resolve.

12.   When team is in mid sprint and a critical issue is encountered, it may require some scrum team members to resolve it.

a.      First thing we need to see whether it can wait until next sprint, as it may delay the current sprint release date and will change the scope of sprint. Another point is that developer should not feel that they are working in an environment where they need to switch gears in every five minutes. These are included as part of type backlog item.

b.      Sometime this issue is on top priority and can’t wait till next sprint. First thing we need to do that estimation of resolution with needed resources. Strategies are developed and after getting internal management buy-in, we need to present the situation to the client and strategy is discussed and approval is taken for the same.

Testing team is integral part of development and their collaboration is essential for the success of the project.

Seema Sonkiya