Why I hate being called a Tester?

Posted on July 13, 2015 by Ashok Tulachan — 2 Comments

Courtesy from Kualitatem.com

Once upon a time, a small agile team comprised of a Software Developer, Product Owner and Automation Engineer (tester as per agile) were traveling to San Francisco for milestone celebration after their strenuous effort on the last release. In the middle of the flight, the plane was hijacked and the company were handed a release clause that was to hand million dollars per person if they want them to be rescued. Now being realistic and financially sound, what would you think the company chose out of three? I can see lot of people opting first for product owner as they create a vision for the product and market them. Then, I see the company opting for developer as they write code, which could help generate value and millions of dollars for the company. Now the company has to make a final decision. The company weighs up to rescue the tester and lose million dollars or ignore the clause and hire some new tester and train him. Finally the company decides to go by the latter as they think Automation Engineer is crucial but not required for the software to be delivered as the developer could test their code themselves. Also, the company believes that they can hire the intern as tester and ask him to learn automation skills easily.

Despite the fictional story that I exemplified above which would never happen, Automation Engineers/Testers/Test Engineers are underestimated by the top level managers pretty much every day. As an Automation Engineer, I have seen some companies’ value work of automation engineers but there are many who assume that they can be hired in the craigslist just as the contractor for painting the house. During my last stint, when the project was cancelled due to stability of the buggy application, both automation and manual testers were the first one to be kicked out of the door. However, big companies like Amazon and Google tend to value the importance of testers and refer them as Test Engineer or Software Engineer in Test due to which, their products seemed to be stable and successful compared to other companies.

Appium – The Ultimate Mobile Automation tool!

Posted on June 9, 2015 by Ashok Tulachan — Leave a comment

Courtesy from speedy.com

As I hop the elevator to go to my work place on 8th floor, I scrambled my pocket and took out my smart phone to check my email and facebook. I gazed around and almost everyone in the elevator was doing the same. Everyone had smartphone whether it was iphone 6 or Samsung galaxy S5. You can call it social awkwardness to use the smartphone for being forced to stand near the stranger or the person you haven’t meet. But in technology, that pretty much means, mobile apps have taken over the consumer world. Well not entirely but pretty much! Companies that were too hesitant to embrace the mobile technology, have dwindled. Just ask Microsoft and Blackberry! However, companies like Amazon, Apple and LinkedIn who have embraced mobile technology, have dominated the Consumer-Centric world. Almost billion people are using the mobile apps for their daily use or entertainment purpose.

When we talk about the popularity of mobile apps, We talk about mobile testing and definitely mobile automation. Although many automation tools such as Telerik, Test Complete and framework like Calabash are available in the market, Appium has become the most popular automation tool and framework for the mobile apps. In this article, I will talk about the advantages and limits of Appium.

In a nutshell, Appium is a free open-source automation tool for automating native, mobile web and hybrid applications on iOS and Android platforms. Before delving deep on Appium, it’s very important to know the difference between the native apps, web apps and hybrid apps. Native apps are apps written using the iOS or Android SDKs. Mobile web apps are web apps using a mobile browser. Finally Hybrid apps are apps which have wrapper around a webview a native control that enables interaction with web content. Appium basically is a Node.js application i.e. javascript which helps you to automate the app using the simulator/emulator or the real devices.

Tagged with: Appium, Mobile Automation, Mobile Testing, Selenium, Webdriver
Posted in Appium, Mobile Automation, Mobile testing, Selenium, Webdriver

Automation Anti-Patterns: Myths Exposed!

Posted on February 4, 2015 by Ashok Tulachan — Leave a comment

Sincere apology to all my readers, followers as well as Automation addicts like me in the world. It’s been a while that I haven’t had time to publish the articles on my blog due to time constraint and new project that I joined making me a big procrastinator. However after watching Joe Colantonio’s video blog, I couldn’t resist to write another one that I have been putting off for long time.

Automation is basically defined as the testing operation to help minimize the manual interactions and eliminate the humanly errors made while testing the application or a tool. Although Automation has just recently drawn the applauding headlines in QA/Testing environment, there has also been increasingly false assumptions or myths that Senior Business/ QA Managers have coined regarding Automation. On this blog, I tend to uncover the top five myths of automation.

Here are some of the basic myths of Automation that management tends to think about.

