Testers keep telling me that testing is not just about breaking things. They also tell me that they are there to help the team think rather than just point out the dumb things they have done in the last sprint.
That’s probably all true. But I have been asked by someone to give them a mechanical set of steps to do when you are an agile tester. That way they have a starting point when they join an agile project.
So here are the 8 steps to follow:
Continue reading “A mechanical guide to testing on agile projects”
Before I worked in IT and even knew what testing was, I knew people made mistakes. But I didn’t know there was an international standard you should comply with when you want to make a mistake.
Then I worked on a project with a mining company and one of the consultants explained human factor analysis to me in simple terms. He told me that mine sites can be dangerous and part of his job was to “stop people killing themselves when they are stupid”.
I suggested he stop hiring stupid people but he told me that they tried that and it didn’t work. Apparently you can be really intelligent on a mine site 800 days in a row but then be stupid for 10 minutes one day and be in an accident and then be killed.
“Luckily we have a standard for being stupid though” he said
Continue reading “An international standard for being stupid? The mistakes users always make”
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”
I have often admitted that I am not a test manager, but I know enough to realise that any project with an IT component needs to have an IT test strategy.
I also know that creating a test strategy should involve more than just taking the 25 page strategy from the last project and replacing the project name.
Continue reading “A test strategy for lazy project teams”