Under starters orders

If there is one person that has delved the deep of thought processes for testers, it is James Marcus Bach (@jamesmarcusbach)
I recently attended his Rapid Software Testing course, held over three days in Brighton @68middlest and organised by the Ministry of Testing.

This wasn't what you would call a certification course. Mainly because there is no certification of the likes handed out by the ISTQB, one which is often quoted by many a tester on their CV, including myself and one which James Bach, and others have competently criticised. Having completed their foundation course back in 2007, this was an entirely different experience.

The teaching mirrored the beliefs.

The days were mixed. Part oration, part practical, part hot seat and even a magic lesson. There were various exercises, lots of questions and lots of critical thinking.

James Bach uses the Socratic method to teach, constantly challenging the class and showing that he has thought and practiced a great deal about what he preaches.

In particular, the hot seat was a Bach laser, focusing on one person to provide answers to problems, aided by the rest of the class, which resulted in differing reactions and responses by those brave souls that offered themselves up for scrutiny.

Each of the three days was intellectually challenging, fun and full of useful information. I also met some testers of the calibre we are looking for - http://www.scottlogic.com/careers/vacancies/test-engineer/ - at Scott Logic.

So, what is Rapid Software Testing?

It is a mind set and a skill set of testing, focused on how to test more quickly, less expensively and with excellent results.

Huh..i don't understand?
Testing isn't writing test scripts.

Really, is that true?
Testing is engaging with the product, questioning premises, managing assumptions, gaining and using knowledge to improve product quality.

And?
Using heuristics, thought processes, tools and experience to test a product methodically and efficiently will produce better results.

So?
Testers must have freedom, wisdom and responsibility.

Rapid software testing is rapid learning. Using product knowledge or domain knowledge, thinking logically and creatively, using impressions and intentions, just indulging curiosity or using critical thinking to look for mistakes, managing assumptions and always questioning premises to uncover the truth about a product using any method, heuristic or tool appropriate.

Use of heuristics is a major theme in rapid testing. Defined as an experience-based technique for problem solving, learning, and discovery that gives a solution which is not guaranteed to be optimal. Experienced testers often use these without thinking, but identifying heuristics is an important part of rapid software testing, so that, as a tester, you are able to thoughtfully explain or report what it is you are doing, or have done.

At Scott Logic, our testers have freedom to express themselves, the wisdom to test in the right way and the responsibility to take action.

We also have shared models of the way an application behaves. These are shared expectations. A shared understanding of something. An implicit declaration across the team about behaviour of the application.

Developers might have shared models, how code should be written, particular notation or input control behaviour. This isn't necessarily verbalised, it could be gained through common code or just chatting regularly about the application under development.

Testers also have shared models. These could be through shared experiences, expertise and common cause scenarios, conversation, bug logs or just from testing the same application.

Developers and testers share models too. It may be that sometimes these models aren't quite in sync. A bug is an example of a difference in the model where the functionality or behaviour hasn't been explicitly defined, but implemented in a way that shows that difference. These shared models are continually updated and refined through continual conversation between the development group and of course bug logging and fixing.

Effectively a shared model doesn't need to be explicitly stated or defined.

A close connection to our developers and great communication provides a basis for us to test efficiently and produce excellent results.

Good testers find important problems sooner.

There are many pitfalls that structured testing provides and good testers go off piste, using their knowledge and curiosity to explore and learn more, which often leads to finding problems that wouldn't be found if they hadn't.

For example, one of the ideas that James Bach discusses is the difference between blindly following a test script and freedom of expression.

We recently gave some regression test scripts (created and updated by the client) to a developer that hasn't looked at or developed a particular area of an application they were developing. They were asked to follow scripts. But, those scripts hadn't been kept up to date as the application had changed considerably in just a couple of sprints since they were written and tight timescales hadn't allowed for updates.

So, they weren't able to properly follow the script without asking questions. (Our developers are good...they ask questions).

To complete the testing, with an experienced tester to guide them, they learnt more about that area through rapid testing, using the scripts as a guide to the functionality under test, but made their own journey through the application. They tested all the functionality, but did so in their own way, which gave them a deeper understanding of that area and found a major bug whilst doing so that they wouldn't have otherwise.

There is a very important distinction between a list of things to think about and a list or set of rules to follow. Good testing is an interactive cognitive process and blindly following rules can lead to important undiscovered bugs.

At it's core, rapid testing is rapid learning and it really is both an art and a science.