October 8, 2013

Off Week

I was planning to blog about API testing this week, but I seem to have a really busy week this week.  The local testing user group is meeting on tuesday and the Saskatoon's First Lean Coffee is this thursday. Currently I lead both groups. So I'll be back next week with API testing. If you have any heuristics or tools that you use for API testing,  Please feel free to put them in the comments on this post and I'll include them in next week's series.

October 6, 2013

MindMaps In Testing: Wrap up

So I spent a week without using a notebook, a testing management tool or any notes except for  mindmaps. It was an interesting week, I think I actually took better notes, missed fewer dark corners of the applications that I tested and was able to share my work with others easier. Alot if this was made easier by the use of colors on the nodes in my mind maps.   I used bold colors for things that I needed to come back to later, and light variants once I had come back and done what ever action was needed.


Lets take a look at what my process looked like.  Every Day I reviewed my Maps from earlier in the week to see if there was anything I needed to pull into todays map as a item I planned to do. So before my day even started I had a map with a center node that was the days date, surrounded by any tasks that carried over from the previous days and the items I planned to do that day.  If there was a task that carried over the the previous day, I would copy the node over with every thing that was under it so that I had my notes from the earlier work to guide my continuing work.   I found that my exploratory testing was very much assisted by this exposure to my previous results. I was able to make links across sessions and generate new charters with better insight than I had when I used a notebook for this same process.

As the day progressed, the first level nodes that I was working on would progress through several states denoted by color. White for upcoming tasks, yellow for the currently active task, Red/Purple for tasks that needed to be revisited, and Green for completed Tasks.  If that was all that I had done, this would not be as great a tool as it ended up being.  Also made notes on the tasks, and did my test planning under the testing tasks.  Since I used an electronic MindMap tool this allowed my test plans to be fluid and dynamic based my results.  Results from the tests were also recorded in the MindMap as were all of the defects and other issue I noted. Again these were color coded to allow me to make notes about them and not get distracted by opening my bug reporting tool  and spending time then reporting, but rather making enough notes that I could come back later to do a RIMGEA analysis and better report.


I found this technique very useful. My entire day was in one place, I could break pieces out to share and collaborate with others,  and I missed less. I will continue to use MindMaps in this way, and will continue to look for new ways to use MindMaps in my work.

October 4, 2013

Schedule Change

I've realized that my blog schedule isn't working very well.  Writing Monday morning seems ok, but I really seem to be writing this post Sunday Night, So I' going to try and Release the Monday post either Sunday Night or Early Monday. The wednesday post doesn't seem to have enough exposure to the tool or technique to have a lot of insight, So I'm going to move this post to Wednesday Night. Same goes for the wrap up post, by writing to for Friday Morning,  I'm losing a day of exposure to the topic before I write, so this will be Friday Night/Saturday Morning depending on my availability.

Tune in tomorrow for my MindMaps Wrap-up.

October 2, 2013

SFDIPOT.... Huh?

One thing last weeks exercise showed me was that while I'm familiar with SFDIPOT, I haven't used it enough to be comfortable with it. So let dive in,  I'll explain what I know (or think I know) about using it and how I plan to use it this week. If I make mistakes,  I fully expect the community to help out and show me where I'm using SFDIPOT wrong, and I'll pass that on to you.  The original blog post about this by James Bach on his blog here. He's mentioned that developed this heuristic from surveying six or seven computer science textbooks to lay the framework for his thoughts on application modeling. 

As I understand it SFDIPOT is a heuristic to use while doing a software tour to ensure that you have a complete understanding of the application.  This is sort of how I use it. I actually do several tours of the application/feature in questions, all very quick and high level while thinking about each of these. I don't do them in the order of the Heuristic simply because I don't really think that way. 

So what does it mean? 

S: Structure, how is the application put together/wired up. These are things like: Uses Mysql as a server, Has a separate authentication server,  Uses memcache and Uses Ajax. Things that can lead you down other vectors that you might not have thought of while doing a simple product tour. You might need to get help/information from the developers and or Documentation for this piece, as such I recommend doing near the end of the heuristic. 

