article or even in a long book.
Recently, on the scene have come the "Jim Dandy" agile warriors to the rescue. They say the code, the product, and people, are most important and that's that. We, the team, should focus by having everyone involved in the testing and coding as a complete product. Good point. The whole team must be made up of developers, testers, management, and users. But here is one problem with that idea. The industry developed all these other systems of languages, because having the "whole team" understanding and communicating the same way is not always possible.
In the early days of software, there was only binary code (0 or 1), and very few people could deal with them (how many of you have ever written a program in hex? I have). The very early days were probably very agile (one guy knew what to do and was the same person that coded 0 and 1). Back then, problems were simple and people were amazed with what could be done, and kept asking for more. With more functionality, came demands for more programmers. Not many people could deal with programming in binary. Because of this, we added levels of languages, which in turn added complexity and sophistication to programs.
Next we added yet more players: analysts, engineers, customer representatives, lawyers, managers, and the list goes on. Our history tells us there is a tendency in the agile world to evolve to complexity, and some might say towards chaotic systems. There are many environments where agile approaches will work, but the agile teams will constantly have to fight to keep things "simple." And, as we all know, there will be cases where some may fail to keep things simple and follow the agile principles.
But wait, we still produced products. What am I to do, crawl back into the caves and give up?
Life is better in many places because of software. This last statement is subject to many debates of course, but I believe it to be true, or I would not be working in the software industry. The modern world runs on software and the information it processes, even with the multihead quality monster, and the well-documented deficiencies of our industry (e.g., NIST studies). Most people would not give up software and the modern life that it is the language of. So this brings me back to why I test.
I Test to Investigate the Qualities of Software Products
In my view, quality can be both good and bad. A bug is a quality of the software, but not a good one. It is one of my jobs to help the team expose the errors. It is everyone's job to work software quality. I have heard of many teams where, once a bug escapes to the field, management blames software quality and testing. This is only a scapegoat. The reality is the whole team produced and then missed the bug.
I Use Test Techniques, Methods, Tools, and People, to Investigate Quality
I have worked in places where the whole team defines tests, requirements, designs, code, and other products that we place importance on, or we don't create the products. I was surprised years ago when I found projects that did not subscribe to agile ideas, and I was amazed when people felt they had to call these ideals something special like agile. Many Agile concepts are good and deserve consideration.
- I use formal processes when needed to keep myself and the team out of trouble (thanks to Watts Humphrey and Rex Black), because processes help "store"