Wednesday, May 25, 2016

Interview with Sahi Pro - The Tester's Web Automation Tool

I am Ajay Balamurugadas and I welcome you to our weekly show where we interview one of the promising leaders of the industry. It gives me immense pleasure to introduce today's guest. He has been a consistent performer in web automation and built a strong hold in a very competitive market. When everyone built the automation frameworks, he focused on what is important - automating the checks. His unique philosophy of helping the tester makes his tagline - "The Tester's Web Automation Tool" the Sahi (correct) tagline for him.
Without further ado, let us welcome -
Sahi Pro: The Tester's Web Automation Tool 
Ajay(A): Hello, Sahi Pro. Welcome to the show. We are very excited that you are here today to interact with us and share your expertise. You are one of the few automation tools who is tester-friendly and gets the job done in a simple manner. Tell us about yourself and your journey.
Sahi Pro(SP): Thank you, Ajay. It is my pleasure. I started as an open source product and then due to customer commitments, I started to focus on my Pro version and fulfill customer expectations. I noticed excellent testers struggling to automate due to complex automation tools. So, I evolved to enable subject matter experts and testers to get into automation easily.
A: Yes, that is indeed strange. When everyone around you focuses on building a robust framework and turning testers to coders, you have taken a different route altogether...
S: I will not say that we have a taken a different route for the sake of being different. My thought process is continuously evolving based on the testing industry and trends. I quickly realized that most of the end users were expected to be technical programmers or automation engineers. They were expected to build a framework from scratch, get the developers write code to align with the element identification mechanism and after all this, focus on automating the checks.
I found it quite disturbing. The purpose of web automation is to automate the checks, give the testing team the confidence that the regression bugs they expected to find are not present. The tool should free up the tester's time. Testers should explore the application and find more critical bugs. I don't expect my users to be technically super-strong. I take care of everything to help the tester, right from identifying the elements, suggesting accessor alternatives, providing relational APIs, excellent logging and reporting, calling Java functions and libraries from my script, automatic screenshots on failure and believe it or not, I automatically wait for page loads and AJAX activities to end!!!
A: Whoa! That's quite a big list of key differentiators! Tell us about your element identification mechanism.
S: I use my own wrappers around the Javascript DOM to identify elements. My APIs use various DOM attributes of an element to identify them. Instead of relying on a single attribute, I look for the element's value, name, id, css class or index etc. So, I work well even if multiple elements have the same attribute value. If I am unsure about a particular element's identification, I rely on my trusted advisor - the Relational APIs to identify one element with respect to another.
A: Many testers want to learn automation and give up as soon as they face problems in learning a particular language. What is you suggestion to them?
S: Yes, that is a common story. People are spending time learning the language more than automating the tests. I am not against anyone learning a language but let us remember why we started this discussion. A tool should enable people to automate and not set restrictions on the way. I am an extension of JavaScript and have a pretty good recorder which can create scripts for further usage. If you have never used any tool for automation, try me!!! If you already burnt your hands spending a lot of time learning a language with little success, let us pair together and see if I can help achieve your goals.
A: Are you only for newbies or can experienced folks take advantage of your prowess?
S: As I have already highlighted, my recorded scripts can be used as a good starting point for further scripting. My JavaScript is executed in a Rhino JavaScript Interpreter, running inside my proxy. As Rhino is a JavaScript runtime running inside a Java Virtual Machine (JVM), this adds a lot of power to my scripts. My scripts can directly call Java code in scripts.
A: I am sure, our readers are excited to try you and your APIs. Does anyone provide training or demo about you?
S: The folks at Tyto Software Pvt. Ltd seem to be quite helpful in this regard. Shoot an email to info[at]sahipro[dot]com or check out the documentation about me at http://sahipro.com/docs/introduction/index.html 
I also meet my friends every Thursday in a webinar at www.sahipro.com/webinar
A: Thank you for your time, Sahi Pro. We wish you all the best for your future releases and features.
S: My pleasure. All the best for your series too. 
Feel free to add your questions as comments and we will get Sahi Pro to answer for you. 

Leia Mais…

Wednesday, April 27, 2016

