Software Testing Methodologies - Guide

Software Testing Methodologies - Guide

by | 5 min read
Published:
Updated:

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.

Waterfall

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.

🚀 Are you looking to level up your engineering career?

You might like my free weekly newsletter, The Curious Engineer, where I give career advice and tackle complex engineering topics.

📨 Don't miss out on this week's issue

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.

V-Model

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.


🙏 Was this helpful? If you want to say thanks, I love coffee ☕️ , any support is appreciated.


ALSO ON ALEXHYETT.COM

How to do Performance Testing with k6

How to do Performance Testing with k6

  • 06 October 2023
If you haven’t done any performance testing before, then k6 is a really simple free tool that you can use to do it. Now you might be…
Types of Software Testing Explained

Types of Software Testing Explained

  • 03 March 2023
We all know how important it is to test our code but there are so many different types of tests that it can be difficult to work out which…
Unit Testing vs Integration Testing - Key Differences

Unit Testing vs Integration Testing - Key Differences

  • 03 February 2023
Testing is an important part of a developer’s toolkit. After all, how are you supposed to know whether your software is doing what it was…
Using WireMock.net for Integration Testing

Using WireMock.net for Integration Testing

  • 22 May 2021
Last week I showed you how you can use Wiremock in a docker container to mock API calls that your application uses. This week is on a…
Mocking API calls using WireMock

Mocking API calls using WireMock

  • 14 May 2021
It is rare in software development that you are building something in complete isolation from everything else. Generally, you are going to…
Using ngrok to test local websites and APIs

Using ngrok to test local websites and APIs

  • 07 April 2021
Often when I am creating a new website, I want to see how it is going to look on an actual device like my phone or tablet. You can use…