Test Automation: How going round in circles improves your chances of reaching your destination

The path from idea to working software is often difficult to plan and hard to repeat.

For those responsible for ensuring the delivery of a project, there are points where you feel the fate of the delivery is in the hands of the gods, as you try to ascertain information from multiple teams who report that they are progressing to plan. Your just not entirely sure that what is progressing to plan is what you asked for..

In most projects, all roads lead to testing.  It will be the first tyre kick of code with production like data, new platforms and environment architecture.  While in isolation all of your project work streams all report green, once you arrive into testing you find out team A were using an old specification,  team B has lost resource to another project, the customer already wants changes that require 3 months of rework and the API to a dependent application is not ready. Now, you would expect the next section to be about how agile can save you all of the above.  While yes, there are definitely benefits to agile, the word can quickly conjure images of lawless development teams  ‘failing fast’ and everyone being even less sure where they will end up than they were with other methodology.

For both the above scenarios, it is neither the methodology used that concerns the stakeholders.  It is the visibility of data that tells you what you are building satisfies your customer.    This means you cannot consider any part of your plan fully complete until the testing phase is complete.  Finding any significant issues even at the start of testing is high risk, you have already made a significant investment in your project up to this point.

The real benefit of Agile when implemented correctly, is the better decision making that can take place earlier with efficient feedback loops.  To learn that you are on the wrong course early in the development life cycle, instead of when you reach testing when you may have spent months on a project, is vital.   At the end of a sprint, you can show a section of your deliverable to the customer, get the green light and consider yourself a step closer to your goal, with the work banked.  However, how do you then ensure that you do not inadvertently take a step backwards?

''Agile and automation go hand in glove''

Where possible, every part of the delivery process that can be automated, should be automated.  Especially in testing!  If you have a team delivering automated unit, integration and functional tests, you have another vital feedback loop in place.  As you focus your resource on the deliverables of the next sprint, your automated tests can be scheduled to run after every build, or every check in to your codebase to tell you that your changes have not impacted your existing signed off codebase.

As you patch your test environment you can automatically run your automated functional and integration tests; Smoke testing your environment and giving fast feedback on any issues to existing functionality from the latest check in.  If you encounter any failures, you can quickly pinpoint which change has caused the tests to fail, assess, take action and get back on course.   Your test and dev resource work in conjunction to ensure that each sprint delivers not just the product itself,  but the framework and testware to exercise the product automatically - on demand allowing you to cycle as often as required. This can help significantly increase your confidence in a delivery as you have an accurate view of the state of the product at any point during the project.

Sometimes going round in circles really does improve your chances getting you to where you want to be.