Approaching your automation – with measured awareness!

The following is a blog post personally written originally for PractiTest

Just as money makes the world go round, automation makes the testing world go round.

Automation has gone beyond just a buzz word and has now become a critical part of most organisations backbone to software releases. But the question remains, is Test Automation being done the right way? or an even bigger question should be, is there a right way to do Test Automation? The answer is usually it depends…it depends on so many different factors that come in to play regarding the application under the test, an environment, data, architecture and tons of other factors.

With any major project or task one does need a plan or a sort of strategy to get going with Automation. Many people use Quadrants, pyramids and other models to use as references to get the wheels in motion when deciding on an Automation approach for example for some awesome detail around some great models (including an Automation triangle model by myself). check out this link.

In my 16 years+ experience in the Test Automation world, my observations and experiences has led me down a path of putting down some of the key elements that goes into consideration when developing a Test Automation Strategy. I will discuss a few of these below.

1. The case of the test case – Test management tools or similar

Lets take it all the way back to the start. Whether you are using a specific Test Management tool or checklists/mind-maps etc in an Exploratory Testing world, there is an underlying aim. The aim to bring some sort of planning aspect or structure to how you tackle a testing task. At this stage believe it or not, is the first place where Test Automation ideas and thoughts should come to mind. You should identify typical automation candidates during the defining of your test cases/scenarios.

The other aspect around a Test management tool or similar is the key element of visibility and transparency that it provides to all. Test Automation should not happen in isolation and the better a tools ability to provide full on transparency, traceability and visibility to the team, the more relevant it will be to your test automation effort. Never under-estimate the power this element brings, especially to a developing Agile universe- where team play is critical to the success of any organisation. Everyone should be on the same page regarding your teams automation effort. Visibility seen in the terms of test coverage, test results, test trends and all sorts of fancy automation stats comes to mind here.

A further point which can be related to a test management tool in some cases or possibly an external tool like CI/CD supported tools like Jenkins or Gitlab is the ability to executethese automation tests/scripts in batches or in a pipeline, scheduled or on-demand. This is a far step forward from the good old days of scripts residing on a specific machine and executed rather tediously sequentially by opening each test before execution

2. Where to automate- Show me where!

Another key element regarding an automation strategy is ‘Where’ and ‘What’ to automate. Well in a way the ‘What’ to automate is tackled above, the ‘Where’ to automate in this context is not referring to a specific test environment but rather speaking to the layer of the application to automate. Are we talking automation of Front-end or Back-end, are we talking API or UI or possibly even DB. And then the question of E2E testing comes in to play and even further to that Multiple cross- system E2E tests. As you can see automation involves a lot of thinking before doing. So typically inter-Team and tester discussions are vital to get right before deciding on ‘Where’ to focus your automation efforts

3. Tool selection- choose wisely

It doesn’t get any easier you know

Now that we have an idea of ‘What and Where’ to automate the even tougher task of choosing the right automation tool for the job becomes key. In some instances a tool is already purchased at a company and automation has to now abide by this pre-selected tool, that scenario provides its own challenges which I wont get into in this post. If destiny was in the testers own hands a then the choice of a tool should span multiple areas. Some quick points that come to mind regarding tool selection are as follows:-

a.) Tool to technology —> can the tool automate our web application? can the tool automate our desktop application? Does it support API automation? How about mobile platforms?

b.) Tool support —> is there support to aid with assistance regarding problems, crashes or tool maintenance. How often are newer versions of the tool released?

c.) Language support —> what coding language does the selected tool support? Does it support multiple languages like Java and/or Javascript. This question also becomes relevant when doing recruitment and hiring.

There could be many other points to consider in your eco-system that would be relevant regarding tool selection but the above points are some of the first things to keep in mind.

4. Environment Stability- keep it tidy

