Just a follow up on the 2015 Kiwi Workshop on Software Testing (Aug 2015). Find my write-up here:
In attendance this year were:
James Bach, Oliver Erlewein, Richard Robinson, Aaron Hodder, Sarah Burgess, Andy Harwood, Adam Howard, Mark Boyt, Chris Priest, Mike Talks, Joshua Raine, Scott Griffiths, John Lockhart, Sean Cresswell, Rachel Carson, Till Neunast, James Hailstone, David Robinson and Katrina Clokie
Posted in Communities, Event, Exploratory Testing
- Tagged communities, event, experience report, James Bach, KWST, Oliver, Roles, Test leaders, Thought leadership
Below is a response we wrote to the latest Tester Magazines Newsletter article; what’s All the Fuss About? Structured vs Unstructured Testing. This was email directly to the author Geoff Horne but after his reply suggested this be used in the next edition of his magazine we felt it would be best published on our own Hello Test World blog.
If you have any thoughts, we’ll be looking forward to the in the comments.
Posted in Communities, Context Driven Testing, Exploratory Testing
- Tagged Brian, CDT, communities, Context Driven Testing, David, Exploratory Testing, James Bach, Oliver, personal, Scripted Testing, Software testing, Test leaders, Thought leadership
I usually move in the performance testing realm and one of the things I regularly do, is check for obvious omissions in website design before I get into the low down with testing.
What do I mean by that?
There is such a thing as (and I am having difficulty writing this) Best Practice, when it comes to web page development. These are technological imperatives that can be easily checked by using simple tools. You don’t need to be an HTML guru to use these or to gain more knowledge about your website under test.
Thousands of words have been written about the investigation part, and it’s usually where the information ends. You’ve got a crack bug investigation procedure. You’ve clearly identified your oracles, you’ve mapped your coverage, you know your quality criteria. You’ve been patrolling the mean streets of your pre-release build, and you’ve noticed something out of the ordinary. The adrenaline starts pumping, and you’re ready to reach for the red and blues. We wanna take this perp down. But hold up, bronco. Before we grab the pepper spray, let’s talk about what happens after you have a suspect in your sights. You’re pretty sure you want to make the arrest, but we don’t want to compromise the sentencing later.
I spoke with a tester recently about capturing tests to be reused. I had a discussion with them on what they thought about the process. I will outline their task, what they were supposed to do, what they did, and the questions and comments that came from the discussion afterwards. Some valuable lessons and insight were uncovered.
“Can you show me your test scripts?”
“Will your test scripts be part of the deliverable?”
“This role involves writing and executing test scripts”.
There is a sector of the software development community that believes, no, accepts unquestionably as a truth, that testing is writing test scripts then executing them. This leads to a vicious cycle of managers and clients asking for test scripts, and testers delivering test scripts because they were asked for them, thus reinforcing the requests and so on ad infinitum.