Week 10 Blog Post for Software Testing
This week i decided to read what Test Engineers do at Google: Building Test Infrastructure by Jochen Wuttke
As google is a popular company and i am new to the world of testing, this article was of immediate interest to me. I was excited to learn what careers in testing were like and what better way to do that then by a test engineer at one of the most popular companies on the planet. Although this article does not talk about all the different things that the test engineers do, it only discusses one aspect of their work which in this case is :building and improving test infrastructure to make engineers more productive.”
One part of this is replacing legacy systems. A legacy system at google was costing engineers countless hours that they could be spending elsewhere. A replacement takes a long time to build so they had to continue using and updating the legacy system as they went. However this allowed them to learn from the legacy system and not make the same mistakes in the new system. The engineers found two major concerns to fix in the new system. Those were “Tight coupling and insufficient abstraction made unit testing very hard, and as a consequence, a lot of end-to-end tests served as functional tests of that code. ” and ” The infrastructure used for the end-to-end tests had no good way to create and inject fakes or mocks for these services. As a result, the tests had to run the large number of servers for all these external dependencies. This led to very large and brittle tests that our existing test execution infrastructure was not able to handle reliably.”
Once they had found the problem they had to figure out the solution which is the hard part. After quite a few prototypes and a year of time a few testing engineers where able to build a new tool that solved the problems they were looking to solve. The next step was teh adoption of the new system, which is never an easy process. This process took them a couple of months in order to fully implement. The results were that the new tests were more effective at finding bugs. The new tests ran in 3 minutes compared the older suite running in thirty minutes and the client side tests are 0% percent flaky.
Although i didn’t completely the implementation it was quite interesting to see the process a tester took in their day to day lives.
Here are some other articles that i found interesting: