¡Hello! Today, and as the title has it, in our post at hand we want to go through one of every Testers’ most valuable assets, and that is actively working with our mind, and particularly, working with our mind building maps.
First things first - So, what is a Mind Map?
It is commonly known as a visual thinking tool, which you can apply to all cognitive functions such as learning, for your creative processes, analysis, and memory workouts.
The term itself was popularised by the popular British psychologist Tony Buzan, although the usage of diagrams and radial maps to visually map information is an old practice.
Creating a Mind Map is a process which involves combining colours, visual spatial arrangement, as well as images, and all of those are for us to use to map our thoughts using keywords that work as triggers in our minds recalling knowledge, and sparking brand new ideas.
Are Mind Maps and Concept Maps the same?
No, they might look alike at times, but they are not the same. Let’s see here, just very briefly put, we have that:
- Mind Maps, which focus on one or a few words/ideas, and they are based either on radial hierarchies, or tree structures to denote relationships connected to a governing concept;
- On the other hand, we have Concept Maps, which connect multiple words/ideas, and also, they typically have text labels on the connecting lines.
How can I create a mind map?
Well, Mind Maps may be either created using software, and there are plenty of applications for mind mapping on the internet, or you may create it drawing the Mind Map by hand on a piece of paper, whiteboard, etc.
The steps I have followed and have helped me to create a mind map have been the following ones:
1. Establishing the central idea
It is the starting point, and it also represents the subject/topic we are going to go through with our Mind Map.
Usually, it is convenient locating the central idea in the centre of the page, or any other surface used while creating it. Furthermore, it is convenient including an image that relates to the topic. Basically, the idea of including images is for easily triggering associations, as our brains have a better response to visual stimuli and thus, the connection to our content strengthens.
2. Add branches to the Mind Map
The first set of branches which flow from the central idea, are the key ideas we want to strengthen, and that we will deepen in greater depth by adding more branches.
One thing to take into account here, in our mind maps we can add as many branches as we see fit, therefore, we are not restricted to using just a few ones, besides, the main purpose of a mind map is to let us map our ideas, our thinking, so it’s natural that more ideas will come to mind, as our brains freely analyse the situation(s) and associations we are mind mapping.
3. Make sure to include Keywords
One other characteristic that differentiates Mind Maps from Concept Maps, it’s that with the first we use as little significant words as possible (one and only one significant word if possible) to represent a key idea. Basically, the idea after using one significant word is that of sparking a greater number of associations.
Additionally, using one word only it’s also useful for putting the information into core topics, triggering connections in our brains, allowing us to easily remember more information.
In my experience, building mind maps for several testing activities has been very useful, I have used them to explore test items, while working with Session Based Exploratory Testing, and a couple of extra examples:
- Building a plan and/or a strategy for my testing,
- Writing down test ideas,
- Recognising and prioritising risks,
- Etc., etc.
4. A picture is worth a thousand words - Using images
Last, yet most certainly not least, as the sub-title already mentions it, a picture (or an image) may convey a lot of information, and more often than not, they convey more information than a collection of words.
What is the reason? Simply put, the brain processes images instantly whilst also acting as a visual stimuli for recalling information. Furthermore, using images for visual stimuli is a means for using more brain power, than for example, trying to learn something by endlessly repeating it. Usually, a mind map will look like this:
All in all, we wanted to first share with you a glimpse of what Mind Maps “are” and “what they can do”. In future posts, we will work on giving you further details of how we have used them in our professional practice.
For the time being, have you used mind maps before? If so, how and when have you used them? What were the challenges you faced while learning how to use mind maps? Did you find your first mind map to be complicated? Let us know about your thoughts and experiences :)
Hello! In our previous posts, we began talking about Exploratory Testing, and afterwards, defining it along with exploration.
Today, we want to keep on sharing with you about this subject, but first, let me share a quick definition written by James Bach:
“Exploratory testing is simultaneous learning, test design, and test execution.””
Doing those activities simultaneously, having taken the context of the test item that we are testing into account is the objective after Exploratory Testing, and that’s also what differentiates it from only following a predefined script.
Nowadays, in my personal and professional experience, it’s kind of difficult talking and praising Exploratory Testing (ET) whilst not saying a word about the subject we will be talking about today, and that is, Session Based Exploratory Testing.
Let me give you a little background and history on SBET, it was originally developed by Jonathan Bach and James Bach in Y2K, and it was conceived and developed as an approach by testers, for testers, so testers could use it to:
- Document our work that will ultimately provide evidence of it to stakeholders; and also,
- To measure the work we do whilst engaged in our exploratory testing work on a test item.
WHAT IS SESSION BASED EXPLORATORY TESTING?
As already mentioned in this post, it is an approach and as such, it gives us some pointers so we can focus our work at hand, either by prioritising it by risk, or by degree of importance to the project, or per functionality of the test item, among others. Having that said, and from my personal experience using it:
- SBET makes it easier to report and present the areas that were covered,
- It helps us while undergoing scrutiny with stakeholders, and also,
- To improve the coverage of our future test sessions, by using the knowledge acquired from the results of our past test sessions. Employing that acquired knowledge will have as a consequence on our tests, that they will grow stronger and smarter, and ultimately, the coverage of ours tests will also be improved.
As you may have already noticed, the post began with the definition by Bach, now, to stress the last point, I’d like to share the following adaptation by Elisabeth Hendrickson:
“Exploratory Testing involves simultaneously learning about the software under test while designing and executing tests, using feedback from the last test to inform the next.”
From my current experience, I can tell you that in order to draw out the latest pieces of information regarding a test item, we must employ the most suitable tool we have at our disposal for it. More often than not, the variety of conditions surrounding a test item are changing almost permanently, therefore, we have to use the best approach we have at our disposal to match those changes, and in my opinion, Session Based Exploratory Testing is an approach I have found to be highly valuable.
- We design;
- Log potential new test ideas;
- Change and adapt our tests based upon the results we’ve acquired, which also include the tests recently completed;
- We report results giving value to the project, thus providing instant, and reliable information about the test item we are working with;
- We are aligned with the context of the test item.
Moreover, with this approach, by no means are we forced to follow pre-established instructions, on the contrary, and in similar words to Cem Kaner’s definition on Exploratory Testing, “our personal freedom is emphasized, as well as our responsibility to continually optimize the value of our work.”
Don’t get me wrong, I am not discarding scripted tests, not at all, because I still happen to use them as tools to set a knowledge foundation, to widen attention, and also, to generate new testing ideas.
WHAT DOES A SESSION LOOKS LIKE?
The session’s report I am sharing here, it’s the same the Bach’s brothers have developed and shared with the community, and also, it’s the format I have used the most either in a piece of paper, a mind map, a plain text file, or a spreadsheet, but that… that is something we will dig into in other posts. In the meantime, let me share with you the components and what they are for:
- This is the mission of our test session, and it usually describes in a few sentences our objective as well as our focus;
- There are general and specific missions, which we will also dig into in future posts, do not despair;
- In addition to that, the charter may also contain information about the area of the test item we have to test, and if necessary, it could have some information as to how you should start testing it.
Do you remember that I previously mentioned we log new test ideas? Throughout our exploration work, and if we happen to find an area which is potentially risky and that it’s not a part of the current charter, then we can write a new one to address it.
- This sub-section, belongs under the Charter, and it’s purpose is record, as well as listing information to provide evidence regarding the coverage of our testing.
- Therefore, it is prone to contain information related either on the areas, or functionalities of our test item that we will go through, also, operating systems, and/or browsers spectrum.
Let me show you an example of how this sub-section can help you, using a dummy example:
||Actions –> Print to file
With that example, we are showing what our os will be, the version of our test item, the areas we will cover (Menu), and the strategy we will be using.
- In this section we record the date and time the session began.
- Insert your name or, the name of the tester, or testers (if you are doing Paired Testing).
One piece of advice on this particular point, Duration in the report doesn’t have to be precise, why? Because remember, we aim to spending the majority of our time testing, and a lesser amount of time on administration.
Test design and execution
- This section is completed with an integer, and it represents a percentage going from 0 to 100.
- Its usage evidences the amount of time we employed to test against our test item.
Bug investigation and reporting.
- Alike the previous section, this one is also filled with an integer which represents a percentage, which also goes from 0 to 100.
- And its purpose relies upon recording the time spent on either investigating and reporting problems.
- As its predecessors, this section is also completed with an integer representing a percentage going from 0 to 100.
- It is used to record time that was spent setting up “things” that support our testing activities, yet, that they are not testing itself.
For instance, a session setup could be:
- Configuring a DBMS to work with the DB so you can run queries, also,
- It could relate to getting your test data ready (should that depend on you, of course), or even,
- Installing a piece of software you need to conduct your testing activities, and the list goes on and on.
The grand total of running a sum operation through the three previously mentioned percentages must add up to **100%**. That 100% is the equivalent of the total amount of time we used for our session.
So, if we ran a short session for 50 minutes, that is our 100%, which, for the sake of explaining the distribution could look like this:
Test Design and Execution
Bug Investigation and Reporting
Moving on to the following sections available in a Session report…
Charter vs. opportunity
- The syntax for this area is represented as a ratio of the session, and personally, the ratio I have used and spent the most is 80/20.
- That means, I have usually spent 80% of the time of a session (regardless its duration) focused on the charter (the mission), and, I have spent a 20% on the opportunity.
- The opportunity represents off-charter work, and that means it’s time I’ve used, for instance, to investigate areas which could be potentially risky, and by going off-charter new test ideas have been generated to address them.
From TASK BREAKDOWN and up to this point, the report is focused on providing and giving value, by presenting how time was spent on what we might call “Qualitative Testing”.
A piece of advice on this point also, in case you gave this a try and noticed that you spent more time on the opportunity, rather than the mission, then make sure to go over your charter to adapt it accordingly, or, to create a new one.
Also, bear in mind that it is (as it usually is) complicated to estimate the ratio of our work. So, as a recommended practice, it’s a good idea to focus on a fixed ratio at first, yet keep in mind that as your tests unfold and progress, it may, and it most likely will vary.
- This section if meant to keep records of any and every file we may have been using throughout our test session.
That proves to be very useful, for instance, in case you or any other tester happens to have to run a new session over the same area/functionality in a new iteration of the project, and having that piece of information easily available will provide her with a better idea, and starting point.
- Keep in mind that all file that is mentioned here, should be saved to a known location.
- In my opinion, this section is essential and one of the most important ones.
- It is in here that the tester(s) will record anything they deemed important over the course of the test session.
- An example would be,
- Showing how the tests were performed;
- How the test ideas developed throughout the session;
- Pieces of advice for the tester(s) who might need it;
- What challenges were either solved, or recognised;
- etc., etc.
- The section, as the name describes it, is meant to list the bugs we find throughout our session.
- Nowadays, and because there are plenty of Defect Tracking Systems, what I commonly do here is list the name(s) of the defect(s) along with its corresponding ID# in the tracking system.
- Lastly, this section lists either problems, issues that came up throughout the testing session.
- Let’s say for instance, that it was the test environment that caused problems and blocked our testing, we should log it here; or also, it could be used to record problems we noticed and found, which could ultimately be deemed as bugs, but we cannot tell for certain until we have it either contrasted against an oracle, or until we have investigated it some more.
An issue may be seen as:
- Anything that threatens the value of the testing, or of the project, or of the business. Moreover, those that affect our work making it slower and harder, give bugs the chance and time to run and hide, reason why fixing issues is sometimes more important than fixing bugs.
All in all, and though the post is longer than usual, we have just begun with the subject. Have you used Session Based Exploratory Testing before? If so, what experiences have you had with it? How are you using it? How did you manage to introduce it in your project/company?
As usual, we would like knowing your opinions, and having your feedback on the matter, so step right up and let us know about you :)
CEO: Hey, how do you feel about the quality of the new model we shipped yesterday?
Head of QA: Great! The new assistant integrated with the GPS will kill our competition.
CEO: Awesome! You guys did an excellent job during the last weeks, I know we have a delay on our production but, you were >able to accomplish your job in a lesser amount of time. Well Done!
Some minutes later …
CEO: Hey, we have a huge problem reported by our resellers
Head of QA: What happened?
CEO: The engine did not start!
Head of QA: …
CEO: I know that the addition was covered but I guess you guys verified that the engine started right?
Head of QA: Give me 5 minutes, I have to take a walk and kill myself…
How do you feel about that scenario? Do you think it would be possible that that could happened to you? The topic we want to cover in this post is how stress can affect our clarity of mind when it comes to designing and executing our plan.
Usually, most projects we take part of have strong requirements of deadlines: market reasons, sales promises, contracts, etc. Since Software Development is probably one of the most difficult disciplines to plan, the starting time is a scarce variable, so, can you imagine which is the area that takes the worst part regarding this? Yes, you are right: Testing.
Once the deadline is close, all stakeholders start to get nervous regarding the project, start asking questions, and probably, the testing guys(you) start to be the oracle of the project status. It’s a matter of time until the stress and pressure is over the testing team, and this could lead to making fatal mistakes while you are working.
There are some activities you should perform before that time, so you can have a set of tools to use in the countdown phase:
- Plan, plan, plan:
- We aren’t talking about building an old fashioned test plan, take a look to this incredible useful James Whittaker article.
- You need at least to focus on:
- What you will test;
- What you won’t test: be honest, why not? Do an exercise to evaluate the risk, you don’t need a number, but at least, a strong reason to keep something out of scope.
- Estimate how many times you’ll need to do this, don’t be scrimpy or you’ll regret it in the countdown phase ;)
- Gather all the information you need:
- Do mind maps or any other thinking strategy to understand the new additions to your project. Share them with the team, ask questions to the stakeholders. Anything you can detect at this point, will help in reducing the time of the team to develop the product and you will also be reducing development<->testing iterations. If you don’t do this for the team, be selfish and do it for yourself; your “future self” will be thankful.
- Do the exercise of building a bulleted list with potential risks, share it with the team. Don’t be afraid to share your thoughts, maybe others didn’t think about it.
- Think as a product user: this is the time to do it, in the countdown phase you’ll start investing most of the time in the new additions, probably, you’ll be smarter at this stage than closer to the deadline. Think that most of the time, Users will not want to lose current product features and for that, plan accordingly. Do you have automated checking? Great! But think that maybe some new features could affect the product in a way that did not happen in the past, evaluate current automated coverage, study it, criticise it.
The Final Countdown
At this point, it is the moment that you need to stay calmed and focused. You don’t have to soak up all the delays in the project. Are you part of the team? Yes, you are! but you don’t have to feel the responsibility to fix any planning fault. If you try to resolve the tasks in a lesser amount of time than you need, guess what? That error in production will be your fault. Some cases are unfair, but others… we just deserve them, we neither thought, nor acted with clarity.
Now is the time to start using as inputs, the work that was performed by your “past self”:
- If you planned X days, by any circumstance don’t think that you are Batman or any other kind of superhero and now you are able to perform in X/2 days. Rise it, talk about the risks of the release, be clear that if you keep the dates you have risks and explain that with strong reasons. That’s why it is important to have a plan and gather information, you have strong arguments to give information to the stakeholders.
- Please don’t forget about the users at this point, do you remember our new model car users? We don’t want our users will not be able to start their engines.
- Never lose the big picture.
- Be transparent with the information you share. If you know something could go wrong in production, let other stakeholders and project members know about it, you are not Harry Potter, and that risk will not vanish into thin air with a spell.
What do you think about the times that you have the backpack? How do you handle that? Did you ever lose the big picture in those moments? Do you feel that at any point you want to have the time machine to go back and change the way you planned for? We want to hear about your thoughts :)