Chat with us, powered by LiveChat
Your address will show here +12 34 56 78
LPS, Testing

Are testers headed towards Extinction: BLOG# 2: Key Drivers
By Venkat Raghavan Test manager

And I am back… 😊 with Part II of my Blog Series. I hope you enjoyed reading the last one. Thank you all for your kind feedback and comments.

In the previous blog, we briefly looked at the triggers for change and the reason for the change. In this blog, we will look at the key drivers that will pave way for the future.



Shift Left, Fail early and Fast. Shift left and Fail early translates to using defect prevention techniques like establishing proper coverage (design, devand test), stringent peer reviews and early defect detection techniques like developing smart and effective unit tests, some examples are TDD , BDD or ATDD . Fail fast translates to using repeatable and scalable automation solutions. These can be for unit testing, code build /merge, deployments, functional and nonfunctional testing – Continuous Integration /Continuous Delivery.

And how do I embrace this #PHILOSOPHY:  How do I Shift left? The answer is simple, get involved in design, solutioning, unit testing (provide prescriptive list of quality goals) ; talk to the Product owners / BAs / architects /solutions designers / developers (#CULTURE) (#LEARNING) to understand why they are building the solutions in context to business value, what are the important levers, start thinking performance, security, scalability, functionality, recoverability, availability and start mapping these to the testing pyramid, and try and get as many early tests in as possible.


Upskilling isn’t just an organization mandate or personal development milestone anymore. It’s now starting to become an integral part of our job and making our team (#CULTURE) successful.

“There is only one good, knowledge, and one evil, ignorance – Socrates”


So, where did I START, … I started off with my online certifications (Udemy learning LPS can be a great place to start), youtube videos, brown bags, case studies, meetups etc.… to better understand the principles while still on the job and starting to apply those principles. I was interested in test management so I started moving into the enabler function. Then I stood up a few KANBAN and scrum teams. I also worked with the developers to drive an effective versioning strategy.

I helped the team move from SVN to BIT BUCKET, put together the automation strategy for continuous integration, kicked off developer peer reviews, created the first checklist for Unit testing, came up with the definition of done with the team, estimation techniques, did JIRA admin tasks like organizing epics, stories, setting up the board, setting up dashboards, integrating releases, testing, confluence, piloting the first rapid release change management process for agile projects, helped pilot automated deployment…etc. etc.

Now looking back I wonder if I have all the skills when I started? No, I didn’t. The team and I learnt and upskilled where there was a need and helped each other out. (#CULTURE) Did we limit ourselves to only testing? No, we did not. The testers sometime would do the peer review. Also the developers sometimes write the tests, etc… In summary, the team will have to rely on each other. Individuals will have to constantly keep upskilling and adapting with the team goals, as the team starts to continuously improve and optimize.



This is at the very heart of any successful organizations.

 “CULTURE is the invisible happy energy in an organization that makes boring work sound like play “ -Venkat Raghavan  😊

Does that mean you should have fancy slides, e-bikes, massage/sleeping pods, gourmet café and buffets etc. To make your organization “cool “… well in my humble opinion infrastructure can only do so much to get the buzz going. It is the interaction between people and people itself that drives this invisible force. How does one start, and how did I start…? It was not easy I must admit.

1) I started off with breaking the convention and removing the barrier of the what I am supposed to do as part of my role…If I saw a problem I either tried to solve it myself or take support or get the experts together and resolve it. It could very well be someone else’s problem that they weren’t able to solve, doesn’t matter… as long as it helps the team get better. Keep in mind, you may end up stepping on people’s toes, and they may not like, so tread with caution. To avoid such predicaments, it is best to rationalize and discuss the ideas you have beforehand with your team or workmates, and collaboratively solve the problem.

2) being truly humble and coming out of the “I” mindset and thinking of “We”, make it a point to celebrate the success and failure as a team, make everyone feel welcome and express themselves in decision making/meetings, make them each feel valued. 

