Early testing: Mere overkill or absolute necessity?

Early or late testing? That's the question. And we've got a clear answer from an expert with 13 years of hands-on product testing experience. In this interview, Modsen Head of QA covers the long-debated issue of early testing, its essence, use cases, and business benefits. Dive in to finally cross the t's and dot the i's on the matter!

— When talking about early testing, most people mentally place this stage closer to the end of the software development process. It seems logical and common. Why is the practice of late testing established in the first place now seeing its end?

— At first glance, late testing does seem logical. During the initial software development phases engineers build the codebase and develop functionality, and then testing specialists assess the result of the work done. But in the real world modern product development and project building appear to be much more complex, so the standard formula is not effective anymore.

— To date, the concept of early product testing has been gaining momentum for some time. How would you explain the essence of this approach and the reason for its ubiquitous utilization by companies of all sizes and industry backgrounds?

— From a business point of view, either type of testing is an extremely impactful tool that boosts the efficiency of the product under development. It allows teams to share their efforts and helps manage project priorities. And while late testing embarks on this vital task closer to the finish line, early testing holds it in focus from the very first steps of the software development process. Imagine that you're building a space rocket. If there is the slightest unnoticed mistake at the stage of projecting, you're likely to spend millions trying to fix it when the rocket is already built. The same is true for software project development. If the testing team delves into the work at the requirements-gathering phase, the chance of a project failure from the technical point of view drops drastically as specialists will highlight potential bottlenecks business-wise, identify contradictions, and give expert advice on user experience enhancement.

— Getting ready for our interview, I came across shocking statistics: as a rule, changes introduced before the codebase is built cost on average 100 times less than those introduced when the coding phase is complete. How exactly does early testing save investments? In Modsen practice were there cases when traditionally late integration of testers into a project resulted in considerable financial losses for a client?

— Yes, the stakes are really that high. The earlier testing specialists dive in, the less money business owners will have to spend on fundamental alterations. If to think of real-world examples, here's the most recent one. About 6 months ago Modsen testers joined an ongoing startup software development process. During the initial analysis, we identified communicative complications between the development team and the business owner, which resulted in the inaccurate implementation of several app features and the blurring of their business value. To get back on the right track, a big portion of the costly work had to be redone, a lot of features were rolled back and the time-to-market was extended immensely. The moral of the story is quite explicit.

— Were there any cases of early integration of testers that didn't live up to the stakeholder's expectations?

— None and hardly can I imagine it's possible given that the selected testing specialists' provider is reliable. When my team joined the process close to its beginning, we were able to carry out a full-scale analysis of the workflow, assess potential risks, highlight sensitive spots – and this one I'd like to stress – show maximum engagement and responsible care for the client's business.

— From the end user's point of view, is there any difference at what stage of the development testing specialists join in?

— None and hardly can I imagine it's possible given that the selected testing specialists' provider is reliable. When my team joined the process close to its beginning, we were able to carry out a full-scale analysis of the workflow, assess potential risks, highlight sensitive spots – and this one I'd like to stress – show maximum engagement and responsible care for the client's business.

— As it stems from the name, “early testing” implies that testers participate in the project development from its very first stages. But what does their input at the beginning of the process look like if at this point there's absolutely nothing to test yet?

— Let's not forget that the testing team is involved not only in testing. At the outset of the project development process, testers actively interact with business owners. Here I mean discussions of the functionality, selection of optimal approaches, implementation of successful solutions, and a lot more. The testing team just like the development one starts its work by analyzing the client's requirements as soon as they appear. Their verification, elimination of contradictions and inaccuracies, and even software logic refinement are the tasks carried out by the early testing team. Mistakes in business logic are also quite common and if identified early, can be localized painlessly for all the stakeholders.

— Early integration of testing specialists in a project bolsters intra-team collaboration which is one of the fundamentals of Agile methodologies, isn't it?

— That's true. Proactive interaction between developers and testers is key and it aligns perfectly with the Agile approach we stick to in every project we build at Modsen.

— Let's talk a bit about guarantees. A lot of business owners keep integrating testing teams at the final stages of product development as, from their perspective, it lowers the project building costs. Is this strategy a trap? And what guarantees does investment in early testing offer?

— If to speak about guarantees, I'd like to emphasize the following: the testing approach we're talking about today is 100% beneficial for businesses, and the first signs of it you can see during the first days of work. I've been in the industry long enough to see various business cases, both successful and failed, and all my arguments are in favor of early testing. Is the perspective to avoid costly redos and delays a great guarantee itself? I believe it is.

— So you're saying the absolute majority of project development cases, early testing appears more cost-efficient than late one?

— Certainly. As I've mentioned before, the early testing team brings an array of valuable positives to the project including collective effort optimization, and cutting bug localization time, which without any exaggeration, drastically influences the financial metrics.

— The importance of early testing for middle- and large-scale companies is vivid. But is it really necessary for startups or smaller businesses?

— I was looking forward to this question. The importance of early testing for startups is even greater than for enterprises. Flexible decision-making, utilization of optimal solutions, and maximum cost-efficiency are crucial for young and emerging companies. Early testing fully complies with these requirements as the team of testers will help avoid critical mistakes, engage in all aspects of the process, and even analyze the business model. And these are not mere words – our experience at Modsen allows me to speak of the benefits with full confidence.

With the average software development project failure rate as high as 80%, securing the success of your future product becomes even more crucial. Early testing offers a unique set of business benefits that help companies reach their goals timely and accurately. Don't risk your business future – choose Modsen QA professionals to lead your project toward the desired 20% of success stories. Read our interviews to stay up-to-date.