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

Implementation

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. https://plugins.jetbrains.com/plugin/8045-idea-mind-map . 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- https://plugins.jetbrains.com/plugin/8045-idea-mind-map
  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! 🙂

hqdefault

10 thoughts on “Mapping your Test efforts to Automation

  1. Wow! This is what I was looking for recently. Mind mapping is awesome, easy, time consuming, visual, but there I couldn’t find a solution how to map them to our automated tests! Great idea, Toyer, I will try to make it work for my company! Looking forward to our testing catch-up soon 🙂

    Liked by 1 person

    1. Great stuff Lilit. Let me know how it goes. Very cool that you thought about a similar concept 😁 keep me posted with how implementation goes on your side. Yes, super keen on the next testing catch-up call too.😀

      Like

  2. Great Approach Toyer. I loved the way you have incorporated Mind Maps into your IDE. In my case, I keep my test scenarios close to automation code by using Feature Files (BDD). I call it Behaviour Driven Automated Testing (BDAT).

    Now I’ll also create a mind maps for the same and import in IDE so combining Feature Files + Visual aspect (Mind Map). Thanks for giving me new vision 🙂

    I am excited to explore it further….

    Liked by 1 person

    1. Thank Ambreen. Yes BDD by design tries to keep the documentation quite close to Automation code, you will add a nice visual element to it by incorporating mind-maps allowing greater coverage representation to your automation. Please keep me posted with your findings 😁

      Like

  3. Hi Toyer, great experiment!
    I have a question.
    As development is in constant flux, what are your ideas for synchronization between mind map and created code, when you need to add/remove/edit features?

    Thanks!

    Regards, Karlo.

    Liked by 1 person

    1. Hi Karlo thanks for the response. This question was asked by Joao on Twitter. Regarding incremental changes this needs to be done manually when the code changes unfortunately.
      Joao said :”What I mean is: that last step of converting mind maps into text and then transform it into code is very cool, but it if you have to change the mindmap later on, you’ll have to also do the changes in the code by hand, right?”
      Toyer answer: “Do you mean if new functionality is added on top of your current functionality? If this is the case then I would edit original mind map, then import it back into the IDE to keep your documentation up to date. I would then just add the new scenarios to Automation if needed.”

      Like

  4. Its a very good visual tool but we have been able to achieve something similar with a BDD tool too [i.e. cucumber] by just adding a tag like “manual/exploratory”.
    Cucumber gives you the flexibility to ignore tags which made it very easy.
    In an agile env where changes are constant and QAs end up working quite often with the BDD tool to add update tests it prevents the overhead of maintaining another document. Which we used to explore more scenarios.
    Have you tried something similar and it didn’t work perhaps?

    Liked by 1 person

    1. Thanks for the feedback Prakriti,much appreciated. Just a couple of points on what you mentioned above.
      – the first point, I think the mind-mapping approach to testing adds a much more visual aspect to testing which is quite different from BDD. Mind maps could even be used on its own or to supplement the process of creating your scenarios to cover in BDD. I would not want to compare the 2 as I feel they are very different and it would depend on a team or individuals way of working and what suits them best.
      -2nd point, agree with regards to keeping the automation and documentation the same which is what BDD has as its fundamental aim. It would reduce effort this way. I have found for UI automation testing BDD to be a much more likely place to be used rather than API or backend testing(although it still can be used for these types of testing) It here that I feel visual type testing using mind maps give better coverage and also much lighter and quicker to create in sprint.
      -3rd and final point. To answer your question, yes I have used BDD to a limited extent a while back. It had much potential however building the different aspect beneath to aid automation proved to be causing the team to deliver slightly slower than previously so we decided to go a different route.
      Thanks once again for your valuable input.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s