3) Sharing is caring. Sharing knowledge and expertise with the team and at the same time learning something new from each of your team members, everyone has got something to offer for sure, you just need to look closer.

4) Avoid unnecessary personal tension or politicking. If you have a conflict try and discuss it with your colleague. Sort the conflict out rather than sitting on it. Believe me most of the time it just some silly. Learn to forgive and take one more for the team (this was my magic mantra). Just let it go. Remember you have so many other things you can invest your energy on. 😊

One must have the attitude to:

– Move from independence to collaboration
– Be flexible and move towards stability
– See common team goals over his or her personal goals



Traditionally, as testers we would just look at requirements ignoring why they were created. This would mean we would focus our siloed tests (System test, Integration test, performance test etc.) to cater to these silos, prioritize them if need be and test. Developers followed suite, they just picked up what was given and seldom viewed the objectives holistically. Things like integration, performance, scalability etc. All that now is slowly changing or has begun changing as Product Managers / Product Owners are collaborating directly with developers and testers.

The POs’ work closely with their business counterparts and come up with a prioritized list of business features or problems, these are then picked up by the developers and testers who work autonomously to a develop a solution or increment that will create/generate value and finally deliver it. The whole team works towards a common goal and always prioritize value creation over everything else i.e. look at how this will benefit the customer and or generate $.

You can start right away by asking questions to yourself or your team (without annoying them too much). For example, what is my project really trying to achieve, and what is the business outcome, who is impacted, how does this make things better for them etc. If you don’t have the answers, ask your project team members. Try and put the product owner or business hat. Dare yourself to put that architecture/solution hat and see what they are trying to achieve with your project, how would you have done it differently to achieve better outcomes, any good ideas that you get, bounce it off your team and together drive it.

Example: We got rid of an excel based utility (which we were asked to update) and we in turn ended up delivering a user-configurable report straight out the upstream system, saving valuable time and effort, and above all simplifying the whole experience, all because we asked the right question and saw the big picture. It’s amazing what a right question to a right person can do.

This concludes BLOG#2. In the next blog I will touch on impacts to the current testing world, what is changing is and expected to change, and finally, conclude my blog series, so stay tuned…


LPS, Testing

What are the triggers for change for testers? Are we headed towards Extinction?
By Venkat Raghavan Test manager

testers auckland and wellington

Morpheus (From The movie Matrix): “This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.”

So, did I really have to make the title this dramatic? Of course I had to, and why? It is because this is my first blog at LPS and I wanted to spice it up…just to get more hits / read, a dramatic title (most of the times) gets the job done 😊. Jokes apart, this has kept me up at nights (or was it Netflix… um) and I started looking around for answers asking colleagues, attending brown bags, drink-ups and reading online content. I started to realize that I was not alone. The community plus industry was filled with people like me, and they all had similar questions, questions.

Where is this industry heading?

What is the next big disruptor, emerging trend?

Are my skills and me still relevant? What skills do I need and how far will they take me?

Agile or DevOps, is it here already and to stay what happens to SDLC?

Is Manual Testing going to become obsolete, Do I need automation? and it goes on…

I am sure there are many more questions, and many of you may share similar thoughts or feelings, so what better than addressing the elephant in the room and kicking off my blogging career  LPS by seeking answers to some of these questions.

Why and what is causing the change?

“The Only Thing That Is Constant Is Change” – Heraclitus

keep calm and drink coffee

Before we get into the trends and disruptors, I think it would be good to set some context and get into the leaders’ shoes and see what they are seeing and why they are driving this. So, what do the leaders really want…? In summary, and based on the patterns of some of the industries and businesses in NZ, they are all striving to (my simplistic view, the list otherwise can get quite long).

1) Deliver better business outcome / value and fast via efficiencies /automation
2)Staying relevant and in most case ahead in terms of techno-business trends and disruptions in this highly volatile and competitive climate. (Some good examples:  Banking-NFC payments /Big Data / Machine Learning/AI. TV and Music – Streaming /online content. Automotive -Autonomous vehicles/ Battery driven etc.).

