Part 3 - Smart Test Automation: Intuitive Enhancement over Reactive Rectification

<< Previous The Problem or Challenge: In a nutshell, a large portion of the total time was spent on Testing, Bug-Fixing and Re-Testing. And, the objective was to shorten the cycle-time pertaining to Test-Fix-Retest cycle (s). It was also an important goal to reduce the required (and applied) human-effort, also, pertaining to the Test-Fix-Retest cycle (s). The assumption in this case was, the lesser the ‘number of times’ the Test-Fix-Retest cycle was repeated, the lesser would be the time and effort consumed. The challenge was to ascertain, HOW(?)!

The goal of the automation-project (solution) in question was to automate very lengthy and repetitive workflows of a Windows-based enterprise-application. The workflows were so lengthy and repetitive, that it took days and even weeks to complete those using the automated test solution.

This point onwards, the discussion is based on the scenario pertaining to the heaviest and the most complex module of the solution (ATS). In total, there were 10 modules and the module in question was the last one to be completed (implemented) and tested. This was planned like this, as the customer wanted a few changes in the solution (in the middle of the project cycle) and those changes had a fairly large impact on this module.

By the time the Change-Requests were communicated to the team, the implementation of the module was over and the team was busy implementing other remaining modules of the solution. So, in order to proceed as per the schedule, without disturbing the development of the remaining modules, it was decided to incorporate the requested changes after completing the development of the remaining modules.

And, the team did so as per the plan. But, there was a concern - the test-cycle time. It was too long. Based on the hardware and software environment, it was ascertained that to test the module once, it would take more than 15 days (with the solution running 24 hours a day!).

Let’s take a closer look at the scenario. Suppose say, we start the test on Day-1 and the test runs successfully for 6 days. And, on Day-7, something goes wrong and the running test is thrown off the gears. And, it’s quite common that each change injected at a later stage of the development cycle increases the risk of breaking one or more things in the existing code | functionality in the Automated Test Solution (ATS). We, in fact, anticipated that to happen and projected on similar lines. We expected the module to break (multiple times) after introducing one or more change (s).

So, the situation was like this; if something went wrong on Day-7, we had to fix the same and start the test afresh. And, the day we restarted the test was again, nothing but, Day-1. Now, if the test again broke on Day-11, we had to start from Day-1 again! In our scenario, it was not ideal and feasible to run the test incrementally. Cumulative Incremental Testing was not a possibility. So, we realized that if we went in the conventional way (exemplified in the figure, Figure – 5, below), it would take a huge amount of time to complete the testing of the module. And, nobody knew when the test would break next. We were simply not in a position to afford taking that long to complete the testing of just one module.

It did not seem prudent to us to fix a problem and then to just wait, without any clue, for the next problem to surface and demand yet another fix! We did not want to get driven by the above mentioned application (ATS) behavior. Rather, we wanted to control the way the application (ATS) behaved. We just wanted to tighten our control over the development and the delivery cycle as a whole. Note: In the above figure, Figure - 5, “Identify and Fix Problem” also includes testing (validating) the ‘Fix’ itself.

In the above case, the rectification of the issue was reactive. A course of action was initiated only on the event of a problem occurring (and surfacing). We have used the term “REACTIVE RECTIFICATION” to describe this type of Test-Fix-And-Retest cycle.

We wanted a paradigm shift. A shift from the reactive mode of rectification to a predictive mode of enhancement termed as “Intuitive Enhancement”. In this new mode of operation, we did not want to wait all the way till the test stumbled upon a problem and a fix was necessitated. Rather, we wanted to enhance our solution in a way so as to minimize the presence of problems in the solution. That is, a sort of providing a “Fix” in advance. But, the term “Fix” is more appropriately applicable to a rectification after the problem has surfaced. Since, in our later approach, we addressed predicted issues before the actual occurrence of the same, we found it suitable to use the term “Enhancement”, instead of “Fix”.  Next Page >>