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.
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:
- Running tool
|Figure 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.|
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.
|Figure 2: Testing all threads under the key area Import in one session.|
|Figure 3: Adding notes in the mind map program. The note refers to the corresponding session report.|
|Figure 4: Pausing the thread Incorrect data.|
|Figure 5: Adding priority.|
|Figure 6: When there are questions, the thread is marked with a question mark and a note is added.|
|Figure 7: Testing two threads for a short time, then pausing them.|
|Figure 8: Testing all threads under the key area Generation in a session.|
|Figure 9: Defects found are marked by a red X, and a note of the ID number is added.|
|Figure 10: Testing two threads in a session.|
|Figure 11: Test status after running three sessions and testing two threads seperately.|
|Figure 12: Testing threads, using the partially filled squares to visualize progress.|
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.
|Figure 13: Test report.|
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.