The development of software is considered a creative process, and as such entices creative people to the endeavour. Conversely testing is perceived as the inverse, and perhaps even as attempt the undermine the value of that creativity;
“Theory states that when an individual has access to the data necessary to perform the creative task at hand, when concentration is not broken by distractions, … ideas and solutions will suggest more ideas and solutions to successive steps of the creative process, in a rapid and orderly flow.”(Brady, 1986) For many developers this theory describes the primary source of satisfaction , they receive in doing their jobs. Anything that stops the flow, like testing, is considered in essence, a distraction. Lewis points out the perception that developers should not be the people that do their own testing, primarily because they already have a perception of the requirement and therefore cannot be completely objective (Lewis, 2004, p.54). Indeed many developers, including myself, have at times used this as an excuse not to develop tests saying “it’s someone else’s job”. Even Royce himself in his original paper on the Water Fall methodology “Managing the development of large software systems” paid homage to this sentiment; “Customer personnel typically would rather not pay for them, and development personnel would rather not implement them.”(Royce, 1970)
Today the world has changed with the advent of agile methodologies. These methodologies place an emphasis on productivity, and in doing so bring about the return of excitement for the developer by removing distraction and constraints. However part of most notable about these methodologies is the explicit inclusion of testing, to the extent that is developers are not writing tests then they are “not agile”. The psychology has been reversed test are not a point of honour and pride.
It has been my experience that this shift in perception is also benefiting other more formal Quality processes like Fagan Inspections. Whist my company does not actually use Fagan, we do perform Peer code reviews and these are becoming more acceptable and considerable less threatening as a direct result of the adoption of agile principles. Pair programming has been demonstrated to improve quality with increased in the number of unit tests passed by as much as 25% (Williams et al., 2000) primarily because of the simultaneous peer review.
None of this reduces the effectiveness of third party (non involved party) inspections and testing, which is inevitably more comprehensive(Lewis, 2004, p55) . It is my belief that software testing is in fact a different mindset of development, with development appealing to the creative and testing appealing to the inquisitive. Another, perhaps subjective, observation or impression I have noticed is that developers running scripts are more prone to taking short cuts when compared to professional testers..
Third party testing is the most comprehensive method. The tradition division between developers and testing is however declining with the advent of agile methodologies. The idea of the C is now rapidly becoming a reality. There is however a risk that the “responsible programmer” may be perceived as a cheap alternative rather than a complement for proper testing and quality assurance.
BRADY, J. T. (1986) A Theory of Productivity in the Creative Process. Computer Graphics and Applications, IEEE, 6, 25-34.[online] DIO: 10.1109/MCG.1986.276789 (Accessed: 15-02-2009)
LEWIS, W. E. (2004) Software Testing and Continuous Quality Improvement, New York, Auerbach Publications.
ROYCE, W. W. (1970) Managing the development of large software systems: concepts and techniques. Proceedings of the 9th international conference on Software Engineering.[online] DIO: ISBN:0-89791-216-0 (Accessed: 13-5-2007)
WILLIAMS, L., KESSLER, R. R., CUNNINGHAM, W. & JEFFRIES, R. (2000) Strengthening the case for pair programming. Software, IEEE, 17, 19-25.[online] DIO: 10.1109/52.854064 (Accessed: 15-02-2009)
