ISDN PRI
With the decision by Nortel management to develop ISDN PRI in-house came the need to identify development and test impacts. The schedule was very tight and as verification technical lead for the group, much work faced me with little time to do it.
I was able to get one engineer regarded as an expert at DMS-10 administration (database translations) to identify test impacts in the administration area. Another engineer identified trunking and AIN impacts. I would focus on the ISDN PRI layer 2 and layer 3 protocol verification as well as SS7 ISUP protocol verification.
Our test document would then be provided to individual testers as they rolled off ISDN BRI. The basic idea being that they would read our document and review their station feature test plans in light of our document summarizing the scope of work, areas impacted, features impacted, an indication as to the degree of impact and an estimated number of tests required for that particular feature. Having read the document, they could come to us for clarification.
During this time, I was also busy installing and provisioning Meridian Option 11 PBX's in the lab as well as writing an initial suite of layer 2 and layer 3 protocol test scripts. The database I designed for the lab PBXs was actually adopted and made an official product by Nortel. See Option 11 database productized for details. During this time, accomplishing all of these tasks required seriously long hours and they would only get longer before the project was completed.
As the day came to begin testing, we already knew shift work would be needed 24hrs per day. With the experience from ISDN BRI still fresh in my mind, I insisted to the supervisor that none of the team experts be assigned the same shift. We needed to be spread out across all shifts so that no one on any shift would find themselves in the lab late at night without support.
The full schedule from start to completion of testing was about 8 weeks, I can't remember exactly. During this time, compliance testing at Bellcore/Telcordia would also be taking place. Unlike at Siemens where I travelled with a PBX to the Bellcore/Telcordia lab, or to the AT&T facility for conformance testing, Telcordia actually had a DMS 10 onsite and there was no need for me to travel there. Normally, compliance testing should be done late in the test cycle but scheduling did not permit it. Telcordia did identify a few defects but since the schedule was such that we were testing in parallel, this was not to be unexpected. In any event, they found no defect of significance.
On a daily basis, the Telcordia contact would notify me of test issues which I would investigate and attempt to reproduce. There was a daily meeting with managers to go over these issues. I could have arranged that I not be on midnight shift at the time but chose not to. So, my days during this time were averaging 14 - 16 hours -- sometimes more. I tried to arrive a little early for my shift so that I could assist people on the prior shift before they had to leave. I also stayed late in order to provide support to engineers on the following shift.
Not long after Telcordia conformance testing had completed, we began preparing for the arrival of the GTE acceptance test team. While we had not yet fully finished testing, enough tests were behind us that GTE was willing to continue. What their people would do is from each area, choose tests and have the responsible tester demonstrate the test. Upon completing their tests, the GTE people were heard to express amazement at having not encountered any defects.
By the time GTE formally accepted the product, all internal tests had been executed and passed. All that remained was cleanup of documentation and placing documentation and test scrits under configuration control.
As the product began being delivered to customers, a certain uneasy quiet set in amongst the field support team because no issues were being reported in the field. The cards were plugging in, layer 3 was correctly being established. Not a single defect came back from the field on that product -- a product that sold like hot cakes.