Here is the tale of your project hiding up to 15-25% of your budget and how to find it with TESTING!
Habib Moskin
Software Quality Explained ?? Head of Quality - Testspring ??? Testing ?? QA Process ?? Trainings ?? Consultancy ?? I help companies reach the quality they want??
Did you know your project could save up to 25% of the development budget? I needed 13 years to learn this. Here is the story of how to find the missing money, direct it into testing without spending a dime, and save some cash for the future.
Testing - a luxury you should afford!
Quality is a luxury these days, and not many can afford it. After all, would you rather have one more developer to develop the product quicker or a tester who will only slow things down?
Can you afford the low quality?
The dilemma is understandable. Testers do not produce, so they are useless—at least in terms of business, turnover, and budget management. It's not a surprise that, doing consultancy all over the world, I would usually hear, "If you find the money, you can have your testers!"
So I've learned how to find the money for testing. I want to tell you how easy it is. Testers have no added value, granted. But you can earn on Testing. How? The concept is straightforward - Quality Control.
Quality - where do we lose the money?
To understand how much money is wasted, let's imagine for a second that making software is no different from producing cars. It's just the production industry. While building anything, you lose money due to issues in three main areas:
Testing - As a quality control tool, it lets you control all the above quickly and reduces money loss. You can easily calculate how much. Compare that to the Testing cost, and you will instantly know why the automotive industry spends so much on quality control. You will also understand that you can afford testing and need it. Let's see where you can find the money to have some cash!
The first rule of saving the budget
Removing a small problem in the documentation can cost you even 100 times more if that problem becomes an issue in a ready product - pure math.
Testers can easily control the quality of documentation, requirements or even tasks you give to developers. I understand if you smile while reading this - thinking - "Oh sure, dream on. I'm sure you aaaaalways have documentation". I never needed comprehensive docs. In the end, it's all about the production lines. If the tester looks at the development task and has no clue how to test it in the future - developers will not know how to code it now. So it surely means it will come back to you as a cost, while you must redo functionality or a design.
We don't have time to test it right now!
"We don't have time to discuss every little detail!" - do you have time to pay to redo all the details? I'm sure the odds are on the side of quality control.
The second rule of saving the budget
How much did it cost me to produce this function? What was the total cost of the system? It might be tempting to say, "The fixed price is the cost" or "Developers' time was my cost." But the problem here is how often the finished product was missing some parts or not behaving as expected.
领英推荐
Quality is the only formal metric that proves what has been delivered. It is based on test reports.
Having your test report is the only way to tell if you have finished the work. Otherwise, speaking about the product and finished tasks is just a form of fortune telling. If you go to court because you are not satisfied with the product, the only thing that will explain what the product is (what functions it has, how it behaves, etc.) is your test report. No one will listen to what you think was done. It's not a game of "She said he said".
The third rule of saving the budget
Imagine you are in the steel industry. Your margin is 3%. You would be very careful with any waste... Can we afford carelessness in IT? Here is the big sack of money from the future that you can use now on Testing;
Eliminating waste is one of the best strategies to improve turnover. Can you do it in Tech? Sure. But first, we need to say it out loud - the most significant waste in the software industry is people's time. It is the sum of all our omissions in the planning and executing phase. To understand the money you spend on the software, you need to track how much time developers code, vs how much time they spend fixing bugs. You will not have that data without the Quality Control process (professional Testing). So much money flushed down the drain.
How much you can save on testing and how to start
You will be shocked to learn that in my 13-year career as a Software Quality Consultant, companies I worked with spent 32% of their development budget on bug fixing and redos. Imagine a business where you can afford to waste 32% of your work. Does Testing fix this? No. But it gives you enough data to know about it and start the process. How do you get that money back in your pocket? Here is a high-level roadmap showing how to reduce 17-19% of the waste-time.
Two practical examples of where money hides and how to get it.
Now the best part. How do you get your money back in the future? Focus on the waste time you produce. It is the sum of all the problems, so you will fix other issues by reducing it. Analyse where most of it is located and fight it. For example, in my career, I usually observe two hot spots:???
It took us long time but we finally have a cure for drownings - we need to dry out the Earth
The first hot spot is wrongly defined goals or requirements, which result in redoing things. You see this in the uneven distribution of time spent on a task vs the estimation. If there are no estimations, it's not a big deal. Usually, you need to take a closer look at those tasks that accumulate much time, as something is generally wrong with them. Then answer a question, - what should happen for those tasks not to reserve so much time? Here is the answer for the first step: implement the processes that would stop jobs from accumulating exceptional amounts of man-days. Regardless of missing information that needs to be obtained from different sources or work that should have been broken down into smaller pieces - you will spot it, fix it and save around 10% of development time alone.
Imagine you run a car factory. You know that every tenth car is broken. Would you give them to the customers just to deliver them on time?
The second hot spot is usually straightforward—a lack of appropriate Testing. This does not mean testing the code only; it means testing the product as a whole to verify and validate that you meet the project's goals. Why? Otherwise, you have a model of deferred payments. You get the code quickly but pay for all the omissions later. Here is where the next 10% of the budget hides. I know that "start testing" is not necessarily the brightest solution.
But let me explain this obvious advice. Imagine you run a car factory. You know that every tenth car is broken. Would you give them to the customers to deliver them on time? That happens with the code if you lack a test cycle that gathers metrics and analyses the data. You might not even know how many faulty functionalities there are until customers report them. These tend not to be gradually reported but come in waves. This slows down the delivery of the next functionalities, putting even more pressure on pushing them to the market, which results in this cycle of never-ending corrections and fixes.
The end, but is it?
Every project is different, and there are no one-fit-all actions. But principles stay the same - if you don't care about quality, you can meet any other requirement until somebody tests it! It's more than just a nice saying!!! Here's why:
Quality is a metric. It measures how much of the requirements you've delivered and how well they reflect the needs of the stakeholders, customers, and users. If you don't measure it, you can point to the rock and say, "Here is your starship! Does it fly?" Well, we didn't check, so we assume it does.
If you find this interesting but would like to understand how exactly you could use this knowledge in your project, let me know. I'm more than happy to explore this with you!
After all, there is nothing better for a product than some quality-driven decisions!
Habib Moskin