Quality assurance methodologies in software testing

QA is an essential part of any software development process.

It ensures that the final product meets or exceeds all expectations and that it’s ready for release.

However, too many companies don’t have proper methodologies in place to ensure that their QA processes are working properly and are being used to the max potential.

Which directly affects the quality of their software and leads to increased costs, technical debt, and extended development time.

Here, we’ll take a look at some of the most common QA methodologies used by companies today and see how they can improve your software development process.

Waterfall methodology

The waterfall methodology was the first widely used software development method and many companies continue to rely on it today.

It’s a linear, sequential model that follows a set of stages where each stage must be completed before moving on to the next one.

That’s why it’s often referred to as the most traditional approach because it focuses on completing one task at a time and ensures that all of them are done before moving forward.

As you can see in the picture below, the process usually features the following stages: requirements, design, development (or implementation), testing, and deployment.

The requirements stage of the project is where you gather all functionality, performance, and usability criteria that your product needs in order to succeed.

The design stage includes creating the overall architecture and specifying system requirements, programming languages, and databases.

During development, developers write code and build prototypes. Once this stage is complete, testing takes place—the bugs are identified and fixed.

If all goes well, then it’s time to deploy software into production.

It’s easy to see why the waterfall method has somewhat fallen out of favor.

At its core, it’s highly structured and rigid, and doesn’t fare well in the face of change.

Alan Mellor, a senior software engineering consultant, puts it this way:

Also, testing is limited to a single phase and takes place only after the development is complete.

This is problematic because if a bug is found during testing, fixing it can be difficult—especially if the code has already been built according to a specific set of requirements.

This means that any changes must be made at great expense—in terms of both time and money.

In fact, according to a study conducted by NIST, fixing a bug during the testing phase is 15 times more expensive than doing so in the requirements stage.

However, you don’t have to discard the waterfall method entirely.

It’s still very effective for smaller projects with a defined scope and an agreed-upon set of requirements that require minimal change.

Because bugs are easier to find and fix when projects are scaled down, in this case, late testing is not a major obstacle.

Therefore, the waterfall method is a good tool to have in your arsenal. It’s just not the best choice for more complex software.

V-model

The V-model is a popular software testing process that was developed to address some of the shortcomings of the waterfall method while preserving its benefits.

It uses the waterfall method as a foundation but adds steps for verifying and validating the project’s deliverables before moving on to the next stage of development.

As you can see in the picture, each phase of development has its corresponding test phase, and since the entire diagram is in the shape of the letter V, it’s called the V-model.

The advantage of using this model is that it ensures that only high-quality deliverables are produced at each stage of development.

As the testing starts in the early stages of software development and it follows through until the very end of the project, you don’t have to worry about any bugs creeping in later on because they’ve already been identified and addressed.

Plus, because the testing is built into the V-model, it’s easier to track how well the project is progressing.

However, it’s important to note that this model isn’t without its drawbacks, and a tech lead Hanumantha Reddy has listed a few of the most common ones in his Quora response about the topic.

As you can see, the initial investment is greater in the V-model than it is with the waterfall model, because the test team resources are needed from the start to develop and maintain the testing infrastructure.

Also, if changes caused by bugs occur midstream, then all documents must be updated.

This ultimately means more red tape and more work for everyone.

That makes the V-model better suited for small to medium-sized projects that have a clear set of goals and requirements, with minimal room for change.

All in all, compared to the waterfall method, the V-model is more efficient, but it’s still very rigid and can be difficult to maintain in larger projects.

Agile methodology

The agile methodology is the most popular of all the QA methods, and much more flexible than the waterfall or V-model.

In a nutshell, agile is an iterative approach that focuses on building software in short cycles, called sprints, with each cycle providing a working product at the end of each sprint.

The process is highly collaborative and relies on frequent communication between all members of the team, including developers, QA specialists, project managers, and other stakeholders.

Considering that 71% of companies are already using agile, and 93% of agile companies reported an improvement in operational performance, it’s safe to say that this methodology is here to stay.

But why has it become so popular in the QA field?

To answer this question, let’s look at the video below in which Peter Gfader, a professional scrum trainer and founder of Beyond Agility, talks about how testing differs in an agile environment.

What’s clear from the video is that in agile, testing is not a phase anymore, but rather a continuous activity.

When testing is just a single stage in the overall process, such as in the waterfall method, QA specialists cannot test until all development work has been done—which can be many months down the road.

In agile testing, QA specialists can perform tests at any time during the sprint.