F:  Functionwhat are the functions of the feature/application. What are the individual things that it does.  This can be a (organized) listing of all of that actions that can be done using the application. These are smaller than the user stories, these are things like "Mark favorite" and "Join mailing list". Stories will come later and will invoke many of these functions. 

D: Data, what are the data types involved in the application. Data types can lead to interesting test cases. Have a look at Elisabeth Hendrickson's cheat sheet for some great ideas on how to test your data types once you have identified them. 

I: Interfaces,  one of the newer letters in this heuristics (and thus harder to get information on), these are the interfaces that the application interacts with the outside world on. Does it have a file based interface anywhere (import/export  functions?)  Does it store intermediate files to a local storage anywhere? Is an api provided? Does one exists that isn't provided? And yes, the GUI is an interface, does it interact in the ways that a user will expect that kind of interface to interact.

P: Platforms,  What are the platforms does this application run on? Is it a java app? Does the version of Java matter? Is it a Web app? Does the browser version or vendor chance the performance or interactions?

O: Operations, What are the operations that the application is trying to accomplish? What is the purpose of this application? What are the mistakes can can happen when trying to do this operation?  I've been asked if these are your User Stories and Test Cases, and the answer for me is kind of. User stories are definitely things that are thought of here, but not just the stories, how those stories can go wrong and or get interrupted.  Test Cases however are part of your test coverage. I'm using this heuristic to create a PCO which will in turn inform the creation of my test coverage.

T: Timings, Another recent addition to the Heuristic, Timings are what are the time based things you will have to think about with this application?  Does your application have to run a specific time? What will happen if it runs on Feb 9th?  Or runs over new years Eve? in 1999? What happens when two actions are done too quickly? Too slowly? A recent conversation with also pointed out to me that these can be environmental. Where is the application? What is happening at the same time? Is it rush hour at that time at that location? 

As you can see, if you run through all of these, you will have a very extensive list of things to think about while designing your test coverage.  As I said in the beginning, this heuristic while seemingly simple does take some practice to use, and that is my goal for the week. To use this heuristic and get better with it. My plan is to use this in my everyday testing, for every feature and bug report from the field that is passed on to me. I realize that this might not align with the it's best uses, but I'm game to try, maybe I'll figure out something new about the heuristic, or  about myself. 

I'll let you know how it's going on Wednesday!

If I have anything wrong or misinterpreted in this, please let me know in the comments below.

MindMaps in Testing: Mid-week

A few days in of increased use of MindMaps in my daily routine and I have seen some interesting results. Like any technique that is new, the novelty of doing something a new way can drive higher short term adoption, and I have been able to consistently use my day notes mind map to track my day. I would normally try to write this in a log book, but I tend to forget. The ability to color code the nodes however has made this more likely to continue after the "New way" interest has worn off.

So what have I done with mind maps so far? Two of my common tasks have been moved over to mind maps.  Test planning for newly completed features, and my daily activity log.  I have in fact combined these two into a single map, one for each day, where testing won't span more than a day.  Where testing will be a multi-day or multi tester effort, I've split it out into a separate map.  The daily activity map has helped me track my day and make notes on the activities that I do. I've marked with color finished tasks, blocked task, bugs found, future investigations and test results. The color enables me to quickly look and see what I need to remember. I used to do this with my notebook, but it's been hard to find the tasks and future investigations easily later when I go looking.

The tool that I've been using has a mode where it will auto color the nodes for you based on a color change at the leaf level to indicate that you have completed a task or  been blocked if you are using your MindMap as a plan/to-do.   I don't usually write detailed plans, I write down a list of areas I want to test, and some notes under each of those about why or how of that testing area.  This feature the MindMap software that I'm using allows me to quickly look back and see what area's I have left to cover in upcoming charters, and update based on the charters that I've completed.


All in all, MindMaps have been a good addition to my work. I haven't had to share the information in them with others yet, but I expect that to be helpful also.