Tuesday, December 6, 2011

Session testing

Earlier today I made a serious attempt at performing session testing.

I had created a simple high level test plan to get started with, and I used Quality Center to log each 'session'.
For each of these, I included the area that I wanted to test, and I recorded the tests that I performed.

I created a separate test for each session and planned 30 minute increments to test. My goal was to spend that 30 minutes testing and not to stop even if I found a problem. I would make note of the problem and continue on if possible.

I logged three separate sessions today.
Session 1: I planned for 30 minutes. I installed the latest version and went to check out the new feature. I ran into a show stopping bug within 2 minutes. A problem with the build process. I made note of this problem in QC and then told the developers, who promptly corrected it.

Session 2: I again planned for 30 minutes and was confident that I would get further than I had previously.
This time it took me 6 minutes to find a bug. This was the hardest part of my day. I wanted to jump up and point this problem out, but I had to will myself to note the problem, and continue testing. This could wait 24 minutes to be reported.  By the end of this session, I had found one more bug and an issue that required further follow up.
I recorded each of these in the session notes and my teams discussion board. This way the team could decide how to handle these problems going forward before creating defect reports.

Session 3: I planned for a longer session of 1 hour now that one of the bugs I recorded had been dealt with.
My first task in this session was to verify that the bug had indeed been corrected. I went to visit that area first and found that while it had technically been corrected, it was still wrong.

Summary:
This was a good learning experience and its something that I want to do more of. I think that I need to refine my sessions a bit, but for a first attempt it went pretty well. Session testing seems to be a useful way to provide some more structure to what I already do.
Previously I would have tested each new version and I would have found those bugs. But I might not have found them as quickly if I had dropped everything to research and report the first problem I found. I may have  written some generic tests for acceptance criteria that weren't very helpful and would never be looked at again.
What I have now is a trail of documentation that better describes the testing that I did, how I encountered problems, and how I dealt with them. I'll continue to refine this idea for my own use and I'll post about it again.