Featured

Agile hasn’t failed you..

Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. I wrote a short spiel on Agile some time ago in an effort to clarify how I see it.


For quite a while I have been observing some interesting posts and discussions going on LinkedIn.


One of the topics that I recently noticed was Agile failing organisations. If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation, as we might understand and critique the failure of any other tool the organisation might use. A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just so you know, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can’t think of at least three different interpretations of what you have received, you haven’t really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”


When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
  1. We don’t know enough about Agile and we tried to “do Agile” rather than “be Agile”.
  2. We thought we knew about Agile and we implemented it the way we knew it. What we did didn’t work..
  3. We thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. We couldn’t deliver anything..
In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.


What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to  understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile (mindset) adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.


So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.



Acknowledgements: Thanks to Paul Szymkowiak and Jari Laakso for their feedback and recommendations.

Quality Index : Fooled by Measurement

STPCon published this article on their website. I am happy to share it on my blog as well. 

http://www.stpcon.com/quality-index-fooled-by-measurement/ 

The software industry seems to have an obsession with metrics and measurement. We want to quantify everything. Once upon a time everything was about counting lines of code (KLOC). Managers ran around asking, “How many lines of code have you written? How many bugs per KLOC are there? What is the size of project in KLOC?” etc. Then we started counting everything else that was left from quantifying KLOC and managers started asking, “How many requirements are there? What is the number of test cases? How many bugs did you find? What is the defect density? How many test cases are passed? What is the requirement coverage?” etc.

The obsession with quantification is often an influence from the manufacturing industry where you can count things that are physical and are visible to eyes. However, counting things in the software industry appears to have helped consultants who sell the premise that charts, graphs and measures based on invalid constructs are meaningful. The problem is often the misinterpretation of these metrics.
At one of my former workplaces, the testing team used to generate a report which had a metric called “Quality Index” (QI). The objective with this measure, that the team explained to me, was to have some indication of quality and performance. The managers needed an indicator to assess development performance (for example, are there any issues with understanding, communications, requirements, process, and so forth). The QI measure was considered a yardstick. That is, every time a new build was tested, QI could tell managers how good (or bad) the build was.
However, there is a problem with using yardsticks. They can’t be used for measuring something that is subjected to interpretation or is subjective in nature. Often they are good heuristics and can be useful as a first order metric, but mostly for physical measurement only.
A metric, like quality index, may be used as an indicator to ask, “is there a problem here?” In that case it becomes a heuristic. Because it is fallible. It may help you find a solution, but it may never guarantee one. Using heuristics for assessing your key employees performance is dangerous. You may lose their trust and respect and they may eventually leave (unless that is what you actually want).
Metrics are a powerful tool but they can always be misinterpreted and can be skewed to show favorable (or otherwise) results. Without context they are very much meaningless. Quantitative measurement can lead to a false sense of control. It creates an illusion that we can understand and control something because we can count it. Someone mentioned in an online forum about quality that if you can’t measure it, you can’t have it. I guess this person was referring to Tom DeMarco who wrote in his book “Controlling Software Projects, Management Measurement & Estimation, (1982), p. 3.” that – you can’t control what you can’t measure. In a recent discussion Michael Bolton reminded me that few years ago Tom renounced from the opinion that he has held. His recent views can be read here.
As I mentioned earlier, metrics are often used as a sales tool by consultants to gain more business. I was recently invited for dinner at a 5-star hotel by the testing group of a large bank in Australia. I wasn’t aware that the dinner was actually hosted by the bank’s testing vendor, a huge I.T. outsourcing firm. This vendor’s introductory presentation included the data of efficiency they brought to their banking client. These details included automating 3500 test cases, reducing test preparation time by 70% and so forth. As James Christie said in his blog post, “100 is bigger than 10. 10,000 is pretty impressive, and 100,000 is satisfyingly humongous. You might not really understand what’s happening, but when you face up to senior management and tell them that you’re managing thousands of things, well, they’ve got to be impressed.” This vendor certainly impressed their naïve client.

What is this beast called Quality index?

The QI index that was used by the teams I worked with had this definition:
The QI has been defined as a measure of defect density, such that the percentage of defects as a proportion of the total number of test cases executed is defined.

This is a measure of company’s software quality delivery to testing as opposed to company production quality.

Lower QI is better.
The report used to have statements like:
171 test cases executed successfully and 93 defects detected, providing a Quality Index (QI) = 54% (this is within the 1 – Unsatisfactory level).
There were graphs like the one below which explained what and how the quality of the build has been:

