Week Night Testing #2: Testing models & mind mapping


Ajay Balamurugadas, Anand Ramdeo, Anna Baik, Eusebiu Blindu, Markus Gärtner, Mike ScottZeger Van Hese all joined me in what I’d say was the most fun & inspirational testing session I’ve ever participated in!  European Weeknight testing session number two, had me on a testing high for at least a few days afterwards.

The mission was simple: Test the site Text2MindMap, making notes of your session in the form of a mind map & recording any bugs you’d found.  Simple stuff really & being focused on mind mapping I was pretty excited by it.  I’d also had some recent exposure to mind mapping in a testing session such as this when I’d paired with Albert Gareev that previous weekend during a Weekend Testing Americas session.  Albert wrote a good write-up about that on his blog, so I’ll not go into that, but that was also very enjoyable & it gave me the chance to work with someone I think very highly of.

Pairing wish list

In fact Albert ticks off at least one name I’d had on my wish list to pair with at some point.  There are many more on that wish list, I’ll not mention them here though.  For me, the trend in my wish list is not people who talk good about testing, it’s those that demonstrate it via good ideas that they’ve posted about or excellent experience reports; people who essentially teach others.  These people really excite me & sadly there are not enough like them out there teaching others through their experience, instead of just talking the testing talk.

Under Pressure

Anyway back on topic, I’d joined the session thirty minutes late & after a quick review of what had been discussed already & the mission I quickly set about testing the application & recording my findings using my favourite mind map tool Xmind.

For myself having arrived late I felt under severe pressure.  I’d given myself half the allocated testing time & having signed up to take the initial Miagi-Do testing challenge with Mr Gärtner I was keen to impress :-)

Testing Models

So what do you do in such a situation?  We’ll I’d never really appreciated the concept of testing models fully until that day.  I did like the concept & Michael Bolton made them sound very attractive & essential tools for any tester when I’d attended his Rapid Software Testing course.  However for me I’d just assumed everyone had concepts of types of testing to try out in their heads & had never really related it to a model.  It is though, and even if I didn’t have a written model of my own to follow at that point in time I did have my mental testing model which was invaluable in guiding my testing approach.

For me my model boiled down to the following: Claims, Documentation, Usability, Accessibility, Functional, Security, Performance, Limitations, Code.  A simple quick model which I could exercise to an extent within the thirty minutes I had.

My plan was simple; exercise each aspect of my model as quickly as possible, not dwelling on anything for too long.  Of course such testing would not catch everything (no testing does); it would however provide high coverage & feedback rapidly for the time allocated.

Times up

The thirty minutes passed quickly & before I knew it, it was time for the debrief.  Everyone posted their maps & we discussed aspects of each, interesting defects found, test approaches & such.  You can see from the mind map below how I got on

Darren mind map. Click to view

I find it’s always good when testing a UI to firstly work out all area’s of inputs.  You’ll want to focus your attentions on these first.  Then take note of all outputs & possible inputs which results in an output.  From these you can quickly apply elements of your testing model, providing a quick initial sanity of the functionality.

Inspectional Testing

Markus got the chance to demonstrate his Inspectional Testing idea which I’d thought looked very interesting & forced me to go read his blog post’s about it, which I’d had on my to-do list having only skimmed them previously.  It’s a good idea & as I’ve commented on his blog, could also be used in a proactive sense.

It really highlighted for me that idea’s shown in execution are more likely to get buy in from others than those ideas that we simple discuss & assume will be adopted.  This brings me back to some thoughts I’ve been having around the initial proactive testing post I put up a few months back.  We’ve nearly completed a full release cycle using these proactive techniques combined with its awareness (not control) metric, so expect a follow up post from me on how they’ve been perceived & how useful they’ve proven to be.

You can see below from Markus’s mind map how he applied Inspectional Testing to drive out his initial test charters.

Markus mind map. Click to view

Reporting with mind maps

I liked how Markus reported what passed & didn’t pass, I could quickly see from this what area’s he’d covered or not.  It got me thinking about SBTM using mind maps as a form of reporting for test sessions.  You can easily see what Markus covered & if we decided it required another session of testing then as a tester I could easily come in & decide which areas needed more attention or not initially.

Dangers of adding to a working process

As a tester though I can quickly see the downfall in reporting what I’ve done as I’m doing it.  My mind when testing is like a volcano ready to explode, I have so many ideas going on it’s often difficult to keep track.  I find that having a mind map, or a notepad handy to take notes of these idea’s or different threads that I’d like to investigate works well, as if I don’t give them attention immediately I’m in danger of losing them.

So that is obviously the glaring danger of adding in another aspect into your working model, by this ongoing reporting you run a large risk of losing test ideas.  Obviously for some reporting what they’re doing results in new test ideas.  I guess it’s down to the individual & highlights why a testing approach or method of reporting should never be forced upon anyone.