First and foremost assumption that Automation is another Quality Assurance(QA) tool. Although it’s another area of Quality Assurance, it definitely needs as much focus as developing a software product although the turn out might not be as huge as developing a software product. That means automation framework will need automation engineers that have programming knowledge, experience and expertise.
Non-technical Managers assume that Automation using Record & Run will save time automating the manual procedures. Although I am not totally against record and run for beginners, the automation framework shouldn’t be dependent on record and run tool as it doesn’t contain the stable framework due to non-reusable tests increasing the time for maintenance.
Once Automation gets stable, there is no need of manual testers/testing. This is a huge and very dangerous assumption that some managers make regarding QA/Testing. Although automation could cover almost 90% of the test scenarios/cases eliminating the redundant test runs and lessen the human errors, it doesn’t have the intelligence that human being is gifted of. Automation cannot do the exploratory testing that manual testers could be involved in finding interesting intelligent bugs in the application.
Automation covers 100% of your test cases. This is another common myth that most of the QA managers/engineers assume while relating automation. Although automation can cover 90% of the test cases, it will be very hard to test the UI issues along with the sounds/image look that the application can trigger.
Last but not least, Automation tool is expensive. Although some automation tools such as UFT(QTP), Telerik, TestComplete could cost some money, there are open resource web automation tools such as Selenium that will not cost a cent. However, the need of Automation Engineers that have programming background is essential in order to succeed with open source automation tools.

Although there are other many myths regarding automation in the Quality Assurance area, I think the top five that I listed above are the top myths which has impacted all the testers/engineers involved in Quality Assurance area.

Tagged with: Automation, Automation Engineers, Myths about Automation, QA Testing, Quality Assurance
Posted in Automation Engineer, Automation Myths, QA Automation

How to Automate the Page With Identical Element Attributes?

Posted on May 12, 2014 by Ashok Tulachan — Leave a comment

Courtesy from http://niche-canada.org/

Similar to Dynamic element selectors, Identical Element attributes are also one of the nuisances that Automation Engineers face every day while automating the web application. Numerous posts are mailed daily in forums seeking for help to automate identical element attributes. In this blog, we will cover how we could automate the web application that contains identical element attributes.

While regular expression salvages us for the dynamic element pages, the Xpaths along with the some programming logic helps us to automate the identical elements which will be explained in detail in this blog.

To solve the problem, I have attached the html page snippet that contains the identical element attributes as shown below.

<div id="mainBox">
    <div>
        <label for = "divCustomer">First Name</label>
        <input name= "divCustomer" id="divCustomer" maxlength="64">
    </div>
    <div>
        <label for = "divCustomer">Last Name </label>
        <input name= "divCustomer" id= "divCustomer" maxlength = "104">
    </div>
    <div>
        <label for = "divCustomer"><b> Home Address </b>
    </div>
    <div>
        <input name= "divCustomer" id= "divCustomer" value="Address" maxlength = "554"></br>
        <input name= "divCustomer" id= "divCustomer" value= "Address" maxlength = "104">
    </div>
</div>

                         Code Snippet: HTML Page

How to Automate the Page with Dynamic Element Attributes?

Posted on April 2, 2014 by Ashok Tulachan — 1 Comment

Courtesy from xkcd.com

If you cringe looking at the page elements that have dynamic selectors whether it is id or name or class, you are not alone as most of the automation engineers including myself tend to do so. Although lot of pages tend to have identical class and name attribute, most of them still contain unique id which identifies itself with other elements which inadvertently makes the job of an automation engineer lot easier as the element can be selected using the unique id.

However, sometimes automation engineers have to accept the way the HTML page was coded by the programmers. Despite talking to the managers and programmers about making the element id unique, the request is seldom done because either it would take too long to do that or they would not care less. But still, the automation engineers still have to automate the application or the page by the end of the day in order to run their daily smoke test or regression suite.

Faced with this problem, I have seen probably hundreds of threads asking for help to automate the pages that have dynamic element attributes which keep on changing every time the page is loaded. However, we can still work around the dynamic pages with the help of Regular expressions. Regular expression again comes to a rescue!

To solve the problem, I have attached the html page that contains the dynamic ids for finish button in the snippet below.

Figure 1: HTML Code

Is Cucumber the Answer for Automated User Acceptance Tests?

Posted on March 24, 2014 by Ashok Tulachan — 5 Comments

Courtesy from cukes.info

As per Agile-Alliance.com, Test-driven development is defined as the style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring). As agile has taken over the Software Development cycle, Test Driven Development (TDD) has also grown rapidly as it embraces many principles of Agile methodology. In the simplest terms, TDD simply asks us to start simply, write automated tests that fail and refactor it to add decisions one at a time. Kent further claims that TDD is an attempt to give any software engineer, working in any environment, the sense of comfort and intimacy so that he/she doesn’t have to fear about the failed unit tests.

Compared to others, Automation plays a significant role in test driven development. Since the typical length of agile cycle is two weeks or less, the automated user acceptance tests helps the team focusing developers to write bug-free code while lessen the burden for testers and automation engineers. In the short agile life cycle of 2 weeks, there would be enormous amount of work for developers to write clean bug-free code while fixing the bugs already present based on the priority. Therefore, there will be hardly any sufficient time for the manual testers to test the entire regression suite in a span of 2 weeks. That’s where automation acceptance test comes into play in test driven development.

There are many test driven frameworks available in the market. Out of those, Cucumber has gained much attraction and deservedly so. Cucumber have leveraged the agile teams creating a team-cooperative environment for developers, automation engineers, manual testers and business analyst as they all can contribute to the project using cucumber. Now, let’s dive into the definition of Cucumber.

