How much coding do you do in building automated tests
Marcee last edited by user
I come out of quite a few years as a software engineering, but now I'm completely focused on testing. Our team has been trying to expand our automated tests and, to me, this means a lot of coding. I wanted to get an idea of what other people in this field thought though, in case this is simply a result of my development background. Do any of you find that there are other ways to achieve extensive test automation without a big focus on coding those tests?
Thanks for any input.
Welcome to SQA, Daniel. Sometimes there are dedicated tools/products you can purchase for specific kinds of testing. For example, there are companies that provide software packages specifically for testing network devices.
For most of us though, test automation means writing code. Sometimes there are ways to cut down on the amount of code you write. If you aren't using a test framework (e.g. JUnit for Java), you should consider doing so. A test framework can cut down on some of the low-level coding work and can handle reporting for you, too.
Sometimes there seems to be a lot of code to write because you face a combinatorial test problem, i.e. a problem in which you have many independent variables to test, and each test has many possible values. See https://sqa.stackexchange.com/search?q=combinatorial%20testing for more details.
Coming from a development background, your inclination may be to write unit tests for developers who choose not to write their own. That can be a lot of work, and once you're done, you may be stuck maintaining them yourself; if a developer doesn't want to write unit tests, they may not want to maintain them either. I recommend focusing on integration- and system-level tests.
You don't necessarily need to write tests for everything. If a part of the product isn't used much or is unlikely to break (the classic example of the latter is setters and getters on a Java bean), automated tests may not be worth the effort. James Whittaker and some other Google engineers wrote a pretty good book that covers those trade-offs; I'm sure there are many other books that cover similar material.