Unbelievable! Up to 80 % off*

* -Conditions Apply

Looks like an attractive festive seasonal sale offer advertisement? Exactly I meant that. But wondering why such title here? Read further.

Most of us on seeing such attractive advertisements go to the sale with lot of planning and enthusiasm to get many items cheaper. But on entering the shop any item we pick will always have zero or very minimal off plus lot of conditions attached to it. [Huh, now you realize that the advertisement says UPTO 80% and a tiny astrix attached to it]

Similarly GUI automation tool advertisement also say it can reduce regression testing cost by up to 80% or such similar tag lines, just by showing a login page automation. I was shown with the similar login screen example in almost every session, demos or presentation I participated. Mostly it goes like this

The presenter would ask to give the login screen of our application. The he would record a script to input the login details, after a successful login he validates the home page. Now he will go and alter the script so that it validates for incorrect login details. Then he shows data parametrization options for many data and proudly says we have automated so many scenarios for a login page in no time. Unfortunately, managers who do not have automation experience were made to think that automation could be so simple and will recommend such GUI tools. Because they see something like 80% cost reduction at that point.

But the first thing I do on seeing such demo is to enable remember password option and then run the script, now the script fails because it can’t find the login page. Presenters will mostly reply that we need to apply some conditional statements to handle that (Now did you get the first condition applied?).Fine, then my application opens a Change Password page on password expiry, the script fails because the script always checks for home page after login. Presenter will think for a while and would say that we need to handle this with some conditional statements. (Now did you see the second condition applied?)Fine, then my application some time gives a full page banner about new announcements or new feature added, like how our online banking starts displaying investments plans or new service offers. Yes you readers got it correctly this is the third Condition applied. Manager also by this would have realized that the offer is not really worth 80% he might recalculated to 60%.

Next, here is another big question I ask, what if all the three of the above appears or two of them appear at any given point of time. Such cases we need to consider the order in which they appear also. Can we automate them in no time?

No, we can’t automate them just like that. We need to write functions, conditions checks and also loops, realize that this is getting into kind of programming by itself. So we now not only write the script but need to be tested as well. [We all know very well that as per D’cruz Defecto Injection law (DDIL) bug count increases exponentially for every conditional block coded. Hey wait don’t Google for DDIL because it do not exist. Then wondering why I mentioned that, because I want you guys to read Pradeep’s post Black Viper Testing]

Now calculate how many such conditions would need to be handled while automating the entire application. Manager realizes that he definitely needs to rethink on the offer that the tool will return. Now did you realize that the festival sales offer and GUI automation tools offer are the same? But wait I got one difference between them, in festival sale Up To 80% means 0 to 80% but in automation this can even go negative 🙂

A good amount of Regression Checks could be automated, but that need a solid approach, planning and good investment (both time and resource). Successful automation can’t be done as a sideline activity with testers who don’t have technical or programming skills.

Share

Automation isn’t just regression, Look Around

Scene 1

One fine Monday morning, I walked across Mark who is a testers and a domain expert in the application to which I am pretty new.

ME: “Hey, café?”

Mark: “No dude just received this list of loans which I need to feed into the test system ”

ME: “Oh is it? What you do actually?”

Mark: “Here is the list of 100 odd loans that I have to feed into this using this XYZ application, so that ABC department will test this out in the build they get tomorrow.”

(Mark is the domain expert in this XYZ application, many other application talk to his application to get data for reporting, rule engines to name a few)

ME: “Hey that should be boring, is a onetime work?”

Mark: “No ME, I’ve to do this whenever any other department need some specific loan data. I have to do this almost every week for one or the other department during the release cycle.”

ME: “oops! So what exactly other departments give to you?”

Mark shows an excel sheet that has just list of loan numbers in a single column

Mark: “They just email me the list of loans they need, I just use the loan number to this main DB machine and gives the source DB so that the loan from this gets copied to the test DB.”

ME: “Is it? Can you give me a demo for it?”

On seeing the demo I understood that he navigates 4 mainframe screens then use the loan number provided and the test DB server provided by the other department to initialize jobs. He repeats this for the entire list of loans, each takes 3 minutes to enter.

ME: “What if the loan is already present in the source DB?”

Mark: “You get a message about the existence”

The first think that flashed is better to automate this. We already had the most costly automation tool with all add in for the mainframe interface. Wrote a very basic script to read the loan number and designation DB name from QTPs Data table and automate the other steps. Now each loan takes less than 30 seconds, asked him to maintain a sheet which calculates how many hours was by this script. The effort to create this script was half a day. We faced few issues in new release that were fixed using regular expression.

Next Monday morning

ME thru messenger: “Mark, café?”

Mark: “I am working from home, have your café alone”

ME:  😦

Scene 2:

Another not so fine someday morning, meeting with Mr.X.

Mr.X: “We need to come up with automation scripts for the entire regression test suite and deliver to the client”

ME: “Automation suite to client? But why do they need?”

Mr.X: “We have made agreement with client that we provide with complete regression automation suite so that they can run complete regression suite through automation”

ME: “But I think from the client perspective they need to test manually so they get the feel of the application, also from our experience we know very well that the automation scripts need to be debugged very often by experienced automation engineer for many problems starting from Data integrity issues to understanding the results to many such problems”

As usual without listening, my Mr.X continued

Mr.X: “We need to build a robust framework and so that the client will be able to use our framework easily”

ME: “So are we hiring another QA team to test this project, this looks like you are building software to test this software”

Mr.X: “Not exactly, but we need to look into next step in automation”

ME: “That is perfectly fine but at what cost? Whose benefit? ”

I am seeing this trend happening in many places. I really don’t understand the purpose of building a GUI automation regression scripts to be run by the client. First the trend was Regression Automation now it has another version GUI Regression Automation Suite for Clients.

But the problems here are

  • As Client I would love to see\test the system that was build, so that I can make a judgment whether the system is behaving as expected. I do not how automation adds value to client.
  • And no one is considering the maintenance cost. Automation even on play back needs experienced person to monitor and debug it regularly
  • And the time automation tool takes to yield the returns. In Most cases it will take three or four years to yield the returns. Refer this link to understand why http://www.testingeducation.org/BBST/BBSTGUIRegressionAutomation.html

I gave those two of those incidents to emphasize that

  1. Automation isn’t just automated regression testing. Automation and regression involve different considerations as said by Dr.Cem Kaner.
  2. Look around and talk with other people to know the kind of work they do, so you may add some value to it. Also you might get some interesting ideas from them to implement in your work.

Happy Looking Around  🙂

Share