Any company using Agile methodology has to invest a lot of resources in testing. However, not all companies invest those resources efficiently.
Manual testing is great because a good tester will be able to think creatively and uncover hidden problems that scripts are not programmed to handle. At the same time, human testers have to wade through an enormous amount of repetitive tasks that sap his or her attention, even allowing mistakes to happen.
Automated testing, on the other hand, is excellent when it comes to routine, repetitive checks, accomplishing them without error and very fast. A good automated testing platform can deal flawlessly with 70 - 90% of the volume of testing a given project requires, leaving the human tester to do what manual testing does best.
TestyBot represents a significant leap forward in efficiency because we have created a VERSATILE automated testing platform that has the ability to handle to an ever higher percentage of testing tasks, going well beyond simple routines.
Moreover, with TestyBot you get a STABLE automation solution essential in the process of delivering a high quality product because the test scripts run daily, create reports, trigger emails so the management is always up to date with the status of the product.
If I were to use a single word, it would be … boredom. Let me tell you a bit about my experience as a tester. Eight years ago I started working as a manual tester at a small company in Cluj. It was the usual routine of writing test cases in a huge excel sheet and then executing them at the end of each sprint. It was fine for a few months while it still held some novelty but, gradually, the work started to become redundant and boring.
I eventually gave up using the test cases and just tested the Webapp, trying new flows, focusing on negative testing, trying to discover something new. I guess there are people temperamentally suited to doing the same thing over and over, but from talking to other testers the problem of repetitiveness and boredom is very real. It is easy to dismiss boredom as something annoying but not very important, but that would be a mistake. Bored testers may miss problems the more bored they are. Now that is extremely important.
It did not take me long to move up to another company which was testing for corporate clients. I saw what big testing projects look like for the first time. We used TestLink - a test case management tool, Confluence for documentation and JIRA for bug reporting. So I would have to say that, yes, you do get access to all kind of tools and, yes, those tools do help. Curiously, though, the testing process didn’t change much: write test cases, execute them every two weeks during regression testing, etc. Some improvement, but I never got over the feeling that it just isn’t enough.
Don’t get me wrong: work was demanding and, often enough, rewarding. It is just that I started accumulating experience and got to know
the “pain points” associated with testing. Especially so when, after a couple of years, I got hired as an automation QA engineer. The moment
I started writing automation scripts I realized just how powerful this could be: you can create an entire automation solution from scratch. It was exciting!
While the process was more or less the same - write test cases, automate them, execute them - the big breakthrough for me was that I could RUN THE TESTS AUTOMATICALLY! No more regression testing (at least not for the obvious flows). Not only are you using your time more efficiently, you also feel that you are using skills in ways they are supposed to be used.
Well… not really. Let me explain.
The automation solution we created was very well written. No hardcoded values, we used xml for test data, we created actions so we wouldn’t have to repeat code, etc. Still, the tests would fail often and not because they were catching bugs, but because of timeouts and missing elements. Inevitably, we started falling into the old routine: “we don’t have ID’s on elements”. Then asking for ID’s, having lots of discussions with the dev team to convince them to put ID’s on elements, getting the PM to create tasks and squeeze them in the sprint, taking days, maybe weeks to have them on our testing environment.
Even though I still thought automation is the only way forward (professionally speaking), when I got to the level of QA manager, I realized that in many cases the costs outweigh the benefits. As a QA manager I had first hand experience planning and implementing various automation solutions using C#, JAVA, Ruby with Selenium Webdriver or Watir. It bothered me that we never really got the tests to run smoothly, without glitches. It didn’t take me long to understand what the problem was: that we were still using lots of location XPaths. And with the high development rate we were trying to maintain, the xPaths would often change and we would be left with broken automation scripts.
Actually, there are. For instance, we found out pretty soon that we can solve this problem by using Cucumber. With it we didn’t have to write test cases anymore because our automation scripts were written as test acceptance criteria. However, this is far from a good practical solution. As a manager I saw that while we saved time on regression testing and test cases we still lost a lot of time maintaining and updating the automation scripts. Plus, it still took us quite a lot of time to write the automation scripts (having all sorts of problems with selectors, mouse hovering, JS etc).
While I was struggling with this problem, I met Nicolae Matei - a brilliant senior developer who was working in corporate environment.
And they were having the same issues with automation until he developed a framework that was, in effect, a wrapper around Selenium Webdriver.
He extended the library over the years creating lots of methods that were making automation a lot easier. Not only that, but his framework
was using labels instead of ID’s or xPaths, making the tests a lot more stable. I adopted this solution and our productivity increased
drastically. Although it’s hard to say precisely by how much I can approximate it around 75%! Because we were basically only writing the
test cases using Cucumber. That’s it! On occasions we would have to create new methods which would only extend the framework.
I was happy for a while but then… I just thought: “What if the test cases in Cucumber would write themselves? After talking this over with Nicolae Matei, this idea got us to TestyBot. As of now, our little robot still needs some human assistance: it cannot create the automation scripts in a matter of minutes. But it can create, with a little help, hundreds of stable, well written automation scripts. In a matter of days instead of months! Just think of the time and money one can save using this tool. Have a tight deadline? Have a small budget for automation? Want to make sure everything is OK on your website? TestyBot is the answer!
We also offer a place for these automation scripts on our Jenkins server. You will be able to run your tests at any time, have reports sent to you via email and keep a history of the results in Jenkins.
Our plans are to offer companies a full, yet cheap and ultra fast automation solution, where all they have to do is to complete a form on our website.
We want to improve testybot to the level where our clients will be able to receive hundreds of automation scripts in a matter of minutes.
We use SSL for data encryption; so when you fill in our form your data is safe.
For more information please read our Terms & Conditions page.