Since you are now an expert on testing and SQA, you have been reassigned to a different group in your division. That group is quite notorious for producing products that have maintenance problems. Because the group has been profitable, no one really cared to change the group's development procedures. But now your company has competition in this sector and the VP of Software Development has decided to tighten the reigns. The VP declared a goal of reducing bugs that are delivered to the customer by 50% and reducing the total project costs by 15%. The bean-counting accountants and the marketing weasels assure your VP that meeting those goals will drive the competition out of business before your company loses market share.
The team with whom you now work produces semi-automated inventory systems. A typical system includes RFID scanners in the warehouse, web-based reporting of inventory levels, automated email alerts when an inventory item is getting too low, automatic ordering, etc. The top selling point to customers is usually the slick custom reports that the system can produce.
Your company has an agreement with a small RFID provider, so you use their RFID hardware and software. Your new group also bundles in an open-source database system and report writing system in order to keep the cost down -- and also to avoid having to work around Oracle's monster system. Since this group has done over thirty of these projects, the programmers have a bunch of code that they like to reuse.
At the bottom of this page is the standard development schedule. Note that the weeks are not necessary consecutive. It depends on when people are available. When not in "development mode", the group responds to "maintenance requests" from older customers. Priority is always for responding to new customers!!! We want to make sure that we get new customers on the hook, we are not worried about losing existing customers.
For the first two weeks of a development project, the two requirements people find out what the customer wants. The two requirements gatherers (Sue and Bob) are pretty good at talking with customers, including the clue-less managers, the blue-collar guys on the dock, and, most importantly, the old secretaries who really know how things work.
About the second week, the four programmers (Zack, Tim, John, and the other Bob) know enough to start building a design (also usually a modified version of a past design). They start with designing a hardware layout for the RFID readers, monitors and printers for the customer's warehouse, etc. Then they figure out how this system is different from the last system installed. By the forth week, coding can start. Everyone knows to stay out of the four geeks' area during that time. Just throw a pizza over the cubicle wall as you leave for the day - they do their best work around midnight.
Once the coders emerge from their cave, and after they shower, all six team members start playing with the system to pound out obvious errors. Sue and Bob have an ability to think like end-users. The four programmers enjoy testing because they get the chance the break each others code.
Note, there is a seventh member of the team. Dave is technically considered the team's leader, but he is often found on the golf course with a manager from the customer's company. But, Dave does love for the group to make weekly status presentations to him.
After eight weeks the software goes to the customer's site. Dave judges how well the development went by the height of the stack of pizza boxes. If the customer had a lot of specialized requests, then the pizza boxes could be as high as the cubicle wall. If there are no boxes and the four geeks are discussing their marathon online game sessions, then Dave is happy that the project is going so well.
Sue and Bob start training the customers. Zack, the youngest programmer and the only one who owns a tie, always goes to the customer's site. He hangs out in the IT office watching for problems. When errors pop up, he gets on his cell phone to the other three programmers who hack out a patch. Zack installs the patch and waits for the next error to pop up. Zack is also the fastest typist. The team likes to say that problems that the customer does not notice will not hurt them, or us.
After a few weeks of this, the system runs enough to be useful and the customer accepts that the system will crash once a week. It really helps that Dave always tells the customer's managers to expect this level of operability. Of course, he doesn't use the word "operability", and his comments come as subtle comments made while on the golf course.
Hopefully, the system will not decide to order 1,000,000 cardboard boxes instead of 10,000.00 boxes, which seems to happen a lot. Compatibility of the software with the customers' hardware and operating systems is another frequent problem. It always amazes Zack how many different web browsers that people use. Surprising to everyone, the new inventory system's interaction with the customers' other software systems is usually bug free. Getting different databases to share data seems like the most complex part, yet it almost always works perfectly after just one week of tweaking.
Since Dave is now under huge pressure to improve his group, he is willing to take your advice. After all, you are an outsider, so that makes you an expert.
A friend of yours who knows all the personalities, recommends not trying to shoot for CMM level 5 right from the start. It is agreed that a formal test plan would make a nice first step that would be acceptable to all involved.
Your assignment is to produce an outline of an appropriate test plan. You meet with Dave tomorrow morning at 9:00am.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | |
| Sys Req Gathering | ||||||||||||||
| System Design | ||||||||||||||
| Software Design | ||||||||||||||
| Coding and Component Integration | ||||||||||||||
| Testing | ||||||||||||||
| User Guide Creation | ||||||||||||||
| Installation and Training | ||||||||||||||
| Production Testing |