User stories for production support part 2: PAC

I wrote an article on stories for production support teams quite a while ago.  But I always meant to add a couple more.

The problem with production support is that nobody has time to ask for what they want, but it is all urgent and super critical. So the last thing you often feel like doing is to slow down and understand the context that the user is in (annoyed, relaxed, sitting in a cafe, in their most important sales meeting ever etc). Instead the focus is usually on fixing “it” before you know what “it” really is.

But this often leads to rework. So whenever I am doing enhancements I always spend a little time understanding why the enhancement is needed, who it is needed by and when/how it is likely to be used in the real world. To do this though, I think we always need to spend a little time understanding the people who will use the system and why they need something new.

There are many approaches to doing this, but one I often find useful is “PAC” or “People, Activities and Context”.

Continue reading “User stories for production support part 2: PAC”


Making regression testing suck less and yet be more effective – exploratory testing

I have often found that regression testing is both important and boring, so I usually try to automate it as much as possible.

Unfortunatley there there is often little or no automation in place at all when you join a new team and there is often not enough time to get it working properly before the next release. 

In fact though, even when there is a lot of automated testing in place, I have sometimes been surprised how quickly a good business person will find a significant bug by simply sitting down and mucking around (playing) with a system for an hour.

Continue reading “Making regression testing suck less and yet be more effective – exploratory testing”

Manual regression testing may not suck so badly after all

I often work with good developers and one thing I notice about all good developers is that they seem to love the idea of building robots.

Bad developers see problems and sit there waiting for someone to come up with a solution in enough detail for the developer to transcribe the solution into code, much like an old fashioned typist takes dictation and types it onto a page.
So if a bad developer noticed that their house needed cleaning, then he or she would simply complain that someone should clean it. Then if you point out that it is their house that needs cleaning then they will either claim management won’t let them clean or that the problem is more complex than it seems cannot be solved.

In fact even if you ask them to try and clean, they will just start to reveal that cleaning is “more than vacuuming” and could involve the removal of micro-particles that only quantum physicists could possible manipulate. Indeed, they will contend, it is unlikely that anyone really cleans their house and the only practical solution would be to upgrade to a new cleaner house.

But good developers are different. A good developer will notice that the house needs cleaning, work out that actually cleaning it less fun than designing a better way to clean houses and immediately begin working on the design for a new robot.
Continue reading “Manual regression testing may not suck so badly after all”