Quality test procedure in two week Sprints? Don’t you play Cricket?

     Two week Sprints. Why not? I compare it with Cricket. When ODIs wrapped the show of five day test matches and then came the 20-20 with more excitement, didn’t we welcome? Quick ROI (return on investment), result oriented and happy stakeholders. :-) 

To ensure delivery of shippable increment with each iteration, programmers look at each story and related tasks to identify the most necessary tasks of the functionality. Those tasks are completed first and then subsequently the rest tasks of the functionality are taken up. The idea here is that instead of delivering nothing of that functionality at the end of the sprint, at least deliver something which works.

Agile testers take the same approach and identify the happy path of the functionality first and start by making sure the happy path works.  And this statement does not indicate to leave the negative tests. Negative testing is vital for quality product. A good approach is to automate the happy testing and once found fine then go ahead with negative testing. However this is very necessary to identify the criticality of the product.

If any defect which is not observed in normal circumstances i.e. to produce a defect it takes various tricky steps which are almost unusual, then it is worth to leave fixing those. To stop the delivery may impact on ROI (return on investment) and one of the good things in agility is early ROI. But yes, this defect needs to be indicated to Product owner. It can be considered as a technical debt and may be re-paid later, if felt necessary. This practice is acceptable in short sprints.

In scrum teams, programmers work using TDD (test driven development) and ensure positive scenarios are working fine. Testers write regression test scripts. The development team which comprises of programmers, testers, designers and sometimes business analysts also, execute these test scripts during the last two days of sprint. Certainly the teamwork during sprints plays a major role in delivering quality chunks in such a short period. And this all get possible with the help of automated tools and continuous integration.

In my future articles we will be exploring such tools used in scrum teams and the continuous integration.

So stay tuned…