La Mejor Manera de Probar

Esta es una presentación de Juan Gabardini sobre formas de hacer pruebas de manera Agile. Una version en texto está disponible en Software Guru.

http://softwareagil.blogspot.com/2011/01/la-mejor-manera-de-probar-en-agilesbsas.html

The best way to fix the Prius sudden-acceleration problem is by not fixing it.

Did I get your attention? Good!
Tonight's news included yet another case of a Prius sudden-acceleration problem, this time in San Diego where the driver ended up being assisted by a police officer who used his police car to stop the Prius by driving in front of it to slow it down to a stop. Toyota's engineers are really scratching their heads over this problem and that particular Prius is now being analyzed very thoroughly in hope to figure out the cause.

So, how to fix this problem? Probably Toyota's engineers already thought about what I am about to propose but here it goes anyway: do not fix the problem! Okay so, before those of you who are still reading on what I think should be done is two things:

• Verify the algorithm and its implementation. One very likely cause is the software that controls the car's acceleration and brake systems. If that is the case and engineers cannot find and fix the bug(s) then a better course of action would be to start from the beginning and (a) create a new algorithm, (b) analyze the algorthm quality as such, i.e. as an abstraction, (c) implement and test it simultaneously. Step (b) is extremely important because that is the best way to make sure the algorithm is robust. If we wait until implementation time to do testing then it will be harder to know if the problem is the algorithm itself or its implementation. I think this is the most viable, fast, and cost-effective course of action.
  
• Unit level testing is not enough. One well know problem with measurement, from the physics standpoint, is that any attempt to measure something will affect what is being measured and therefore the measurement will be inexact. This means that once the algorithm and its implementation are robust it will be more effective to test at subsystem and system levels instead of inisolation.
• Reproduce internal and external test conditions. The best way to reproduce a behavior is by recreating all conditions that triggered the undersired behavior. In addition to the car conditions this includes road, slope, weather, etc.

Building things anew might be a quicker and better way compared to trying to identify and fix what is wrong.

Book review: Agile Testing by Lisa Crispin and Janet Gregory

Agile testing is a great book to both new and seasoned test engineers and test managers. At 533 pages, the book might feel a bit heavy but it is actually a pretty light and practical read if you read it to get a solid foundation on agile testing and then as reference. Note that the book is not about test coding techniques.

Part I is an introduction to agile testing and proposes ten principles for agile testers. What I don't know is if there are really 10 principles or if Crispin and Gregory forced it to be that specific number because it sounds better than 9 or 11. In any case, this chapter is a must read for all. Part II discusses organizational challenges, specifically cultural, logistical, and transitional from typical processes. This is a must-read for managers and team leads, and highly advisable for engineers if you want to have a successful test organization fully integrated with an agile organization. I personally encourage the division between development and testing to disappear completely. Part III is about he testing quadrants proposed by Brian Marick (one of the Agile Manifesto signatories) a while back. This is the first time I see the quadrants treated in larger detail and highly recommend it as a must for all.

Part IV is about test automation. It is a good read to understand the advantages of test automation and proposes a test automation strategy. This is a good starting point for test organizations that are new to automation but for mature test automation organizations it might add little value. Test code writing techniques are beyond the scope of this book. Part V illustrates the previous parts and then some by following a tester's activities through an agile iteration and the activities prior to it.

One problem I see way too often in test organizations and the way companies treat their test organizations is due to a lack of understanding not only of the difference between Quality Assurance and testing but also because of the place testing has hi people's minds. This book is a big help to create a cultural shift for the better.