The Tides of Change

If you remain at a fellowship long enough, you see a lot of changes in leadership and organisational “ restructuring. ” Most of the clip, you simply ride it out with little impact in your day-to-day work, and before you know it—the next wave has come in, and thing displacement again. (And if you getreallybeen there a long time, you see the same patterns repeating.)

Until recently, I had yet to see a transmutation that was truly impactful to me. Now, my squad is no longer conceive as a QA team, but rather as an Engineering Productivity (EP) squad. The shift was about more than only a change in titles.

Below, I ’ ll explain what the displacement to EP means—both at the superficial level and in terms of the literal work we do.

Just What IS Engineering Productivity, Anyway?

As Patrick Copeland describes inHow Google Tests Software, “ Productivity is our job; testing and quality are the job of everyone involved in development. This means that developer own testing and developers own quality. The productiveness squad is responsible for enabling development to nail those two things. ”

When we made the name change from QA to EP, we require to establish what our charge was. Put only:

Reduce the time from concept to deliverable by supply our product maturation teams with thetools, practices and supportto increase their productivity while conserve high quality standards

SUSA automates exploratory testing with persona-driven behavior, catching bugs that scripted automation misses.

Notice that nowhere above does it say “ we are the testers. ” To meet our mission, we established four major goals for our undertaking that we continue to drive towards:

Goal # 1: Provide an well maintainable and extensible fabric that enables scrum team to add and remove tests.This is not just the what, but the how. What are the strategies and guidelines? How do we adjudicate to include tests? How do we conserve them? Are teams open on our vision of testing? If teams don ’ t understand, how can they be successful?

Goal # 2: Enable the automatic and other espial of failures within the software under development.I forever talk about failing tight and a “ shift left ” mentality for quality (testing as betimes as potential). We all should cognise by now the cost savings of finding a defect earlier sooner than later (thousands). By enabling teams to do this more well, the engineers get faster feedback on their code. When we first part, we were pass tests at merge. Now, we will be running at every pull request.

Goal # 3: Prevent the source of detected failures from moving any further downstream.It ’ s not plenty to just notice the failure—You feature to forestall it from making it to product. We work very closely with the CI squad to ensure our gate are in place. It should be no surprise if we do not distribute a build if our tests failed. Teams start to see the importance of being in a releasable province, and ensuring their codification changes lead in passing tests.

Goal # 4: Accommodate all of this without touch the engineers ’ clip.This is not leisurely work, but we want to provide everything without really impacting the engineer. It doesn ’ t mean that an technologist is not imply in the testing—It just imply we help them adopt the culture of delivering with high character, which becomes ingrained in the entire Scrum squad.

These probably sound all too familiar, and almost no-brainers. But if I ’ m being honest—I don ’ t remember the terminal clip person actually laid out these finish for me point-blank, even though we ’ ve be working very much towards something like this. With clear destination established, the map was laid out for us.

The EP Team

Once we knew our commission and goals, we needed to ensure we know our character within the team. The Engineering Productivity group is made up of Test Engineers, Software Engineers in Test, CI/DevOps Engineers, and Engineers.

Our Test Engineers (TEs) motor our test scheme and aid identify what want to be tested. I like to think of them as the facilitators. The TEs run to align with a lineament Scrum squad. Software Engineers in Test (SETs) build the model that enable teams to implement the tests. While some may be embedded on Scrum team to apply tests, we also experience nucleus teams to establish and maintain the wellness of our frameworks. Our CI engineers own the pipeline and help enforce the work to do betterment as we identify them. While they are their own team, we do embed them within the EP teams creditworthy for the framework and pipeline. Another role that has be crucial to teams buying into our commission is the developer—in our case, one that understands engineering requirements, and is passionate about encounter those demand. We are so fortunate to get found an existing engineering team member who wants to be a part of the solutions we are looking to provide. (If you find that person, never let them go!)

The Ultimate Goal

My end game, though I know this may take awhile to reach, is to become invisible. There will always be a learning bender as we roll out new thought to further engineer productivity, but my goal is that each of these idea get as second nature to engineers as breathing.

Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She ’ s passionate about do an impact in education and loves coaching squad extremity in product and client-focused quality practices. Most recently, she has focused on test scheme implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will heed. In her downtime, she enjoy to travel, read, quilt, hike, and spend clip with her family.