How much can you save if your software house starts testing early on in software development?

You might think only finished things need testing. After all, how can you test something that’s not even ready? Or better yet, something that’s still stuck at the specification stage? It turns out, however, that the correct placement of testing in the software development process will have a really tangible impact on the final price and schedule of the project. So, if you think the later your testers get down to work, the more money you will save (after all, they will work fewer hours, right?), think again – you might want to do a 180.

Shift right or shift left?

In the olden days of software development (meaning several years ago), there was much less awareness about software testing than today. The norm was to shift it right in the software lifecycle, i.e. postpone it until the later stages of the project. The team would define the requirements, start working on the code, and quality control would need to wait until a greater part of the app was finished. Unfortunately, that created a lot of problems.

Slip-ups at the early stages of the project could have a painful impact later on. Sometimes, developers had to rewrite entire functionalities, which adversely affected project budgets and schedules. Not to mention lowering the morale of the team and creating potential tensions between testers and developers.

Source: https://www.reddit.com/r/ProgrammerHumor/comments/tcomip/at_the_end_of_the_day

Today, we are already aware that testers are more than just “clickers” who only need to step in toward the end of the project to click through a finished application. Their role is to ensure quality at every stage of software development, so the sooner we bring them in, the better the outcome. Accordingly, a new approach, known as shift left, has emerged; the approach is to introduce testing early on in the software lifecycle. And we don’t just mean testing as such, but the involvement of testers at the earliest possible stage.

How does the timing of software testing affect the IT project as a whole?

The old approach – shift right:

• Testers: happy, because they find errors
• Developers: crying, because fixing them will take a lot of work
• Project Managers: angry, because they need to notify the client
• Clients: mad, because the project is set back.

The new approach – shift left:

• Testers: happy, because they find errors
• Developers: happy, because they can fix them immediately
• Project Managers: happy, because they can tell the client everything is going according to schedule
• Clients: happy, because the project is right on time

Early testing. Why is it worth it?

Testing at later stages of software development inevitably increases the risk of project and product issues.

Let us walk you through some of these risks:

• Testers are not very involved in the project, which means that there is less software quality control;
• Any bugs (both in terms of requirements and code) are detected rather late, usually post-implementation;
• There is very little time to fix the bugs. Work is postponed until later versions, which lowers software quality and creates a technical debt;
• Bugs are more difficult, time-consuming and expensive to fix.

In contrast, shifting left allows testers to ensure that the solution is of high quality. Of course, a single tester cannot take responsibility for the whole project, but they can provide important support to the team. In the SCRUM model, we find space for testers even at the backlog stage and at all the subsequent stages of the software lifecycle:

• Backlog creation (testing stories, testing mock-ups, testing specifications, testing documentation, DOR – PASS);
• Planning (planning subtasks, estimating costs, detecting threats, identifying bottlenecks, defining priorities);
• Development (preparing scripts and test campaigns, signalling problems);
• Testing (testing, identifying scripts for smoke tests and automation, ensuring app quality, detecting and test elimination, DOD – PASS);
• Implementation (supporting client testing, system stability control, controlling functionalities and their compliance with requirements and specifications).

What are the advantages of this approach?

• We create a comprehensive testing strategy for all quality control areas;
• Inconsistencies are detected at the backlog stage, which speeds up the whole project;
• Testers support the team at the planning stage, which makes it easier to detect potential threats and project bottlenecks;
• Projects involve static testing, which helps to verify the requirements and detect any bugs before the code is compiled;
• The final cost of detecting and eliminating bugs is considerably lower.

Early testing as a key to success

Let us now pause and think: if this is so, why are testers not the staple members of every developer team? Why are they not automatically included in the project from the get-go? The reason is that there is still too little awareness and, secondly, many believe it would involve a greater cost. You might think that bringing testers in at the very end will simply be cheaper. You would be wrong.

Here is one example. In 2002, the NIST published a study that looked at the cost of fixing a bug at different IT project stages (using the traditional Waterfall methodology). As shown below, fixing bugs that were detected in production turned out to be 30 times more expensive than fixing the same bugs at the planning and requirement analysis stage.

Source: https://dzone.com/articles/quality-is-the-answer

Why was the difference so huge? As we said before, the later you find the bug, the more work you will need to invest to fix it (which will directly translates into more developer hours). The study also included the cost of project delays and the technical debt.

We also collected data from our own projects from several years ago. The projects were carried out using agile methodologies, but our awareness level in terms of testing was definitely lower than it is today.

As you can see, the results closely mirror those of the study discussed above. We reached identical conclusions: when detected in production, even a handful of bugs drives a huge increase in costs. Even though we found most of the bugs in the early stages, the oversights dealt an important blow to the final budget. Fixing them cost nearly 5 times more than it would have in the earlier stages.

To test or not to test?

We hope that these figures will speak to your imagination and convince you that it’s a good idea to include testing practically from the start of the software lifecycle. Testers should already be part of the project at the specification stage and closely cooperate with analysts and architects. Experienced testers will be able to catch the first errors when reading the specifications and verifying requirement consistency.

Is it always possible to find and fix all bugs so that none makes it into production? There is never a 100% guarantee. But we still continue to find ways to minimise project risks and approach software development in a safer and more efficient way.

Want your software to be developed under the watchful eye of our testers?