Source code for the OneNote Merge Pages powertoy and a tedious test task
Reader Mark Jordan made a request last week for the source code for the Merge Pages powertoy at http://blogs.msdn.com/johnguin/archive/2007/08/16/merge-pages-in-onenote-powertoy.aspx. Jeff Cardon graciously agreed to release it, and you can download it here. Down at the bottom of this entry below my signature is the link for attachments and the compressed file is there.
(I would have posted it with the previous entry, but the blog software we have only lets me add one attachment per article. I'll update that page to point here, too).
My other big task for this week has been tracking a bug in our newer, still in progress versions of OneNote. Head's up early: this is a tedious story about tracking a tedious bug, but it also shows a typical (yet tedious) testing task. We have a test notebook that will not sync properly on our sharepoint site. The problem was pretty easy to narrow to one particular section that has about 80 pages in it. From there, I had a choice on how I wanted to narrow down the problem. First, I eliminated the easy to find problems: the section was not bigger than server size limits, my permissions were correct, etc… After working through that, I was left with the assumption that one of the pages had some data on it that caused the sync to fail.
My first though was to do a "binary sort" through the section. I would test the first half of the pages, and if the sync failed, test half my data set again, and keep reducing the data set of pages until I had found the problematic page. Other ideas were sorting by date or classifying all the pages (which had ink, embedded files, etc…) and using that methodology.
The "binary sort" has the advantage of being the easiest to start and is the most efficient method of finding the single offending page. It's what I started to do when I realized there may be more than one problematic page. In this case, I could get unlucky and find only one of two or more offending pages. Say page 1 and page 29 were both "bad". My first test would be the first 40 pages, which would have produce and error. My second test would be pages 1 through 20, which would have produced the error. I would have eventually narrowed down page 1 as the culprit, but missed page 29. So I was left with the problem of finding potentially multiple bad pages.
My solution was probably not the most elegant, and definitely not the quickest, but was easy. After making each of my two data sets, I tested both. If both failed, I knew I had multiple problems. In my particular case, though, I found the single bad page and turned it over to the dev team.
Like I said, tedious. It's not all automation and powertoys in test!
Questions, comments, concerns and criticisms always welcome,
Published Thursday, January 08, 2009 7:51 AM by JohnGuin