Task 10.2

Gladwell’s video revolved around Howard Moscowitz and his impact on the food industry.

The issue was first noted when Pepsi came to Moscowitz with the aim of creating the perfect Diet Pepsi. As per traditional methods, Moscowitz went about his research by making large batches of Pepsi with different amounts of aspartame, asking people to sample them and plotting down the results in a graphical format to ascertain some sort of pattern. The problem however was that Moscowitz found no distinguishable pattern. While most researchers may not be bothered by this, Moscowitz was obsessed with trying to figure out why it made no sense.

A stroke of brilliance finally overcame him when he realised that the reason for those ‘messy results’ is: People have been asking the wrong question. Instead of looking for the perfect Pepsi, they should have looked for the perfect Pepsis.

Moscowitz finally got to implement this idea with Campbell and their spaghetti sauces. He created 45 varieties of spaghetti sauce according to all the different ways spaghetti sauce can vary from each other; sweetness, amount of garlic, sourness, ‘tomamoey-ness’, visible solids... From here he gathered people to taste the sauces and instead of finding the most popular one, he focused on grouping them into clusters. He found that Americans are fans of 3 main areas: smooth, spicy and (something that was not in the market at the time) chunky.

This method of collecting information is different from the traditional methods of asking people what they want. As Gladwell points out however, people don’t tend to know what they want. And even if they do, they don’t know how to communicate it.

Another popular marketing concept at that time was by creating hierarchies for products. In doing so, companies created the perception of luxury or higher standards for customers to aspire to. This concept of hierarchical marketing, Moscowitz points out, does not really exist; all products lie on a horizontal plane and can therefore only be segmented horizontally.

Overall there is no one perfect way to create the perfect dish. Moscowitz highlights the importance of moving from the idea of universals to understanding the idea of variability, and only in “embracing the diversity of human beings will we find a sure way to true happiness”.

This idea of diversity can also be seen in software development projects. No one program can be implemented to all systems and be expected to work very well. It is therefore up to system analysts to make sure that the system they develop is designed specifically to suit the needs of the users and their environment. The key to doing this is gathering the correct information during the analysis phase. Yes, this includes asking the correct questions so that analysis and recommendations can be formed according to the system’s capabilities as well as user requirements.

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.