“So what’s the problem here?”, you may ask.
This seems to be a valid question, especially when you have been told about these indices and were presented with data that seemed accurate. We see such indices on TV every day where some eminent economist is presenting his view on the economy and predicting which way the markets will go, and later convincingly explains why the markets did not go the way he predicted. The simplest answer is that no one, including Nobel Prize winning economists, can predict the future. Humans simply do not have the ability to predict. You may say that you can predict that you will read the next word on this post – but even that is unpredictable. What you would actually mean is, “I predict that I might be able to read the next word provided the boss doesn’t call right at that moment, or the monitor doesn’t lose power or the sky doesn’t fall or..!” The list can go on.
I studied Statistics as one of the subjects during my Masters degree. While that study did not make me an expert in statistics, it did improve my knowledge of the subject though. And I think it will also help us examine what is the problem with this quality index. Let’s start by looking at definitions.

What is “quality”?

Jerry Weinberg defines quality as “value to some person(s)”. James Bach and Michael Bolton added ‘…who matter.’ to this definition. So the definition that I like is, “Quality is value to some person(s) who matter”.
Michael Bolton suggests that decisions about quality are always political and emotional; made by people with the power to make them; made with the desire to appear rational and yet ultimately based on how those people feel.
Let’s have a look at the overall definition once again. “The QI at Company X has been defined as a measure of defect density, such that the percentage of defects as a proportion of the total number of test cases executed is defined.”
What catches our attention is the term “defect”. Although I prefer calling them bugs.

Is there a point in defining defect density?

James Bach says that a bug is anything that threatens the value of a product – something that bugs someone, whose opinion matters (this last part was added by Michael Bolton). This definition automatically makes the benefits that someone may be seeking from quality index highly questionable. Like predicting the future, humans do not have the ability to find and explore all bugs that might be there in a system. Michael Bolton notes that “the idea of a “bug” is subject to the Relative Rule meaning a bug is not a thing that exists in the world; it doesn’t have a tangible form. However, a bug is a relationship between the product and some person. A bug is a threat to the value of the product to some person. The notion of a bug might be shared among many people, or it might be exclusive to some person.” So, there may be little point quantifying something that does not have a physical existence. Once people start counting bugs, they start falling in love with them. They feel that they own these conceptual non-physical things. Psychology defines this as reification, the perception of an object as having more spatial information than is actually present. Is it worthwhile defining density of an abstract concept or of something that is subject to relative rule?

The wild world of test cases

The definition of QI also talks about deriving a percentage as a ratio of number of test cases. What is your definition of a test case? My team stopped writing lengthy, step-to-step test cases or scripts in a deliberate move away from the idea that testers should develop test cases based on a requirements document. What I have observed is that many testers take a requirements document and create a number of test cases for each requirement like positive, negative, sedative, nonsense-itive and so on. These testers wrongly believe that these test cases provide complete coverage1 for the requirements. They create a Requirement Traceability Matrix (RTM) which is usually a table with test cases on one axis and requirements on the other. If all requirements have a mapped test case, then coverage is complete. The managers believe that these detailed test cases help their tester perform complete testing. Managers get upset when coverage metrics are not there or the RTM is missing.
What they don’t realize is that when they say test, what they really mean is check. Then, a single requirement may mean more than one assumption, proposition or assertion. A business analyst who writes business stakeholders requirements may interpret them entirely differently than the stakeholder herself. A developer may interpret them differently and similarly a tester may interpret and intersect the requirements in a very different fashion not understood or agreed by others. Hence writing a test case per requirement or multiple test cases per requirement sounds completely incorrect. If that is incorrect, then the ratio based on an incorrect number would be wrong too. And therefore, that makes the concept of Quality Index meaningless.
So what do you think of this claim now:
This is a measure of Company X’s software quality delivery to testing as opposed to Company X production quality.

Lower QI is better.
The QI as it is defined is not a measure of anything of value about the software or its quality – and is easily gamed (e.g. just split test cases into smaller test cases and hence immediately reduce the QI for exactly the same piece of software under test with exactly the same number of defects!). The QI itself even tells you that the testing it relates to (and the way it is being measured) is not great, by saying “Lower QI is better” – this means you are striving to make test cases that don’t find defects, why would you do that? Ethically we should not.
As skilled craftsmen, we should not waste time counting and showing percentages when we could best spend our time talking to our stakeholders about the things we see, the things that interest us, things that looks suspicious, the risks we observe, and the overall quality as we perceive it.
So, the next time you are counting test cases or bugs, working on a RTM or looking at percentages in reports, ask yourself, “Am I simply counting and giving statistics or am I helping our organization to deliver a quality product with the lowest risk of failure?”

Helping those on the spectrum / Information radiators – TEAM meetup #13


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/.

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.

Zero Bugs: TEAM meetup # 9

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.


Experience Report from TEAM Meetup # 8


On 24th of Feb 2016 we organized our latest Test Engineering Alliance Melbourne (TEAM) meetup at Envato’s cool (figuratively speaking) office. Envato graciously sponsored the event and arranged for venue, pizzas and drinks for our event. We had observed that the TEAM membership increased by 10 right before this event and crossed 350 members. It has been a good growth in the last 8 months and demonstrates that the TEAM has been successful in its mission of building the community and advancing the practice of software testing in Australia.

