An Intro to “TestOps”?
A few of my co-workers and I were just talking about testing trends and I was recently directed to Seth Eliot’s blog (here) by another colleague. Seth is currently at Amazon and he was at Microsoft for approximately six years in various test management and test lead roles. His work experience is noteworthy because he’s been working for very large organizations that deliver software at a rapid pace. He’s put into words the thoughts I’ve been muddling around on for the last five years.
It’s an interesting time for QA individuals. Due to several factors, their world might be a lot different than it has been in previous years. This is the first post in a short series of blog posts on the topic of testing trends. This first post will just lay some groundwork. Subsequent posts will go deeper and offer up possible solutions.
I used to work on a development team at a large organization that would take six to eight weeks to document and refine 75-pages of requirements. They’d then hand these over to the development teams who would write code for three to six months. Although the developers would do some unit testing and even some functional testing in a dev environment, they would depend on a sizable QA team to validate that the build was meeting expectations. This QA effort would take another two to four months. Altogether, that’s between seven and ten months to get this project out the door and into users’ hands.
In this world, QA had weeks or months to write manual test cases and execute them, but it was rarely enough time to test the new functionality and fully regression test the application.
The popularity of agile has definitely surpassed critical mass! Enterprise development teams NOT incorporating several agile practices are now the exception. This often means development teams are reducing their release cycles from months (years?!) down to four weeks or even days. This provides tremendous business value as stakeholders get to see their most-valued requirements implemented and working in a dev environment faster than ever.
Unfortunately, the pervasiveness of agile has been limited to those writing code and not to the greater set of people involved in the software development process. Shortening your release cycle to two weeks doesn’t do you much good if QA requires weeks/months to run their tests. The bottleneck has now shifted from developers over to QA to get what developers are showing to stakeholders out the door and into the hands of end-users! (This same pressure applies to Ops, but that’s a different blog series.)
I’ll dive into these topics in future posts, but let me give you a teaser on some of my thoughts…
- Move QA earlier in the cycle
- Reduce your dependence on manual tests
- Increase your dependence on unit tests
- Ask yourself how your automated functional testing is going
- Learn more from production
Would you like to discus these topics in person? Come join us at the St. Louis Silver Linings Conference on Oct 30. Admission is just $30 for a whole day of breakout sessions on DevOps, the cloud, and more!