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…

Sunday, January 24, 2016

Life moves on. Thank you, Fiberlink (IBM)

I wasn't challenged at my job as I had spent just over 5 years at my first job at EFI. Most of them who had joined with me had quit. I had groomed my skills at EFI - thanks to the 9-6 office timing. I would reach home by 7pm and practice. I used to practice at 99tests, participate in Twitter conversations, read books and blogs. One fine day, I got a call from 99tests Founder - Praveen Singh that MaaS360 wanted to give a project to 99tests for 6 months. Before that, they wanted to have a pilot for a month with 1 tester. I was the chosen one. I tested the product. I also got my first Android smartphone for that (which I still have in perfect working condition).

After 2-3 weeks of testing, the QA director at MaaS360 called me for a chat. I kept on refusing. But after persistent calls and emails (6 to 7 times), I finally went to the office for a chat. They liked the reports and I liked the complexity of the product. I was offered on the spot and in the name of chat, I was interviewed :) I resigned from EFI the next day and after serving the notice period, I joined MaaS360 (Fiberlink) on Jan 30, 2012.

My first blogpost after joining the company is here: http://enjoytesting.blogspot.in/2012/02/new-job-best-is-yet-to-come.html

There are many things I got to learn - both professionally and personally. I would like to highlight some of them below:

After close to four years of working at Fiberlink and IBM (IBM acquired Fiberlink), I wanted to try my hand at freelancing. I wanted to get out of corporate culture, the performance appraisals, the fixed timings and working on the same projects. I did not have any problem continuing what I did for my last four years but the urge to engage more with the testing community is strong. 

I want to spend more time focusing on individual testers, sharing what I know, helping small teams achieve greatness. It is time to move on. Thanks Fiberlink, IBM for the learning and the happy memories. Till the next blog post, be fearless and follow your heart :)

Leia Mais…