2. Use Peer Reviews to Take Advantage of Resources You Already Have
Peer review is when the author of a program and one or more of their colleagues sit down and examine the code in order to detect and correct any issues within. This method is often used in literature between writers and editors, and the principle is sound. A fresh pair of eyes will often catch mistakes that the author themselves would otherwise miss.
Peer review is generally considered the cheapest, easiest method of early bug detection. It requires no additional hardware and gives developers a chance to practice their skills and help each other learn, which in turn can prevent similar mistakes in the future. This testing also happens very early in the development phase, meaning that bugs can be caught before they become expensive (and stressful) problems. Inspection is even faster than automated testing, as studies have shown that developers can find defects in code 3-4 times faster through inspections than can be found through testing.
Worried that taking developers away from their own code to do reviews will reduce productivity? Don’t be. Inspections expert Tom Gilb reports that “each defect uncovered by peer review can save up to nine hours of work when compared to having to find and fix a defect later on in the cycle.”
3. Complement Reviews with Quality Testing Practices
Skills essential for a good software tester. Image courtesy of Guru99.com.
The two aspects of software testing. Image courtesy of dotnetcurry.com.
There are two major forms of software testing: automated and functional. Automated testing is when a tester uses a specified debugging program to run through the code. When the debugger is finished, it returns a list of the code sections that are passing or failing the checks. This method of testing is good for finding spots where code simply isn’t executing properly, and leaves the tester free to work on other projects while the test program is running.
There are times, though, where automated testing can be fairly inefficient. For example, if one aspect of the code fails, the debugger usually immediately stops checking that section. If there is another error further down the line, it will be passed over until the initial defect is corrected.
Functional testing, on the other hand, is when a person or group of people sit down with a working version of the software, and test individual aspects manually. This is where most system performance and user interface defects are identified, as developers get to see the software in action.
Functional testing also serves to test the outcome of six essential criteria (source: Wikipedia):
- It verifies the functions that the software is expected to perform
- It creates input data based on the section of code that is being tested
- It determines the output of the section of code that is being tested
- It ensures that the test case executes correctly
- It demonstrates the difference between the actual output and the expected outputs
- It checks whether or not the application works as per the customer need
Functional testing, of course, runs into similar concerns as those tied to peer review regarding time, resources, and developer involvement. Since it’s a manual form of testing, a human needs to be present to navigate through the software and to record errors, specifically what they were doing when the error occurred, and the steps required to recreate the error.
While each of these suggestions is a powerful tool individually, the best way to improve your software quality is to use all three in tandem. Using these three methods of catching defects in your software will greatly improve its quality before it even gets passed to QA.
Next week, we will go more in depth on the various methods of peer review, so make sure to subscribe!