¡Hello to everyone!

Today, I’d like giving out a few pieces of advice from what I’ve done to introduce the ideas of using and working with Exploratory Testing while managing it with Session Based Exploratory Testing, and organising it using Trello.


Let’s get started taking our first baby step, because as it is expressed in a quote credited to Lao Tzu:

“The journey of a thousand miles begins with one step”. Lao Tzu

Baby Step Number One: WALK YOUR TALK

Exploratory approach - Figure 1

More often than not, you will come into a team that is already working/operating in a certain fashion, and because of it (provided you are in that situation), making a compelling presentation will play a key role. On the other hand, you may have the rare chance of already working with either Exploratory Testing, or with Session Based ET, or maybe even with both, if that is your situation then two things, the first one is that you are a lucky person :) and the second one is that you can skip this section of the post, otherwise, if your case looks more like the first scenario, keep on reading.

Before you can start talking about the What’s, How’s, and Why’s to your audience, make sure to read about the matter, to learn from it, and more importantly, practice it with a great deal of curiosity. Practice it not until you do it right, oh no.. no.. practice it until you cannot do it wrong! Basically, what I am saying is, you must make yourself an expert so that others see you like it. However, if time is against you, and you cannot allocate some room to learn and practice, then ask for someone with more experience and knowledge on the subject to help you with it prior to introducing the ideas.

Why is the previous important? Because, having a solid foundation on the subject is paramount, and also, it’s part of the basics, specially if you are looking to be successful when introducing new ideas to an organisation with old-time fixed practices.

What should I present?”” Focus on the main ideas, concepts and cornerstones around Exploratory Testing, make sure to explain the big picture, and also, what the team would gain from its implementation as a regular practice.


Exploratory approach - Figure 2

Ok, so if you are here, that means one of two possible things:

  • You either skipped Baby Step Number One because you are a lucky person, way to go!!; or,
  • You have already managed to introduce the idea, way to go again!!

Let’s continue then, so once people decides going for the idea of introducing and working with Exploratory Testing, then it’s time to keep on moving fast and propose a P.O.C. (a.k.a. Proof Of Concept).

You will have to let them know that it will bring value onto the team, as well as a new experience to those who are unfamiliar with the approach, and also, it will have a sense of participation, of involvement, because all of a sudden a lot of people (if not everyone on the team) participates in the experiment.

A few points to make the most our of the P.O.C.:

  1. Make sure to engage all of the members in the team, if they all, or at least some of them buy into the idea, then chances are they will also, somehow, help you with it;
  2. Propose working with it in a real project. In my experience, it has usually been easier earning people’s trust proposing the implementation with a real project, but, a real project in which risks are not “big”, or at least, in which there are no major impediments/constraints yet. Does that mean it should usually be like that? All POC’s should be conducted through low-risk projects? ¡NO, definitely NO! Why? Simple, because depending on your stakeholders, the people who matter and may make a difference to either support, or completely discard the idea, a low-risk project may be completely insignificant for them to the point in which they will not really see the real value to it. They might ultimately feel reluctant to include it in a high-risk project, or include it at all should they even consider implementing it. However, why is this so important? Because if you propose using it, experimenting with it in a real project, then, the results you make will be a lot more appealing to the people who matter, to the people who can make the decision to adopt it as a common practice within the organisation;
  3. Keep in mind at all times, a clear objective for the vision you have for the P.O.C., be very clear with what you are trying to achieve out of the mission;
  4. Last, yet certainly not least, keep your eyes on the results that you are trying to get, and more importantly, on how you want to present once the P.O.C. is completed.

Baby Step Number Three: RUN YOUR P.O.C.

Look for “a partner in crime” or for as many as you possibly can, and yes, I am talking about testers in your organisation. I know that that will at times be an easy to accomplish task, and some other times it will be hard, if not an impossible task. However, there’s always someone out there who happens to be willing to help us out while learning something new in the process.

Do you remember something I mentioned in the previous step? For the P.O.C., begin by picking either a project that is not on fire, or just a few areas of a test item within your organisation to conduct your chartered sessions.

As it is a P.O.C., let’s suppose you will be testing a small subset of functionalities from a test item in your organisation, what you can do is to think about your charters, create them and have them available in a tool such as Trello, and your board could look something like this:

Exploratory approach - Figure 3 Using such a tool has plenty of benefits, among which we can mention its reach, since it’s online, if you have a distributed team across the globe, the charters from your P.O.C. can be easily shared with your teammates. Otherwise, another way you can do the very same with a team located in the same office it’s through a whiteboard divided in columns, and lots of post-its with the charters in it.

Anyhow, and regardless of your preferred method for generating the charters, one other thing that will help you is assigning values to the charters, and by values, I am referring to weight. Take a closer look at the screenshot I shared from a board I created in the tool, the one charter that’s under TESTED is #6, whereas the one charter under TESTING is #5, you get the idea. Basically, the point is to weigh them so you have your priorities in order.

And you may ask, “Hey, wait a minute… where and how am I supposed to log my test notes?” Good question! That’s simple, let’s suppose you go for the first option, therefore, you make up your mind for using Trello. What you have to do is simple, each card has a placeholder for comments, and you can add as many as needed, so that very same space can be used for your Test Notes, check the screenshot:

Exploratory approach - Figure 4

“What would happen if you were using the whiteboard with the post-its?” Well, that’s pretty simple too, make sure to use coloured post-its, so you can use a colour of your choosing for the Charters and stick to it, and then, pick a different colour for the Test notes, which might also vary in terms of priority using an appropriate colour convention. For example:

Charters: Post-its with a yellowish-like colour; Test Notes: Whereas you might use coloured post-its like the following to indicate priority:

Reddish-like colour for those of high priority; Blueish-like colour for those of medium priority; and, White-like colour for low priority. Regardless of the systems or applications you implement, it is of the utmost importance to convey your ideas in a successful manner, as well as your objectives, results, and the value they will add with their implementation.

Stay tuned, because in following posts we will start talking about managing this type of work. In the meantime, let us know what you think, your opinions, your feedback, ideas and experiences on the matter.