Posted by Richard Bustamante on April 2, 2009
Test code has a tendency to bypass the rigors of normal development, since it will never be used externally and is more prone to rapid changes, it’s easy to slip into taking an ad hoc approach even in a long term project
But in a sense, writing test automation is just like any other software project. You have developers (SDET’s) writing and maintaining code.When running it you’ll run into bugs and feature requests, and the whole effort needs to be managed in order to meet deadlines and goals. So it makes sense to apply many of the same tools that exist in the software industry.
To that end, in the past six months we’ve started actively using a separate project in our bug database to manage work on our automation. When we come across bugs or features we want, we log them, just like bugs against the main project we’re testing.Then, when we have time, bugs are distributed and fixed.
While it may be overkill when first starting out, it’s been invaluable as our automation has matured into upwards of twenty thousand lines of code. It’s too much to keep everything in our heads of who’s fixing what and what needs to be done, and it would be a mistake to try.