 |
|||
  |
|||
I took a 15% pay cut to move 3,000 miles to Greensboro, North Carolina. The pay cut was mostly offset by the difference in the cost of living, and the 3,000 miles cut about 2 total hours off my commute each day. If you sit down and do the math, that's like getting another week's vacation every month. There were a lot of other quality of life benefits to moving here. My mission this time was the same as it was a Legent: build a QA department from the ground up, this time for a cellular telephone billing system. Vanguard at least had a QA department in name. It had some test equipment, and even some processes in place. What it was mainly missing was people. We also had a deadline; Y2K was approaching and we needed a to be able to test it and our new products as well. The answer lay in getting the right people and building the right test tools. People was the hard part. I had a very difficult time trying to recruit people, and eventually wound up taking people from training, customer service, and other parts of the organization and training them to be quality assurance analysts. I built the team around two senior analysts plus a new hire who could provide "lite" Unix-systems administrator / Oracle DBA services. The system we set up was an exact parallel to the production system with true directory structures and links on a file-by-file basis. This configuration allowed us to manage as many individual environments as we wished. We could change individual files, keep the rest of the structure identical, and use little more than enough disk space to hold a single system. We borrowed some programming help to build us a call record generator. We could create a call scenario in a spreadsheet, save it as delimited text, feed it as data though the program, and the output would look like a stream of data coming from an actual telephone switch. The tool allowed us to create highly customizable data and was superior to, and cheaper than making real test calls on real switches. For example, we could place a call of exactly 59 seconds duration or start a two-second call that spans over a time of day rate change boundary. We created several test markets containing hundreds of customers making thousands of calls. We could simulate inter- and intra-carrier roaming, and fraud calls. And in the end, these same customers, making these same calls, produced the same bills over and over. It was the key to success for regression testing and even allowed for some "what if" type of game playing. Most of all, it was the basis for our Y2K testing. Our base year was 1997 - the next year that was a mirror image was 2011 - that is the julian days (used by the switch to record call records) matched the day of the week (used by the rate plans for things like free weekend calling). We aged the data for activations and payments (so things like people being 30 days overdue were still 30 days overdue and not 14 years overdue), and had these same people make the same calls. We moved the machine into the future, and ran the bill. The expected result was that the bill was to be identical to the baseline except for the bill date. We also ran some other special tests for leap year, 9/1999 and the "Happy New Year's" call which started at 23:59 on 12/31/1999 and ended at 00:01on 1/1/2000. There were concerns about being bought out by AT&T (again). Although they liked our billing product very much, they were not going to cut over their existing client base to it. It was about this time that my former boss at Vanguard recruited me to iWork software.
|
