Testing Times in Scrum

Ballistic missiles are extremely adept at shooting down a target, be it surface to surface or surface to air. But what happens if the target is a rogue fighter jet moving in different directions at lightning speed? Testing professionals in a scrum team are forced to play the role of these ballistic missiles. Ideally, testing teams need a finished product to validate requirements. But in a scrum setup, testing professionals need to be on their toes as the scope keeps changing and they have to adapt to changing needs. It does seem like a daunting task at hindsight! Let us look at a few approaches which could make it plain sailing for the teams.

Fail Fast Approach

Richard Hughes, considered an authority in testing, observes that since software is shipped often, testing should happen continuously. Testing early and often eliminates defects and uncertainties sooner. Defects are more expensive to fix at a later stage. Scrum eases this process by advocating the creation of short time-boxes for sprints, and topping it off with frequent build and automated testing, which cuts down on time taken to ship quality software. In fact, the basic premise of test methodologies like Test Driven Development (TDD) is the fail fast approach. TDD starts with testers designing a test which fails, following which developers construct code to pass it. Scrum Agile practices like TDD create testable code, encourage repeatable tests, and support rapid change.

"Walking on water and developing software from a specification are easy if both are frozen" - Edward V. Berard

Disregard 'Rock star' Status

Throwing a ball to the other side and waiting for it to come back is definitely not the scrum game. There are no silhouettes when it comes to the activities team members perform, and no team member deserves a special treatment either. For example, Teams sometimes give a rock star status to a developer who saved the day fixing a monstrous defect. In scrum, every team member is given equal credit and each one takes part in every sprint activity. In this context, T skilled professionals add immense value. A T skilled person has deep expertise in one area and is a generalist in multiple areas. For example, a member with deep expertise in testing and also possessing prior product owner experience could be of great value add to the team. In such a scenario, a QA professional can participate in development tasks as well, while providing expertise in testing. That doesn't mean a tester needs to master Java script.

Continuous Testing

In the scrum world, changes happen frequently and as a result testers need to accommodate testing of new features as well as regression test sets. Automation plays a key role in such a scenario. Teams will reap the benefits of an automated bed, though it involves considerable time and resources in the initial setup. The approach to continuous testing involves multiple stakeholders ranging from Dev (Dev environment) to the Ops teams (Prod environment). While the Dev teams use products like Selenium to configure these tests, QA teams can reuse these tests by modifying test parameters, and the Ops teams can leverage these for production monitoring. Continuous testing culminates at continuous integration and continuous delivery. To know more about setting up the continuous delivery pipeline, read 'Sports car on a mud track'.

NFR Testing

For banks, customer information is considered extremely sensitive and critical. In most financial transactions, details like credit card numbers and account numbers are masked. Similarly, other industries like life sciences and defence have certain regulations to be met. Such requirements are usually modeled as constraints or non- functional requirements (NFR). Apart from security and regulations, NFRs can also define other attributes like performance, usability, and scalability. In a traditional world, NFR testing happens quite late in the SDLC, which can cost the teams dear. This is because it might result in completely revisiting the basic architecture of the system. We advocate continuous testing of NFRs just like functional requirements to overcome these challenges. To begin with, teams will have to add NFRs to the 'Definition of Done', which ensures that these requirements are validated with each increment. Since this is a continuous process, the NFR testing, wherever possible (load or security testing) should be automated. These automated tests are configured as part of (the ever growing!!) regression pack. The other roadblock which teams might face is getting access to the production environment. In such scenarios, hardware virtualization techniques like OS level virtualization (Container technology) can come in handy. Finally NFRs, especially the ones with security and compliance attributes need to be transparent to the entire team. Publishing this in a common repository like a cloud software or wiki document will definitely help this cause.

Real Measure of Progress

In scrum, testing serves as the real measure of progress. A user story is not ready until development is complete, all its associated tests including acceptance tests have been passed. To track completion of activities of a sprint, Agile task boards or test boards can be used. Completion of an activity in an iteration is based on an agreed upon criterion called 'Definition of Done'. A user story reaches 'Done' stage after all checklist items in the 'Definition of Done' are complete. A clear 'Definition of Done' should contain functional characteristics, non-functional characteristics, interfaces, and product specific criterion.

Going back to the question initially raised regarding a ballistic missile shooting a fighter jet, the question looks more answerable now. With the advent of technologies like heat maps, missiles can be self-guided to demolish a moving target, even if it's a fighter jet moving at a rapid pace. Similarly, these approaches help scrum teams simplify QA processes and sustainably deliver better quality products.

Get in touch for futher quries