This event was largely focused on Agile. I commenced the event by introducing TEAM to new members and sharing details of upcoming workshops. After the intros  Lee Hawkins, who is also a co-organizer of the meetup, gave his talk titled “Growing Testing Skills using the Agile Testing Ecosystem”. The content generated a lot of interest from the audience and there was a long Q&A session.

The next talk, “Why/how Agile Transformations Fail”, was from Paul Seaman, who has been a very active member of the testing and Agile community and is also a co-organizer of TEAM. Paul has been known for a while as “The Agile guy” inside and outside of the local testing circles. He has recently worked on various Agile transformations and his talk was purely from the experiences he had working on those projects. Paul knows his subject matter pretty well and his talk reflected his knowledge.
The TEAM organizes meetups every month and they are a great platform to learn, network and talk about testing with fellow testers.  This meetup is the only testing meetup in Melbourne that has many internationally recognised testers as organizers or members. Join the meetup at:
TEAM is also bringing one of the best testing experts Michael Bolton to deliver the most sought after testing course Rapid Software Testing (RST) and Rapid Software Testing for Managers in May 2016. If you want to know why you should attend the course, you should read this by Lee Hawkins. 

By the way, if you have not heard about the brand new international testing conference that TEAM is organizing in Australia yet, have a look here: 
http://www.testengineeringalliance.com
The conference features best of the testing industry experts as speakers, including Lee Copeland, Michael Bolton, anne-Marie-Charrett among other talented testers from Australia and New Zealand.



Paul’s  presentation: Yogurt has an inbuilt culture’

Delhi Testers Meetup- The Power of Conferring


On my recent visit to India, Santhosh Tuppad (@santhoshst) decided to travel to New Delhi with few of his colleagues so that we all can meet. On my suggestion Santhosh organized a public event instead. The Delhi Testers Meetup (or TEAM-Delhi) was born and was planned for Sunday, 27 September 2015.  
I called the meetup TEAM-Delhi because Test Engineering Alliance Meetup (TEAM) in Melbourne has been a very successful meetup since its inception and testers in Delhi exhibited similar passion and engagement when we announced the meetup in Delhi.
The meetup was at a hotel’s conference room and the hotel staff arranged the room in a formal classroom structure. But I wanted my Exploratory Testing workshop and other discussions more interactive, so we began the meetup by moving tables & chairs around. The benefit of this movement was that it started informal talks among people. I did not realize that passionate testers can turn anything into a worthwhile valuable discussion. It was a good beginning.
Testers who attended the meetup were: Santhosh, Dwarika, Alka, Siddharth, Devangna, Sahas, Atul, Nitin, Rupinder, Ramit and Kapil. After a while Smita Mishra also arrived who is organizing a Testing conference in Delhi along with Rapid Software Testing class with James Bach.


I started the Exploratory testing workshop by giving a snapshot of context-driven testing and the strong community support that Context-Driven testers get. I focussed on following topics in my workshop:

– Definition of Exploratory testing
– Changes in definition over the years and the latest from ET3.0– Skills of a good exploratory tester – Note taking, exploration, experimentation, questioning, study, modeling, observation, inference etc.


We talked about Heuristics and mnemonics (“rules of thumb”), Oracles (how to recognize problems), Session-Based Test Management (SBTM) and cheating. Some of the good exploration skills that we talked about were self management, critical thinking, developing test ideas, examining a product and telling compelling testing stories.  
An important part of the workshop was to explain ET from Rapid Software Testing namespace perspective. RST has its own namespace and I believe that any practitioner who teaches ET should keep that in mind.
Another important aspect of my workshop was the exercises. We worked on various exercises including developing testing idea for a simple program that calculates two integers, testing a basic calculator and testing an image. I explained through exercises that testers can miss bugs because of inattentional blindness. We looked at Google calendar to understand oracles.
There was a lot of discussion and everyone was contributing. When we discussed about questioning skill, Ramit mentioned 635 technique (Method 6-3-5).  We talked about effect of culture on testers (and testing) and then there was another discussion about testing conferences and their value.
Santhosh shared his views & experience on Security testing and very soon the discussion digressed to emotions, at which point Santhosh explained Plutchik’s wheel of emotions. From there the discussion moved to Persona-based testing and that led to a question whether testers can actually test like users or not. There was a mention of colorology but I do not remember the context in which it was mentioned.
The passion and energy in the room was contagious. Even those who I considered reticent, participated well in all discussions. It was a free-flow of ideas and I did not stop anyone from contributing or digressing.
I learned so much from everyone and I am sure all learned a lot too. This is what I call power of conferring.
Thanks to TestInsane for organizing the event.