Regression testing – day 1

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.

Day one – first thing in the morning

Start by getting some context before you expend a lot of energy testing what you don’t understand. I have put some tips in this article, but you can also just do the obvious things:

• Read the project charter if there is one, otherwise sit down and create one
• Sit down and discuss the users of the system you are building and the product you are building
• Document what you found, even if it is just on the whiteboard or on napkins

This can all be done in under one hour and it is worth getting the regression testing team to sit down together to do it. Of course you can feel free to take 2 hours if you want to fully understand what you are testing

Day one – 20 minutes of scripting

Create some scenarios that you will use for testing.  This does not mean that you have to fully document well written test scenarios, since that comes later.

The easiest way is to simple use the PAC table you created and come up with some examples of what some users might do.

I am using the example project from a previous blog where a cafe owner wants to :

Scenario	User	Activity and context
1	barista	Enter new member while the customer is watching over their shoulder
2	Jenny	check activity from PC browser
3	barista	Look up a customer record while relaxing at lunch
4	barista	Check to see if a customer is already a member
5	barista	Blog about a new type of coffee
6	Jenny	Send an email to some customers to notify them of an event
7	Jenny	Correct the details for a member who complained that we had their information all wrong.

This is our initial map for our regression testing. It won’t last long but it gives us a place to start.

Spend an hour or two doing exploratory testing

Now that you have some rough scenarios, log into a test version of the system and try to run some tests.

The tests you run will be “exploratory” because you have not created any instructions yet. But for each scenario, don’t just log in and make things work, instead try this:

• Try to run the scenario successfully from end to end and then record the outcome
  • Write any bugs or “strange things” on a piece of paper or whiteboard
  • Write down how long it took to run the scenario
• Stop and ponder for a moment, Use the international standard for being scared to come up with things that might go wrong. Then try to run the scenario again seeing if it will fail.
• As you run the scenario a second or third time, try using the international standard for being stupid to come up with mistakes or “strange things” the users might do at each step during the scenario.
• Document your findings again
  • Scenario number
  • Potential errors or questions I found
  • Rough steps I followed

Go and report the potential errors you found and if they turn out to be errors then record them in whatever bug tracking system the project uses.

Discuss the context again for 20 minutes

Sit down with the other people doing regression testing and discuss how things went

Provide the following “management report”:

Scenario	Run today	Passed	Failed
1	Y	1
2	Y		1
3	N
4	N
5	N
6	Y		1
7	N

Tests pass if you found no errors that went into the bug tracking system. They fail if you did record errors. Passing or failing is not good or bad, it just shows which scenarios found something.

Now sit down with the group again and discuss the context your are testing in

• What led to errors?
• What did you learn?
• Should you change the PAC or Product statement? Should you change the scenarios you are running.

There is more to do tomorrow, but you have already done more thorough regression testing than a lot of teams do. Well done.