Automation - The story you dread to hear...

Monday Morning 10:00 AM
Rakesh had just returned from the awesome conference on software testing. He being the Senior QA Engineer of the testing team was representing the company in the conference. They had sponsored this conference and had received one free pass to attend in a 4 star hotel ambiance. He had to present on what were his key takeaways from the conference. Rakesh had scribbled lots of notes in his brand new Moleskin notebook. It was time for the presentation.

The Punchline from the Conference
When everyone gathered with their laptops and coffee mugs expecting a boring presentation, Rakesh had a single slide which read “We need to automate but we have failed in our previous attempts. Should we try again?” There was pin drop silence in the hall. No one was even trying to drink the coffee. Rakesh had just displayed what everyone was thinking. No one dared to accept that they had failed to implement automation in their testing plan.

Let us have a brief look at their previous attempts to automate.
Attempt 1: Everyone automates, let us automate too!
The first time they tried to automate the tests, they just wanted to automate so that they are not left behind. Their application was not stable enough, there was no POC (Proof of Concept) done and the testers were confused whether to test or automate what’s working. Should they focus on finding new bugs or meeting the weekly target of automating 15 test cases.
This continued till the release date was near and everyone focused on testing rather than automating. No one talked about automation after that.  

Attempt 2: Automate 100%
The next time we had our testers return from a conference on Test Automation. Since then, we started hearing ABC pushes code to production in X seconds due to automation. They don’t have a single tester and everything is automated. Let’s just follow them. We are also the ABC of tomorrow. The testers had a tough time convincing the management about the difference between testing and checking. Thoughts on how testing cannot be automated were falling on deaf ears. The management was convinced that 100% automation was the key to the company’s and their success.

The last time we asked the team, they were still working on 100% automation. Few customers had lost faith in the product’s quality and were with the competitors.
Attempt 3: Automate key scenarios
After burning their fingers twice, the team was now focused on doing it right from the word go. It started with identifying key scenarios for automation. They had their test artifacts for manual testing. They hired two engineers who would help them with automation. The first complaint was that the test artifacts were not easy to understand by the automation engineers.
The team spent a considerable amount of time writing scenarios in a way understood by the automation engineers. Everything looked smooth till the final suite was automated.
Automation scripts was running successfully but it took 25 hours for full suite. As the team was hooked on to Agile, they were getting daily builds but the automation results for a build would come only the next day. By then, the team was testing on the next build. The failures anyways had to be validated by the so called manual testers as there were many false positives.
No one was ready to accept it as a failure as the team had spent a lot of time and effort in this exercise. It takes a lot of courage to accept one’s mistakes. Isn’t it?
Attempt 4: Automate to complement our testing
Finally, some good sense prevailed and testers were courageous enough to voice their opinion on where automation could help them in their testing. They did not pick the tool first and look for scenarios which the tool could automate. They picked the scenarios to be automated and then explored the tool which could help them. 
The team understood the reason for automation - complement testing. Use tools to come up with test data quickly, use tools to run smoke tests on every build, use scripts to confirm that things are working fine after minor changes in the code, build suites to check across configurations quickly.
The Climax
Every year as soon as the budget is allocated for the quarter, multiple teams jump onto the automation bandwagon and try to see if they can succeed at least this time around. Some invest on their skills, some on costly tools and some hire engineers who are good at automation. It is hard to convince testers that they need to be good in thinking and testing to be good at automation. Many testers are misguided and want to build their career based on a particular tool used for automation. Hey testers! What is your future after the tool has lost its sheen in the market?  Will you learn yet another tool?
Do not differentiate between manual and automated testing. Use tools to complement testing. Think deeply and critically before you embark your journey of test automation.
As mentioned in the above story, there are multiple such attempts everywhere in this software industry. Which attempt resembles your story? Share your learnings in the comments section and we can learn from each other.
Check out our weekly webinar on Sahi Pro - the web automation tool that doesn’t need any automation engineers to get started. Who knows, Sahi Pro might be the tool to help you achieve the success you are looking for.
Till next time, think of automation as a key activity to complement testing.

Leia Mais…