We’re all Testers Now

As I was preparing a presentation on Top Trends for 2016 for the OreDev conference in Sweden I started to remember how much the software industry has changed in the last 15 years. I remember the days when QA testers were treated almost as second-class citizens and developers ruled the software world. But as it recently occurred to me: we're all testers now.

Shift-Left

Much of this is driven by the shift-left strategy of testing as early as possible in the development process. This helps your teams focus on quality from day one of your project, rather than waiting for defects to be uncovered late in the software development lifecycle.

With more and more companies making the shift left in their development process, testing and automation are no longer just QA activities—which means that the roles of developers and testers are beginning to blur. Change is challenging, but there are some things your team can do to prepare for this shift that will make for a much smoother transition.

Five Steps for Testing Automation

These five steps have greatly helped the teams I've worked with:

• Make developers responsible for testing
• Code review quality checks
• Teach testers to code
• Use the same tools
• Start with testability in mind

1.Make developers responsible for testing

With the current trends in software development practices, as well as the shift in focus toward customer-driven development models, test automation is more important than ever. Agile and DevOps demand more automation, and practices like continuous integration and delivery require automated tests that can be run quickly and reliably.

I would go so far to say that one couldn't be successful in any of these practices without some degree of test automation in place. In my experience, teams often have more developers than testers, in which case the developers need to take responsibility for at least some of the team's test automation efforts.

If testers are the only ones responsible for creating an automation framework and writing tests, it's going to slow down your development process. Distributing testing to developers helps expedite your efforts.One way to induce your developers to start creating tests—bridging the gap between developers and less technical testers—is to use behavior-driven development practices that help split the testing into layers.

Stories can be created using an agreed-upon, customer-focused vocabulary with which product owners and testers can create test scenarios using an English-like syntax. Developers can then implement the scenarios in code to automate them.

Not only will this help create more automated tests, but it will also assist the team with collaboration.

Also The teams I work with cannot close their user stories until their entire automation tests pass and each new story has an automated test associated with it. Making test automation a part of your definition of done (DOD) will help emphasize the important of testing as well as make everyone on the team responsible for creating code that is automatable.

I would also recommend that if a developer makes changes to the application — say they changes a field name in a login screen–then they are also responsible for updating the field id in your automation frameworks LoginPage page object.

2.Code review quality checks

What I've seen happen at large enterprises is that there's typically a test automation lead outside of the sprint teams involved in all the test automation code reviews. This individual helps guide the teams with best practices for automation and testing.

Developers on individual sprint teams submit their tests for code review. The key reviewer, a tester, can then make sure that the checks are correct and that there are no other scenarios the developers might have missed that should also be tested.

It's rare to have testers who also possess the skills to create reusable, maintainable code, so I recommend that your developers build out your automation framework rather than your testers. Testers should be focused on finding bugs, not spending all their time creating a framework when you have software developers who are more adept at programming.

With your developers now contributing to your testing efforts, your testers will have more time to define good checks for the developers' scripts and to focus on exploratory, security, and performance testing.

3.Teach testers to code

While developers need to take on some testing responsibilities, testers also need to do some coding. In order to be effective at code reviews and as part of a sprint team, testers need to learn how to code.

I'm not naive enough to recommend that everyone on a sprint team be able to fill each role on the team completely, but testers need to be technically proficient enough to be able to read and modify code at some level. For example, they should be able to modify an automated test or refactor some simple methods.

4.Use the same tools

If you're a tester, one of the issues you might have encountered in the past is the inability to create automated tests using the same tools as your developers.

This was always a roadblock for testers creating automation frameworks from scratch using these tools, since it made it difficult to use some common, object-oriented design principles and discouraged developers from collaborating with testers on the automation code. In my 15-plus years of experience, I've never once been able to convince a developer to install and use these types of vendor tools.

The good news is that it's now becoming more common for popular test tool vendors to support programming languages such as Java and C#. Many of them also integrate with popular developer IDEs and source control software. If you're just beginning your test automation efforts, you should use tools that fit into your developers' ecosystem.

5. Start with testability in mind

Regardless of your role on the team, development testing (and ultimately delivering a feature) requires a total team effort. Testing shouldn't be an activity that is done only at the end of a sprint by a designated tester.

Before one line of code is written for a new feature, the developers should be planning their solution with automation in mind. Developers should ask themselves, “How can I expose a hook or create a unique ID for this element in order to make it more testable?”

Making developers responsible for the majority of your test automation framework creation will also make them more aware of some of the issues that can cause unreliable tests due to poor application testability code design.

Only when an application is built with automation testing in mind right from the beginning will a team be truly successful as they shift left. Following these five steps should help get you there.

FYI – this article was originally posed on TechBeacon.