Editor's Pick (1 - 4 of 8)
Gaining 360 Degree View of Consumers
Predicting a Better Future for Students
The Changing Dynamics of Engineering Industry
CIO ... Only Until the Next Data Breach
Embrace Technology to Stay Ahead!
Dave Doyle, CIO & SVP - IT, Regal Entertainment Group
The Changing Role of the CIO
Mel Kirk, SVP & CIO, Ryder System, Inc.
Effective Strategy While Implementing SAP or ERP Systems
Daniel M Horton, CIO, Michael Baker International
Leveraging Data as an Enterprise Asset
Renee P Wynn, CIO, NASA
Extending Automated Testing
By Steve Berczuk, Software Developer and Team Lead, Fitbit
In spite of the importance of test automation, not all teams have the skills necessary to do automated testing well. For an agile team, the best time to write tests is while you are writing the feature code (or even before, if you follow Test Driven Design principles). Since good automated testing requires not only basic development skill, but also knowledge of appropriate technologies and a testing mindset, this isn’t always easy.
There are two ways to fill skill gaps. A “resource based” approach involves adding people with the skill to do the work. This can work, but is limiting. A “learning-based” approach which focuses on enabling the team to do the work builds on the foundations that make agile teams work: the ability to be cross-functional, self-organizing, and able to commit to their work.
Automated Testing Options
“Automated Testing” covers a variety of areas ranging from straightforward Unit Tests that run entirely in a developer workspace to end-to-end testing that runs in an integration environment. While most developers can do unit testing reasonably well, integration testing and formulating an overall automation strategy each require additional expertise. Some teams treat a gap in skill as a staffing or workflow problem and hire specialists such as “automation” or “test engineers” to fill this skill gap.
The dedicated assignment approach has the advantage that the test engineers are part of the team and share the commitment to deliver that everyone else on the team has; they are part of the team. But specialists on a team can become bottlenecks:
- An insufficient number of test engineers in your organization can mean that some teams may not have all the people they need to complete work.
- The need for automation expertise may vary widely between sprints, and across teams. An insufficient amount of work on a given team for a period of time would mean that your specialists are idle.
An alternative is to have an “automation engineer pool” and have the specialists work with teams as needed.
In spite of the importance of test automation, not all teams have the skills necessary to do automated testing well
While this addresses resource constraints, this is can also create bottlenecks:
- The pool engineers lack the context of the team, and the deep understanding of a feature set that comes with being “on the team,” so they may not make the best choices.
- The team becomes dependent on a external, and unpredictable, resource, making planning and commitment difficult. There may be no test engineers available when a team needs one, since this approach does not lend itself to slack.
These and other options that focus on optimizing the use of the Test Engineering Specialists, moves the testing outside of the cross-functional development team. When you move a development task (which test automation is) away from the development team you are likely to have slower delivery, and less effective tests.
While a staffing-based approach can work in the short term, an “enablement based approach” can be more effective. When you acknowledge that you have a skill gap in your scrum team, you can then have a team of testing specialists work with these teams on a medium to long term basis, not to simply implement tests, but also to coach and train the teams. The goal of the test engineering Specialist Team is to enable teams to write tests. Since examples can be the best teachers, these specialists also deliver testing code.
These testing specialists:
- Are software engineers who happen to have expertise in test automation.
- Are assigned to teams for a long enough time that they can learn about the project, and become part of the team.
- Identify testing strategies and tools that the team needs to get their work done.
- Work as developers during short intervals when the team might not have automation work to do. This can help them understand the code base and integrate better with the team.
- Mentor and train their teammates in test automaton skills, helping people on the team to be more cross-functional.
- Establish best practices, and develop common frameworks as a side effect of their team work.
- Serve as connectors between teams by sharing experiences that they have brought from other teams, and facilitating informal networks.
Prioritizing where people from this team work won’t guarantee that every team will instantly be able to create integration tests, and some projects may be need to struggle in the short term, but you will be building a testing culture, and a increasing the skill set around testing in your organization, which will benefit you long term.
The combination of long term assignment and rotation enables for organic transfer of deep domain knowledge. By having deep experience across the organization the members of the Testing Specialist team are able to identify good generalizable solutions that are rooted in practical experience.
The power of agile software development to deliver high quality features quickly lies as much in the collaboration of the people on the team as it does on technology and technical skills. If you approach skill gaps by building specialist teams that can help teams become self-sufficient, become conduits of knowledge, and help build common tooling, you will be more successful in the long run.