There is no other way but automation. Interview with Shrinivas Kulkarni. Part I
Through his career Shrini has worked in companies like Microsoft Global Delivery center, iGATE Global Solutions, and currently engaged to Barclays Technology Center India activities. Having over 16 years of testing experience hе worked in many roles covering entire spectrum of IT – like Software developer, Project lead, SQA lead, Test Lead, Test Manager and Solution Architect.
According to him «Test automation is probably the most misunderstood concept in the field of software Testing…». a1qa invited Shrini for an interview to discuss this topic.
a1qa:.Shrini, we are grateful that you accepted our invitation. The first question goes to the core of automation process. Are there any determined practices where we should definitely start testing automation and when it’s worth finishing? Could you please share your viewpoint about, where this border is in Test Automation?
Shrinivas Kulkarni (S.K.):. Before I answer this question, please let me turn to background. When it comes to automation – one thing that I have not heard much talk about is the industry or domain in which testing/automation is happening. I have studied the industry as a consultant working for IT service providers and an automation developer for software development companies, for last 10-15 years. The beliefs, practices and expectations from automation in these business domains (hence need testing and hence automation) are very-very different.
Coming to your question of when to start and when to end automation, I think one needs to take into account the type of business/industry, where automation is used. Traditionally software product companies never had (I think that is true even now) a specific thing called automation or automation team. It was all part of development. In the present world, companies like Google, Microsoft have taken the idea of automation to a level, where engineers in these companies cannot (at almost all times) distinguish between writing code and testing. Testing = writing some code to test another piece of code. This is how product companies view automation. Here there is no clear start or end of automation – it is all part of the lifecycle, happens throughout and continuously. Agile movement eradicated any traces of separate automation cycle/effort/start-end through the practices of XDD – X would be any favorite letter such as “B” or “T” or similar.
a1qa: How actually IT world sees the automation?
S.K.: In the world of IT service providers or offshore tech centres of Banks, insurance companies – automation takes a whole new meaning. It is seen as a means to cut down costs, reduce time and effort of testing. It is founded and tracked as a separate (at times totally disjointed from core dev/test teams) activity. How it became this way? In the world driven by outsourcing – the IT service providers are constantly in need of broadening and deepening the services to continuously generate revenue. This often causes situations (sometimes artificially) where they need to look at testing, automation and other related services in another way. First comes independent testing that is disconnected from the development team. IT service providers essentially operate in this model. More separate and disjointed services – more revenue.
How do the IT service providers look at automation? Mostly as a means of cutting testing costs, this is a primary and most popular way of selling automation. On the surface, it might look plausible that a sensible automation, aligned to development life cycle can help to reduce cost of testing and improve value out of testing. But the way IT service companies sell and approach automation has – over a period of decade or so – created more concerns than solutions and benefits. The start and end of automation in such conditions depends on many factors such as availability of funds, technology road map of products, status of testing etc. In my opinion, IT service industry should adopt the model similar to software product companies – treat automation as continuous process, running alongside the development cycle – with no definite start and end. But then, they have to figure out how to sell such long running automation service that costs more, though they sell it as a cost saving method. That is a puzzle, a difficult one. Thus these companies have chosen to downplay the issue.
a1qa:. In your opinion what indicators can prove effectiveness of Automated Testing implementаtion? And which of them can be applied to people, who involved in that processes?
S. K.: One sign of successful automation is its widespread usage. Any automation that is outdated, cumbersome to maintain and use – would be put aside by testers and developers alike. Do not make a mistake – the primary aim of automation is to assist testing in coverage, speed and filling gaps/shortcomings. Effective automation works to help human testers to be more productive and efficient. On the contrary to popular belief – effective automation would allow broader testing assistance to skilled human testing in the areas where machine/computer program does things better than a human. Successful automation makes more people to embrace it and promote.
Cem Kaner defined automation or automated testing as an assisting testing tool. You would be surprised to see that many software applications such as MS Excel can assist so much in testing that Excel can at times be used as an automation tool. There are similar examples from Non-windows world. The bottom line is to ask “what can enhance my productivity and efficiency as a tester” then pick tools that help in specific direction. Anything that helps testing is an automation tool. Many specialists in our industry don’t think of automation like this and that is a problem…
On this Thursday we continue the conversation with Shrinivas Kulkarni about test automation.
You can check his blog here.
