The very successful Australian Testing Days 2016 conference helped the TEAM gain tremendous respect in the community. Many conferences offer meaningless gifts to speakers, instead we made a large donation on the speaker’s behalf to BeyondBlue. So, when Epic Assist approached me for support in spreading their message about hiring employees on the autism spectrum, I was excited to have the opportunity to help. I was in the process of planning the 13th TEAM meetup, and I had Aaron Hodder presenting his strategic mind-maps to the attendees. Aaron was visiting Melbourne for a speaking session at Agile Australia and he was eager when I approached him with the idea of him delivering his well received Australian Testing Days 2016 talk again at our meetup.
On 21 June, the 13th TEAM meetup took place at Robert Half Technology. Richard Neville from Robert Half has been very supportive at sponsoring our meetups at his centrally located office in the city. As always Robert Half arranged plenty of food and drinks for the attendees arriving at a cold and wintery night.
Paul Crimmins was the emcee for the night. He introduced TEAM and the agenda for that night to attendees.
The first talk was from Zach Zaborny of Epic Assist. Epic Assist is a not for profit organisation that works with people with both visible and invisible disabilities, including those on the autism spectrum. It assists people on the Autism Spectrum to find meaningful employment. The organisation not only helps people in finding employment, it also trains and educates them so that they can be successful during their employment. People with Autism may find it difficult to operate in a corporate environment and may require extra support. Epic ensure that someone from their team stays with the employee until their assistance is no longer needed. Their engagement also helps employers in understanding the needs of their new employee.
Zach shared his own story with the attendees. A prolific speaker, Zach was diagnosed with Asperger Syndrome at 8. How he went through the struggle, many of us can’t understand. His presentation was hilarious, heartfelt and touching.
Zach said that the individuals on the autism spectrum are loyal, like structure, are hardworking and focused and can be great employees. He shared some tips for interviewing someone with ASD and also explained the employment barriers for people with ASD. Zach’s talk was a very informative talk and it was received well.
After a short break, it was time for Aaron’s much anticipated talk. Many attendees had not attended ATD2K16 and therefore were excited to hear Aaron. His talk was about using Mind mapping software as a test management tool.
Aaron started his talk by sharing his story of becoming a skilled tester and joining the CDT community. When he started in testing, he found himself a misfit among other testers he worked with, mostly because others believed that there was a single right way of doing things. Aaron’s talk was engaging and educating. He spoke not just about his subject matter, but he also demonstrated how he does what he was talking about. His mindmaps, which he rightly calls information radiators, were truly informative and valued. One of his slides explained why testing is not just about creating and following steps. It said,”Testing is NOT a series of steps; it’s a multithreaded series of activities that are mutually supportive”.
This meetup was one more successful event for the local testing community. While we inch closer to TEAM’s first anniversary, we have already planned for some really interesting meetups in the next few months. Check them out at http://www.meetup.com/TestEngineeringAlliance/.
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:
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:
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.
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:
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:
- 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?
- 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.
- 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.
- 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.
On 16th of March, the TEAM group organized its ninth meetup in a sophisticated office at Australia Post. Thanks to the Digital Delivery Team of Australia post for being supportive and proactive in sponsoring the event and providing the venue, pizzas and drinks. The TEAM meetup group is expanding rapidly and it is great to see testers engaging more into intellectual discussions about their craft. At the time of writing this post, the group stands closer to 380 in just its ninth month of existence.
Scott Miles introduced TEAM to the attendees and there were a lot of new faces. It is worth mentioning here that both Scott and Lee Hawkins have been accepted for their talks at StarWest conference which would be held at Disneyland Hotel in Anaheim, California.
After his short introduction, I started the discussion by asking the group what was their definition of a bug. On Paul Seaman’s suggestion, we decided to commence the discussion referring to a blog post that I wrote many moons ago about bugs vs. features. The post was about paper towel dispensers that may dispense more than one towel even if you pull just one. From a user’s perspective that may be a bug because the user may expect just one towel to be dispensed. However, the dispenser or towel manufacturer may want users to pull more than one towel to increase the profits. I left the discussion right there so that people could think more on the topic and can come up with their own reasoning.
In order to maintain focus and increase participation, we decided to break the big group into two smaller groups. There was a lot of debate and discussion within both smaller groups while almost all members were trying to present views from their own perspective. There was a lot of energy and laughter in the room because attendees were sharing their experiences, asking questions and being questioned on the definitions they came up with. It was evident that many attendees started thinking in a shallow way, associating bugs with requirements and code, etc. However, debate and questioning helped them think more deeply and critically.
When both groups came up with their agreed definitions and presented them back to the larger group, it was about time to introduce them to the Rapid Software Testing definition of bugs (for some reason I mistakenly attributed this definition to Jerry Weinberg):
Bug: Anything that threatens the value of the product. Something that bugs someone whose opinion matters.
Everyone in the room seemed to agree with this definition. Now was the time for the debate on the main topic of this meetup: Zero Bugs. Each group was to take a side, in favor or against. Since there were not many who favoured the idea of achieving zero bugs, we asked for volunteers who could think and come up with arguments especially against something that they believed. It was certainly a challenge for many of them and some of them told me after the meetup that it was a great experience and a learning for them about thinking beyond their beliefs.
The debate was indeed feisty. Arguments and counter-arguments kept the room full of energy. Some of the testers who never before spoke at the meetup came up with such convincing arguments that everyone applauded. The passion of these testers was contagious and was making my job as a moderator harder.
Colin Cherry shared his experience that he recently discussed in his blog post too.
Towards the end Paul Seaman quoted Dijkstra saying:
“Testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence.”
A break followed the discussion and allowed the group of about 45 to talk more and clean up what was left of the pizzas. Good conversations ensued and, as usual, the group were a very engaged bunch. I wasn’t surprised when people enquired about the next meetup and I suggested them to bookmark this page:
Scott had already suggested that everyone keep an eye on our website, http://www.testengineeringalliance.com, where we are offering much more value to the testers of Australia – including the opportunity to take the Rapid Software Testing course with Michael Bolton and a testing conference, Australian Testing Days, all happening in May 2016.