LambdaTest TeamWhen hiring test automation engineers, you need to remember to include TEST as a part of the process. Different tools, languages, and concepts in the job descriptions to get the expected result are also important.
In this session of the Testμ Conference, Brijesh Deb, Principal Consultant, Infosys, teamed up with Navya Manoj, Product Marketing Manager at LambdaTest, to explain the importance of shift-left technology to progress as a tester.
At Infosys, Brijesh Deb holds the position of principal consultant. He is an accomplished crowd tester, a qualified scrum master, and an authority on creativity and innovation. He is an expert in leading, managing, and coaching testing teams. He has been involved in testing applications from lightweight mobile apps to large-scale industrial IoT solutions. He’s also the founding enabler of a global testing community called the Test Chat, which is focused on bringing the tester’s voices to the forefront.
He started his talk by giving “food for thought.” He asked the attendees to imagine a highway road of three divisions. And we all are driving on the middle division of the highway road at 150km/hr speed. He jumped into the core of shift-left before continuing.
The “Why” behind Shift Left
He starts with a question.
“Why did somebody come to the thought that shift-left is something that needs to be answered?”
Testing was frequently the bottleneck to progress when people first began to think about product development or the software development life cycle because it occurred at the end. Someone had the suggestion to move the testing to the left, which indicated that they wanted a response extremely quickly. People had to wait a long time to receive feedback in the past because testing was traditionally done towards the end of product development, but that was ineffective. People sought quick results since they were having trouble. Rather than waiting six months or a year, they preferred to spot such flaws immediately.
Shifting left gave them the chance to catch issues early, and more significantly, it led to reliable code, making the end product considerably more stable.
Shift Left Recommended Practices
Brijesh says he usually goes to the customers as a consultant, and they ask him about improving their testing. So he generally makes some recommendations. They are:
Involve your testers early.
Fail fast culture.
Optimize test infrastructure.
Continuous monitoring.
Enable and Empower Developers to test.
Brijesh openly brings up the top 3 pain points that don’t allow him to sleep:
Too many bugs in the production.
Large-scale distributed applications.
Can’t simulate edge cases.
He comes up with a solution to solve this. The other C of CI/CD is Continuous Testing.
Dan Ashby’s Continuous Testing model is shown on the preceding slide. When preparing for DevOps, one must test at each stage — product planning, build, release, monitoring, and feedback gathering. Why should attention be given just to checking the left side of the loop? Why not begin to look to the right as well?
Shift right testing comes into play here.
As we have been discussing shift left for so long, let’s move on to shift right since shift left is not enough.
Our Android phones received a notification from Airbnb a week ago. There were many jokes about this. The developer was criticized. But it’s good to know that Airbnb conducts testing while in production.
Someone who conducts testing while their product is in production is interested in gathering customer input and wants to enhance their product.
Shift Right Recommended Practices
In addition to the Shift Left techniques Brijesh recommended, he also suggested a few Shift Right practices. They are:
Continue Shift Left.
Implement Continuous Monitoring and Observability.
Engineering Practices like “Feature Toggles.”
Observe, Analyze, and Act (OAA).
Production Tests.
A lot of tests need to be carried out in production. He highlights some of them:
Canary Test:
An employee is surveyed after deployment when a new feature is set to go live or when an existing feature is being upgraded. They adjust, modify, and update their work in response to employee input. Only 2% of the product is made available for production before another round of feedback is collected. 10% of the input is then made live and then feedback. Finally, without any errors, 100% goes live on production. We call this a canary test.
AB Test:
AB test compares your two releases and observes the changes. This is a perfect way to detect the changes early before they impact the users.
Rollout Tests:
In a typical product development life cycle, where features are developed according to the product owner’s priority, rollout testing is crucial. However, depending on the customer’s needs, the rollout’s priority may alter as it happens.
Scalability Tests:
Scalability tests are crucial because as soon as you put your product into production, you’ll see that more and more consumers will start adjusting to or adopting and utilizing it.
Fault Injection and Chaos Tests:
This is also one of the basic tests to check the scalability and reliability of the product.
Finally, he returns to the highway, using the middle lane. He uses highways as an example to demonstrate how it is crucial to maintain a balance between the left and right panes. He contrasts it with the harmony of the Left and Right Shift Testing.
It was indeed an insightful session with Brijesh. The session ended with a few questions asked by the attendees to Brijesh. Here is the Q&A:
What are your thoughts on Shift Left Non-Functional Testing, and how can we achieve that?
Brijesh: Non-Functional tests are referred to as performance and security tests. If you’re talking about the performance of a system, you are making sure that the system is functioning and doing what it must do very effectively. And thereby, when more and more people start using it, you want to see the impact. That is where the system is put under stress. So to perform non-functional, begin with the performance testing.
What are some ways in which we can optimize test infrastructure?
Brijesh: When building your test environment, you must have a setup where you could have your entire environment as code. So that you could build it up anytime, you could tear it down anytime. You can spin up environments as and when you want. One of the easiest or best ways to keep it optimized is by looking at it continuously, monitoring it, and understanding it. This part of my environment takes a lot of it because the application has a bigger dependency on a certain part, so if you want to reinforce that little part of your infrastructure.
In a project which has more developers than testers involved, do you think it is efficient?
Brijesh: The tester developer ratio is quite lopsided; where you have ten developers and one or two testers, it is not recommended in such situations. Because the testers will have their plates full, and usually, this is what happens. However, you know, in agile teams, people are expected to have that cross-functional ability to pick up stuff and run it as it comes to them. Everybody can do everything in that kind of setup. This is a good practice for people to look at Unit Testing.
People often ask me what is needed for a tester to know how to code; this is where it comes in handy. If you know how to code, you know precisely the language in which your developer and architects are talking. This means that you get better ideas for testing the product. So that’s where it helps you join hands with the developer to build better Unit Tests. It also allows you to invite the developers to help you during your testing. It always gives you more opportunities to interact and increase your efficiency as a tester.
How can we incorporate Shift Left Testing in Agile effectively and efficiently?
Brijesh: When you talk about agile, everybody will immediately say that you’re going to shift left. If you go back to my slide, I showed the picture from Dan Ashby where he drew the DevOps model and emphasized where you could test. So the whole idea is the level that is very early when you start thinking about the product design. That’s when to gather the requirements as they come in when you do your user needs, analysis, and user stories are written.
That’s when you should start your shift left testing. You want to make sure that those stories are accurate and complete. So accuracy and completion are two aspects you want to test right, which is also one kind of testing.
