To many, software testing may seem a boring and unimpressive subject. We speak of ‘software development’, an integral part of which is testing, but when most people think of who does ‘software development’ they think of programmers, not testers. In other words, in application development, testing can have a relatively low status.
To my way of thinking, it concerns me that perhaps people in software testing get so focussed on testing methods, that they forget that ideally there would be no need to test because software would be built without defects. Therefore, of course, we must always be thinking about how we can avoid defects in the first place. Comically, to a degree, the introduction of defects is in the financial interest of testers and testing companies. Think of how much less effort would have to be devoted to testing if numbers of defects dramatically decrease! If this were to occur generally, imagine the concern of vendors of user interface automation tools! Some might argue that I’m too idealist, but it is illogical to aim for less than perfection. You will never get there, but that must be your goal.
To get to a more specific testing subject: I wanted to discuss testing within the now ubiquitous Agile methodology. Agile makes a lot of sense to me as it recognises realities such as:
• Attempting to document all the low-level requirements for a project upfront is a largely a waste of time. A great many obstacles and opportunities only become apparent as the software is developed.
• Development is unpredictable, and really accurate estimates of time and effort needed can only be given for small pieces of work.
• Developers and testers should mainly manage themselves: they are doing the work; they generally know the best way to do it. And people want to be efficient; no-one likes feeling that they’re wasting their time.
• When people working on complex projects are physically close to each other and verbally communicate a lot, they’re far more efficient and effective than if they don’t.
However, I think some of the ways that people think Agile should work are just plain wrong. For example, that you do not document detailed requirements, but rather these are agreed upon in collaborative meetings, and that testers’ acceptance test cases developed as a result of these meetings effectively become requirements. This may happen, but I think it’s a very bad way to go. Requirements and test cases are very different, and need to be documented in very different formats. Business analysis and testing are different roles, with different skill sets. Testers should not effectively become business analysts. A correct Agile process says that, yes, don’t develop detailed requirements upfront for the entire project, but you do develop detailed requirements for relatively small pieces of functionality. Of course, there is and must be a role for business analysts in development, be it Agile or otherwise.
Don't Test 