go back to the blog

Changing Metamorphosis – Journey into the Next Form for Testing!

  • 04/07/2013
  • no comments
  • Posted by EuroSTAR

Testing is increasingly beginning to feel the push from two very interesting but intrinsically-related factors, which is driving the Testing World into a difficult situation. Time is now to either change the complete paradigm slowly but surely or degenerate into a phase where testing is seen as a volume-only game driven primarily by rate and the resources are branded semi- or unskilled with hardly a career line. Testing today is increasingly taking the slot for the best place/phase to manage an IT budget cut and also something you can get done with “any” set of people – which hardly need any experience or expertise. Whatever small part of the story we call niche testing mostly involves only technology! Let’s look at the two factors key to this scenario in a little more detail to understand this better.

Factor I – Technology Trap

kumar pic1_300x161Quite often, and it is true very often, we tend to become so transactional that it becomes difficult to connect to the Big Picture of why we are doing something! Technology, for instance, has taken such a predominance among us all geeks that we tend to think that businesses exist for technology – forgetting that technology has no business to exist if it did not help businesses drive efficiencies – either through better time-to-market or reduced cost for doing something or increasing the quality of an end-user product!
This is the first factor that is affecting the testing World! The Testing World has made rapid strides. We talk about evolution in our ability to automate and perform state-of-the-art testing and setting up Testing Centers of Excellence (TCoEs). However, we are completely bogged down by jargon that we approach problems and solutions with a monotonous narrowness and focus to just make something work; without an iota of thought on how far the testing is worthwhile for the business being supported! Everything we look at is highly technical in nature – be it the way we do test planning, design, execution and also the way we report- every aspect is mired in a Web of technical conundrum. The fundamental reason – to drive business efficiency for the customer – for doing testing sometimes (or many a times) is camouflaged completely from the normal vision! No doubt, we do talk a lot about domain testing; but, invariably get slowly pushed into the same technology trap at some point in time! The absence of the understanding of where we are and what needs to be done generally drifts us back into a technical lane that turns boilerplate!

Factor II – Commoditization of Testing – The Other End of the Spectrum

kumar pic2_499x279

While the “technology for technology sake” testing is at one end of the spectrum, the other end seems to be the phenomenally high level of “commoditization” of testing in the services space! While thinking through where the source of this problem lies, one is tempted to question as to what makes testing, especially in the services space, tick? They call testing “vanilla service” or a “commodity service”. Most of the large testing deals today end up being decided primarily on price after a never-ending rate war (though neither vanilla nor any of the commodities come cheap today!).

We do talk about many value differentiators in the form of automation, tools, techniques, processes etc.; but ultimately, none of that gives a compelling reason for the CXOs to change their mind from looking to manage their budget cuts primarily through testing. This situation leads to testing vendors driving down price drastically to avoid losing business. However, to make ends meet, they end up delivering with low-end and relatively inexperienced resources. Though, superficially, the situation looks a Win-Win, these decisions will come back to haunt everyone as they manifest in the form of a chaotic IT landscape that produces a “Not so” end-customer-friendly and unreliable applications in production with a high level of unpredictability and possibly downtime, resulting in extremely high impact to business and increase the overall IT cost exponentially!

Attributing this to the short-sightedness of the CXOs is not right! The Testing World is refusing to evolve itself beyond the technology space (or the niche services as we call) and the rest is just a group of manually-driven redundant executors, who are increasingly been seen as not adding value to the end-outcome! In this scenario, it is only too obvious that testing gets the stick! The inability to show or create the differentiation has made testing heavily “commoditized” – to the extent that it is in jeopardy of being aligned with the business process outsourcing services – which are generally semi-skilled and is neither categorized as a niche service nor seen as a career line for people!

A Paradigm Lifecyle Shift – The Next Change in the Metamorphosis

It is important to accept and agree to the fact that all of us are in a state of taking the next jump in the evolution of testing. We are set to enter a time of transition – we have been through this before when testing was just a pushover and overtime, came to be slowly recognized as a necessity and today, a specialty. However, when even this specialty is turning extremely commoditized, it is imperative that we re-invent ourselves to enter another phase – a critical one – of transition into the next Avataar!

A more detailed analysis of the issue will clearly signal a need for change in the way testing is currently positioned in the IT lifecycle – A Paradigm Lifecycle Shift! What does this mean? Today, testing is primarily driven by development – both in lifecycle as well as in operation. This development-driven focus is the reason for the technology getting to the fore and domain/end-user being pushed behind.

Therefore, the only way testing can retain its rightful place is by changing its outlook and therefore, its focus, organization and overall approach.

kumar pic3_499x325

Changing Lifecycle Dynamics

It is important to drive a Twin focus rather driving with a single focus and trying to bring in multitude of things from different perspectives.

