One of my coworkers asked me for advice on shifting from a testing role to development. Inside IBM, cross-role experience can often be picked up within a project, on a BizTech opportunity, or by assignment to another role (if the project manager really, really believes in you). Here are some tips if you’re considering the shift yourself:

Although you can build your skill in steady increments, building expertise can be a long and frustrating process. You’ll make a lot of progress in the beginning, but you’ll probably hit a plateau. Don’t be frustrated.

Unless your project manager is okay with taking a risk on you, you probably won’t be able to immediately spend time developing those skills on the job. Here’s how you can free up some time to work on improving your skills:

1. Look for ways you can work more efficiently and effectively, so that you can save time.
2. Document those processes so that you understand them better and so that other people can take over your role when you leave.
3. Automate as much as you can, saving more time and enabling more people to do your work.

You want to be replaceable. You can’t spend time learning something else or move on to another project if that would leave a big gap in your previous team.

How can you learn more about development when you’re testing?

• You can improve your processes, learning more about available tools along the way.
• You can learn how to script while automating tasks.
• You can learn an in-demand skill and get pulled into projects that way.
• You can focus on providing additional value while testing. For example, if your project is okay with it, do whitebox testing in addition to blackbox testing. By reading the source code, you might be able to think of test cases that should be covered. You can try helping with problem identification, using tests to narrow down where the bug might be. Once you get good at that, you can try documenting your problem-identification process and commonly-encountered bugs. When you’ve got a good feel for the structure of the program and how things are generally fixed, you might even tentatively propose fixes.

What other advice would you give to people who want to move from testing to development?