Testing - When, Where and How on agile projects....

I think this question haunts most of the agile QA's mind. I am going to wrote something in this post from my previous experience.

As agile is not a fixed set of processes, so its is imperative to be agile in testing as well. However, some practices help..but again everything is contextual.

1) Adding value early : Agile testing is all about giving feedback early, not necessarily only by testing the software, but in different ways as well.
  a) Looking at requirements for Clarity and Testability  - QAs really need to look at the requirement / stories upfront to figure out that requirement are  unambiguous and testable.

Unambiguous .  - I think unambiguous in agile has little different context compared to typical waterfall project.

- Requirement should be small enough to make sense in the context
- Acceptance criteria (Stories are generally broken in to acceptance criteria) should not be duplicate or overlapping from different stories.

However, doing that can be really difficult and can only be achieved with really good communication between Dev/BA/QA.

Testable : Testability aspect of the story requires QA to scan through the story to see what needs to be done to test the story. These factors can generally be.

- Finding hidden requirements
- Environment
- Test data
- Dependency on other requirement.

Getting these details early helps the story to be prioritised accordingly in the backlog, and allows smooth execution of the story in the iteration.


2) Use Automation to the advantage not for sake of doing it

Automation in agile is quiet controversial, as people try to automated everything and end up having a long feedback cycle.

Automation is meant for giving early feedback on the latest code, and automation should be limited to what is worth Automating and what is not.

Every automation test written has a cost against it. The cost can be seen as

Cost of continuously running it (Increased feedback cycle).  This cost should be compared against cost of not runing it. So, a question needs to be asked what if a test is not written? what we gonna lose, what would be the cost of fixing the stuff around the code for which we are losing the coverage?

And this might not be straight forward finding the worth of a test. Its a contextual decision and also depends on size of the project and number of people involved in it. 

Simply putting this in other words mean : 

Longer feedback cycle = More people losing time in getting instant feedback.


I will write posts on - How to write automated acceptance tests in my future posts.....

This post to be continued

 

2 comments:

  • Nice post. I really liked your blog. The information that you provide is always helpful and informative too. Thanks for sharing and posting.

  • SWIFT Interview questions on

    http://testwithus.blogspot.in/p/swift.htm

    For selenium solution visit
    http://testwithus.blogspot.in/p/blog-page.html


    For QTP interview questions

    http://testwithus.blogspot.in/p/qtp-questions.html


    www.searchyourpolicy.com

Post a Comment