Testing is the most important part of any kind of software development methodology, but it is also the most neglected one. Nowadays, when an organisation does testing, it produces such a high amount of waste that the whole development process becomes very expensive, which makes it harder to win projects over the competition and risks the existing relationship with the customer.
When an organisation follows Lean thinking, then it is capable of finding and eliminating waste through Kaizen, which means more output with fewer resources: less expenses and more revenue.
Lean thinking does not bother with testing and technical details, it just gives you the idea and approach, the rest depends on you, and how you implement it. In this post, I’m going to share how I would find and eliminate waste created during testing.
There are different kinds of waste (you can read more about them here), but first let’s have a look at their consequences on the level of the organisation: wasting money, losing trust and revenue.
Most of the organisations work like this:
This is a quite common structure. A large company (the customer) outsources some work to a start-up company (the organisation), and provides services to somebody else (the external customer). The same roles appear at large multinational companies as well, where the organisation may be a division inside the large company.
Before going any further it is very important to clarify the two processes of testing:
-
Verification: what I implemented is working
-
Validation: I implemented what the customer wanted
Without giving any spoilers on the upcoming paragraphs, I can tell you that in nine cases out of ten, the root cause of the testing-related problem is the misuse of these processes.
Before I forget, there is another highly important thing to mention. There is no such thing as a defect-free software. There will always be defects, the question is how you handle them, and what you do in order to have less of them.
In the following scenario I’m going to show how much money is wasted due to wrong testing attitude.
In my imaginary team there are three developers and one tester. I’m going to use fictional values and units, but I think you can map them quite accurately to your organisation.
A quite common scenario: the developers didn’t care about verification, because it is a testing job. As a result, the customer found 7 defects (3 verification and 4 validation), and the external customer found an *additional 2 (1 *verification, 1 validation) right after delivery. How much will these cost to the organisation?
| Day | Activity | Comment | Cost |
| 1. | Fix and test the problems | A developer costs 7 units a day, a tester 5, this all together is 26 | -26 |
| The customer is blocked until the fix is delivered, it costs 100 units per day for the organisation (possible loss of trust and future project opportunities etc.) | -100 | ||
| The external customer is also blocked until the fix is delivered, it costs 1000 units per day for the organisation (the same applies here as above plus the costs of the customer) | -1000 | ||
| 2. | Delivery | Usually, it is the task of the tester | -5 |
| Idle developers, the fix is ready, the tester is working | -21 | ||
| The customer is blocked | -100 | ||
| The external customer is blocked | -1000 | ||
| 3. | Customer tests and delivers | No new tasks from the customer, idle developers and idle tester | -26 |
| The external customer is still blocked | -1000 | ||
| -3278 |
According to the table above, the organisation lost more than 3000 units in three days instead of earning about 100 units, assuming the customer pays 12 units per employee per day. I’ve never met a customer who willingly paid for defect fixes right after delivery, so the organisation works for free during these three days. Additionally, there will be tons of heated discussions even if the relationship between the organisation and the customer is good.
What went wrong here?
-
Since the developers didn’t do any verification, it became the responsibility of the single tester and she hardly had time for validation
-
While the tester was really busy with the delivery, the developers were idle
Where is the waste?
Well,** the waste is that the tester had to spend her precious time with verification and had no time for validation.** Additionally, she had to do the delivery as well, while the developers were idle.
The regular management approach would be to increase the size of the test team before the delivery date, but how? It is proven that this approach is ineffective, but let’s take a look at it anyway. Where should the additional testers come from? Another project, or hire a freelancer? Bringing them up to speed would cost a lot of time and resources, which is a waste. Also, what should happen to them afterwards? They are going to be idle during the development process: more waste.
A recently emerged approach would transform the testers into tester-developer hybrids, and the developers into developer-tester hybrids. This has more potential than the previous approach, but it kills the testing skills, which are the most valuable possessions of an organisation. When a tester starts writing code, based on my experience, she will lose her ability to look at the system from a different perspective. Based on my observations, even the most skilled and experienced developers cannot see the product like an average skilled tester does.** Let the testers be testers**.
Would Behaviour- or Test Driven Development help the situation? Fortunately, it would, because when you as a developer write test cases, you take care of the verification.
But again, verification does not equal to validation! A very few people are capable of validating their features properly, because when you are doing programming your view is too narrowed down to enable you to see the whole picture:
Making the verification the duty of the developers is the first step in our Kaizen. After the developers are capable of making sure that their features work - with or without TDD -, the testers can use their skills to validate them and look for other problems.
The second step in our Kaizen is to verify each other’s features. According to the figure above, a developer’s perspective will not be as narrowed-down when it comes to viewing somebody else’s feature. This means that the organisation can find more verification-related defects and perhaps some *validation *ones before the actual testers get the features.
We have been working like this for several weeks now, and the amount of verification-related defects reduced drastically - we are talking about a 60 percent decrease -, and we even found some small validation-related defects during the implementation process. Unfortunately, we missed some validation-related ones, but our lead developers - who also act like testers - found them. They see the system on a much higher level; almost like the tester from the picture above.
In this post, we found the place where most of the time and money had been wasted in testing, and got to the conclusion that our way of working can be improved if developers take on the verification along with small validation tasks and leave more space for testers do to valuable validation. In my next related post, I’m going to show how to do verification properly as a developer.
comments powered by Disqus