Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy : Chapter 9

The author discusses about how to manage risk and bugs in software development. The author divides risk management in following

1. Risk Assessment: The author suggests to brainstorm a list of things that might go wrong for risk assessment including things that might impact the cost, schedule or quality of the product. The author then asks the reader to order the list of risks based on importance. This is achieved by assigning probability and cost to each risk and multiplying them to get the impact.
   
2. Risk Control: After the risks have been identified and prioritized, the author advises to create a risk management plan where the reader needs to specify what he is going to do to mitigate the risk.
3. Top Five Risks List: The author advises the reader to maintain top five risk list including its previous rank and how long the risk is on the list.
   

The author then discusses about Bug Triage, a term that refers to prioritizing bugs based on their criticality and decide on what to do about them. The author then provides following list of resolutions that can be applied to bugs:

• By design
• Duplicate
• Postponed
• Not reproducible
• Won't fix
• Reassigned
• Fixed

The author then discusses different types of software testing such as:

• Unit Testing - This is done by developers to ensure a function or unit is bug-free.
• Functional Testing - This is is carried out by testers to make sure the application confirms to the requirements and specifications.
  
• Conformance Testing - This ensures the application confirms the industry standards.
• Compatibility Testing - This ensures that the application runs in different environments including hardware, operating systems, browsers etc...
  
• Performance Testing - The goal of this testing is to identify performance issues and creating benchmarks.
• Stress Testing - The goal is to identify how the application fails when it is subjected to excessive stress. It involves simulating large number of users, low RAM, CPU contention etc... to make sure the application failure doesn't result in damage to operating system or data loss.
  
• Regression Testing - This involves making sure that new features didn't break the existing functionality.
• Smoke Testing - This involves running quick tests to verify that major features work.
• Black-box Testing - The testing of components is done based solely on their interfaces.
• White-box Testing - Internal behaviour of the components is tested with full knowledge of the implementation.

The author provides some tips to effectively test the application when there is no separate quality assurance department. The author also suggest to take every bug as a learning experience rather than as a deficiency in coding skills of a developer.

The author then provides following tips to create a test network:

• Buy pre-assembled machines
• Buy name brands
• Buy serious development hardware
• Store data separately
• Keep drive images
• Use virtual machines
• Use KVM switches
• Get your own domain
• Use a firewall
• Set aside test machines
• Set aside a build machine
• Use a mix of machines for testing

The author then discusses about bug-tracking tools. The author then provides a list of issues to consider while deciding on a bug-tracking tool:

• Price
• License Fee structure
• Cross-platform availability
• E-mail notification
• Allow outside access
• Allow custom information
• Differentiation between bugs and feature requests
• Integration with source code control and requirements tool
• Flexible workflow
• Storage Format

The author then provides an example bug-tracking tool and how he used it to track one of the bugs for his own application.