Why I attended RST and why you should too!


Ever since we (Test Engineering Alliance Melbourne) started our meetup in June 2015, both Dr. Lee Hawkins and I have spoken about the great experience we had learning from James Bach and Michael Bolton through our direct interactions with them and also by attending Rapid Software Testing class (RST). So, when we organised an RST course in Melbourne for May 2016, there were many questions from people who wished to attend but were confused about the course and wanted to know more. Some people had genuine financial concerns and needed ammo for their business cases; for that I would suggest you read this post.
Since I had been planning to write a blog post after I attended the 3-day course in Sydney last year, I took these questions as an opportunity to complete that post by expanding the mindmap that I created while in the class.







What is Rapid Software Testing?


RST is a mindset, a methodology created and taught primarily by James Bach & Michael Bolton. You may wonder whether it is similar to other training courses which offer you a certificate. Simple answer is no, it is not a certification course and it goes far beyond any other training courses that are offered in Melbourne. Although the organisers may provide you with a course completion certificate to show that you attended the course.

RST does not teach you about testing through reading and memorising from a catalog or glossary. There is less emphasis on theory and more on learning by doing. Imagine learning to cook by reading a cookbook and passing an exam to prove your competence. You may learn some terminology but unless you really cook, experiment with food, make mistakes and probably also burn your hand, you may not learn cooking. RST takes a different approach; you learn or improve on your testing skills by performing tests on the software. You are asked to apply cognition while doing testing. The course is based on Socratic method. That is, you understand the concept by answering questions or through arguments & dialog with the teachers.

What makes RST different?


As I said earlier, unlike other testing courses this class is not just about teaching testing through theory. The RST class is based on learning through experiments, practicals, discussions and hot-seat exercises.

There is a lot to learn and 3-days (or 1-day for managers preferably after taking 3-days RST class) are probably not enough. But an important aspect of the RST mindset is self-learning. The information available online helps in continuous self learning. This course equips testers with critical and lateral thinking skills that most other testing courses do not. Testers learn about testing through heuristics and oracles.


The course teaches:


  • test modelling & designing


  • how to test when time is limited


  • what to look for when you are testing a new product and you are not sure of what to do


  • questioning skills, judgement, observation, conjecturing and much more



  • improved cognitive abilities through games of critical & lateral thinking




The list above is not exhaustive. There is so much more in the training if an attendee is willing to learn and comes with an open mind. The course aims at making you a better tester and lifts you up from having a shallow understanding of testing to having a deep comprehension.

Another important aspect of this training is to teach attendees about the distinction between testing and checking. If you have not heard about the discussion of testing and checking, a starting point is here.

You learn more about focusing on your mission, on your client, asking questions, risks and most importantly, cheating.
Testers learn about time saving techniques like mind-mapping which not only helps them build their test ideas, but also reduces time instead of writing a magnitude of documentation. Another important thing that one learns is bug and test reporting (no, your automated reporting tool does not do what you learn here).

As managers, bug reporting and coaching testing techniques to our testers are important skills. Knowing when to do MIPing (mention-in-passing) and when to do black-flagging certainly goes in testing team’s favor. It is worthwhile attending the 1-day manager’s course which also focuses on test management aspects.  

One of the questions that someone recently asked me was why they should attend RST in person while all the material is available online and there is also an online training. This is true. These days almost everything is available online. Not just for this course, but also for performing surgeries to bomb making. Would you become a surgeon by watching videos online? The other one might be easier although (but the end might not be).
The online RST course information is concentrated. Unless you have read all written work of James and Michael, and have discussed those with them, it is often not as easy to assimilate the content.

The online RST course is a refresher or an advanced study course for those who have already attended detailed RST class. The online class runs for few hours and is online. The RST 3-day class is face to face and is delivered in a classroom setting. The manager’s class is for 1 day and it is recommended that they attend the 3-day class before attending the manager’s class.






Here are some other blog posts that talk about RST and why you should do it:


Heuristics & Oracles

Recently, I was invited to deliver a talk at a local meetup group that focuses on automation in testing, the Software Test Automation Group. Since this group has a strong leaning towards technical aspects of testing, I decided to explain the terms testing and checking to them and why understanding these terms matters. During the talk, I touched on Heuristics and Oracles as approaches of testing and I could see the puzzled look on many faces. These terms were clearly new to many people in the room and I am sure for many others the word oracle was limited to the company Oracle. I wasn’t surprised, though.
For many testers, heuristics and oracles are strange or new concepts. They find them pedantic, too philosophical and not practical for use in real situations (yes, I have heard these comments from testers as well as non-testers).
It takes some education and explanation about heuristics and oracles (and how we can use them as effective tools to amplify our testing) before people start to “get it”.
In its simplest definition, a heuristic is a rule of thumb that you apply to solve a problem. Wikipedia definition is here:
A heuristic technique, often called simply a heuristic, is any approach to problem solving, learning, or discovery that employs a practical method not guaranteed to be optimal or perfect,  but sufficient for the immediate goals. Where finding an optimal solution is impossible or impractical, heuristic methods can be used to speed up the process of finding a satisfactory solution. Heuristics can be mental shortcuts that ease the cognitive load of making a decision. Examples of this method include using a rule of thumb, an educated guess, an intuitive judgment, stereotyping, profiling, or common sense.

