Task 10.2

Write a blog entry summarising the major points made by Malcolm Gladwell in the video showed in the lecture (from the Ted conference). Can you relate his main points to some aspect of IT system design - for example, documentation. Value points 2; individual points 2; design points 2.

Malcolm Gladwell made some very interesting points regarding the power of choice and the way the spaghetti sauce industry along with the whole food industry in the United States tried to establish "universals" for each food. Companies at the time (around the 1970's) were trying to find the "best" recipe for their specific foods.

Gladwell explains that although statistically there may be a "best" option for a food recipe, it still leaves a considerable amount of people unhappy with the project. Sure, the majority may be satisfied but what about the others?

Variability was the solution, in this day and age, as Gladwell explained, we look for variability in all things and then try to come up with solutions for a range of variables.

The idea behind the variability in food can be applied to the IT industry as well. There is no one solution in which will meet all other user's expectations, we too in the IT industry must (and do!) harness the idea of variability within products. Which is why a lot of the time a company would rather have a system built for them than purchase an already built program off the shelf.

The assumption in all things is that people know what they want, when in actual fact people very rarely know what they want because they're unsure or oblivious to what is actually available. This is why we use prototyping within the design stage, sometimes a client will not actually realise something is possible within a program or system until we show them.

Task 9.1

A CIO magazine podcast featured a discussion by Meredith Levison 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.

Meredith Levison describes the testing stage as the most overlooked, underfunded and important factor within a system's development. Although such statements are unbacked by anything but her own opinion it is easy to understand why such statements would be made.

Meredith starts the top twenty tips for software testing with the suggestion of using educated and experienced testers instead of using testing as an entry level job (which it is in most companies Meredith claims). As a result, it is argued that poor testing practice and outcomes is caused by this entry level mantra within companies.

Raising tester awareness of their value is brought up next, Meredith states that testers should be aware of their importance within the company and that good quality work achieved by them can actually save a considerable amount of money in the long term. Statefarm insurance created a website which highlighted the defects testers and developers found and fixed early in development stages and how much money they saved in the end. Although I do agree with this, you don't necessarily want the testers to think that they themselves are purely responsible for such large amounts of money saved. Which brings us onto the next tip.

Co-locate testers and developers to avoid confrontations and feelings of disdain between the two groups. Testers and developers are usually at each others' throats within the workplace as the tester's job is to break code in which the developer has coded. Although some may thing that some kind of rivalry may encourage both groups to work harder, it more likely impedes productivity. Meredith also mentions about how physical communication can significantly lower such feelings of resentment between the groups, especially when working closely together.

Cross training developers and testers in each others' fields also would have a great benefit I believe. As soon as the groups have spent a small amount of time in each others' shoes I can imagine a greater understanding and appreciation for each group's work. In turn, which Meredith thinks will create a better application in the end.

Telling programmers to chill out; this is something I can understand. I quite enjoy coding myself and I can only imagine the rage which would be summoned inside myself if a tester broke my beautiful new line of code which was supposed to be unbreakable. Tensions would most definitely rise, mainly on the programmer's side when their code was tested to failure. Once again, the previous strategies for keeping the two groups close should be revisited as I do think such a working environment would help deter persons from hateful feelings, whether it be towards testers or programmers.

Independent reporting is a good idea, but just how realistic getting the CIO or an external overseer to review the reports in detail is unknown. I believe that there may be a conflict of interest if the developers are the ones doing the reporting, just as there would be a conflict of interest if the testers were doing the reporting.

A centralised test group is a fantastic idea, the sharing of knowledge and past experiences would greatly benefit the testers as a whole. Functional testers are deployed to a project and then return to a centralised group afterwards. Meredith argues that if the group wasn't centralised, testers would have their own individual methods and wouldn't necessarily learn from the past mistakes of others. I can completely agree with this and believe that although some testers are going to be better depending on the application at hand, they should all return back to a centralised group.

Continuing on from the previous centralised tester group idea. It's important that separate groups have their own specialty (one set of systems) which means there's a higher understanding of the system at hand and also because of this greater understanding the testers can sometimes include tests which might have been overlooked in the general testing regime. Meredith uses the example of eBay stating that the company has three separate testing groups; one for site functionality, one for payments and one for data warehousing applications. The IT industry is no stranger to specialisation, I believe that such practices can only benefit the company overall.

Meredith talks about the benefits of having testers participate in business training, Station Casinos makes members work the front desk, the casino floor and different business departments in order to have a more full, well rounded understanding of the business as a whole. Although this is a good strategy, it may not be feasible or even necessary for most businesses. I believe that specialisation for testers should be a considerable amount of experience within a certain application/department.

Involving business users in testing means that the system which is being developed is meeting their requirements. Not only this, but incorporating the end user as a tester can reveal potential problems or workflow issues which would not have been identified otherwise. I believe you should always incorporate some kind of stakeholder within the testing process for this exact purpose.

Involving network operations can help identify unnecessary network usage or unexpected network traffic within a system. Also this means that certain tests can be ran to ensure that the network can deal with any new traffic in which the proposed or developed system will be creating. This is a great idea, most corporate applications these days would most definitely utilise network infrastructure, so it is important to consider such things when testing.

Testing labs can also replicate the environment in which the application will be used, Meredith gives a good example of Station Casino creating a test lab which resembles that of a mini casino. I can understand the thought behind creating a similar environment as to that of the application proposed use environment, but recreating such an environment could be costly and most of the time unnecessary.

Developers shouldn't be let into the testing environment as they'll want to change the problematic code straight away. This will cause problems because the new code won't necessarily be recorded and therefore retested if such a situation arose. It's better to completely lock down the testing environment until such tests are complete. Then you will know what has been tested, what has been successful and what hasn't. If coders were running into the test environment continuously to try and correct code it would not be a good environment for controlled testing to be conducted in.

Testing the old with the new means that old, already tested features of a system aren't interrupted when new features or functionality is added. This is essential to the overall success of a product, users are quite often enraged when one function is added to a system which in turn renders a suite of older functions unavailable or buggy. To avoid such poor acceptance this really is an essential step when adding onto an already existing system.

Ensuring that test cases are ran against any code which has been changed or added is also an essential task. Referring to the last two points, this is an important step as modifications very often lead to bugs within applications. This process is called code coverage.

Scanning source code for known problems using third party software is suggested by Meredith. Although such software can be helpful, coder's shouldn't be causing problems like memory leaks and other such nuances in the first place. A lot of Integrated Development Environments or IDE for short usually implement live debugging of commonly known problems already. Depending on the IDE you're using along with the development team's experience would depict whether this step is necessary or not.

Identifying patterns in data about defects can be a good step in order to identify root causes behind these defects. Although Meredith suggests an analysis tool, depending on the size of the system would really depict how relevant this tip is.

Using quality checkpoints in the system development life cycle or SDLC is suggested Meredith to ensure high quality outcomes through communication between teams. I don't necessarily think this tip is essential to the success of a system. Although feasibility should be considered, most of the planning and analysis should be done by those who are employed to do so, I don't believe that checking the previous team's work would produce a much better outcome.

Applying equivalence class partitioning is used to find overlooked system functional requirements. It is supposed to give testers a clear picture of how many tests they're required to run to cover all the system functions.

Developing a plan B can help when applications fail regardless of how much testing how been applied. A backup plan needs to outline what is going to be done if the worst case scenario occurs. Usually a migration back to the old system would be the Plan B for many companies. Whether or not this is realistic or feasible also depends on the company.

Task 6.2

(click to enlarge image)

The Deepwater Horizon oil spill, also referred to as the BP oil spill was an oil spill in the Gulf of Mexico which flowed for three months in 2010. BP released a video (frame grab above) in which the Vice President talked about BP "ramping up" their oil collection efforts.

Looking at the graph we see a steadily increasing bar graph, at first glance the audience would assume that BP is increasing it's efforts and actually collecting more and more barrels of oil over time, this is not the case. As the graph states, the vertical axis it is the cumulative amount of oil collected. Of course the overall or cumulative oil collected by BP would be increasing over time, the only time it wouldn't be is if they stopped trying to collect up all the leaked oil in which the graph would plateau. In this example we can clearly see that BP has deliberately formatted their results into this bar graph in an order to mislead people.

If the results were put into a line graph the outcome would look a lot less favourable; looking at the bar graph, we can gage the amount of oil actually collected per unit of time by comparing one bar's value with the one that precede's it.