Regression testing days 3 to 7

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”

Performance agreements – a first attempt for agile project team members

I was just reading an article on performance appraisals by Shane Hastie. It is a good summary of some of the issues that traditional performance appraisals cause on agile projects.

But it leaves two questions unanswered:

  • Where would you start if you actually had to do a performance agreement; and
  • How would you actually know what was expected of you if you didn’t?

The situation is made worse, according to the links in Shane’s article, when you want the team to be jointly accountable for shared success rather than individual success.  This is important if you want to work out how to evaluate testers or BA’s for example, because their purpose is to make the team successful rather than to stand out on their own.

Continue reading “Performance agreements – a first attempt for agile project team members”

OODA Loops for fighter pilots, business analysts and testers

When I started to learn agile approaches to projects, OODA was all the rage, but it seems to have disappeared from view as modern agilistas move from Scrum to lean to Kanban to ultra-velocitus development.

I guess I am still a bit old school, because I still think the OODA loop is the essence of the agile approach.

So what is an OODA loop?

OODA loops began as an approach for fighter pilots to avoid dying. It is a way to train fighter pilots and also a way to design fighter aircraft, develop tactics for air combat and win wars in the air.  It turns out that it is also really useful for agile projects, production support teams and anyone rolling out a product in a competitive market.

Continue reading “OODA Loops for fighter pilots, business analysts and testers”