This is one area which is often over-looked yet negligence or instability in this area could almost nullify all you test automation efforts. Think about this, imagine having the flashiest, beautifully crafted new age Yacht! But you take it to the most rockiest waters to sail on. What an epic fail that would be!

This is exactly how it feels or would feel if there is environment in-stability. Questions around environment up-time, dependency availability (whether local or external) needs to be address here. An example that comes to mind here is something like a google API dependency to test log-in feature of an application. If there is interrupted connection to external services and your tests depends on it, then how reliable or trustworthy is your automation.

Finding ways to weed out problems in your environment and coming up with ways to make your environment more stable as you grow your automation efforts becomes critical.

5. Data, data and more data

Data is another concept which is so key to an automation approach. Data is complicated and can bring many challenges, this is mostly down to the numerous permutations that could exist per any given scenario. Hard coding automation test inputs and variations are almost frowned upon and rightly so in many instances as the power of your scripts reach to find defects is greatly enhanced by feeding it random data per execution. You chances of finding defects per unique data scenario greatly increases with this approach. In a way this can be seen as a form of automation exploratory testing which is a win-win situation.

So focus on finding ways to randomly generate or obtain different combination of data inputs to strengthen your automation efforts, whether this be in the form of sourcing data from tables, files or api’s, it is definitely worth investigating. Some thing to keep at the back of your mind here is the speed aspect. Would sourcing this data slow down your scripts? By how much will it slow them down? These are calls you would need to make as a team when considering how to approach the data vs coverage topic.

In closing

To summarise, It all starts with with how you start. For a well thought out automation approach one has to keep in mind that automation does not just happen. Early automation candidate identification, visibility, team interaction and general planning is imperative to have a solid foundation. Once this is established the other key factors like tool selection, level of automation, data and environment issues need to be addressed to make your automation a success in your world.


The Test Leadership Leap! an intro (part1-Leadership series)

In my last blog post I mentioned that I have had a change of focus this year regarding a key focus area which I am concentrating towards building on.

