In this era of Agile software development, the life of a product manager, who has to talk about or plan a single feature, is easy. The life of a developer, who has to code one feature, is easy. For the designer and DevOps engineer, designing and deploying one feature is easy.
You know who’s life isn’t easy? The tester. He has to test that new feature, or product, while at the same time testing all the old features as well. And, he has to do it in a very small amount of time.
And, according to Mudit Singh, director of marketing and growth at cloud testing platform provider LambdaTest, it’s not just regression testing. It’s more like a progression of tests. “A progression is more of that I have tested once, and found a bug. The developer has fixed it. I come back and test it again,” he explained. “But in general, it’s the first level of testing itself. He’s asked to test one feature, plus 1500 old features as well, in that small amount of time.”
This is because continuous deployment is happening, and even though people are moving to microservices architectures – and there are mitigations to that, Singh said – the state of testing remains the same, in that you have to test everything to be sure it’s right. But, he said, “you can make the process more intelligent. The brute force way still has limits. So people are saying, I cannot do manual testing of each and every feature; I’ll automate the tasks that are repetitive. And that’s where automation testing comes in.”
The result is that when a developer commits code in the repository, that act triggers a set of automation tests that ensures whatever has been committed is perfect or not.
In a small enterprise, in a small-scale setting, this process works. It’s in larger enterprises, where they might have hundreds of thousands of tests, the test time of whole build takes hours. As Singh pointed out, “I write code today, and I commit it, and the test starts running. The whole test process will take, let’s say, four or five hours. I am now dependent upon the test to complete and it’ll be four or five hours until I get feedback on what I’ve written is right or not. So now I’m reading, twiddling my thumbs.”
Commonly, organizations will write code all day and run the tests overnight and get the feedback the next morning. But by then, the developer is out of the zone, and has to remember what is there to debug what is breaking, Singh said, “so the whole productivity starts to break down.”
But productivity could continue if you run the test in an hour, or 30 minutes, and remediate issues while they’re still fresh in your mind, with much less time wasted waiting for feedback from the test results.
Platforms such as LambdaTest can run tests on a massive scale, across multiple machines, at the same time, in parallel, to reduce overall test execution time by multiple folds.
“If I have 100 test cases, each test case takes a minute to execute,” Singh said. “If I run them sequentially, it would have taken me 100 minutes to do the whole test suite. But if I run these tests in a parallel setting in 10 different machines, I run 10 tests at the same time. So the whole test execution time drops by a factor of 10. In 10 minutes, now my whole test is complete. If I’m doing 100 parallel, the whole 100 minutes has been reduced down to one minute.”
This is something that Singh maintains is difficult for organizations to do in-house, as opposed to leveraging the scalability of cloud computing. “There was a time when enterprises and big-scale companies used to set up their own in-house device labs, their own in-house VMs and everything. But one of the biggest challenges was, of course, maintenance of these devices, maintaining some of these VMs anytime a new operating system comes, anytime a new security patch comes, anytime a new browser version comes,” he said.
As to the difficulty of doing this in-house, Singh noted that a new version of Chrome is released once every two months. Firefox updates once every three months. In the same year, you could get 10 to 12 different browser versions – not to even mention new mobile devices and operating systems. Samsung, for example, comes out with 17 new devices each year, and if the company bought every one, that’s at least a $20,000 expenditure for each developer, since almost all developers are working remotely, away from an in-house installation.
Further, during the time the developer is coding, and not testing, the developer’s test lab is not being fully, 100% utilized. But if that lab is connected via the cloud, now four or five people – or more – can work on it simultaneously. This makes it more cost-effective.
Using a platform such as LambdaTest, you get full browser and device coverage, and perhaps most significantly in this age of instant gratification, test execution times are reduced as well.
Content provided by SD Times and LambdaTest