How to Guarantee High Quality Testing in Agile Sprints

Testing Perfection.

As we discussed in the last post, testing in agile life-cycles is a constant battle of timelines, priorities, integration and system issues and overall quality of product.  Its very important when running your tests that you are able to see the overall picture of the product and maintain a high level of quality, while keeping in line with the release time frames.  This is true whether your company is running long interval releases, short and frequent or daily releases.  QA is pressured to keep the pace of development and its important for all companies to put into place regular strategies to keep the QA on track without sacrificing quality.

Hereby we present the 4 Prong Method to Testing Quality in Agile.  The 4 Prong Method explains how to ensure your testers are keeping up with the speed of agile, and still supplying the best possible quality.  Here's how it goes:

• Design phase QA inclusion 

At what point should QA be told about the feature being developed?  More often than not, the developer has already coded most of his user story, when QA comes over and discusses it with him.  Unfortunately, this is a mistake.  QA, and it can be the testers themselves or a team leader or a tech lead, needs to be in on the meetings where product and dev discuss the user story.  The reason for this is simple: Testers think different than developers.  They tend to think about the whole system, rather than just the feature itself, and they have considerations like the support matrix and system integration in mind when they learn about new features.  A great tester will be able to identify a big hole in the feature before dev even begins working on it.  In a very simplistic example, we can understand how this works in the following scenario: Product would like to add a new feature to the mobile app.  Its a feature that involves security concerns.  The Android developers are there, and they are discussing how to move forward.  A good tester will consider how this will work on ios devices (since they usually test both systems) and can raise the serious security concerns on the apple side to make this feature work.  It could change the whole design of the feature.  This is one example, and there are many, where a tester can provide valuable input at the design phase.  So invite QA to the design meetings.

• Test case parallel writing and reviews

Once the sprint is planned and approved, and dev begins designing and writing their code, QA isn't meant to sit around working on other things.  All too often, they are still playing catch up from late arrivals from the previous sprint.  Ideally, they should be writing tests at exactly the same time that dev is coding.  They should participate in meetings, work in the same room as them, and discuss openly how the feature is designed.  Once the tests are written, they are to be reviewed.  Now, this is important, so stick with me.  They should be reviewed by product, architects, dev and program.  They should then be reviewed by other QA testers and verified that the test cases get updated accordingly through some sort of quick audit process.  Its not a lack of trust, its quality.  You work on a team, and so the team needs to work together.  By maintaining this open communication and synchronisation with members of your team, you find more bugs before the code is even written, than you would have found later.  So do everything you can to make it that testers are writing and reviewing test cases while the feature is being written.  Once dev is ready to drop it to QA, they can begin right away and maintain those ever so important sprint milestones.

• Test case -Test step writing

In the old days - when I started in QA, we had a training course of how to write test cases.  They explained that test cases should be clear and concise, and cover all aspects of the specific item being tested.  Test cases were often large and long, but were meant to fully test the feature.  Honestly, its a good way to start learning how to write test cases.  There's a problem though - it doesn't work for agile and continuous integration.  

Agile needs to move faster, and everything is smaller and more concise.  Because of this test cases need to be spread out more, each one should be one to five steps max.  So instead of writing a test case like: "Test Login Page" which covers all aspects of the page including user name/ password/ help and negative testing, we will have to make a few like this: "Username validation" "Negative Username tests" "Password Validation" and "Help Menu".  Each test case contains a few parameters that satisfy the test and can be done quickly.  Writing tests like this will accomplish all of the following needs: 

• Tests can be reviewed faster since the subjects of the steps are in the titles.
• Tests can be managed faster, since all steps are understood by the titles and can be prioritised, categorised and migrated faster.
• Tests can be migrated to automation faster.
• Tests will cover the specific feature, and not allow itself to wonder off into features that aren't relevant right now.

So make sure your tests are tight and concise.  It will allow the testers to work more efficiently and keep the direct feature in mind, while being able to move this tests more easily into regression and automation.

• Integration consideration 

The best testers always think one step ahead.  During a standard development cycle there is nothing more important than asking the question: "How will this be integrated?"  Or "What will happen when we integrate this?"  Its true that of the 4, this is the weakest link, because we don't need to test integration in every sprint, and if its a large system environment, it will be inefficient to try to integrate each time.  But still, integration needs to stay in the minds of the engineers all the time.  Therefore, in order to increase quality, make sure you have, at the bare minimum, a plan for an integration environment and know where this feature will fit into the larger picture.  

• In a slow release management cycle, where releases come infrequently and in large packages, the integration tests are the first that will prove the strength of the new features.  So have it ready, and give it priority.
• In a constant release environment, where the product gets updated once every few weeks, or even every day, the integration environment is much more important.  It needs to be maintained and cared for, and always ready to test the new features coming in.

Make sure integration is a priority.  If your company will use hardenings, give time to build the integration environment.  If your company has constant releases, keep the integration environment in good condition, and never release anything without testing it there first.  This all may seem obvious, but unfortunately not everyone thinks about it, and that's when issues come up. 

This is the 4 Prong Method to Quality Testing in Agile.  When you run your sprints, when you do planning and retrospectives and when you release, keep these 4 methods in mind.  They will strengthen your product and help bring you closer to the perfect product.