This means that they can test a new feature as soon as it’s available, instead of waiting for developers to finish coding, which saves time overall.

Also, quality assurance is more about preventing bugs than finding them.

This means that QA specialists aren’t trying to break the system by looking for vulnerabilities—instead, their goal is to improve its quality.

That is possible because agile development practices enable QA specialists to be more involved in the project from the beginning, which gives them more meaningful insights about the goal of a project and helps them better understand how it works.

One Twitter user puts it this way:

One thing, though, that is highly recommended for agile QA specialists is to automate the testing process as much as possible so they can focus on more important tasks.

That’s why tools like our own solution, Shake, are so important in the agile method.

Shake is a bug and crash reporting tool that can be used to automate many of the repetitive tasks that are associated with mobile app testing.

It allows QA specialists to easily create reports, track and manage bugs, and provide developers with a location where they can view all of the issues that were found.

When they spot a bug or some other issue in the app, all they have to do is shake their phone, and the tool will automatically create a report that includes the details about what happened, including the following:

This will ensure that developers have all the information they need to get to the root cause of a bug.

The tool also allows QA specialists to attach screenshots and video recordings of what happened to the report, so if there is something that needs further investigation, everyone will be able to see exactly what happened.

When all is said and done, it’s clear that the agile method is a proven and effective way to develop, test and maintain software—especially for big projects where time-to-market is critical.

Extreme programming model

Extreme programming is a popular agile methodology that focuses on building working code in every iteration.

It emphasizes communication, simplicity, and feedback over comprehensive documentation, long-term planning, or heavyweight design processes.

As such, it’s based on strict values, rules, and practices that guide the development and testing processes and are intended to help teams produce higher-quality software.

The process begins with planning, in which the team defines user stories and estimates the effort required to build them.

The process then moves to development, where the team implements the user stories.

After that, they test the new features and ensure they work as expected.

Finally, once defects have been fixed and any necessary refactoring has been done, it’s time for deployment.

At this point, it’s worth noting that there are two important testing practices in XP:

• test-driven development (TDD)
• pair programming

Test‐driven development is a practice where the developers write automated unit tests before writing the code.

This means that they must first write a failing test for the new functionality and then make it pass by adding code to fulfill their requirements.

This process ensures that the code is correct and that it works as expected.

On the other hand, pair programming is a technique where two developers work together side-by-side at one computer, with one person (the driver) typing while the other (the navigator) reviews their work.

This practice is an excellent addition to TDD because having another pair of eyes on the code during its development increases the chances of finding mistakes.

While these two practices rely on developers, acceptance testing is where QA specialists shine.

At the end of the process, they test the software against its requirements and ensure that it works as intended before it gets released.

As you can see, the key to XP’s effectiveness is its ability to allow developers and QA specialists to respond to each user story as they’re introduced, then adapt or make changes on the fly and test accordingly.

In contrast to other agile methodologies, XP is much more disciplined, relying on frequent code reviews, and unit and acceptance testing to allow rapid iterations during all stages of development.

Iterative testing method

The iterative testing method is a hybrid of waterfall and agile development.

It’s similar to agile methodology in that it emphasizes rapid development, early and frequent releases, and collaboration between developers and QA specialists.

However, just like the waterfall method, it still relies on a phase-based approach, with each phase having its own set of tasks that must be completed before moving on to the next one.

If you look at the picture, you’ll notice the waterfall structure, but the difference is that the process is iterative.

This means that each project has multiple iterations, and at the end of each iteration, there is a deliverable ready for testing.

When it comes to testing, the focus is on gradual improvements based on many different types of feedback.

Mari Luukkainen, a startup growth advisor and keynote speaker, explains it like this:

Iterative testing refers to the process of making small and gradual changes to a product or business process based on a wealth of different insights, from testing results to overall user feedback.

The advantage of this type of testing is that feedback from it is immediately available and allows the team to incorporate changes into the next cycle.

As they gain experience with each iteration, less time will be required for testing in successive iterations.

As such, the iterative testing method is a data-driven process that uses the results of earlier iterations as input for building later ones.

That’s why it’s an ideal way to create flexible products, for example, startups, where requirements tend to change often, and scalability is important.

Conclusion

There are a lot of different ways to approach QA.

Each one has its own benefits and drawbacks, which is why it’s important that you find the right balance between them.

By implementing the most effective methodology, you’ll be able to create higher-quality software that meets your users’ needs.

And by doing so, you can increase both efficiency and productivity in your QA and development team.