Often enough, when we face a problem, we try some solution that may work.  If you suddenly find your computer inoperable, what do you do? You may press the power button; if that doesn’t work, then you may check the power cable, and if that also doesn’t work, then you may try plugging it into a different power source and so on. Most of us try a number of steps to solve our problems. These steps may not always work but we try them because we know that they may work.
When you test software, you use these heuristics either knowingly or unknowingly. Even when you have your test cases or scripts written down to minute detail, you don’t usually follow them exactly as-is. Have you noticed there are times while testing that something captures your eye that is either not in your scripts or not even in the requirements and you say to yourself, “hang on, that doesn’t look right. Let me try this (something) to see what happens.” You suspect a problem because heuristics (your knowledge, learning and experience) are guiding you.
What are oracles?
An oracle is a principle or mechanism by which we recognize a problem.
I often use an example of a calculator to explain oracles. Let’s consider adding two numbers on a basic, digital calculator. Let’s press 3, then press 4 and then press the equals button. What do you expect? You may expect to see a 7 on the screen because your previous experience with calculators – and mathematics – has taught you that 7 is the right output.
Now what would you do if you see this 7 appearing upside down, or as 7.000 or on the left side of the screen instead of the right? You will probably suspect that there is a problem there. And how do you know that there was a problem? The experience with calculators is your oracle. You are comparing your results with similar, comparable products and also from your familiarity with other calculators. In other words, you are seeking consistency or using “consistency heuristics”.
In our example, the oracle will fail if what we saw as problems are in fact features of the product. 

James Bach and Michael Bolton devised a mnemonic called FEW HICCUPPS where F represents familiarity and the first C represents comparable products. These heuristics are fallible, but they help recognize a problem. These techniques, like any other testing technique, are fallible and context-dependent.
Familiarity. We expect the system to be inconsistent with patterns of familiar problems. Explainability. We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.
World. We expect the product to be consistent with things that we know about or can observe in the world.
History. We expect the present version of the system to be consistent with past versions of it.
Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
Claims. We consider that the system should be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals…) or in conversation (meetings, public announcements, lunchroom conversations…).
Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.
Let’s take another example that my friend Dave Greenlees explained in one of his articles.
Google Calendar has a logo and a search bar on the page. When I asked people at the meetup what they expect if I click on the logo, many said that they expect to navigate to the Google home page. Why? Because that is what most other websites do. So that behaviour became an oracle. An inconsistency in this behaviour might have prompted some of them to log a bug (and their bug report would have more credibility by referring to their oracle than just expressing an opinion).


Learning more about heuristics and oracles can help you test better. There are numerous resources available online. For me, I often resort to my usual source of knowledge, Michael Bolton’s blog. Specifically, read “oracles from inside out, part 1-9” on the developsense blog along with these posts to learn more about heuristics:
A useful tool that I have been using is the Test Heuristics Cheat Sheet created by Elisabeth Hendrickson et al. If you have come this far, I would urge you to learn and then start using Heuristic Test Strategy Model created by James Bach.

Convincing Your Boss (or not) for Trainings & Conferences

Many of us would like to take advantage of the numerous workshops and conferences available in order to further our knowledge and professional growth. However when it comes to convincing our employers to sponsor these events some of us find it difficult to justify the expense to our employer. Some of us also complain that their bosses do not take interest in their professional growth, learning and development.


I believe that organisations have a responsibility in the training and development of their employees. Not only because these employees are an integral part of the organisation and act as representatives, but also because good employees help the organisations grow (in a similar way that bad employees may ruin an organisation’s reputation).

If you are considering asking your employer to pay for your external training, a conference, or a similar event, then here are a few things that will assist you in being well prepared to make a compelling case before you approach your boss.

Convincing yourself first
First of all, ask yourself why you want to attend the event and what’s in it for you. Do you want to attend the event because it actually adds value to you and your employer or is it because your colleagues from another department attended a conference last year and you just want to settle the score? Are you convinced that it is good for you to attend this training or conference, or are you looking for a couple of easy days off work? If the objective is not clear to you and you are not convinced then you will not be able to convince others; specifically those who you want to pay for your attendance. Do your homework and learn about the event as much as you can before approaching your managers. Consider how the event will improve you as an employee.

