Five Questions With John N. D'Addamio

John N. D'Addamio has a bit of experience in the computing world...thirty-five years of it or so. Once upon a time he was working towards a PhD on operating system security. He never finished, though, because he decided that his subject was in fact an oxymoron. So he left academia and found a series of positions which recompensed much better than a doctorate ever would have. Positions liking developing in assembly on IBM 360 and 370s. Positions like developing, testing, and leading programming efforts on Unix. And, most recently, positions like testing for Microsoft, where he tests tools which Microsoft plans to release as open source.

Here is what John has to say:

DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
JND: Every programmer’s first introduction to testing is running the code they wrote for class assignments! I was lucky enough to have an instructor who talked about the basics of testing and debugging along with teaching the language. At the time, I thought testing was more of an art than a science. I also thought similarly about coding and debugging. While some people are more adept at one of the three tasks than others, there is now enough good information that any professional programmer should be able to do a good job at all aspects of our job.

DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
JND: The relatively poor set of test tools available for automated testing of GUI applications is surprising. Whether you are talking about web applications with a client-server model or locally installed applications, there is not much that is widely available either commercially, free binary only, or open source.

DDJ: How would you describe your testing philosophy?
JND:

1. Plan a minimal number of tests necessary to cover all the application’s functional requirements. Ideally, these requirements should be in a spec but, all too often, the tester has to pull them together from emails, meeting notes, etc.


2. Prioritize the implementation of tests so that the most important get done first.


3. Automate as many tests as possible given the testing tools available to you.


4. After all the application’s functional requirements have been tested, use code coverage tools to identify untested code in the application. You will usually find a combination of gaps in the test suite and some unnecessary application code.

DDJ: What do you think is the most important thing for a tester to know?
JND: Testers have to know how to work with developers in a collaborative rather than an adversarial way.

DDJ: To do?
JND: Pay attention to details and requirement combinations! Of course, we have to keep the “big picture” in mind while testing but the details of behavioral requirements (especially in combination) are usually where you find problems.

DDJ: For developers to know and do about testing?
JND: Developers have to be able to write good unit tests. Two reasons: good unit tests will eliminate a lot of bugs before the test team gets the application and good unit tests allow the test team to concentrate on integration and scenario level tests. The net result of both effects is the team turns out a higher quality product if the developers provide unit tests along with their application code. Obviously, test driven development can provide huge advantages for both the developers and testers. The difficulty is often getting management to accept the idea because they see a longer development schedule than they would like.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
JDN: I think the biggest challenge for the test discipline is the same as the single biggest challenge for software industry in general. We have to find a balance of planning, documentation, development and stabilization (including testing and bug fixes) that makes sense. Large segments of the industry spend very little time on planning. We often just start writing code at a vague or moving set of requirements and then spend most of our time fixing bugs and rewriting the code to meet the unexpected requirements. The technical documentation needed for maintenance is usually neglected. On the other extreme, we have projects that are written for the federal government including the various branches of the military. These projects usually have such rigid planning and documentation requirements that senior programmers spend as much as two thirds of their time on the project doing planning and documentation. Of course, this shortens the coding and stabilization phases as well as providing good documentation for maintenance efforts. Neither model is ideal for the software industry at large so our challenge is to find a balance that actually works well.

Posted by The Braidy Tester at 07:30 AM  Permalink