There is a great misunderstanding when it comes to software. Many developers, managers and other leaders share in this misunderstanding. They often see a differentiation between \u201cproduction software\u201d and everything else, including test code. People agree developers should carefully design, model and test \u201cproduction\u201d software, but some of those same people seem to think non-production software doesn\u2019t need the same attention to detail.<\/p>\n
If that ever was true, it\u2019s certainly not true now.<\/p>\n
Our customers and users expect production software to function properly. When we design and build software, we work hard to make certain our software addresses the needs of the people depending on it. We ensure we properly apply the design model, engage in common practices of pair and ensemble (sometimes called mob) development and code reviews, and review the design and examine database calls for accuracy.<\/strong> We test the code.<\/p>\n If we use test automation<\/a> software to help test production software, should we not apply the same level of diligence to that software? We rely on the test code to correctly exercise and report on the production code. How is it not at least as important as the production code?<\/p>\n All software is created to support a business purpose. It may be for increased efficiencies, identifying possible opportunities, or other purposes. Modern software development<\/a> enables common practices which improve stability and drive value. These include using common design patterns which help maximize code reusability and simplify future maintenance.<\/p>\n We model customer-impacting software and use modular design techniques to reuse code efficiently.<\/strong> These common development practices help with better delivery and better overall application quality. They contribute to a better experience for the software application users. At the very minimum, the software we use to test the software needs the same level of attention as the production, customer-facing application.<\/p>\n When some people think about testing software, they focus on the obvious scenarios \u2013 they see a \u201chappy path\u201d and create test cases to get 1 to 1 requirements coverage. They may look a little deeper and consider how much of the code the tests exercise. Often, people don\u2019t consider the idea of line and branch coverage. A single trip through the possible branches is often the extent of in-depth testing. Many developers do not consider the conditions that might impact their testing. Rarely do they think about the environment they test in and the tools they use for testing until it fails.<\/strong><\/p>\n This is a problem and presents one of the main challenges of testing.<\/p>\n The challenge of testing software is not filling out forms, creating test plans or scripts or cases, or building the tool to test the software. The challenge is the hard thinking about how to do those things.<\/p>\n Some people look at testing as breaking software or approach testing as a box to be checked. A few celebrate finding a problem in someone else\u2019s work. At best, these ideas are counterproductive and weaken how teams work together.<\/p>\nMaking Software<\/h2>\n
Testing Software<\/h2>\n