Doveryai, no proveryai - Trust, but Test!
Blog on Software Testing, Offshoring, Testing Centre of Excellence - Suresh Nageswaran
Doveryai, no proveryai: Suresh's blog on Software Testing
What this blog is about ...
Every blog should have a purpose and the audience gravitates towards the content when they identify with the purpose themselves. This post is my attempt to outline the raison d'être of my blog.
A lot of you may have been following my earlier blog at testingreflections.com here : http://www.testingreflections.com/blog/76
That one was a technology focused Performance Testing blog. This time, I intend to paint on a larger canvas.
For those who came in late, a little something about myself:
I have spent over 13 years in the software testing industry, working for top consulting firms in India, the US and Europe. This has seen me work in different geographies like the US, the Netherlands, France, Germany, the UK, Japan and India.
Specifically, over the last 5 and half years, I had the opportunity to build a testing service practice at one of the largest European consultancy firms. A practice that was focused on offering testing services to the financial industry - namely, large banks, insurance companies, capital markets firms etc.
It's been a roller coaster ride, with my work spanning everything from hiring good technologists, creating the business case for top management, advising and consulting with top client CIOs to managing projects and selling services. Of course in the inital couple of years, I pretty much did everything from waiting on tables to cooking the food (metaphorically speaking!).
Some of the most interesting work in the last couple of years had had me running a Services Innovations team focused on creating testing services for the financial industry. It has had quite an impact to our bottom lines, since the Test Assessment service offering that I designed had opened doors to some $24 million worth of new business for the company.
This blog is to share the experience of creating a testing services practice, setting up Testing Centres of Excellence (TCoE) / Test Factories that leverage talents from multiple geographies, the hows and whys of creating business cases from a services viewpoint and some crystal ball gazing on my part.
I'm no Alvin Toffler, but I think the Software Testing profession is in flux influenced by technology changes, consolidations in the tool vendor space, the mushrooming of open source techniques, process models, tools and of course, newer business /regulatory pressures. It will be my endeavour to outline how this will influence our world.
A lot of you may have been following my earlier blog at testingreflections.com here : http://www.testingreflections.com/blog/76
That one was a technology focused Performance Testing blog. This time, I intend to paint on a larger canvas.
For those who came in late, a little something about myself:
I have spent over 13 years in the software testing industry, working for top consulting firms in India, the US and Europe. This has seen me work in different geographies like the US, the Netherlands, France, Germany, the UK, Japan and India.
Specifically, over the last 5 and half years, I had the opportunity to build a testing service practice at one of the largest European consultancy firms. A practice that was focused on offering testing services to the financial industry - namely, large banks, insurance companies, capital markets firms etc.
It's been a roller coaster ride, with my work spanning everything from hiring good technologists, creating the business case for top management, advising and consulting with top client CIOs to managing projects and selling services. Of course in the inital couple of years, I pretty much did everything from waiting on tables to cooking the food (metaphorically speaking!).
Some of the most interesting work in the last couple of years had had me running a Services Innovations team focused on creating testing services for the financial industry. It has had quite an impact to our bottom lines, since the Test Assessment service offering that I designed had opened doors to some $24 million worth of new business for the company.
This blog is to share the experience of creating a testing services practice, setting up Testing Centres of Excellence (TCoE) / Test Factories that leverage talents from multiple geographies, the hows and whys of creating business cases from a services viewpoint and some crystal ball gazing on my part.
I'm no Alvin Toffler, but I think the Software Testing profession is in flux influenced by technology changes, consolidations in the tool vendor space, the mushrooming of open source techniques, process models, tools and of course, newer business /regulatory pressures. It will be my endeavour to outline how this will influence our world.
Testing, Test Engineering, Quality Assurance?
A couple of months ago, a colleague of mine and I hijacked a regular sales conference call. So one moment we're talking about open sales leads and client situations and the next moment, the conversation veered around to how we needed to revamp our Test Maturity Assessment offering.
That's when we started to argue whether or not our existing service offering (built around Test Process Improvement - TPI®) should be rebranded as the Quality Blueprint. This is no innocuous discussion, because in effect, we were debating whether it was Software Testing or Quality Improvement we offered our customers.
Now I should possibly go fully disclosure and admit that I'm from the engineering side of the house, having spent over 13 years in this profession. Sure, I engage with clients all the time and sell them services I genuinely believe are going to improve the overall reliability of their business systems. But I can't see myself as someone only from the sales side of the house. My colleague, on the other hand, was more of a marketing maven. Arguably, he was more wedded to how we'd be perceived by the market. Two individuals, two perspectives.
I don't see software testing as anything but another engineering discipline. Quality improvement and assurance is more to do with the classical "process + people" doctrine. Software testing does not improve quality, it is merely a lag indicator of deeper issues within development and deployment. I see it merely as a harbinger of tidings, good or bad. One viewpoint is around how Quality Control tries to achieve the same thing as Software Testing. History tells us that QC is a means of oversight and stories about of how King John of England employed William Wrotham to surpervise workmanship during the contruction of the English fleet. That's oversight, not engineering. What we do in Software Testing has to do with the design of tests, which, with the advent of complex technologies has become an engineering discipline in it's own right.
I'd assumed that pretty much a consensus of sorts had developed around this subject. After all, what one should call oneself pretty important. Professionals need to be able to define their profession and explain in simple layman's terms to their 6-year-olds exactly what it is that daddy does at work.
I know what I am. I'm a Test Engineer.
That's when we started to argue whether or not our existing service offering (built around Test Process Improvement - TPI®) should be rebranded as the Quality Blueprint. This is no innocuous discussion, because in effect, we were debating whether it was Software Testing or Quality Improvement we offered our customers.
Now I should possibly go fully disclosure and admit that I'm from the engineering side of the house, having spent over 13 years in this profession. Sure, I engage with clients all the time and sell them services I genuinely believe are going to improve the overall reliability of their business systems. But I can't see myself as someone only from the sales side of the house. My colleague, on the other hand, was more of a marketing maven. Arguably, he was more wedded to how we'd be perceived by the market. Two individuals, two perspectives.
I don't see software testing as anything but another engineering discipline. Quality improvement and assurance is more to do with the classical "process + people" doctrine. Software testing does not improve quality, it is merely a lag indicator of deeper issues within development and deployment. I see it merely as a harbinger of tidings, good or bad. One viewpoint is around how Quality Control tries to achieve the same thing as Software Testing. History tells us that QC is a means of oversight and stories about of how King John of England employed William Wrotham to surpervise workmanship during the contruction of the English fleet. That's oversight, not engineering. What we do in Software Testing has to do with the design of tests, which, with the advent of complex technologies has become an engineering discipline in it's own right.
I'd assumed that pretty much a consensus of sorts had developed around this subject. After all, what one should call oneself pretty important. Professionals need to be able to define their profession and explain in simple layman's terms to their 6-year-olds exactly what it is that daddy does at work.
I know what I am. I'm a Test Engineer.