Finding out about the event
Before you know how the event can benefit both you and your employer, you need to understand what the event is offering. Here are some ideas on how to conduct your research:

  1. Google it. Find and read all reviews & feedback. What are others saying about it? Did people like it and recommend it? Why did they like it and what value did they get out of it?
  2. Learn about the speakers or trainers. Are they known for their skills in the industry? Are they local or international? Do they organise or participate in any other events? In other words, check out the credibility of the people you’re paying to listen to.
  3. Ask others who have experienced it before. Connect with other members of your industry and ask what events they have participated in themselves. Ask what they think about the speakers or trainers, even if they haven’t been to this event.
  4. Connect with the organiser(s). Contact the person collaborating and organising the event. Find out what they hope the event will deliver and what the key takeaways will be.

What to include in the request (your business case)
Now that you know what the event will do for you, ask what’s in it for your employer. Every employer or manager has a budget set for the year and training, conferences or similar events are often a low priority for them (sad, isn’t it?). In most cases, managers have to justify the benefits of these events to someone else in the organisation. It may be a senior manager, an accountant or a finance team member or even an auditor. Therefore, it is important that you present a convincing and strong argument to them.

A good way of coming up with a business case is asking yourself “if I was the approving manager and someone had come to me with this request, would I have approved it?” Your employer will be thinking about much more than just the value that the event will add to you. Does the company benefit by your presence? Would you be able to meet potential clients and spread good word about your company? Will you be able to share this knowledge with other members for your team?

It is also worth considering the frequency of the training or conference. If it is a high profile training course (I consider Rapid Software Testing to be such a course) or an annual conference, you may add to the business case that if you miss the event it may be a year or more before there is another opportunity to do so.

Find out whether there are any other similar events available to attend (similar here meaning in content, trainer reputation or ideas generated/learned at the event) that may help in moving to a more positively radical or innovative work environment. The event may be unique and may not compare with any other events offered. Adding this information to your request may help.

Also find out whether attending that event gives you or your employer an edge over others in the industry. For example, if everyone is delivering using a lengthy documented process, your experience of effective delivery through visualisation models may make you (and your employer) appear different from the crowd.

It might be useful to add to the request that if you are allowed to attend, you may be able to train others or share your experience with others who might benefit from it. Or that you would be able to make changes to the existing systems, practices or processes that might have positive impact on the business.

When you ask your boss for the privilege of training, ensure you make your case legibly, easy to understand, balanced and un-emotional (note that this is not the same as emotionless). My personal experience is that short, to-the-point sentences in bullet points make it easier for managers to read and assess.

Hopefully you will not need to explain this much to your boss, but if you have to then ask “If you were a carpenter, would you invest in upgrading your tools?” Just as a carpenter sharpens their tools, a tester needs to sharpen their minds.

Your sponsorship request failed, now what?
You did everything that should have convinced your boss, but for some reason your request was not approved. If you feel that by not getting sponsorship you are losing an important opportunity to learn or network, then probably it’s time you think about this situation from a different angle.

If you are convinced of the value of attending the conference or training, then you could consider paying for it yourself. At first it might look like a significant amount, but don’t you think a good investment would pay a good reward? If yes, then why shy away from investing in it yourself? You are doing it for yourself, aren’t you?

Be aware of HR and other relevant policies
Check if there are any company policies that you can benefit from. For example, you may be allowed to take paid leave for attending external training or maybe you are allowed to go for training without using annual leave. The best way to find out is to speak to your manager or the HR team.

Checkout if there are any government policies that you can take advantage of. For example, Australian Taxation Office (ATO) allows people to claim expenses on professional courses, trainings and seminars. Speak to your accountant or look at ATO website for more information about this.

Why self-investing might go in your favour
If you are considering a job change, then attending professional growth events can be a great investment, even if you need to pay from your own pocket. Firstly, you do not want your employer to pay for something which you know they will not benefit from. Don’t ever let go of your ethics for short term profit. Secondly, if they pay for your attendance and then you leave shortly afterwards then your manager may not be inclined to give you a good reference.

You may meet potential hiring managers at the events and you may feel more confident talking to them, especially if it is an event where you expect senior managers from other companies to visit or if you notice companies attending that might be looking for people.
Remember that this is your career and no one but you is ultimately responsible for it.  Your employer’s and manager’s interests are secondary. No one cares about your career as much as you do. So if you think that doing something extra would help you do better, do not hesitate. Money well spent is money well earned.