While my relocation to Oklahoma was greeted with cheers on the personal side, my parents lived two hours away and my kids were glad to be close to Grandma and Grandpa, this would be a new adventure in my career. I was about to experience the world of software, testing avionics software for a military bomber. What was I thinking?
Used to laying hands on pipe, wire and equipment, I had no experience with bits and bytes. Computers were still used only for word processing, glorified typewriters actually, and I didn’t give the software driving the computer a second thought. These days preceded Microsoft; the term ‘reboot’ referred to a change of shoes.
I moved into my job cautiously, trying to absorb everything I heard and read about the avionics system. I discovered the projects were run like any other project I’d executed. The lingo differed and after some coaching by my new software friends, understanding started to fall into place.
My job involved creating procedures and testing the developed software in a lab environment that simulated the actual aircraft environment. Avionics software includes the navigation, radar and weapon delivery systems. Weapon delivery became my specialty and I spent many hours in the lab bombing the heck out of various parts of the globe.
My test methods proved successful and groundbreaking. I asked for and received permission to use video to assist test analysis. Program success is measured in large part on the user interface, the information presented to the operator. Sure the weapon needs to make its mark, things like collateral damage are frowned upon, and the software contains calculations for many algorithms to guarantee that happens. If the data provided on the screen to the airman is erroneous or non-intuitive, then his job just became more difficult. Think of websites that you’ve had trouble navigating (there are a lot of them out there).
The bomber uses two crewmembers to both execute offensive maneuvers and defend the aircraft. The lab line provides both ‘sides’ of these stations and while they are in close proximity, it is difficult to witness everything on every screen at the same time. Our analysis tools failed to provide a view of the screens to replay to the test analysts and software designers. Videotaping became the next best thing.
My anal nature that certainly engineering has helped me develop came in handy working to find problems in the software. My mantra is thoroughness, investigating not only what I call ‘the go path’, the perfect scenarios, all systems go, that kind of thing, but also the resistant paths: setting up for failure to see if the system responds. Therein lies the STPRs, Software Test Problem Reports.
Armed with my procedures and video camera, I attempted time and again to ‘break’ the software. I wasn’t actually breaking it, just discovering problems that existed but may be hard to find. The number of STPRs that I wrote measured my success. Each problem received its own STPR. I wrote a lot of them. On a typical day, I wrote at least twenty STPRs. Software design loved me.
Once in awhile the designers would claim the software was working as it was meant to be. In these instances, the STPR status reflected ‘Mechanization OK’ or MOK. To a tester, these three letters might as well have been the kiss of death. I protested until my anal nature conceded that sometimes the designer was right. But not often.
I wrote more STPRs than anyone preceding me. I’m talking hundreds of them, with very few of them MOK. I did my job and when the project was done, prepared for the next one.
The management conducted meetings with everyone in the program on a quarterly basis. The program at that time had about fifty people including systems, software and test engineers and other support personnel. These meetings are boring for the most part; in addition to a speech about how great we all are doing and an outlook for future work, awards were given out for various accomplishments. Most of these ‘accomplishments’ are nothing more than people doing their job and very few go above and beyond, in my opinion. It’s fascinating what people are awarded for. I’ll go into that in more detail in a future post.
My lead engineer, Joel, took vacation the week one of these meetings was scheduled. I was surprised to see him before the meeting with his toddler son in tow. Surprised, but I didn’t dwell on it. And so we all sat and listened to management drone on and on about the program. Finally the awards part of the show started. It was almost over. Or so I thought.
Joel stood at the front of the overflowing room and began to speak about a top performer. I half-listened until I began to feel the stares of fifty people. Joel was speaking of me and it appeared all of these people were in on it. I felt my face turn red. I was still a few years from menopause, so it wasn’t a hot flash.
At the end of his speech, Joel announced a special award for me, the crowd applauded and I made my way to the front of the room. I received a chunk of acrylic with the corporate logo on it, but Joel had another surprise for me. He told me, in front of my co-workers, that he had collected money for a t-shirt to commemorate my achievement. In fact, he collected more money than needed and had to turn people away. Then he unfolded the t-shirt.
The program manager made a remark that he hoped a discrimination or harassment complaint wouldn’t be filed. That was the furthest from my mind. I couldn’t believe that my co-workers had expressed this love for me. Now this is an award I can appreciate.
The t-shirt remains one of my most prized possessions. I’ve never worn it. Are you kidding me? I wouldn’t be caught dead in that thing!