QA as the perfect enabler to shorten your project’s time to market

In our ever faster digital world, time to market is an increasingly important factor in any IT project. A shorter time to market is crucial to stay ahead of the competition. However, this is not possible without an agile and qualitative IT environment. This is where Quality Assurance comes into play.

Concepts such as the V-model and the various test phases are considered to be textbook practices, but in reality, that’s not often the case. A mere 15 years ago, software testing was considered to be a necessary evil which was rarely set up in a structured way. Today, it’s still the first activity to be scratched when time is running short.

As a result, around the turn of the century, more than 70% of IT-projects worldwide did not meet their projected planning, quality and/or budget. Even though considerable progress has been made over the course of the past decade – and Quality Assurance is no longer viewed as ‘monkey testing’ – the overall project success rate has not increased at an equal pace.

All too often the focus lies on manual testing output, performed by end users not only lacking the necessary testing skills but, who are often asked to take on the testing tasks on top of their running operational duties.

Apart from these issues, organizations and their ICT-departments are facing an ever-increasing pressure to deliver. More mobile and demanding customers, global competition and making the switch to a digital-first mindset are just a few of the challenges business and – as a result – ICT are facing.

Decreasing the time-to-market is crucial in all this, but converting the classic waterfall ICT-model with 3 releases per year to an agile, monthly release cycle is easier said than done.

QA can plan an important role in facilitating this transformation in two ways:

1. First time right, i.e. investing in QA from the start of the software development lifecycle (SDLC);
2. Shortening the lead time by automating the manual QA activities.

First time right: involving business from the start

A recurring but painful phenomenon is that business comes up with an idea, has it developed by IT, only to come to the conclusion during UAT or in production that it’s not exactly what they wanted or needed. Because of previous negative experiences, there’s a growing realization that requirements have to be clearly defined from the start.

Traditionally, business discusses the requirements with analysts who then further research and document the possibilities after which they pass the requirements on to developers and quality assurers.

In an agile context, the product owner ensures business is more firmly involved in each phase of the project, with feedback being provided following each sprint. But even in this scenario, developers often already have implemented a sprint with possibly malfunctioning features. To avoid this and to get things right from the start, it’s important to increase business involvement even more.

Amigos meeting: setting your requirements straight

A method used to involve business earlier in the process is the so-called ‘amigos meeting’. This is a meeting with the product owner and a representative of each of the IT-parties involved (architecture, development, analysis, QA).

During the meeting, the product owner discusses the project feature by feature. Because all of the stakeholders around the table get the information directly from the product owner, possible pitfalls or issues can be identified early on and tackled before errors have been made.

At the end of the meeting, all questions and remarks have to be addressed and all stakeholders need to see eye to eye. The deliverable of the meeting is a checklist of all of the requirements for each feature to be considered as ‘completed’ and which has been signed off on by all parties.

The checklist can then be used by the QA lead to define everything that needs to be tested and validated. Usually it’s also this person who will check whether all of the requirements have been met before the project is delivered to business.

Working this way makes project validation from the business side a formality. But to get there, business will need to sufficiently trust IT.

Automated testing can help shorten your project’s lead time

We’re currently seeing a move towards automated testing, affecting unit, integration and GUI testing. Because business often still lacks the confidence in IT, too much time is devoted to manual software testing during the UAT test phase. This is a time-consuming activity, with a huge impact on a release’s lead time.

Living by the aforementioned first time right principle, business is involved early on, even before the development phase. Because at that moment, a requirements checklist is created for each feature to be considered done, it becomes much easier to perform automated tests early on: at the low-level unit testing stage.

Automated testing of each feature during the development process will lead to a more stable system at a much earlier stage. If at the same time the integration tests (services such as API, Rest, …) can be automated, you’ll end up with a very stable system that should meet all of the business requirements.

This will imply that the effort spent on GUI testing – automated or not – can be reduced. Mike Cohn’s test pyramid model is a good model to illustrate this as it provides an indication for the required test automation investments across the various test phases. While this is a goal to shoot for, we’re not nearly there yet.

Once the step has been made to automating most tests in the earliest stages possible, we can start thinking about continuous deployment.

In a continuous deployment process, it’s possible to immediately install the result of a development process on a pre-production environment that closely mirrors the production one. In this environment, several functional or GUI tests can be performed by the business.

Most companies are dreaming of a fully automated testing process. This in fact entails not only automated testing, but a fully automated process starting with checking in the code all the way to the deployment in production. This is what’s referred to as a continuous delivery process.

As part of this process, checking in of the new code is automatically followed by the automated validation of the new code in light of the definition of ‘done/completed’. If that’s the case, the new code will be deployed in production automatically using the same process.

This decreases the time to market considerable. It goes without saying that the model of continuous delivery is not applicable to each and every situation (legacy environments, for example). Plus, it requires a high maturity of all IT-activities.

What’s most important though is that it allows you to adapt to the changing world around you much faster than your competitors do.

Interested in speeding up your IT delivery model while keeping the level of quality intact? Get in touch with our QA team.

Special thanks to Joeri Wijns for his contributions to this blog post.