This is change in the overall lifecycle dynamics. While in the traditional V-model, testing is supposed to be involved from the early stages – from testability of requirements thru test design and then execution – it is still lacking – in most of the cases – the testability approach from a business or customer perspective. It is more of a functional/techno-functional feasibility of whether a requirement can be tested or not. Similarly, throughout the cycle, the focus on test design, execution and reporting will be more in terms of working out a way to make the product/system work in production – the scenarios created are more driven by application construct and not end-user construct; the execution is strictly following the created scenarios, the reporting on the status of pass-fail of the application construct and not business. Many of the cases, the UAT scenarios are created by the SIT team and hence, likely to lack the industry/business/customer focus. The root cause of this is the alignment of the testing organization either as part of the development organization (in the case of a projectized model) and even in an independent testing (functional or hybrid matrix), the testing team follows what is being defined by the development team as requirement and built! The level of communication of the testing team with the Bas and the business users is anywhere from minimal to nil – in most cases!

Twin Focus

The solution to this is to look at a radical change (not that radical though!) in the way the SDLC is driven. Primarily, it has to be acknowledged that testing needs to be focusing its efforts from two different perspectives:

1. Technology Focus – Idea is to ensure technically, the system/application is able to function to deliver the business requirements – this will primarily focus around supporting the development team in building and performing Unit and Assembly testing; in addition own integration/interface testing, automation, performance and regression (of all the listed testing).

kumar pic 4_499x170

2. Customer-cum-Business Validation – this works under the premise that it is important to have a well-interlocked business (call it UAT or end-users – whoever drives the business requirements), Bas (the business analysts who convert the business requirements in functional designs and what we call as the Test Bas – the testers who will drive this validation – primarily focusing on what is being delivered to business and finally, to customers, why it is being delivered, how it will impact/enable the end-users, under what conditions are they expected to use these functionality and how will it manifest? This is very critical to ensuring that IT delivers what business wants and something that will make the customer experience better (directly or indirectly).

Operationalizing the Change

The next question is how to operationalize such a change? There is not a major change in any of the processes, workflow or standards adherence. It is primarily a mindset change and accept that it is important to categorize and create two pockets of testers – one to be aligned with business – Always! And another working closely with all stakeholders and focusing primarily on the technical aspects of the requirements.

Where do we start?

The following are some of the low-level activities that need to be performed to change into the new model:

1. Break the exiting Test team into two – One with Technology focus and another with Business-cum-Customer focus.

2. Align the technology team closely with the Development team

3. Align the Business-cum-Customer focus team with Business Group (that is responsible to work with IT).

4. Ensure the BA Group continue to work with Business Group (and hence, the Test BA Group) and delivery functional designs and manage the overall business analysis phase and all follow-ups.

5. Execute the lifecycle as per the normal model – expect the stakeholders in each phase and roles and responsibilities will need to be modified as per the new change.

Impact on Cost, Quality and TCO

The impact on cost is likely to be nil to may be positive – as we start driving better efficiencies through closer interlock among the Dev-technology test team and the business-BA-Test BA teams.
If the model is implemented successfully, it is likely to show a significant difference in the quality of the end-product – again, because of common sync on what is to be delivered and testing focusing on ensuring those.

The Total Cost of Ownership is likely to see a positive change because:

1. The overall cycle time for test design and execution will go down due to clear segregation of responsibilities and early interlock with business.

2. The ability to identify critical defects early due to identification of the right scenarios and ability drive a better risk-based approach.

3. Interlocking develop-technology test will enable effective unit and assembly testing (or CIT as it is called in some places) helps deliver reasonably good build for the Business-Customer-Validation team.

4. UAT will be an extended test and will flush out all possible critical defects before going into production and hence, driving down the overall Cost of Poor Quality.

5. Ability to optimize the number of environments is a possibility but not from Day one.

Pitfalls/Challenges of the Model Change

Some of the pitfalls of this change are:

1. Certain organizations have a very rigid business-IT heatmap that it becomes difficult to drive any change in their interlock structure.

2. In addition, it is possible that this change may result in some change in the overall powermap, especially in functional test organizations as test teams need to be aligned with the development (technology test) and Business Group (Business-cum-Customer Validation Test). Hence, this may not suit all organizations directly as they are.

3. There may be an initial cost in driving this change – which may become an entry barrier.

4. Organizations that averse to taking medium risks – which this is definitely – may not be ready to go for it.

Closing Bell

All said and done, it is definitely time for the testing fraternity to look at the relevance chart of their Testing Group. It is important that we reinvent ourselves and if we need to change to do that, so be it! Let us accept that it is important to change out mindset on thinking that testing is always going to be treated as a separate phase and will continue to enjoy its rightful place in the SDLC. If we do not accept, embrace and drive this type of a change, someone will!




kumar raman_120x89Kumar Raman is a Senior Manager at Large multinational IT company working out of its Chennai Development Center in India. Kumar is a member of the testing platform helping testing projects achieve greater value. Kumar comes with over 15 years of total experience and is a Testing SME specializing in working with clients in defining Test Organization Models, Testing Centers of Excellence and overall, reducing the Total Cost of Ownership (TCO). Before joining a Large Multinational IT company, Kumar was leading the Testing Practice for one of the domains for a US-based software services organization and was responsible for driving growth, rolling out offerings and supporting customers in optimizing test organizations. Kumar has a PMP and CSTE.

The views and ideas expressed are authors and does not necessarily represent the firms.

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery