Software development often gets a bad reputation for being costly and time-consuming. This is often due to bad planning and estimation.

There are a number of different methodologies that are used to help make software development more efficient. Each approach has different beliefs as to what they think will make a good development process.

Some approaches put all the planning and development upfront, while others such as the agile approach will work in sprints and plan out work as they progress.

The different software development methodologies obviously have an impact on how the software is tested, and the approach will vary depending on which methodology is chosen.

Let’s have a look at the different software testing methodologies and how they relate to the software development process.

Waterfall Method

The waterfall methodology is one of the oldest software development processes and is also the most rigid of the ones we will cover.

If you imagine each process in the software development lifecycle as a step going downwards, with work flowing from one step down to the next, this is the waterfall method.

Each step needs to be completed before going on to the next. This method canoe good if the application is relatively small and all requirements are well known, however, that is rarely the case.

The steps will typically follow this process:

1. Requirements
2. Design
3. Implementation
4. Verification
5. Maintenance

This flow doesn’t allow for changes to be made after the requirements are done. It is a head-down and get-on-with-it approach.

For teams following the waterfall approach, the testing isn’t usually done until the verification stage after all the development has been completed.

As you can imagine, if you wait until all the development has been done to do the testing, then you are going to find a lot of bugs!

This isn’t an ideal approach but can be manageable for very small projects.

Agile Method

The agile method attempts to overcome the downsides that we have seen in the waterfall method.

Instead of doing all the development in one go, the work is split up into sprints. Each sprint typically lasts between 1 and 3 weeks, depending on the preferred pace of the team.

As work is completed it is available to be tested and typically tests will also be done against what will be released at the end of the sprint. The key to the agile method is delivering at the end of each sprint.

The agile approach is generally preferred over the waterfall method, however, it still has a number of drawbacks.

By making it easier for stakeholders to change the requirements, you can almost guarantee that they will change. As a result, there is often a lot of rework being done with the agile approach, which leads to more testing being needed.

Developers typically underestimate how long it will take to complete a piece of work. On top of that, we have Parkinson’s Law to deal with. The longer we have to complete a task, the longer it is likely to take.

The combination of the two results in what we call “Scrum-a-fall”. Where each sprint is effectively a mini waterfall project, with all the testing being done at the end of the sprint.

Verification and Validation Method (V-Model)

This method is often called the V-methodology due to having two V’s in the title and the shape of the diagram looks like a V.

This differs from the other methods as the testing is done in parallel with the other steps. Even the requirements are subject to testing and feedback.

Verification: Are we building the product right?
This is done at the start of the project to make sure that the requirements that are being gathered are correct and that the design meets those requirements.

Validation: Are we building the right product?
Once the application is written, we then move on to the validation stage to test that the actual product meets the requirements that we gathered.

Like the waterfall method, this approach tries to overcome the problem of building the wrong product by spending more time on planning in the early stages.

Iterative Method

The iterative method is very similar to the agile methodology. The key difference comes with how often the code is deployed to production.

The work is still split out into smaller components and iterated and tested, but the deployment process happens once the application is complete.

Personally, I prefer the agile methodology over the iterative method, as from experience I know that something that works locally isn’t necessarily going to work once you get it into production.

This method has a smaller focus on initial planning and requirement gathering, which may result in unexpected consequences and delays to the project.

As the work is still done in small increments, it is common to see the scrum-a-fall issue raise its head with the iterative method as well. There are likely to be other issues once the code is deployed to production as well, which is why you should always aim to deploy to production as soon as possible.

Extreme Programming (XP) Method

Extreme programming (XP) doesn’t introduce any new concepts to the ones we have discussed already. But the cycles are a lot shorter, hence being called extreme.

The XP method works on short iterations with constant testing at each phase. One aspect of the XP method that isn’t seen elsewhere is that programmers work in pairs. Each is working on the same piece of code. It is believed that 4 eyes and 2 brains on the same problem will result in better code and fewer bugs.

One person writes the code while the other one observes and comes up with ideas and spots errors.

I have done pair programming a few times in my career, it can feel unnatural at first, but it generally does result in well-written code with good feedback from those involved.

The main downside of extreme programming is that it is incredibly fast-paced for everyone involved, including the testers. This can often be too much and can lead to burnout if done for an extended period of time.

Final Thoughts

Developers and QA don’t always get to pick which development and testing methodology they are going to use, but clearly, there are pros and cons to each method.

The success and failure of a project are generally down to the team rather than the methodology that is picked. I have seen teams be successful with both waterfall and agile and really depends on how well the project is managed.