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”
This article is part of a series on making regression testing useful rather than painful. The most recent article was (as you would guess from the title to this one) about day 2 of our regression testing adventure.
So far we have been looking at how to do some testing, and then do some basic scripting and mapping as we do more testing. In doing so we have (hopefully) been learning more about the system we are building but our main focus is on making sure it is still performing the way we want to.
Now we are going to evolve our testing onto a proper OODA loop. I have created another article to explain what an OODA loop is, but for our purposes it means this:
How fast and how well can the team move between the following 4 tasks?
- Observe the world around them – the way users are operating, the way the system is performing and the way things are coming together.
- Orient themselves or make sense of all that data (interpreting, analysing, integrating and assessing).
- Decide what to do next with all that information.
- Act on their decisions as a cohesive group.
To do this we need a little lesson in OODA regression testing theory
Regression testing is the easy part of IT development, not the horrible monster some people think it has to be.
But where do you start if you want to do effective regression testing, but you are already busy and don’t want it to be huge burden?
I hope this article and a couple that follow will turn out to be a guide to one painless way to get regression testing up and running. Let me know if it helps.
Continue reading “Regression testing – day 1”
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”