Task 9.1

A recent CIO magazine podcast featured a discussion by Meredith Levinson discussing her top 20 tips for software testing. Follow the link on the week 9 panel for the unit and listen to the podcast. Make a critical summary of Meredith Levinson's top 20 tips on software testing (3 value points, 5 individual points, 5 implementation points). Post the summary on your blog.

Levinson acknowledges that testing is not only essential but is the most critical part of the System Development Life Cycle. The problem however, is that it is also:

• The most overlooked
• The most underfunded
• The most rushed

Levinson has therefore compiled a list of 20 tips that aim to improve software testing.

The first few points seem to revolve around social understanding:

1. Respect your testers
2. Raise testers’ awareness of their value
3. Collocate your testers and developers
4. Cross-train developers and testers in each other’s roles
5. Tell programmers to chill out

Firstly, it is important to make sure that testers are aware of the importance of their work and the impact it has on the company. Simply doing this can help improve testers’ morale. It is also a good idea to hire qualified testers (particularly those that have programming skills) as they will gain more respect from system developers which, as Levinson points out, is a good thing as it helps reduce the gap between these two. Testers and developers are often on opposite ends of a stick because of the fact that testers are hired to find faults in developer’s work. This brings us to Levinson’s 5^th point to “tell programmers to chill out”. Developers must be assured that if they are doing their work to the best of their abilities and continue to learn from their mistakes, then errors found in the code will not be held against them in performance reviews.

Another way to ensure better cooperation between testers and developers is by having them interact with one another face-to-face. Personal communication aims to reduce grudges against one another. Cross-training is also a good way to improve their understanding of each other’s jobs (thereby improving relations). Moreover this leaves each group with a better understanding of the larger system development life cycle and more importantly, the importance of what they do and its impact on the overall system.

Focusing more on the testing team now, Levinson proposes to set up an independent reporting structure, more specifically, independent of the development team. This prevents the development team from attempting to hide or deliberately keep errors away from testers in the hopes that they remain hidden.

Centralizing test groups and dedicating testers to specific systems allows them to share their experiences, stick to their own set of methodology and have an in-depth understanding on of each other and the system they are allocated to.

Getting stakeholders involved in some way or other is also part of Levinson’s guide to testing.

• Giving testers business training for instance gives them a better understanding of the system they’re testing.
• Involving business users in testing help ensures that the system meets their requirements.
• Involving network operations can help identify performance issues that may originate from the way a hardware or software is configured.

Having tests in a locked-down environment and/or building a lab that replicates the business environment are also ways of improving testing techniques. A closed testing environment can prevent unwanted people (such as developers) from interfering. Having a replicated environment of course means testing in situations as close to the real situation as possible thereby reducing the number of errors.

Testing the old system with the new is one way of determining how much better the new system is in comparison with the old. As Levinson states, “some new projects may contain the same functionality as previous projects.” This can also help ensure that codes still work properly in spite of new features. Moreover this helps identify where new test cases need to be added. Ensuring that test cases are run against any code that developers have changed or added (or code coverage) is another way of reducing error rates. Code coverage tools can be used to track the number of new or modified lines of code that have been tested thereby giving an idea of how effective the testing is.

Other tools are also available to, for instance, scan source code for known problems like the fact that doing one thing a certain number of times always leads to the same problem; or to identify patterns in data to identify the root cause of certain problems.

Establishing quality checkpoints or milestones throughout the entire development life cycle can also help reduce errors as it brings about a culture of quality within its development and testing groups.

A mathematical technique called class partitioning can also be used to identify additional functional requirements as it provides testing a clear picture of the type of test cases they need to do.

And lastly, despite taking all the extra steps above, it is always best to also develop a Plan B. Preparation in particular, for the worst case scenario.