I had my first taste with working with software testers during my first project where I was involved with porting an old system to a new version of the software. My first task involved porting reports which were to be generated by the users then printed out. The task wasn’t too difficult: basically you took the source code of the report (it was some weird binary format recognized only by the particular reporting tool – that was how it was done back in the day) and open it using the newer version of the tool, and the tool did some sort of migration magic to adapt it to the new format, then you just save it back again. You compile and run the report using the new format and verify that it’s getting the correct output (needs to be the same output as the old format), and that should be it. Most of the time, at least. Sometimes there were some things that the new format couldn’t handle, or maybe there were some minor compile errors after migration, but such problems were easily fixed, so it was pretty straightforward
Or so I thought. All the reports I was porting were being tested by one of my team members, who was also a newbie like me. Coincidentally, both of the testers I had on the project were also ECE graduates same as me; I was the unusual one who took the developer role. They had their own training focused on tester concepts, so initially I had no idea what to expect. When you’re fresh out of school you don’t have any idea yet how much iteration and rework goes into software development, so there’s this attitude of, “Hey it’s working. Looks good!” without being too thorough
I soon found out that the testers were trained to be very thorough, so I would get a bunch of bug reports. One of my testers would print out the reports, both the new format and the old format, and hold both reports up against the light, overlaid on each other. And they had to match, pixel-perfect! If the new report generated in a slightly different manner, that was a bug! (Of course, this made no sense to me, since logically the users wouldn’t care or notice if some column in the report was 1 pixel over to the right compared to the old format, but those were the instructions so whatever). And then they would use like really long nonsense strings in the data, and in some cases it would make the text wrapping in the report work differently, so I had to fix those too. Then one of the testers would print out reports with a lot of data, generating like 30 to 40 pages or more (we wasted a lot of paper in those days), and the pagination had to match exactly between the old format and the new format. And if it didn’t, I had to spend some time poring over the printout to find the exact point at which the pagination changed and what caused it. Eventually I learned a set of tricks and knew what to look out for when porting the reports
When you’re starting out as a software developer and you’re first introduced to the idea of QA or software testers, there’s a slight tendency to be offended or defensive about bug reports and to be a bit annoyed at the testers. After all, these are people whose job is specifically to find your errors! It’s a problem especially if you have a sense of pride about your work, but once you let go of that pride and recognize that you are not your code, you get to realize that you and the testers are working as a team. The testers are the shield that make sure that stupid stuff you missed or overlooked doesn’t get sent to the users. It’s like how in a buddy cop movie you need to have a partner to watch your back or to cover the other exit so that the bad guy doesn’t get away
After working with the same testers for some time you get used to their individual quirks and figure out which bugs they are more likely to find, so you start focusing on those areas more. You also learn some tricks to sometimes troll around with them especially when you get annoyed with too many bug reports
One of my favorite things early on in the same project was when I would send one of programs over for testing. In addition to the reports, often we would also be doing forms running using the same tool. In those days, we didn’t yet have Hudson or Maven or Ant any sort of automated build system. We would commit our source to version control and generate the binary file manually and copy the binary file over into a shared network drive. And there was no versioning on the network drive, just one folder where all the binaries were. Then we can tell the tester, hey you can test so-and-so program now
The tester would copy the binaries from the network drive to their own machines for testing, and after a while he would come back with some bug reports. The bug reports would be logged in an Excel file (we didn’t have any bug tracking software then either), and I would do a quick skim, and if the changes were easy enough (minor UI stuff), I’d do some quick edits, rebuild the binary, and copy it to the network drive. Then I would message the tester, pretending I’d just seen the bug reports, “Hey, these bug reports don’t seem right. I think you forgot to get the latest files from the drive.” And sure enough, they get the latest files and check again and the bugs would already be fixed. I managed to do this a couple of times before my tester caught on
With the advent of dedicated test servers and modern build scripts, of course this was something I couldn’t regularly do anymore – although once or twice I did have the opportunity to do a live edit on a test server (to verify my fix works) and troll the tester a bit by telling her it worked fine!
After a few months of working with testers, you quickly get used to working with them and get into a good rhythm. You’re kind of partners in crime, except instead of crime it’s quality in software programs. Even with modern developer unit-testing and automated testing practices, having a second set of eyes looking at your program and attacking it from different angles helps improve the quality of the system. A good tester is the shield to the developer’s sword, they make sure the developer keeps his guard up and doesn’t lose to his own mistakes
See Also