If you’re really keen on the reporting aspect of what was tested but don’t want your testers to lose valuable test ideas when testing, then using a tool such as Test Explorer would be useful.  Having used this myself I can honestly say it’s an excellent aid when doing session based testing.  It allows you to focus solely on testing while leaving the reporting aspect up to it.  It’s not free though, that’s the only downside.

Using others models

Jumping back into testing models slightly Anna Baik explored the application using a Heuristic Test Strategy Model, in this case (although I’m not sure) I think it was The Test Eye’s excellent Software Quality Characteristics 1.0.  You can see from her mind map below how this proved useful in allowing her to test aspects she might not have considered without it.

Anna's Mind Map. Click to view

Template mind map models

During the session I’d suggested that a really clever tester would have a template mind map pre-prepared which would provide them with a base list of aspects to be aware of when testing.  Anna said she’d considered this also & had thought about putting the contents of a HTSM into a map to use.  I’m certainly going to document my testing model in the form of a mind map after the holidays; I’ll publish it here once I do so.

What things stood out?

So what cool stuff did people find?  We’ll an excellent & very common issue was found by Anand Ramdeo.  He simply disabled JavaScript on his browser & low & behold the application stopped working.  I’d noticed when I’d had a quick glance at the source code some JavaScript dependencies, however I failed to follow up on that with the test that Anand done :-)

Error handling

So what’s the big deal then if we obviously need JavaScript enabled to run this application?  Well it’s simple really; the application doesn’t provide any feedback to say what the problem is.  It’s good practice when coding to account for possible errors, in this case a simple message to alert the user they needed to enable JavaScript on their browser to use the application would have sufficed.  In fact it’s often a good question to ask a programmer “What error handling code do you have?”  Seriously it’ll at the minimum get them to consider possible errors that might occur.

My assessment

Myself I found the application to be ok for basic usage.  It did as it claimed, coverts text to mind maps & in that respect it did a good job at the minimal levels of usage.  I wouldn’t recommend this to anyone though for serious usage.  Why?  This is why:

  • Under volume it simply renders unreadable mind maps.
  • Under depth certain nodes will disappear.
  • It has no undo which for me is basic usability & with the text area being its main area of input could result in users losing data.
  • On page hyperlinks don’t have a target of new, resulting in you losing all unsaved data

For me those are all basic functionality essentials.  The data integrity aspect is a major image concern for all companies & in this respect it fails on this twice.  Sure it’s meant to be a bit of fun, however if the creator wanted to seriously market this then they’d have invest a lot more time on it.

Eusebiu Blindu killed the application stone dead with his million character test :-)   Markus Gärtner also did some locale testing using accented characters which was cool.

Taking it local

For me though this was really an exciting, thought provoking & inspiring session.  So much so that the next day I setup two laptops in a room & invited my team mates to try it out in two groups of two :-)

The mission was the same as mine & of the two groups only one managed to get the application up and running before their laptop crashed ten minutes later.  The other pair couldn’t get a new version of flash installed to run the application.  Failure?  Not quite!  Both groups paired up & produced a textual report which I’ve converted into a mind map below.

My teams mind map. Click to view

I talked to them all afterwards & their perception was that it was a failure as they couldn’t test the application.  To me it was a great success!  They didn’t give up; they were resourceful in pairing up & using the knowledge and skills of both groups together.  In fact the four of them managed to find issues with an application they couldn’t test.  Not only that they planned in possible tests for a future test session, which could uncover further defects.  I think they did excellent & was chuffed they didn’t just give up when the technical problems occurred.

Wrap up

So to wrap this up what did I learn from this session & what can others learn?

  • Developing your own testing model is essential
    • Using other available models can be helpful
  • Creating a template testing model in the form of a mind map could prove to be really useful
  • Inspectional Testing is a good idea & should be explored further.
  • Any new input into a working process can have serious negative side effects
  • Mind maps could be useful for reporting/debrief/follow-up sessions with SBTM
  • Good error handling is important, let’s not forget about it.

Most importantly, there is a lot to be learnt from pairing with others.  Even reflecting upon your own approach can provide ideas & insights into what you could improve upon.  For myself I’ve came away from this looking to produce a base template testing model mind map to aid my future testing in testing sessions like this & also for my day to day job.  Something which I think will prove invaluable for me in the future, so I’m very happy.

I hope to see some of my readers at the next week night testing session after the New Year.  Drop Mike Scott a message on twitter for more details if you’re interested, or just keep an eye on his tweets for an announcement on this or any future sessions.

On a parting note, Ajay Balamurugadas is a freak of nature!  Seriously I’ve been reading all the reports from Weekend Testing sessions & he appears to be attending every one :-)   Ajay, you’re only human, the sleep will have to catch up with you sooner or later :-)

Thanks for reading.

Related posts:

  1. Week Night Testing, oh yes it’s begun!