Just some quick background regarding the so-called ‘Pact’ tradition that Elisabeth Hocke and myself have found ourselves doing since the end of 2016. It has become an annual thing where we hold ourselves accountable on reaching certain medium term goals: for a recap checkout some of my earlier posts specifically and Lisi’s blog site for some detail on the full story regarding holding each other accountable on challenging goals and the actual pacts.  As you will read on Lisi’s 2019 challenge, she has pitched forward the idea of her becoming ‘Code confident’ – a rather amazing challenge! On my side I decided to take ‘The Test Leadership Leap”. So my goal and pact for 2019 is to focus on building all areas of becoming a better leader. This ties in with multiple areas of my career, I have recently been given the role to manage several testers at my company, this to add to my current role of a QA Tech Lead. So the balancing act of People vs Tech is a rather interesting aspect to get into. The other area is on Test community matters, where the itch to learn and share knowledge has automatically made me more visible in the test and software community, both locally and internationally. The prospect of inspiring and motivating others really excites me, so learning key areas of leading is rather important to me at this point. More about this further on in this post


          (image source:

The opportunity

At the end of 2018 I was given the opportunity by the company that I work for, to attend an internally run Leadership course which spans 3 years. The first 2 years of which includes being on 4 day block weeks for about 4 times a year and the final year which includes a leadership focused project that cohorts need to work and submit on. This was something which fitted directly into my short and medium term goals, an opportunity which I was willing to grab with both hands and a grateful heart!

The reason why I specifically waited a few months to blog about this pact was to gain some early insights into the first 2 block weeks of the Leadership programme to gather thoughts and application of the leadership concept and overlay that against the background of the Testers world. This will be an ongoing Leadership series of things I have learnt and how I see the possible practical implementation of some of these concepts.

Screenshot 2019-04-19 at 01.16.24

Early insights- do you know yourself?

My learnings started with a bang! Fairly early on I was introduced to the concept of Enneagrams- – a quick definition from that site is “The Enneagram refers to the nine different types or styles, with each representing a worldview and archetype that resonates with the way people think, feel and act in relation to the world, others and themselves”

After doing an assessment to determine my Enneagram type, many things fell into place regarding my thinking, feeling and acting areas of my life. I will not share my enneagram type on this blog post due to a personal choice 🙂 but I must say I definitely knew which type I resonated with the most before doing the actual assessment.

1 thing I picked up that defines the way I move forward in this Leadership journey, is that you firstly have to know your own positive traits along with your areas of development and blindspots to be an effective leader. The power of influence is driven by how you convey the ideas you are looking to implement or to get buy-in for. You have to know yourself and you have to know the person/s on the other side. Knowing your audience and their needs is key to make the topic of influence a little easier.

Find your “Why”!

As with any individual including someone who also chooses to lead you have to know why you are there.

As mentioned in my intro, one aspect which has always drawn me to leadership and influence was my passion for people, also to add to that – the satisfaction I gain in helping others learn and push them to reach as far as they can.


                                                             (Image source: “”)

I asked myself am I really living this as someone in the Testing Field. I then gained much comfort in 2 very recent testing related examples and experiences.

  • firstly as a leader, last year our testers were given a new challenge to upskill quickly to this new super technical angle that our company was heading towards. Quite a few of the testers that we had at the company had moved in from business areas of the company or did not have previous experience with coding or even the aesthetics around tool specifics. I decided to drive forward and host a 5 part bi-monthly sessions to give them intros and some practical demos on:-
    • version control software like git, the check in and merge process etc
    • API basics like what is an API, what does it do, how do we test API’s and much more
    • automation tools used at our company, and what level of the application they cover
    • Javascript and some of its basics, standards etc
    • other technical tools like Monitoring tools
    • High level system architecture -so that one knew the flows intra and inter system in order  to test better
  • secondly as a test community member, Lisi and myself decided to do a few things to inspire others:-
    • share our story of pairing at conference and via blogs, social media, webinars, articles and podcasts–all this to get others to push themselves to reach new heights to benefit self and company.
    • form an extended “PowerLearningGroup” – which is an international skype group which meets every 3 weeks or so. This group includes 10 like-minded, passionate testers and leaders from across the world (9 countries) who meet regularly to share ideas and concepts that can benefit our day to day tester lives. The other benefit is to spur each other on to work on latest and greatest initiatives to better the testing world practically.



(image source:


Doing is believing

So I looked to bring this back to testing. As a Test Leader and manager I had to take steps of doing massive introspections and also getting to know my peers, mentees and fellow colleagues even more. I am making concerted efforts to setup time with those who report into me to better understand them from a personal and work point of view. To find out what makes them tick, what drives them and what would they like from me as a leader. I also looked at using my technical knowledge to leverage more respect by doing , helping and working together to attain a common goal. For example a recent practical example was to improve the presence of Performance testing across multiple areas. I decided to setup an initial session with a broader group to highlight the reason why Performance testing is vital in our environment , how it was done and what needed to be focused on to get it going themselves. I have now proceeded to have more focused team specific sessions where I would physically help in implementation of these tests. In my view a better leader (especially in the IT development world) does as much as he speaks, don’t just talk the talk, but walk the walk too. Lead as YOU want to be led!

in Ending

This leads (see what i did there) me to the end of part 1, as I wrote this I realised that there are layers and layers to this Leadership area and it might take me a good few hours to keep going on this post. It is a journey indeed! There is so much more to share on this early stage of my Leadership journey but I will save it for the next part of the series 🙂 So welcome on this journey with me!


(image source:

DevTestOps: It’s alive, but what can testers do to make it alive AND kicking into overdrive! (My External community guest blog post)

It’s me again 🙂

It’s been a rather crazy beginning to 2019 with so much happening. This year I have a key focus area that I will be sharing in a detailed blog post real soon.

Hopefully that key focus area will be a kick-off to a series of blog posts related to that particular topic

For now, please check out my recent blog post feature on the Testing in DevOps community site.

Enjoy 🙂

Lower level Automation and testing? Be more precise! The Automation triangle revisited…again!

A blog post has been well overdue for me- but hey better late than never.

In this post I want to bring together a mixture of current experience, some theory and a word of caution when tackling low-level automation and testing. An observation and point of note to anyone who finds themselves in a similar situation now or in the future. I recently found myself in a very interesting space on one of my projects which got me thinking about a potential point of caution when one is looking to automate or even test across the different levels of your system.

Recently there has been this great ‘Shift Left’ concept which was mostly spearheaded by the famous ‘Automation Pyramid/Triangle’– yeah that famous pyramid again. I am not putting that pic up as I think that pyramid is tired of making so many appearances 🙂 Instead I will use this pic of a real life pyramid for effect. If you need to check-out all about the automation pyramid, then I suggest you do some reading on it. Check out these 2 links for a start : and


Setting the scene

So where am I getting to? I must highlight 1 point before I go any further the following dilemma I mention below would not be evident on all types of systems that one faces but it would be the reality in most modern systems/applications including Low-code type systems and systems where there is a some sort of manipulation or translation from the UI to your middle layer or even API’s . Regardless the question begs to be asked on every project that you tackle just to reassure that the Automation and testing approach that you follow gives you a peaceful night’s sleep.

Well consider the following scenario on your project, you have a shiny new application with some cool front end tech coupled with some sleek back-end engineering. You wonderfully decide to follow this magical Automation pyramid, you think you are going to totally smash that Automation pyramid/triangle model by working real close with your devs to create superb unit tests, you want to add in a dash of component tests to further strengthen what you covered in your unit tests. You don’t stop there you decide want to throw in some fancy Integration tests. 1 last topping on this amazing triangle- you ponder a hint of E2E UI tests to top it all off. Not too much just the right amount. How awesome you think, this defence I have planned to build up is surely watertight!

What they don’t tell you!

Based on the famous triangle or pyramid this is usually how people want to tackle their Automation. But remember, it’s not magic! its not plug and play, you have to keep asking the questions. What am I testing? Am I automating just for the sake of it? am I automating or testing here just to fit in to the Automation pyramid?

download.jpeg . image from:

When you get back to your desk to start on this cool testing task, you pause and think- hang on something is amiss! something is just not adding up here. Create unit, component and integration testing–but where? Well I found out the hard way and also found out where the major shortfall was on my project- that I will explain afterwards.

The simple answer is the Automation triangle needs to be expanded in practice. One needs to break it up even further when you tackle the actual effort on your project. This effort then explodes- as I said its not magic and one has to prepare for this personally and let it be known to the team and relevant interested parties- as this effort ultimately affects the sprint and in-turn estimation which then impacts actual time to delivery.

My attempt at breaking up the Automation triangle according to my experience is depicted below. I will then give a brief explanation below. The reality looks like this!


The reality

So now that I have broken the triangle up a bit more to put theory into practice by aiding actual day to day activity or project contribution. Lets unpack it a little more.

A testers full testing effort is usually not limited to just an API or one part of the UI. A testers effectiveness is evident when he/she has the full picture in his/her mind, testing the entire application as seen by the user and beyond! Front end, back-end, logging etc. With this in mind if the true sense of ‘Shift left’ is to materialise one needs to cover testing and automation at every possible level. UI and API (and whatever other backend magic that exists)

That then means that triangle now needs to be less vague and more specific to include both UI and API/Backend tests across the different levels for it to make practical sense to the actual testers who need to carry out the detailed tasks at hand.

UI Unit– usually done by the devs to cover unit level of a UI validation, field, text etc

UI Component –usually written by testers to see how that component/area of the UI behaves usually by mocking out its dependent calls or API’s

UI Integration (within the application itself)- usually written by testers to test how that new component behaves when integrated within the application at large. For example does a new field/element that is recently added to the application conflict with an already existing field or element- or just finding any weird general issue when this is merged to the greater individual application under test

UI Integration (to APIs/Backend)- usually written by testers to test one of the most important aspects-bringing the Front end and back-end together. Passing on variables and composing a payload or xml to be sent to the API or Backend/webservices etc.

API Unit-usually written by devs, where testers atleast have some visibility into coverage. Covering unit/s of an individual API composition

API Component-usually written by testers with dev assistance and input. Consisting of mocking of dependencies, run independent of environmental related data.

API Integration (to backend and/or other API’s)-usually written by testers. Consisting of actually calls to dependent APIs and/or downstream systems/dbs

E2E UI- usually written by testers- light coverage to bring all of the above together and just provide re-assurance that all is in order- Run in a fully integrated non-mocked working environment

Hope that makes sense 🙂

The diagnosis

As mentioned earlier on the project I worked on I found this out the hard way. I actually had multiple tests and some great detailed coverage across all areas of the triangle accept for 1 area.

Any guesses where?

Well that area proved to be the UI integration to API. I had covered tons of different API scenarios and I figured I was safe when it came to hooking up the UI. But that wasn’t the case at all. The manipulation of variables and parameters from the UI as they passed through various different workflows that composed the payload, which then passed on to the actual API’s proved to be the big problem area. Individually everything worked great, but when integrated it didnt play nicely.

This was quickly identified and a solution suggested to hook into this UI workflow integration to API level and bolster coverage at that level to prevent any gaps in coverage.

So basically the lesson learnt from this is to understand your application and its inner workings when approaching your testing efforts. Following a model or blueprint blindly without asking the relevant questions can be catastrophic. The key is that a model is just a guide and should be used that way, for maximum effectiveness you need something that suits your situation. It can be tweaked to suit you unique situation or system.

Keep challenging your own thinking and the system will be a better place.

Finally you can sleep peacefully, knowing you have your bases covered!

lion sleeping beside rock
Photo by Aldo Picaso on


Mind-Mapping in Software Testing: Increase that Test coverage, its about time! (VIDEO)

Where has he been?

It has been quite a while since my last blog post and most of my blog followers have probably been wondering what I have been up to.  From day to day work across multiple projects, mentoring workshops, podcast recordings and webinars, things have been really hectic over the past few weeks. Hopefully I will be sharing much more of those details real soon.

I recently presented an internal presentation at my company regarding practical examples and benefits of Mind-Mapping in Testing to increase Test coverage. I then followed that up very recently with a Webinar on the Biggerplate platform. Biggerplate is quite passionate about getting the concept of mind-mapping to take off across the world in multiple industries from Education to Finance & Medical to Information systems.

They have very kindly allowed me to share the video on this blog. Thank you Biggerplate. I hope you enjoy the video and drop a comment if you have a question 🙂

Check out this link for the video :

This webinar was recorded for the BiggerplatePRO Members. Save $10 on Annual membership ($29) using the code TOYER10 today! To find out more, visit



How fasting helped shape my testing career

So the idea for this next blog post came after questions from one of my colleagues was posed to me during the last lunch @ work before the month of Ramadan commenced. Some quick background for those who don’t know, Ramadan is the Holy month in the Islamic calendar where fasting is observed for an entire month, from sunrise to sunset-daily.



So back to my colleagues questions, he posed a few questions to me regarding why fasting is observed? what benefits do we attain? why are we encouraged to give charity during this month? This then sparked many discussions but it also helped me understand many attributes or lessons I have learnt over the years from fasting that helped me apply to my testing career. I am sure the month of Ramadan and fasting in particular has many individual benefits to each person in many different ways, I have applied many of its benefits and virtues to other areas of my life, but below I highlight some key factors that fasting taught me which I used to shape my testing career.

Dedication, discipline, focus and persistence

Fasting requires a lot of dedication and discipline. It requires abstaining from food and water (from sunrise to sunset), it also encourages one to restrain from bad or sinful speech amongst many other things. This highlights the focus one has to have and also the persistence to get through the day and then the entire month.

These qualities have been applied to my testing career as well, more so the last aspect of persistence which is a key factor in the Software testing world. I recall over my 15 years of my testing experience, I was given many opportunities to change my career path- from the possibility of becoming a Business Analyst, a Developer or even a Scrum Master. However I turned these roles down to focus on Testing, I did try out being a Scrum Master for +-6months at some point but the lure, passion and my dedication to Software Testing just brought me back to the field. Check out Wait how did I get here? Time for reflection (part 1). , in that post I highlight these points. Stick to what you believe and you will be fine

Persistence is a nice quality to have as a tester, pushing hard to get a bug resolved or pushing the levels of quality to software is a key element in this field.



Fasting teaches one to be patient, I re-call growing up as a kid and a teen constantly watching that clock ever so frequently, waiting for the time to sunset before one can enjoy the delicacies prepared that evening. It teaches one to have the will-power to get through the day, the endurance of the night prayer after a long day of fasting and the entire month.

Looking back over my testing career thus far that’s exactly how I approached it, I also advise junior testers to take this patient approach. One can be overwhelmed with all the insane amount of different technologies available nowadays – there are tons of programming languages, tons of tools, tons of approaches, frameworks etc. There are so many different industries one can work in, each having its own challenges, do you focus on business, people or tech objectives? I’m sure you will agree that can be overwhelming indeed. If you take it step by step and set yourself regular objectives you can achieve key aspects in manageable chunks. Set yourself a daily goal, a weekly goals, monthly and yearly goals! Doing it all at once can confuse you and mess up what you are trying to achieve.

My current company encourages annual objectives setting, I recall over the years that I have been employed with them – some of my main objectives included: 1 year I would have a business focus in that I would try to learn as much as possible from business users, then there were other years like the current one where I change my focus to everything Tech. Researching and playing around with Docker, Kubernetes, AI and everything new in the Tech world. A tester and more so a ‘modern tester’ needs an armoury of different skills to succeed in this ever changing landscape. Be patient and take it step-by-step!



Punctuality and Time Management

Another lesson I learnt from fasting is how it had got me on track by following a specific routine and being punctual. We have to get up at a certain time to eat (before sunrise), eating a minute after sunrise and this could nullify your fast, performing prayers at a specific time, then breaking your fast at a specific time. Everything had order and an allocated time.

Well in testing and in almost every career being punctual is key, managing your time and what you do in your job is key. Over my career I try to never be late for a meeting, I always try to schedule things well in advance too. With regards to testing, this can help you prioritise and schedule your testing. If you are doing different things as your tester job function for example running performance tests and functional automation, then set aside time to schedule when you do these. It helps clear the noise when panic and pandemonium sets in which i’m sure you all can relate to. Test Co-ordination and test scheduling is something that comes to mind here. Add order to your day by being punctual and managing what you do, when !



Giving back

During Ramadan one is encouraged to give more charity than usual, give back to the less fortunate or just sharing a meal with someone when you break your fast for the day.

Over the past 2 years or so, I have realised that I have reached a point in my career where I can give back some of what I have learnt and know in the testing industry. Which is why I decided to have more knowledge sharing sessions, present at conferences, webinars and even blogging more. All this to give back to the testing community, to junior testers and even to people in rural communities who might not have had exposure to the Software or testing field. Ultimately knowledge is wealth and giving/sharing this knowledge is a pure form of charity. Even helping out new starters or junior testers at your work place would fall under this banner 3 different mentoring experiences in a short space of time!

Below is 2 recent examples that spring to mind where I could give back something.

Screen Shot 2018-05-20 at 07.43.27

Screen Shot 2018-05-20 at 07.44.54

Seek knowledge

Throughout ones life we are encouraged to seek knowledge, knowledge of the world and knowledge of the religion. This is more relevant during the fasting month too. One increases in prayer and supplication plus reads/researches more regarding religious matters.

In one of my more recent blog posts Observations of the testing universe- where are we? And where are we heading? I mention “The testing world as we know it is changing dramatically right in front of us, its scary yet exciting. The best way to make it more exciting than scary is to learn, learn and learn more. Social media and pairing up with others is key to keep in-touch and at pace, google is also your friend and should be used extensively.” this has been at the forefront of my testing career from day 1 and I always kept an eye out for what is happening in the testing world around me. Seek knowledge in this ever changing IT and tech world to prevent you from being left behind. There is so much of change around us and with the evolution of Automation Testing and where its headed this is something we need to keep in touch with. AI + Machine learning is here and will spread at a rapid rate, just knowing 1 form of Automation would not cut it in the future.

Spread your wings and seek out that knowledge as much as possible!

201512221913571159.jpg (image: (image: Mohamed Salah:

Mapping your Test efforts to Automation

Recently I have had quite a few ideas for my next blog post, all aiming at different aspects of testing however time has been a major issue for me due to work commitments. I do promise to get those ideas onto this blog eventually. So watch this space.

An idea which I was pretty excited about sharing, was the idea of bringing your test scenarios close to your Automation code. In fact I worked on a case where it can actually reside on the same repo or code base as your automation scripts. I received a lot of interest on the topic when I tweeted about it a few weeks back.

Screen Shot 2018-04-17 at 10.16.26.png

Ok, ok let me explain by first starting on the problem case or dilemma most testers face with when thinking of converting manual test cases/scenarios to automation scripts and how it would fit into the bigger automation picture.

The case for mind maps

Lets start all the way at Sprint level and your daily standup. For a proper illustration I created a simple example Project Jira board and code project for a dummy e-commerce application to explain my thinking around this concept.

Its Day 1 of your Sprint and your Dev has started working on an API story, in this instance he is working on the Items API story and the get Items API task to be precise. You proceed to define you test scenarios/cases while he is busy developing.

Screen Shot 2018-04-17 at 09.29.07

Previously I would have written my test cases in ‘traditional format’ – in a test management tool or document. But after being introduced to mind maps and how it can be used effectively in defining test scenarios/cases, I have found the many benefits of it that facilitate better efficiencies within the Agile process. Some of the advantages of mind map test cases that I have found are the following:-

-greater test coverage

-greater team collaboration

-faster test scenario/case creation

-easier reading/understanding due to visual representation

-more time to focus on exploratory testing, automation and non-functional testing

The above points have been quite evident on my project but as a word of caution there were also some points of caution I had to address to convince my team that mind maps was the best approach for us. Some of the concerns and questions included the following –I have added my answers in italics :-

what about traceability back to the story/task? Answer: Adding the mind map as an attachment to task (on Jira) worked for us, also a link to a shared drive or address to where it is stored would work.

only the person who creates the mind map would understand their thinking vs step by step detail of test case. Answer: Fair point however it depends on how the map is created. The easier solution is to have a quick 5 minute pow-wow with your team to give them a brief overview of your thinking. Agile is about collaboration after all, everyone is working on the same product, if they are not on the same page regarding functionality then there are bigger issues. Rather a quick catch-up session with everyone compared to the pain of writing step by step detail which might not even get looked at post sprint.

what about newbies joining the project at a later stage? how would they understand the test cases? Answer: multiple points come to mind here, 1- you can take the newbie through your mind map collaboratively, they have to learn your system anyway so that initial time to get them on the same wavelength will be worthwhile. 2- why shy away from working on a more efficient way of test scenario definition by worrying about when a newbie starts. How often does that happen? if it does then we deal with it by tackling it with point 1 (above).

-would this totally replace conventional test cases? Answer: It depends, you can if you want to. The whole aim of mind mapping test cases for me is to quickly define or extract test requirements for your system or application which can aid exploratory testing and give you way more coverage than normal. You could if you want highlight the main regression or critical scenarios on the mind map and only do detailed traditional test cases for those scenarios. This way you still defined better test coverage and still keep your normal detailed cases and stats. Your mind map then becomes a tool for you to better create test cases.

Take your mind maps to your automation

Now that I have got the case for using mind-maps out the way lets get back to our e-commerce app example. To keep my example simple I have mapped out a few test scenarios for the get Items API using xMind

Screen Shot 2018-04-17 at 11.15.32

I have now been in testing and Automation for 15 years, the big problem I have seen over the years and today is the blank look you get from the testers (including myself) when they have to create Automation scripts. I can imagine the thoughts going through the minds…what do we automate? how does this automation tie back to the story/task? my test cases sit in this system but my automation sits in that repo? This disconnect from Test cases/scenarios to Automation scripts is a problem, consider also a few months or years down the line when your Automation scripts grow massively to a point where nobody even knows what they are covering, unless you go through the lines of code on the script. Well with this concept of bringing ‘Mind maps closer to your Automation Code’ I am hoping to bridge this gap and bring the visual aspect to Automation coverage along with fast and efficient test case creation.


Back to our e-commerce app, the developer has now moved the task over to you for testing and has also thanked you for adding the mind map to the task as this also helped him to create some detailed unit tests covering areas which he would have not generally thought about. Good job he says! You now either execute you test scenarios quickly with the mind map as your reference or you proceed straight to creating your automation api test scripts. Lets assume you do the latter.

I recently (together with the help of my wife 😉 an ex-Tester and now ScrumMaster) found a cool mind-map plug-in for intelliJ. . How cool, with this plug-in one can create a mind-map directly in intelliJ (hopefully you use intelliJ IDE to create you automation scripts) or you can import a mind-map created from other popular mind-map software like FreeMind and xMind (which is what we use). This is where my concept comes in with the ‘Testing’ context.

Pull in your test case/scenario mind-map into the IDE or just start creating your mind-map directly from the IDE . In our case we use a Javascript library for creating our API automation tests (superTest) and another JS library (nightwatch) for our UI tests.

Here is how that works.

Tools used in my example: IntelliJ IDE, idea Mind-map plugin, xMind or Freemind (optional), Javascript (superTest for my API Automation script)

  1. Install the mind-map plugin to IntelliJ-
  2. Go to your automation code project in IntelliJ
  3. Under the relevant folder where you would create your automation test script, create new or import the test case mind-map (see screenshot below where I import the xMind mind-map that I created during my test case/scenario definition in-Sprint.)Screen Shot 2018-04-17 at 11.45.54.png
  4. In-order to now use your mind-map as a template for your automation script, right click and choose to export the mind-map as a plain-text fileScreen Shot 2018-04-17 at 11.52.08.png
  5. I now save my file with the name of my intended Automation test script and change the format to a .js fileScreen Shot 2018-04-17 at 11.54.59
  6. I now right click on my folder structure and ‘Synchronize’ the folder to pull in the file created above.

Screen Shot 2018-04-17 at 11.57.12

7. And voila, you now have your template to create your automation script in, with all the test scenarios you defined showing up. You now have a 1 to 1 mapping

Screen Shot 2018-04-17 at 12.01.37.png

8. Now you can proceed to create your automation script, which should look something like this (you can comment out the text pulled in from the mind-map)

Screen Shot 2018-04-17 at 12.11.46.png

Points to note and summary:

This concept shows how one can use mind-maps to generate test scenarios from story task level, then import this into your Automation code base repo so that your test scenarios now live side by side with your automation code providing one with an easy transition from manual test definition to automation script. There is now also enhanced documentation of your actual test automation coverage by having these scenarios as a reference living in the same repository.

Happy mapping! Your Automation scripts should not feel alone! 🙂