Tag: regression testing

Agile development, Capability growth, Idea management, ImplementationLeave a comment

Regression testing days 3 to 7

James King

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?

  1. Observe the world around them – the way users are operating, the way the system is performing and the way things are coming together.
  2. Orient themselves or make sense of all that data (interpreting, analysing, integrating and assessing).
  3. Decide what to do next with all that information.
  4. Act on their decisions as a cohesive group.

To do this we need a little lesson in OODA regression testing theory

Continue reading “Regression testing days 3 to 7”

Agile development, Implementation4 Comments

Regression testing – day 1

James King

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”

Agile development, Idea management, Implementation4 Comments

An international standard for being stupid? The mistakes users always make

James King

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”

Agile development, Idea management, Implementation4 Comments

A simple product summary to help requirements

James King

I was speaking to a crew who were struggling with regression testing and after interrogating them they finally admitted that a large part of the reason they were struggling was that they did not really understand what they were testing.

I was shocked and horrified so I wandered off.

Soon after I spoke to some business analysts who were struggling with an agile project. They alleged that the agile approach they were using did not allow enough time to capture the requirements properly. But guess what, they broke down under interrogation and admitted that a large part of the problem they were having was that they did not really understand the product they were building.  Apparently the evil agile people had forced them to write stories about the system before they had time to understand it.

Continue reading “A simple product summary to help requirements”

Agile development, Implementation, Measurement3 Comments

Manual regression testing may not suck so badly after all

James King

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”