Testing is for QA engineers, right? Nevertheless, we find it to be an essential part of developers’ work as well. Self-testing often raises controversial questions among developers and becomes a hot potato that gets tossed around in development teams. You’ll often hear things like:
- Why should developers do testing: it’s a QA task;
- Developers can’t test because they have a different mindset;
- Developers don’t have time, etc.
Self-testing is like checking your pockets before leaving the house. You’re checking for the keys, wallet, phone. Your main aim is to leave the house for work BUT you need to be sure that everything is in its right place. Plus, you want to ensure that everything will be safe and secure after you come back home. So you check the water supply, heaters, lights, take out the trash, and feed your pet. Of course, you do, and if you have a pinch of doubt about not turning off the iron, you return to recheck it.
Self-testing is similar to this routine. Its aim is to leave the product safe and sound after implementing a new feature or fixing a problem. Before we go any further, let’s shed some light on the notions of self-testing, unit testing, and smoke testing, as other categories related to the topic, and underline why unit/smoke test should not be taken as self-testing.
What is Self-testing?
Self-testing is a type of testing executed by a software developer after the code is written and integrated into the system, to check whether their piece of code delivers the expected result when integrated into the whole system of the product.
By comparison, unit testing is done during development with the goal of validating the result of the code in isolation. Smoke testing is a kind of software testing performed after the software is built to ascertain that the critical functionalities of the program are working fine.
For starters, let’s make it clear that self-testing done by developers is considerably different from testing done by QA engineers. Developers are expected to make sure the new feature is integrated into the system successfully. On the other hand, in addition to the main flow, QA specialists consider every possible positive and negative case, they consider the feature from the point of view of all possible users, as well as from the perspective of business. Moreover, they test it in connection with other modules somehow related to it and suggest improvements to make the feature better.
By contrast, no one expects developers to do all that, right? To put it another way, developers are expected to verify, while QAs follow verification up with validation. Meaning, they make sure development meets business goals.
With that in mind, let’s list out some weighty arguments in favor of self-testing.
Whatever you do, do it well.
This is not just a motivational quote, it’s a lifestyle. So self-testing is a helpful habit to bring into your life. You deliver better code as a result of self-testing. As a result, you see better results and set challenging benchmarks, and become a better developer. Defining standards for oneself has always been an essential key to self-development.
Taking a fresh glance at your code
As a result of self-testing, you begin to acknowledge the possible weaknesses of your code. One can fix most issues in a more mechanical way, but after fixing them make sure you have time to look at your own code with a fresh glance. This will allow you to understand the weak points, and improve, as well as find better solutions leaving you with optimized code, better quality, and performance.
Prevent instead of fixing
You say you don’t have time…Ok. Imagine there is a defect in the code. You know you could have prevented it. The QA specialist finds it, does some research, reports a bug, then the PM takes a look at it, prioritizes it, and assigns it to you anyway. Assume you are already working on another feature. Now, you have to interrupt your work and dive back into the previous feature. So a stitch in time saves nine!
Fast delivery, better product
Deadlines are an inevitable part of projects, and when projects are in production, deadlines are often very pressing. When self-testing is not done by the developer and main flows and integration are not tested and verified, then testing of the feature takes plenty of time to verify all those bug fixes and finalize testing, which, in its turn, causes delays in the project.
Steps to Guide You in Self-Testing
👌 Do it as a must until it becomes a habit
When estimating the implementation of a feature, make sure you factor in self-testing time. If you are dividing the main task or story into manageable sub-tasks, make sure you also have a separate sub-task for self-testing. The fact that there is such a task urges you to resolve it ensures you are delivering a complete feature.
🤘 Think like a user, stay a developer
High-quality code is not a guarantee for trouble-free features. Features need to be checked manually in the context of the whole system. Think like a user: Is it convenient to use the application? Is it secure to store or transfer sensitive data? Being in a user’s shoes while testing your own code is a trusted method to becoming a successful developer.
🤝 Sharing is caring
Helping other team members to have a better understanding of the technical implementation of the feature is as important as implementing it. Jot down your comments, specific steps, endpoints, routes, even worries regarding some weak points of the code, and inform other team members how the new module can affect other parts of the application. Passing this kind of information on in written form also reduces time-consuming verbal discussions full of potential misunderstandings.
✊ Resist dark forces
Never pretend that you’ve done self-testing when actually you haven’t. Never lie. It becomes obvious whether the feature has gone through self-testing or not when it fails on the first or second step. If you have a time constraint and can’t manage to do self-testing, inform your fellow QA about it, and highlight the parts that need to be tested more scrupulously.
———————————————————————————————————————————–
Here at Flux Technologies, we have been practicing a self-testing policy for almost a year. As a result, we had a remarkable reduction of bugs (25–35%) in just a month.
We asked the developers to assess the effectiveness of the self-testing policy in terms of the product they are currently working on and in terms of their own productivity and code quality from 1 (not effective at all) to 10 (very effective). And most of them (60%) find self-testing very effective both for the product and the code.
Also, we asked to list some pros and cons of the self-testing policy and combining the answers received from the survey, we got the whole picture that, we guess, doesn’t need any further comments.
