Software testing. Fast... Faster... The Fastest...

Have you heard these words before? Do you work in IT? Oh if you do I am sure you heard IT ! I need IT yesterday :) Everybody needs IT yesterday however there are delays... And all the delays are accumulated in the last phase of the IT project which is in most cases . Well my fellow testers have you felt the pressure before? I certainly did... in many projects. You need to finish faster and at the same level of quality as if you would have had the necessary time frame.

With this challenge in mind I need to find a solution to speed things up while maintaining the same quality level every time. Oh, nobody likes to lower the quality to increase the speed... nor to ask for more resources... no no no the budget is fixed. So you have to deliver with what you have. Luckily for me I have test automation skills in my team. I have seen other managers increasing the number or people and continuing with manual testing because they had many modifications or they asked for overtime but how much is enough?

As for myself I choose Automated Testing, actually a blend between manual and automated testing . Normally I prefer single malts, Scottish please but this time for testing I have a blend between manual and automated testing because I strongly believe that brain should be used for creation and machines for execution! I have seen many examples where the weak point of manual testing was repetition, over and over again the same test cases. It is ok for a worker in a factory to do repetitive tasks but in IT and software testing we prefer to have intelligent people who's brain is build to solve challenges and gets annoyed when it does the same thing over and over again. The brain becomes asleep as Susan Reynolds says in her article (read here) and the tester does not find defects anymore. "I've tested this one... it worked before"

This is why I promote test automation for these situations because machines are made for execution; On top of that the machine executes the test scenario identically every time. This is only a partial solution because you still need brains to create new and innovative test scenarios, to manually verify new functionalities, to ask people to simulate real live situations and see the outcome before your customers do.

Test Automation is only a part of this powerful blend; It has the advantage that in medium and long-term projects generates return on investment. As you already know the initial investment in Test Automation is high at the beginning and it pays off only after a certain number of test iterations.

How it pays off? Well here I should answer the question how to be Fast... Faster... The Fastest... and one of the magic ingredients is that scripts can run unattended during the night or during the weekend! From here you start calculating how many hours you gain. Did I mention that a script runs much faster than a human executing the very same Test Case? about 70% faster. Actually a well-designed automated testing solution can be up to 70% much faster than manual testing at the same level of quality (the number is obtained from my projects). I say "up to” because it depends a lot of the Application Under Test, how the scripts are written, how many scripts and how long it takes to prepare the input data and how many input data you have. In my last project the development was so late that the estimated due date of coding the last functionalities was couple of days away from delivery to the customer for Acceptance Testing.

Couple of days are not enough for testing so I automated tests on all components as soon as they were ready and launched the test almost every night. In the morning we found a few defects automatically submitted by the scenario and analyzed them. It was ok for developers because they got a few defects daily or once every two days. Of course not every night the test was executed completely but every stop was followed by a defect. It was not smoothly and comfortable for us as a testing team because we had to do maintenance, regular (daily) update of the object repository, rebuilding the input data files, script creation (to keep up with the manually tested features) etc. BUT in the end allowed my team to focus on the new features developed (manual testing) in the same time do regression testing overnight and that allowed us to catch up the missing time. Was I fast enough? Yes for that project! Did we have a return on investment? If time to market counts, yes we did but we could not quantify it. If it does not the investment will pay off in about one year according to estimated number of releases and test iterations. But for the time being IT was fast, we delivered on time.

In Antiquity and Middle Ages you had to react fast to win a battle, the stakes were high: you are either fast or dead. I am looking into the strategies of warriors of that time because their skills and strategies were very efficient in PRACTICE. A Scythian or Mongol archer could draw, launch an arrow and hit you in a split of a second... while his horse was galloping at full speed. No mistakes, no excuses just fast and accurate.

Enjoy your battle!

Author: Victor Horescu