Your product simplifies business critical workflows for banking organizations. Your product has complicated workflows which are accomplished by navigating through various forms and screens of your web application. Currently you are doing a lot of manual testing. You have testers who understand your domain well and are good at identifying problem areas. These testers are not programmers, but use computers to get their job done.
Sometime back you moved to faster releases. The development could cope with it (or so they believed and claimed). But testing started lagging behind. You realize that a lot of time is spent verifying older functionality. So you start skipping some parts of it. One day your friendly customer calls and says, hey, I am no longer able to edit loans as a manager. A CRITICAL BUG! Your mature, smart testing manager resists the temptation to shift blame (thank god for that!). You discuss with her and realize the manual testers are overwhelmed by the speed of releases. Bugs are slipping through and they are frustrated.
You realize YOU NEED AUTOMATION. And that you have no clue how to go about it.
So you ask your testing head. She says she knows this tool which she has seen used in an earlier organization. You look at the cost and blanch. You still go ahead and evaluate it. You think you will just have one tester on automation then. The testers are able to understand the tool and work with it. Unfortunately it does not support some components on your web application. You are silently relieved that you did not have to justify such a cost and make the compromise of using just one automation tester!
Next you ask one of your developers. He has heard a few things and suggests that you go with product B. You ask him if he has used it. He says, he has not, but EVERYONE seems to be using it. Many of the bigwigs are using it too. It is open source and free too! Wow! – you say. Let’s try it. The testing head is a little cautious. You are mildly irritated with her and assign the developer to do a Proof of Concept. The first trivial demo goes through. The enthusiastic developer blogs about it. He then goes on to do the POC. He needs to demo it in 2 weeks.
A couple of weeks later, you talk to the team. The testers say they have not been able to automate much. The developer says they do not have the skillsets. You should hire automation engineers. You try out with two automation engineers. They don’t come cheap. They seem to love XPaths and adding waits and digging deep into browser developer tools. But one of them seems to not understand the business functionality. He even has a holier than thou attitude, as if testers who understand business, but cannot automate like him, are beneath him. The other one thankfully is saner. Both diligently dive in to create a “framework”. Your existing testers are getting demotivated. They fear they may be fired. You are getting frustrated too. You think maybe you should outsource this. You talk to a few vendors. They say they know the tool but you will need a framework. The framework will cost you thousands of dollars and a few months of effort. Automation can only start after that. You start budgeting for it. But you are worried. What will I do with my current testers? This all seems unnecessarily complicated. You sense that YOU ARE SOLVING TECHNICAL AND PEOPLE PROBLEMS INTRODUCED BY A TOOL RATHER THAN YOUR OWN BUSINESS PROBLEMS.
Thankfully, you talk to your friend who heads engineering in that clinical research company in the US. He tells you about another tool. A tool which has enabled his existing testers to automate. A tool which does not need XPaths or waits. A tool which has a good recorder. A tool which has inbuilt technology to ease every bottleneck you yourself have encountered so far. And a tool which works reliably across browsers. Fast. Even on Internet Explorer, which you have not been able to reliably run on yet with tool B. (Tool B’s fan boys kept blaming that IE is cr*p and is slow). And he raves about the support team which has bailed him out every time. They even shipped an entire new build in 3 days for one of his issues.
So you change track. You ask your tester to evaluate this tool. It is called Sahi Pro. She schedules a demo from the Sahi team. She asks lots of questions. She does a screen sharing of her application and the Sahi team demonstrates how to automate it. She finds it easy. She does not know yet about running it in suites, distributing it across machines, taking screenshots, integrating with Continuous Integration systems etc. But she need not worry. Everything is inbuilt into Sahi Pro. The developer went through Sahi Pro’s documentation and found that it covers all of this. And your friend said it works too.
You are happy. You are happier to know its cost. And the fact that it allows flexible licensing. It all makes perfect business sense. Your developer who was handling automation is back to development. He was frustrated with the brittleness of the tests and having to interact with non-programmers. He is happy to go back to doing fun creative coding. His first love. The testers have automated a lot of scenarios now, especially with Sahi Pro’s inbuilt framework. One of the automation engineers who was hired is a little disappointed that he did not get to develop his own framework. He has applied for developer jobs elsewhere. The other automation tester has gone back to do what he loves – exploratory testing of complex business scenarios, while his automated tests verify known paths and regression scenarios reliably…