These days, even in the industry, there’s a big push to embrace Test Driven Development, right? Today, let’s dive into test methodologies from a maintenance perspective. 🔍 When discussing tests, the ownership debate is inevitable. Who should own the tests: the system or the business? Before I share my personal take, let’s first explore the essence of testing.
Whether it’s new system development or additional maintenance, it’s crucial to complete testing on the final application to confidently say testing is done. Ensuring it works in real-world scenarios is paramount. Developers naturally test as they build, because developing without testing—no matter how minor—isn’t really feasible. How effectively these tests are done will determine the user’s experience during the testing phase. 🛠️
TDD is all about developers crafting unit tests for each module to ensure clarity in their work. This approach allows for reusing test codes and measuring their coverage, giving a quantitative view of unit test levels. But, does simply creating test codes for every module enhance the application’s quality? Looking at the bug rates post-release between projects using and not using TDD, it seems effective. However, what’s crucial isn’t just the test code coverage, but how TDD is applied to the specific application. We can expand this discussion to cover the entire testing process.
For both developers and business professionals, the key to effective testing isn’t just about techniques—it’s about understanding the business within the system. Applying this to developer unit tests means first grasping the structure of each business logic.
Personally, I believe designing a test framework tailored to the business or system architecture is more impactful than applying generalized methodologies. Especially with limited maintenance resources like in the industry, focusing and choosing the right path is essential. Even with TDD, it requires 20-30% more effort during development, making it challenging to enforce in maintenance. This could lead to higher fixed costs for staff, which can be daunting. Thus, crafting a method suited to the system’s structure or business seems to be the way to go. Not all applications are TDD-friendly; for those that frequently change data, TDD might be more cumbersome than beneficial. If necessary data is missing, you can’t run test codes. In industry systems, which are mostly management systems, such considerations are always present in both TDD and general tests. 💡
From a personal standpoint, user-level business testing holds the utmost importance—assuming developer unit tests are a given. I am keen on finding ways to achieve big results with minimal effort. Two key factors are essential for maximizing effectiveness: a well-constructed test framework and automation—hardly a new concept. 🤖
To create a tailored test framework for a project or maintenance, one must consider the overall business understanding, past experiences, and the architecture of the systems involved. This process identifies focus points for efficient testing. I don’t believe every system needs a built-up and applied test methodology. Some businesses are straightforward, with minimal errors, low usage, and little business risk. Unlike typical IT companies, the industry doesn’t just run one or two systems. Facebook, for instance, only manages the Facebook app. However, for systems handling core business in the industry, it’s essential to conduct such thorough work. After all, it’s these businesses that sustain the company. 💼
Once the test framework is defined, it leads to a suitable automation plan. Automation interests all companies, with many already using RPA and relevant solutions. However, relying solely on test solutions can hit many roadblocks, especially when database tests are involved. In such cases, developing specialized test applications can complement and enhance the process. For example, verifying figures in generated PDF reports via RPA can be database-intensive and time-consuming. Designing the functionality with MVC to ensure no logic in the UI control layer and creating a service-level data verification app might be more efficient. Conversely, RPA is more effective for testing actual UX and application functionality. About a decade ago, I designed and developed a test application for efficiently maintaining a core business system, which is still in use today. 🔧
Initially, we discussed test ownership. In development, delivering an error-free system is fundamental. During business verification, discovering and correcting misunderstandings in business logic or operation mechanisms that developers might have is what business-side testing should address. Thus, while the business owns the final testing phase, developers must ensure development quality so only necessary tests are conducted at that stage.
Ultimately, if development isn’t done right, a well-defined test framework won’t be enough, and the journey will be long. 🚀
Leave a Reply