[Updated: Fixed grammar foul on ‘Tenants’ vs. ‘Tenets’.]
2012 is drawing to a close, and apparently all the worry about the Mayan calendar not extending past today is thankfully misplaced!
The ending of a year is a good time for some introspection, and some thinking about what’s in store for the next year. Lots of smart folks in the testing field have their own opinions about what we’ll see (or won’t!) next year, but here are a few of my thoughts. Keep in mind this list is totally in line with my own very opinionated biases!
This discussion has been going on, well, forever, but I think it’s rightfully gaining more and more traction. Maybe we’ll be able to start moving past the awful “collaboration” and “agile” buzzword silliness and really look to a serious commitment at all levels to push testing communication throughout a feature’s entire lifecycle.
I know I’m talking a lot about lean concepts with automation, and I see more and more pals and influencers in the automation field using the same ideas. I think we’re finally seeing more and more conversations in the automation sector regarding careful selection of what to automate. The idea of converting 100% of those 35,423 manual test cases to automation has thankfully become less acceptable.
Be clear: I’m not the one who’s started this line of conversation/thinking, I’ve just been a long-time proponent of all things Lean, and we need to pull those same value-based concepts into automation: focus on automation that delivers the highest value, ignore everything else. Increase value, eliminate waste.
Bringing Craftsmanship Tenets to Automation
The software craftsmanship movement has been extremely inspiring and advocates many great approaches regarding how system software is built. The testing industry needs to carefully look at the craftsmanship movement and take the same approach. Hopefully we can avoid some of the silly condescension and egomania that permeates that movement and instead focus on adopting some of the tremendous lessons they’ve learned.
Our tooling also needs to continue evolving how we express the tests, acceptance criteria, and most importantly the why of what it is we’re doing. Tools like Cucumber and Robot Framework aren’t the final answer, but they’re certainly amazing steps in helping us explore the next steps.
This ties together with Whole Team Testing. We can’t afford the mindset that it’s acceptable to do weeks’ or months’ worth of work, then throw the project over a fence (metaphorical or not) to “Quality Assurance.” That’s never, ever worked, and we as testing professionals need to be more emphatic about changing this.
Instead we need to push our collaboration earlier into every conversation about features and roadmaps—getting involved before any work is actually done. Moving our conversations and work earlier in the schedule (left on the project plans) will help save our sanity, and more importantly, help us as teams deliver better value to our customers.
Here’s another buzzword I generally dislike; however, I had my mind changed on it during my trip to India earlier in December 2012. The people I spoke with at conferences, events, and customer sites were serious about transformation. They’re asking hard questions about how they need to change their work to not only remain relevant, but awesome.
“How can we work faster?” “How do we deliver more value to the customers?” “How do we ensure we’re working as best we can?”
These sorts of questions were prevalent everywhere I went, and it was wonderful to see so many people serious about fundamental changes to how they do their work.
I have no idea where we’ll be at the end of 2013, I just know it won’t be where we’re at right now. I look forward to seeing what 2013 really looks like!
What are your thoughts on testing’s evolution over the next year? Three years? Five years? Let us know in the comments!
Subscribe to be the first to get our expert-written articles and tutorials for developers!