LPS, Testing

Blog Series Testers: Are we headed towards Extinction: BLOG#2 : Key Drivers

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.


 

#PHILOSOPHY:


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.


#LEARNING:


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.


#CULTURE:

 

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


 

#BIG_PICTURE:

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…