Quotes on Software Testing: Load Testing, Unit Testing, Functional Testing
One of the most common mistakes that teams made was treating specifications or related automation code as less important than production code. Examples of this are giving the automation tasks to less-capable developers and testers and not maintaining the automation layer with the same kind of effort applied to production code. Reference: “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning, 249 pages, IBSN 978-1617290084
A test is not a unit test if: * It talks to the database * It communicates across the network * It touches the file system * It can’t run at the same time as any of your other unit tests * You have to do special things to your environment (such as editing config files) to run it.
Defects are not so much a technological as a sociological problem. So the measures we take to control them can be expected to lie largely in the sociological plane, affecting the structure and organization of projects, the allocation of goals, and the fostering of new attitudes. Tom DeMarco, “Controlling Software Projects”, Yourdon Press
As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications. Dave Parnas, Communications of the ACM (33, 6 June 1990 p.636)
“We define an agile tester this way: a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development. Agile testers tend to have good technical skills, know how to collaborate with others to automate tests, and are also experienced exploratory testers. They’re willing to learn what customers do so that they can better understand the customers’ software requirements.” Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley, 2009
Over the years I have come to describe Test Driven Development in terms of three simple rules.
“Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured.”
