Now the Real Work can Begin

  Something has struck me during my last couple of sprints. I'm not finding obvious bugs.
  I've been with my current company about 10 months and during that time the developers have been slowly, but inexorably, building up unit tests and integration tests. We've now hit the point where the fruits of this labour are being shown.
  We now have an environment where the Testing Dead cannot hide, where a tester can hone skills to an edge and truly thrive. And I do intend to thrive.

  Although I know it wasn't done for me (it was done because we all want our product to be better than even we think it could be), I want to thank the team for getting us to this point. I think we are on the brink of a new era and I am very much looking forward to it.

Debriefing PROOF

 One of the things we have been keen on implementing at my company is testing debriefs. Our main purpose for these debriefs is to learn from each other, as opposed to using them as a management tool. We experimented with a couple of techniques, including the session debriefing checklist from session-based testing. This we found a bit too cumbersome for our needs, but we did find that the idea of a standard set of questions was particularly useful. A little digging led us to PROOF:

Past - What happened?
Results - What did you find?
Obstacles - What issues prevented you testing?
Outlook - What still needs to be done?
Feelings - What do you feel about the testing?

This set of questions (originally conceived by Jon Bach) we found gave us a good balance between a checklist and a starting point for discussions.

Cross-Pollination

  I've been working in an agile development environment for a couple of months now and a thought has been niggling away in the back of my mind.
  One of the ideas that agile raises is the idea that people are not segregated, or purely responsible for their own silos. The most common scenario I have seen is developers helping out testers. But I have not seen the reverse. I've not been asked, when there is a backlog of development work, if there are any cards I can work on.
  So here is my question. Are there any testers out there who can and will take on development work if required? I don't mean automating tests, but actively contributing to a products code base.
  Personally, I think it is a good idea, especially for cleaning up small issues (e.g. spelling mistakes) where the time it takes to send it back to dev and have someone else do it is longer than just doing it yourself. The biggest problem I can see is that a tester is never going to know the code as well as a dev. Therefore, knowing which activities it is worth you performing may be a bit tricky, but I do believe it is worth trying.

Grab Automation by the Cucumbers

  In my previous company, we started experimenting with automation. I had fun trying out the various tools and languages that were around, but we finally settled on implementing WATiN (for anyone interested, the others we seriously considered were Selenium and Sahi). I think we settled on the correct framework, but didn't have a good way of creating tests. What I had written was code that would replicate a workflow, but it turned out to be very flaky and not as much use as I'd originally hoped (if anyone from there is reading this, sorry about that).
  I have recently moved to a new job, and the automation there is going to be driven using Cucumber, with Watir-Webdriver as the framework. I think that Cucumber will sit very well with me, because the scenarios that are written very much invoke my idea of a test case (Given your application is at some state, When you do something, Then this will happen).
  I'm really looking forward to getting stuck in.

More Time to Test

  My company has recently announced that it has ended support for IE7. Lets all be thankful for that. Ever since I started testing web applications, I have had one heuristic that has served me well:

  'If it is going to break, it will break in IEx' - the x was originally IE6, then IE7 and now it is IE8.

   The sad thing is, I actually like IE. I preferred the interfaces of 6, 7 and 8 to the minimalist style of Chrome, FF4+ and now IE9. I have used it for years, meaning I had little trouble in finding settings, since I knew the general menu layout as well as the terminology it uses.
  But the fact remains that, unless I have specific reason to use another browser for testing, I have to use IE8 because any problems that are in the software that are browser related, are likely to be caused by IE incompatibility than anything else.