How to Streamline Quality Assurance for Agile Scrum Development

I have learned over the years that tried and true quality assurance (QA) practices work great in a waterfall approach. QA is regimented by nature and lends itself perfectly to the methodical nature of waterfall development, only with a lot of extra fluff. Can we cut out some of that fluff to match the streamlined nature of Agile Scrum development? I believe we can trim down some of the QA practices included in waterfall, keeping the highest quality of standards and even improving on them by being more efficient with our time.

First, realize that long test scripts are a waste of time.

I do not advocate eliminating test scripts completely, but waterfall allows far more time to write lengthy test cases than Agile. This practice can be cleaned up to fit the compressed timelines of Agile development.

The typical script – you know, the one that will put an insomniac to sleep – follows the same path:

1. 1. Login to www.blahblahblahdevtestintstage.com
   2. Click this
   3. Click this
   4. Check this
   5. Check this
   6. Click this
   7. Cli….zzzZZZZZ thump!

That curious red mark on your forehead that has the outline of your keyboard is a result from the test script you just tried to write or complete. As a member of a Scrum development team, you should not be put to sleep by your work unless nap time is part of the user story.

So how do we get past the snooze fest? The simple answer is to cut out the wasteful narrative in our scripts. There is a reason why each user story is written out the way it is. Through the acceptance criteria we are shown a path to our destination.

Example:

User Story – As an administrator, I want to be able to update a customer’s contact information on the customer profile modal because I do not want standard internal users to have access to this function. I want to have certain fields required, as well as a dropdown for easy selection.

Acceptance Criteria:

• • Only Administrators can change the customer’s profile.
  • All fields must be editable.
  • If I hit cancel on the modal, none of the information I changed will save.
  • When I hit save, the information will be updated.
  • Email must be validated against the approved email domain list.
  • Address 1 and 2 will contain Street Address, State, City and Zip.
  • First Name, Last Name, Email Address and Address Section 1 are all required.

Below is a partial example of a tired and bloated fictional script that a waterfall QA tester would normally create.

1. 1. Open Browser
   2. Enter link to application
   3. Type in username
   4. Type in password
   5. Click the Login button
   6. Click on the Administrator link
   7. Click on the Customer Administration link
   8. Type in customer name into the customer search box
   9. Click search
   10. Click on customer name
   11. Change the first name
   12. Change the last name
   13. Change the phone number
   14. Change the email
   15. Change Address Line 1
   16. Change City
   17. Change State
   18. Change Zip
   19. Change Address Line 2
   20. Change City
   21. Change State
   22. Change Zip
   23. Click Cancel

I’ll save some typing and real estate on the page, but you will repeat the next 30 or so steps, except additionally you will add lines for validations testing. In the end, you will click save, pull up the account profile and take a screenshot of your typing ability.

Alternate Method

1. 1. Prerequisite – Admin account access, any customer type setup in system.
   2. Take a screenshot of customer’s profile modal.
   3. Modify each field of the customer’s profile, test required field validations. When done, click cancel.
   4. Open the modal again take a screenshot of customer’s profile modal.
   5. Modify each field of the customer’s profile and click save.
   6. Open customer profile and take a screenshot of the modal.

50+ steps vs. six with both accomplishing the same thing… which would you prefer? I can hear the howls from the conservative base, “How did you know the way to the profile page if I didn’t tell you in 50+ steps?” As quality assurance, you should know the application. You don’t need baby steps to get to your goal. The user story and acceptance criteria didn’t say anything about steps 1-10. New development only covers what I did from step 11 till the end. “All fields must be editable” is part of the acceptance criteria, and I don’t need 24 steps telling me about each one and what to enter. Keep in mind each extra step has an expected result that has nothing to do with the user story or acceptance criteria except for the cancel and save functionality at the end.

The Alternate Method script is shorter while evoking the same message, and it will require very little upkeep. With parameters, you can cover variables such as browser type, customer name, and user type (for negative testing). Remember that this is not regression. This is a single test designed to try out the new or current functionality that was added or modified. Once you have a release built, you would then test all of the previous changes for a regression test. Remember, the definition of regression testing is a type of software testing that verifies that software previously developed and tested still performs correctly after it was changed or interfaced with other software. If you want to test the ripple effect, you would create other test cases that you could add to your current test set for an application-wide assessment. These, of course, would be reusable, and they would be small and easy to manage.

So why the mess and extra work? Is it because project managers are interjecting themselves into the Scrum team by looking for metrics that have little to no bearing? Are quality managers who are not part of the Scrum team casting a shadow over the process? In today’s hypersensitive world of Audits (SOX or PCI compliance), do we need to be able to assign blame more easily? None of these questions matter if the principles of Agile Scrum are applied correctly.

You shouldn’t need test scripts that are drawn out like a novel when following Agile. When testing to an end result, you are already crossing territory that is known and should not need a Sherpa to find your way. By taking the blinders off, it will allow the tester to be more aware of the landscape as they cross until they get to their destination.

Can we finally look to improve productivity by dispelling the myth of “Click Here a hundred times?” I believe so.