The aim of this blog is to look at things from a automation and performance tester’s practitioner’s point of view; for that matter software testing in general even. Since things rarely plays out like they do in the textbooks its good to have a real-world point of reference. For example, Queuing Theory is a powerful tool, and I’m a fan of calculus and the like with all of its un-decipherable notation but does your client who is implementing a Financials package really appreciate project time going towards building that sort of model? Performance modeling is an adventure to say the least, but when it comes down too it, what really works and what matters?
There is a great blog Fabulous Adventures in Coding that inspired the site’s title, expousing on how rocket science is a relatively simple and exacting activity that requires a decomposition of systems to make them easier to digest. Something that I don’t think has been fully embraced by functional software testing, much less performance and automation. Some developers test their code at the unit or component level, but in my opinion that should be done by resources dedicated strictly to testing. The developer as tester, instead of tester versus developer is a novel concept. A novel concept that is truly a matter of opinion and circumstances/environment. What this site hopes to do is become a resource to answer questions about how we should approach testing to get the job done.
Test Well!
The blog entry Writing Code Isn’t Rocket Science (It’s Worse Than That)
This site is administered by Howard Clark of the Software Testing Advocate Group, LLC.