After graduating with a degree in computer science, I found a job in Boston’s Chinatown doing software QA. I had told myself that this was a stepping stone to development work, and it was! But my years as a programmer was in turn a stepping stone back to software QA. This first job was back in the late ‘80s, the early days of desktop publishing. If you think about full page car ads in the Sunday circulars and the state of desktop publishing, you can understand the technology challenges of the day, which were in turn the challenges of my first real job in IT. So, between lunches of lemongrass chicken or vermicelli-bun with beef strips and spring rolls at Dong Khanh (still there and still delicious), I began my illustrious career somewhere between software, QA and publishing, a mix I’ve continued to this day.
The first thing I learned was that well-detailed bugs get fixed, while vague bugs neither get fixed nor get eliminated as potential duplicate bugs. If QA cannot determine the steps, Development has no chance. But by giving sufficient detail (which sometimes meant viewing the code and entering the actual code patch), my low-hanging fruit became a welcome sight to any programmer with a fixed bug count deadline. As a result, I easily had the highest number of submitted bugs to be fixed in the entire QA department.
The second thing I learned was the importance of boundary testing. When I found a very short system constraint list, I volunteered to take it over and to greatly expand what it tracked. Certain interesting workarounds quickly became apparent. For instance, you could only have 1,024 objects on a page, but you could be creative about breaking an object into subcomponents which could be used like multiple objects (a box was 4 sides and 4 corners, which could be dismembered and buried around the page). Using a similar trick, a crossword puzzle could be published as 2 objects (the squares as a Dingbat textbox, and the numbers as a tabbed textbox), instead of many lines, black boxes, and floating numbers.
The third thing I learned was that siloed departments was bad. I talked to programmers about internal structure, and to trainers about what the users were being told. Somehow, this was the main method available to discover what the new features were, how they worked, and any interoperability I would need to know. By volunteering to attend classes with trainers, I became a vector for QA to gather information about new release features. The details did not seem to come from an organized process for QA to be able to use; the formal procedure was that we had to figure out “what was expected” on our own. The test plans were limited (I’m not sure where they came from – they may have just been for regression), and we had to do a lot of exploratory testing to compensate.
I still have fond memories of the people I worked with there, and the lessons I learned by example, although sometimes it was from my desire to avoid the example and build a better technique.
Do you have a “3 Things …” from your life in QA that you need to share with the world? If so, email it [email protected], so you can tell your story too.