As per cukes.info author Aslak Hellesoy, Cucumber is a living documentation and a command-line tool that let software development teams or automation tests describe how the tests or software should behave in plain text. The text is written in a business-readable domain-specific language serving it as documentation for business analysts and manual testers which is then connected with the programming code which will test the application as per the requirement. Cucumber has extended their support to work with Ruby, Java, .NET, Flex or web application written in any language. Although cucumber could be used with other primary languages such as Java, .NET, Flex etc, it’s commonly used with Ruby and therefore I have used Ruby as a primary language in the article.

Tagged with: Automation, Cucumber, Gherkin, Ruby, Ruby Cucumber
Posted in Cucumber, Ruby Cucumber, Selenium, User Acceptance Tests

Which programming language do I use for Automation?

Posted on March 4, 2014 by Ashok Tulachan — Leave a comment

Courtesy from blog.utest.com

As technology has changed drastically, the importance of Automation has also propagated exponentially. As per salesforce.com, about 1 million browser tests run every day in 50,000 VM’s. If you just think about it, that’s a lot of automated tests in one day but with the cloud computing business scale that sales force provides, it can definitely be a necessity for the company. During the Selenium meet-up at Sanjose, Greg Wester from Salesforce.com stated that the quality assurance at sales force is entirely dependent on automation that means no manual testing is done at all except few exceptions.

Now and then, I have been asked from my fellow colleagues about the best programming language to learn automation or to apply automation at work. My immediate answer always tends to be: “It depends”. It’s a complicated question and depends on lot of factors which I have attempted to describe below.

Tool: All automation tools are developed by certain programming language and therefore there is need to learn the programming language that the tools support. For instance, if you are using Quick Test Pro (QTP), the primary language that you need to learn is VB Script. Similarly, if you are using Test Studio, then you will need to learn C# or VB.NET. However if you use Selenium then you have variety of options to choose from which are C#, Java, PHP, Python, Ruby and JavaScript. Each language has its own advantages and disadvantages so it’s very hard to decide which one is better than another.
Project Framework: Although this factor can be very debatable but still many companies tend to use the same language that the developers use to develop the application. In most companies, Java is the commonly used language and therefore the QA Managers tend to use the same programming language with the concept that there is help when needed from the developers. However some QA teams tend to use different language that they think suits the most disregarding the language that the company uses to design the application.
Team Knowledge: In my opinion, this factor plays a great role on determining the tool and the language for automation. If all or many QA Automation Engineers feels comfortable with any particular language, then that particular language should be opted for automation. Any new Automation engineers can be recruited with the language that was selected by the team. Personally, I have worked with many different teams which used variety of languages such as C#, Java and Ruby as the team opted for the language that they feel the whole team was comfortable.
Automation Framework Support: Another factor to consider a programming language for automation is the support availability. For instance, since Java is the most commonly used language for automation, it has a significant amount of Selenium Java users and hence more automation support in Selenium. On the other hand, Python along with C# probably has the least automation support for Selenium so it will be very hard to find help if needed. Unless the automation engineers are expert in certain programming language, it is very important to consider the automation tool support especially for Open source tools such as selenium while deciding the programming language for automation.

Are you a Software Engineer in Test or Test Engineer?

Posted on February 26, 2014 by Ashok Tulachan — 3 Comments

Technical recruiters are always looking for automation engineers or testers that can deliver valuable contribution to the company saving lot of time and resources. Although different company uses different approach to recruit automation engineers, nowadays most of the companies are following the model that Google has implemented successfully to hire the engineers for their need.

As explained in “How Google Tests Software”, James Whittaker, Jason Arbon and Jeff Carollo has described the three roles that Google have created making the engineers responsible while making productive and more quality-minded which are described below.

Software Engineer (SWE) : SWE’s play the role of tradition developer writing functional code that is dispatched to the user. They also create design documentation; choose data structures and overall architecture of the automation framework. They are involved in writing test code, test-driven design, unit tests and they own quality for everything they touch whether they wrote it, fixed it, or modified it.
Software Engineer in Test (SET): SET also wears the hat of developer role but focuses on testability and general test infrastructure. SET’s review designs and looks closely at code quality and risk. They are more involved in refactoring code to make it more testable and write unit testing frameworks and automation.
Test Engineers (TE): TE is similar to SET role but focuses on testing on behalf of user first and developers the second. They are involved in writing the code that drives usage scenarios mimicking the user. In short, TE’s are product experts, quality advisers and analyzers of risk.

Although the definition of three roles seems self-explanatory and we are more interested the later two roles, lot of people including myself are always wondering what engineering hat do we wear every day.

To answer the question, James Whittaker, Jason Arbon and Jeff Carollo has summarized the list of questions that could help you decide whether you belong to the SET or TE.

	Ashok Tulachan on Why I hate being called a…
	Tester on Why I hate being called a…
	vikrant on How to Automate the Page with…
	Vishal Aggarwal on Is Cucumber the Answer for Aut…
	Dwarika on Are you a Software Engineer in…

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: