What Programmers Have to Know About Testing
- Jan 11, 2010
From the author of
Programmers as Testers
I consider myself lucky: I started out as a developer who learned the testing process. Back in my first days of programming, we didn't have "testers" on our team. Programmers were expected to test their own code, and they were held accountable for fixing software defects that they introduced, as well as any schedule delays that resulted from lack of testing. When I started my first job after my university graduation, my supervisor walked through my testing strategy with me on every new piece of functionality, and then again when it was time to look at the test results. He asked questions, and he made me go back and do more testing until he was confident that I knew what testing was all about. I guess he was responsible for my coming to understand the importance of testing my own work. (Thanks, Rob!)
This was back in 1992, in the days of COBOL. We had no concept of automated unit tests, so all our testing was done manually. I can only imagine how stable my code would have been if I could have automated all those tests! We were coding for a stock exchange and clearing system, so our code had to be pretty solid; a lot of financial transactions would pass through our software. We didn't have actual customers doing testing, but the company's support and implementation team performed the acceptance testing on their behalf.
Because I was trained to be accountable for my code, it was easy for me to turn my attention to testing, and I learned from experience that you cannot "test in" quality. Not every programmer today has that luxury.
