To help, give something back to the community, I recently gave a presentation at the 2011 ignite software testing conference in Sydney. Here is an updated version of that presentation.
There is a lot of sound advice in Rob Lambert’s free book The problems with software testing he covers all the big topics that come up regularly when discussing testing with testers.
Certification
When I mentioned we were recovering from our attempt to certify our way out of trouble it’s important to point out that we are still certifying ourselves silly. But I strongly believe there are now enough people in the industry who understand that certification is not working as anticipated and are stepping up to do something about it.
I personally have similar feelings about certifications, however I do think that they have a role to play for individuals who want a structured framework to learn in. I think that if the industry stopped thinking about profit driven certifications and started thinking about licensing then we would be in a better place. Steve McConnell talks about this exact topic in Stinking badges in his book; After the gold rush.
Licensing is a mandatory, legal process that is intended to protect the public. Licensing is typically administered by jurisdictions (states, provinces, and territories). For many professions, national organixations advise the jurisdictions on appropriate licensing requirements and exam contents.
Most professions are licensed, including doctors, architects, lawyers, and engineers. No occupation that affects the public as much as software does remains unlicensed.
Automation
I think Rob captures automation beautifully with this one phrase.
Software testing automation is very much like lifestyle automation; in some instances it is invaluable, in others not so. If done correctly rewards are bountiful, regression is taken care of, impossible manual things become possible and testing can be done early and often. It can also remove the tedium in our daily testing lives. Done badly and we are left to wallow in a heap of expensive kit, heavy weight instruction manuals and defunct skill-sets.
Personally I think that the term “automation” has always been a misnomer, but an alternate like “computer based test execution assistant” is a bit unwieldily so I guess we are stuck with is.
Upfront test cases
According to Rob
Upfront Test Cases are to blame for everything that is wrong with Software Testing.
Well i’m not so sure that we can blame everything on upfront test cases, but I agree with Rob’s point that we need to apply a combination of both scripted and exploratory testing, and testers should be skilled in both.
Rob’s book is full of these gems, and is a short read so it is well worth a look.
A lot has happened over the last few weeks. One of the most enjoyable experiences was to meet James Bach at the Sydney testers meetup. Since then, Trish and I caught up with James again over Skype to record a couple of episodes of Testcast. In the first half of the show we discuss walking away from a client, failing fast, and the tools that James uses.
In the second part, we discuss using Pairwise combinatorics to develop test cases.
Show #7 will be up in two weeks, in the meantime, head over to www.testcast.net and grab yourself a copy of show #6
In test cast show #5 we discuss baked goods, Trish’s six blogs, Bruce’s blogs, sqa.stackexchange.com. Then we finally get down to this weeks main topic, test data. Specifically, when is it OK to use production data in your testing.
Head over to http://www.testcast.net and download a copy.
Were’ back ….. in this episode, we talk about the Given-When-Then test case syntax, record and playback, excel-based test generation, waterfall, gated release processes and ask the question: should testers be consulted in the UI design process?
Head over to http://www.testcast.net and download a copy.