In this blog post, I want to discuss the general testing practices in software development companies. What I have learned and found during my work experience will be described in this blog post.
Testing is unavoidable and if it is not done at all the shipped software is exposed on a high risk from not found bugs or problems. Not tested software can drop dramatically the quality of the product. Fixing issues after production began is expensive and slows down further deliveries.
How are the developers testing software? How is our testing team testing the same stuff? Can we test everything and can we assume that all resources spent on testing activities are worth?
There are so many questions in this topic and this somehow makes it hard to be untangled easy.
In my opinion, the common setup can be in one of the two main directions:
- Specialized testing team
- Software development without any QA (testing) team
Let us try to explain and analyze both scenarios and the have a conclusion.
Specialized testing team
Most of the developers will be happy about this setup. This means that there is someone who accepts the task to try our software and to test every available scenario. On paper sounds amazing but in reality, there are problems in this setup. Let us check some of them.
First of all, do you trust that the tester knows enough or more than the developer? So to speak is the QA stuff reliable in their test plans? Another aspect could be: Do you know if the test environment is the same as the production environment? The test environments are sandbox systems where some aspects can differ from the live environment. Nevertheless, the load of such systems is negligible and they are different from the production world. Also, calculate the “lead time” when some problems are submitted. Usually, the tester will submit a problem and after an unknown amount of time, the developer will respond to it. Afterwards, the tester will test again and so on. This loop can continue several iterations until both sides (or most of the time the testers) agree that everything is working perfectly.
When to use this approach:
- Very complex systems where the business knowledge can be dedicated to a QA person
- Small organizations or dedicated teams where the testing loop is not such a hassle and it will not create delay problems based on the communication loops or bureaucracy processes
No testing team
This may sound like Ludacris statement but it is true. Some organizations will not spend resources on dedicated testing and therefore will try other actions in order to ensure the needed quality.
How the hell is this working? I don’t know… It just works and I think there are two explanations:
- Either you spent a lot of time on testing yourself …or…
- The volume of users using the feature is so high that every edge scenario will come apparent immediately.
If 1. is chosen, be prepared for a lot of unit testing, knowledgeable developers who do a lot of “rubber ducking” with colleagues and low task throughput because of all these preparation actions.
If 2. is the style of your organization, then you definitely need to ensure feature toggling and closer monitoring of the system. The DevOps engineer is your closest friend at work. The tester is your users/clients but they don’t know it. In this way, you can immediately get the best possible feedback and stay closer to the environment where the feature will be used.
Personally, I like “No testing teams with a high volume of users for testers”. It is a really exciting technique and a place to be. I hardly can see any downsides except that some software companies can’t have so many users or they have constraints in the deployment methods 🙂
radoslav.dk 