This vision has led to organizations embarking on transformation programs – call it technology transformation, new ways of working, automation, Dev Ops journey, Agile journey etc. and there are some splendid examples of what organizations have been able to achieve through their journeys. Some interesting case studies and success stories – Capital One , ING and good old Spotify.


How does this affect us the “Testing guys “?

“Here is a test to find whether your mission on earth is finished:
If you’re alive, it isn’t “. -Richard Bach

Now that we set some context and triggers causing change, how do we Testers fit into all of this. The simple answer to all of this is – If there is code produced, there will exist bugs and it will need to be tested. Software Testing and or Quality is an integral part of the process / lifecycle and it cannot be ignored, as there are consequences or risks, and these risks will always need mitigation.

So, what will be different for us testers?

 I have summarized what I think is the continuously evolving picture of the key drivers that will affect our community, and each of these can be vast oceans in themselves, so we will try and look at each of these key drivers at a very high level in my next blog.

Again, this is purely my personal perspective and interpretation on the topic, and the ever-changing testing landscape, would be great to hear your thought and comments and stay tuned to read my next blog, coming soon…


LPS, Testing, Thought Leadership

TestI’ve been fortunate enough over the past few months to be involved in a number of high-level Test Maturity reviews for several organisations, and found myself asking the question “why do we test?”.

A very simple answer may look like “We test to ensure that the application under test works as expected”. So often we fail to define exactly what “expected” looks like and we don’t come to a common understanding of what we are producing and what we should be testing.

One of the reasons, I have seen many times, is that we don’t come to a common understanding of what is expected because we “don’t have time”. We have all seen what happens next; the project is de-railed by applications that, all too late, don’t meet expectations – which of course were never understood – with deadlines missed, budgets blown, customers disappointed.

If we were to pause for a moment and define these “expected” outcomes, what could the final outcome possibly look like?

  • Shared understanding of expected result

  • Clarity on what is or isn’t a defect

  • Defects and changes caught earlier

  • Re-work reduced and ultimately,

  • Projects delivered on or close to Go Live dates

I’m not suggesting a ‘plan everything upfront before being built’ waterfall approach, but more of a collaborative approach between those members of the team that need to be involved. Something similar to the concept of the 3 Amigo’s; where BA’s, Developers and Testers work together to gain a shared understanding and agree on how they know when something has been done correctly.

I’ve worked on many projects where a solution is developed by a 3rd party. The developer produces code based on their understanding, the code is unit tested by the developer and then tested again by the vendor’s test team. Each pass with flying colours, only to be delivered to the client to fail dismally.

You ask yourself the question “Why?”. You jump to the conclusion that ‘they’ didn’t test it properly. But more often than not, it comes down to a misunderstanding of what was actually required. Taking the time up front to communicate amongst the team, the BAs, Developers, Testers and the Business would have given a much better chance of common understanding leading to a better view of what is to be delivered and when.

The cost associated with these misunderstandings is evident in Boehm’s Law, illustrated below.

There isn’t a “one size fits all” model but perhaps a clearly defined set of principles we adopt may help us along our journey. So, next time you find yourself testing in a world where project members are clearly not communicating to get to a common understanding and where there is not enough time to elaborate the requirements, consider promoting a collaborative requirements gathering, involving all the team and a JBGE (Just Barely Good Enough) approach.

This isn’t an excuse for doing a poor-quality job because quality is in the eye of the beholder: the audience for an artifact determines if it is sufficient, not the creator of it. If your stakeholders require an excellent, detailed artifact then it is JBGE when it reaches that point of being excellent and detailed.

Given the promise of Agile, can we adopt similar agile-like practices into waterfall or hybrid projects, what do you think?

In the meantime, when you are faced with a project that hasn’t got the time (or other excuses) for requirements gathering, ask yourself in the words of Dirty Harry “Do I feel lucky?” (Well do ya….?). Because you’re going to need luck to get this one done on time.

Contributor: Wayne Kelly