Engineering Productivity

This post is about a new development in software testing, a possible evolution that makes so much sense logically to me I can’t believe I didn’t draw the conclusion earlier in my posts about Test Ops.

Google has recently (ok, more like earlier in the year) renamed their Testing Automation Conference into the Engineering Productivity conference. They also did the same with their team.

And this instantly went back to all the Test Ops posts I’ve been reading.

All of them showed the natural progression of simple testing into something wholly devoted to increasing productivity itself of an engineering project. Continuous Improvement, Testing and Development. Testing not only if a product works but if it is working effectively or not. Testing and Quality Assurance are simply the beginning of using software to ensure increased productivity of software engineering projects.

The essence of it is to let the developers themselves handle the tasks of making sure the code works and is of good quality. This means that they will be making tests for their own code. Obviously, just doing this would not be very effective, as developers might not be great at testing. This is why a new task for the Engineering Productivity team is provide guidance and tools to developers to help them more effectively produce effective tests with good code coverage and that will make sure the performance is reasonable. By doing this, the responsibilities of the team are lowered and they can take on more responsibilities in terms of aiding with Continuous Development, and using big data techniques to test the how effective features are at keeping users (for projects where this is applicable) so developers know where to steer productivity.

Of course, there needs to be flexibility. Focusing on testing in the beginning seems to be very effective, leading to there being much less issues down the road. So the team focuses their time on things like pending time on IDE plugins, code coverage, and effective code review. After release, the team can shift over to Testing in Production tasks, especially when features or updates start development. A responsibility the team always has is making sure there are no testing bottlenecks. If a test takes too long, people will stop running them altogether at some point.

This is really a formalization of all the other topics I’ve posted on. Seeing the evolution of a dedicated testing team, the blending between developer and tester, and finally leading to the testing team becoming a team focused not only on testing but increasing production in general is quite fascinating. In a way, the testing team was always about increasing productivity, and formalizing it has made that apparent.

Original Post:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s