Follow-up on xBTM

Background

At STARWest 2011, I gave a talk about xBTM together with Michael Albrecht. Jon Bach was in the audience, and he gave us some very valuable feedback on our idea and how we presented it. This blog post is a follow-up on our conversation in Anaheim.

Recently I was testing version 1.5 of AddQ’s SBTM reporting tool SBTExecute. The team wanted to release the new version as soon as possible, and I was travelling so there was not so much time for testing. We agreed that I would spend one morning – four hours – testing the final version. My method of choice was of course xBTM. In this blog post I will go through how I spent those four hours, and what was the outcome. For more background on xBTM and the tool, please refer to my earlier post.

Test plan

My initial step was to make a mind map test plan. My preferred (free) mind mapping tool is XMind. I opened a new mind map and placed my application under test (SBTExecute) as the central topic. Next I identified my key areas (also known as function areas). I spent a couple of minutes thinking about some obvious groups and came up with:

  • Configuration
  • Documentation
  • Running tool
  • Import
  • Generation
  • Report

I added these six key areas as subtopics in the mind map. Then I decided I also wanted to some stress testing and added that as a subtopic too. See Figure 1.

SBTExecute 1.5 testplanFigure 1: Mind map test plan. The central topic (SBTExecute 1.5) is the software under test. The subtopics are key areas, or test techniques, and grouped under the key areas are the test threads.

Then I spent about twenty minutes thinking about test ideas, or test threads, and writing them down in the mind map under the appropriate key area. Since this was not the first time I tested the tool, I already had some ideas of things to test. After a total of maybe half an hour or less, I had my test plan, see Figure 1.

Testing

I decided to start by testing Import, since that is the key feature of the tool, if you cannot import data from the session reports nothing else is really worth testing. I looked at the threads I had listed under the import node and figured that I could probably test all of them in one 45 min session. To show this in the mind map, I changed the colour of all those threads to blue, see Figure 2.

Session 1Figure 2: Testing all threads under the key area Import in one session.

I write my session reports using the SBTExecute Excel template, and I use the mind map note functionality to connect the session report to the mind map. The yellow paper icon on the subtopic Import shows that there is a note, which can be viewed and edited by clicking the icon, see Figure 3.

NotesFigure 3: Adding notes in the mind map program. The note refers to the corresponding session report.

I ran the session, making notes in the session report. When I felt I was “done” testing a specific thread in that session, I visualised that in the mind map by adding a green check icon to that thread. Once in session, I realised that I didn’t really want to test the thread Incorrect data, since there is data validation in the Excel template. I decided to pause that thread for now, and maybe come back to it later if I had time. Hence I added the pause icon to that thread. I also added some notes on why I paused the thread, see Figure 4.

Notes 2Figure 4: Pausing the thread Incorrect data.

Then I realised I had forgotten to prioritise the key areas, so I did that using the colourful number icons in the mind map program. The highest priority is 1 and the lowest 6. See Figure 5.

PriorityFigure 5: Adding priority.

It turned out that the tool only reads files in xlsx format, and not old xls files. I wasn’t sure if this was a feature or a bug, so I marked the thread with a question mark and made a note of it, see Figure 6.

Notes 3Figure 6:  When there are questions, the thread is marked with a question mark and a note is added.

I ended the session, but the fact that xls files were not read made me curious so instead of starting a new session I decided to look at the configuration key area for a while. I spent a few minutes trying to create session reports in Office 97-2003 and Open Office and have the tool read them. These two threads were tested as threads rather than in a session. I only spent a few minutes on them since it was a low-priority area, made a short note, then paused the threads and decided to come back later. If I were to resume these threads (in the end I never did), I would keep making notes in the notes window, see Figure 7.

Notes 4Figure 7: Testing two threads for a short time, then pausing them.

Next I decided to test all threads under the key area Generation in a session, the same way as I did with Import, see Figure 8.

Notes 5Figure 8: Testing all threads under the key area Generation in a session.

Here I found a few defects, which is illustrated by the red X in the mind map. Whenever I found a bug, I made a note in the mind map of the ID number and added a short description. Of course this information was also added to the session report, see Figure 9.

Notes 6Figure 9: Defects found are marked by a red X, and a note of the ID number is added.

After completing the Generation session, I started looking at the Report key area. Here I decided that the two threads Iteration Reports and Summary Reports were extensive enough to make up a session, see Figure 10.

Notes 7Figure 10: Testing two threads in a session.

After running three sessions, and testing two threads separately I had the following status in my mind map, see Figure 11.

Three SessionsFigure 11: Test status after running three sessions and testing two threads separately.

The documentation for the tool consists of three manuals, and I felt they were best tested as threads. At this point I was running out of time, and decided to simply quickly skim through the manuals. I used the partially filled square icons to visualise how far I felt I had gotten with the manuals and made short notes in the mind map (no session report since I tested them as threads). The final couple of minutes I decided to spend on testing running the tool with correct parameters, which I also tested as a thread since there was not enough time for a session, see Figure 12.

Notes 8Figure 12: Testing threads, using the partially filled squares to visualize progress.

Test report

Finally my four hours were up and I stopped all testing activities. At this stage I had a test report in the shape of the latest version of the mind map, see Figure 13.

SBTExecute 1.5 stopFigure 13: Test report.

I also had three session reports (Import, Generation and Report) and an error list.

Given more time, I would have returned to the paused or partially tested threads and continued, adding notes in the notes window. I would also have spent some time on the previously untouched threads. Due to the very limited time in this case, the above story is not a very good example of thread-based testing, but I hope to have one soon.

About Christin Wiedemann

Christin Wiedemann (@c_wiedemann) is the Co-CEO and Chief Scientist of PQA Testing. After finishing her PhD in Physics at Stockholm University, Christin Wiedemann started working as a software developer for the Swedish consulting company HiQ. Christin soon discovered that software testing was more interesting and challenging than development and subsequently joined the Swedish test company AddQ Consulting. At AddQ, she worked as a tester, test lead and trainer, giving courses on agile testing, test design and exploratory testing throughout Europe. Christin developed a course on exploratory testing, and is a co-creator of the exploratory testing approach xBTM. Christin currently lives in Vancouver, where she joined Professional Quality Assurance (PQA) Ltd. in 2011. In her current role as Chief Scientist, she drives PQA’s research and method development work. She continues to use her scientific background and pedagogic abilities to develop her own skills and those of others. LinkedIn Profile
This entry was posted in  All, Agile Testing, Test Planning & Strategy and tagged , , , . Bookmark the permalink.