The term "test" in its dictionary meaning refers to "a procedure to establish the quality, performance, or reliability of something before it is widely used." This article isn’t about methodologies like Shift-left testing or Test-driven development (TDD). What we should focus on is the intrinsic meaning of the word "test." People often get caught up in the impressive terms used but fail to focus on the core aspect. TDD is an excellent software development process, but it is just one of many means to address the core problem.
"Developer testing" refers to the act of programmers directly testing the programs they have written. I believe that developer testing is crucial. Quality assurance (QA) teams and specialized testing organizations are essential to create software that can be widely used, and QA teams are responsible for establishing efficient testing strategies and plans. These plans are crucial for efficiently managing the software lifecycle pipeline. However, there is a prerequisite for these plans, and it’s one that developers can fulfill.
Before QA teams test a program, developers should improve the program’s quality as much as possible. While it's impossible to improve every aspect of the program’s quality upfront, there are clear advantages to developers conducting their own tests. Conversely, there are some disadvantages to having QA teams do the testing instead of developers. Let’s explore both sides.
Advantages of Developer Testing
Simple issues can be addressed immediately
You might think that "simple issues don’t need to be dealt with directly," but this isn’t the case. The sheer number of issues can make a significant difference. When there are many issues, decision-making becomes harder. The morale of the project team can decrease as the number of issues increases. The attitude toward large issues versus small ones can vary greatly. When there are many issues, developers become fatigued, and it becomes harder to assess which issues are urgent and which are not. The side effects of fixing immediate problems can be quickly corrected, improving the speed of resolution. Although ideally, issues should be fixed without side effects, in reality, this is often not the case.Saves time in documenting reproduction steps
Writing reproduction steps in human language, rather than code, can be a tedious task. It’s not just challenging to write, but information can be lost in the process. When the QA team finds an issue, they are required to document the reproduction steps, which can take a lot of time and effort. Developers are usually better equipped to know what information is needed and can generate the reproduction steps more efficiently, saving time and reducing information loss.Simplifies complex reproduction steps
In cases where testing requires complex initial conditions, it’s often difficult to set up these conditions without extensive effort. In the early stages of development, this is not as challenging, but as various modules and components begin interacting, the cost of setting up test conditions rises. Developers can minimize these setup costs by identifying the specific code or components needed and creating a simple test program that can quickly reproduce issues. This reduces the complexity and effort required for troubleshooting compared to having the QA team deal with the entire setup.
The Dangers of Ignoring Developer Testing
One of the biggest issues when developer testing is lacking is the increase in QA cycles. When issues are not caught during the development phase and are handed over to QA, the cost of QA efforts rises exponentially. While it might seem that spending time on testing as a developer is more expensive, the reality is that issues not addressed early in development result in higher costs during QA. It's akin to recycling—if everyone handles recycling properly from the start, it’s far more efficient than waiting for the final stage to sort through the waste. The effort of properly managing waste upfront is small, but the cost at the final stage is far higher due to the scale.
What Inefficiencies Occur When QA Cycles Increase?
Large reports need to be generated for each cycle
Every QA cycle generates numerous documents, including bug reports, quality verification summaries, testing results, and staffing breakdowns. While templates exist, the content must be filled in, and this can be time-consuming for both the writer and the reader. As reports grow in length, fatigue increases, making it harder for team members to effectively review these documents.Increased manpower needs
Coordinating the schedules of multiple people and ensuring smooth communication takes effort, and if a build doesn’t arrive on time, costs increase further. Managing these resources and ensuring that testing is done on time becomes an increasingly complex task.Time is wasted
QA cycles always take time, regardless of how long or short they are. During this period, developers should be preparing for the next cycle, but often, new specifications or requirements sneak in, causing delays. As a result, when the next cycle starts, previously undetected issues may appear, leading to more work for everyone involved.
Reducing the Number of QA Cycles Solves Major Inefficiencies
Each additional QA cycle increases the overall cost of getting a program released. The cost doesn’t just increase for the development team; stakeholders also experience the burden. The most effective way to reduce these cycles is through developer testing.
In Conclusion
The ultimate goal of both development and testing is to ensure high-quality software that is widely used. Reaching the point where a program is ready for mass use is the responsibility of the developers. Whether there is a QA team or not, developers have an obligation to ensure the software meets the necessary standards. Among the various methods available, developer testing is one of the most effective.